>> 1. Define separate media types for <XRDS> and <XRD> -- I suspect it will be helpful in the long run (as per Atom/APP experience).
> Any suggestions? I feel uncomfortable having two different formats use application/xrds+xml, but it's an option. Is there a good precedent for this?
"application/xrdseq+xml"?
>> 2. Add a sentence to the spec explicitly stating that the “application/xrd+xml” media type can be used for both <XRDS> and <XRD>.
>> 3. Wait until it is needed then define a type parameter as per APP.
> This is my preference, since APP sets the precedent. Why do you prefer 2 to 3? How about specifying types for xrds, xrd and link now?
A "type" parameter feels like a hack when its too late (for backward compatibility) to specify separate media types. Perhaps it works ok most of the time. I am not sure. I haven't had enough experience with APP. I am not sure a type parameter works in an HTTP Accept header, for instance.
We don't need type=link. The XRD Provisioning spec could use complete <XRD> elements and merge the contained <Link>s (or <Property>s) with the existing <XRD> -- probably with the new PATCH method [RFC5789] (instead of POST, and certainly instead of misusing PUT).
--
James Manger
