OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: [xri-comment] RE: XRDS media type


Mary,

Can you please advise how to handle the media type registration?

Thanks,

EHL

-----Original Message-----
From: Jonathan Rees [mailto:jar@creativecommons.org] 
Sent: Thursday, June 10, 2010 5:03 PM
To: Eran Hammer-Lahav
Subject: Re: [xri-comment] RE: XRDS media type

I think the style now preferred by IETF is to include the media type registration as a section in the spec that defines the syntax and semantics of that file type. E.g. see the http: URI scheme registration in RFC 2616, and the draft text/html media type registration in the draft HTML(5) spec.

IETF has a list of organizations that are trusted to do this, and W3C is one of them. Don't know about OASIS.

I don't know the 'chapter and verse' for this, but you might want to check.

FWIW.

Jonathan

On Thu, Jun 10, 2010 at 11:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> We decided to drop the appendix and deal with this issue when we 
> register the media type. This way the spec can move forward.
>
> EHL
>
>
>
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Sunday, June 06, 2010 6:21 PM
> To: xri-comment@lists.oasis-open.org; jaredhanson@gmail.com
> Subject: [xri-comment] XRDS media type
>
>
>
> XRD v1.0 CD02 defines the “application/xrd+xml” media type.
>
> Presumably this can be used when the content is an <XRD> element.
>
>
>
> The doc also defines an <XRDS> element.
>
> Is the same media type supposed to be used when the content is an 
> <XRDS> element?
>
>
>
> I notice there is some work (outside OASIS) on “XRD Provisioning”
> (http://xrdprovisioning.net/).
>
> Draft 01 of that work reuses “application/xrd+xml” when the content is 
> a <Link> element.
>
> This must be wrong.
>
>
>
>
>
> Atom [RFC 4287] defines “application/atom+xml” for both <atom:entry> 
> and <atom:feed> documents.
>
> I suspect that is now considered a poor (but irreversible) choice.
>
> The subsequent Atom Publishing Protocol [RFC 5023, section 12] defines 
> a “type” parameter to go with the media type to distinguish the two 
> type of
> document: “application/atom+xml;type=entry” and 
> “application/atom+xml;type=feed”.
>
> The APP spec says:
>
>   “The Atom Syndication Format [RFC4287] defines the "application/
>
>    atom+xml" media type to identify both Atom Feed and Atom Entry
>
>    Documents.  Implementation experience has demonstrated that Atom 
> Feed
>
>    and Entry Documents can have different processing models and that
>
>    there are situations where they need to be differentiated.  This
>
>    specification defines a "type" parameter used to differentiate the
>
>    two types of Atom documents.”
>
>
>
> An <atom:feed> is basically a collection of <atom:entry>s, hence the 
> strong analogy to <XRDS> and <XRD>.
>
>
>
> My suggestions, from most preferred to least:
>
> 1. Define separate media types for <XRDS> and <XRD> -- I suspect it 
> will be helpful in the long run (as per Atom/APP experience).
>
> 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.
>
>
>
> --
>
> James Manger
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]