For review: application/atom+xml

[Mark Baker]

[ CC: IESG, since I suppose this counts as a last call comment ]

Mark,

Congrats on going to last call with the atompub format! -

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

But I note that my comment[1] on the lack of any mention of the existing
use of application/atom+xml with the incompatible Atom 0.3 content
didn't make it in.  Though not widespread, my understanding (though I'd
be happy to be corrected!), at least at the time that you first drew up
this media type[2], was that it was in use[3].  I certainly don't feel
that this is a big enough problem to warrant a new media type, but I do
think it should be flagged to implementors.

Also, I noticed something else that I missed my first time through ...

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Additional information:
> 
>    Magic number(s): As specified for "application/xml" in [RFC3023],
>       section 3.2.

Based on my understanding of the purpose of magic numbers, I think
referencing another spec's magic number algorithm to be prima facie
incorrect.  What I think should be there is information that, as
uniquely as possible, identifies Atom documents, and RFC 3023 can, of
course, only help with identifying XML documents.  So I'd suggest either
adding something about the root namespace value (if indeed the spec
requires that the root element always be from the Atom namespace?) as I
did for XHTML[4], or else just saying "Magic Number: None" (as we did
for SOAP[5], in effect, by not providing an algorithm).

Cheers,

 [1] http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html
 [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
 [3] http://diveintomark.org/archives/2003/12/13/atom03
 [4] http://www.ietf.org/rfc/rfc3236.txt
 [5] http://www.ietf.org/rfc/rfc3902.txt

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca