RE: [xri-comment] XRDS media type

["Manger, James H" <James.H.Manger@team.telstra.com>]

>> 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