Subject: Re: Profile Media Type Extension

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 14:51:08 +1000

Ah, fond memories:
   http://intertwingly.net/wiki/pie/PaceProfileAttribute

Putting it in as a media type parameter is interesting, but I think it  
needs to be in the document as well.

What I *really* think we need to do is define the current use of Atom  
as a profile (which is what I suggested many years ago), so that use  
cases that don't require an updated element, or a title element, etc.,  
don't have to have one that carries useless -- or worse, misleading --  
information.

However, doing that would likely require defining a new namespace and  
media type for Atom, since doing so wouldn't be backwards-compatible.

Personally, I think it's worth it, provided we can find enough other  
clarifications/fixes to bundle in to make a new namespace attractive  
enough.

Cheers,

P.S. Using RFC#### as a convention effectively prevents any recognised  
standards org from building on top of Atom in this fashion; use a  
registry. Also, it will doubtless lead to the dreaded RFC10K problem...

On 13/06/2009, at 8:52 AM, James M Snell wrote:

>
> Well, the second half of my work week ended up getting preempted by  
> a stupid primary development workstation that decided to go kaput on  
> me so I have not yet had the opportunity to write up the Profile  
> media type extension spec. While I'm waiting for the last few apps  
> to download so I can reinstall them, I figured it would at least be  
> helpful for me to write up my thoughts and I'll get the draft  
> published next week.
>
> Basically, a "Profile" is going to be some kind of document that  
> provides implementation guidelines for an Atom app. It will define a  
> specific use of Atom along with whatever extensions, assumptions,  
> options, etc necessary for that.  For instance, one could easily  
> imagine a "Blogging" profile for Atom that describes in detail how  
> to use the Atom publishing protocol specifically for Weblogs, etc.
>
> Every Profile document will be associated with an identifier.  The  
> identifier is either a short name or an IRI following the same  
> pattern as atom:link/@rel values. However, use of the short names  
> will be restricted and must follow a strict convention...  
> Specifically, only Profiles published through the IETF process will  
> be allowed short names.  For a Profile published as an Internet- 
> Draft, the profile identifier is the document name. For instance,  
> given a theoretical draft-snell-profile-blogging-01.txt, the  
> identifier for the Profile is "draft-snell-profile-blogging-01".   
> For a Profile published as an RFC, the project identifier is the  
> RFC# in the pattern "RFC####". The shortnames are always case- 
> insensitive so "rfc9999" is equivalent to "RFC9999" or "Rfc9999",  
> etc.  For all other Profiles, the identifier is an absolute IRI that  
> SHOULD be dereference-able to retrieve the Profile document.
>
> In all Atom media types, the profile parameter is an optional  
> quoted, whitespace delimited list of profile identifiers, e.g.
>
> application/atom+xml;
>   profile="RFC9999
>   draft-snell-profile-blogging-01
>   http://example.org/profile/foo"
>
> Someone looking at this media type can determine that the Atom  
> document in question conforms to three profiles identified by  
> "RFC999", "draft-snell-profile-blogging-01", and "http://example.org/profile/foo 
> ". What "Conformance" means depends entirely on the profile.
>
> The profile parameter is intended only as a hint. An application can  
> use it to help make decisions about a linked resource, etc but the  
> presence of a particular profile identifier in the media type does  
> not place any obligations on the application.
>
> As always, comments are requested and welcomed.
>
> - James
>

--
Mark Nottingham     http://www.mnot.net/