[ 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