For review: application/atom+xml
One of the deliverables of the ATOMPUB WG is an xml-based format for Web syndication. Please review the proposed "application/atom+xml" media type therein; the registration template can be found below, and the complete draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt Regards, ---8<---- An Atom Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application MIME subtype name: atom+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. [[anchor59: update upon publication]] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. [[anchor60: update upon publication]] Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. File extension: .atom Fragment identifiers: As specified for "application/xml" in [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot@pobox.com> Intended usage: COMMON Author/Change controller: This specification's author(s). [[anchor61: update upon publication]] --->8--- -- Mark Nottingham http://www.mnot.net/
Mark, One thing I didn't catch earlier (sorry): the change controller for types in the standards tree MUST be the IESG. It would be more appropriate to say it's the IETF community as described in RFC 2048 and the documents that will soon obsolete 2048, but the IESG is the standards process gatekeeper so that's what we've been using. We've also accepted text where people have said something like "The <foo> working group as designated by the IESG". -Scott-
-----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net] Sent: Wednesday, April 06, 2005 11:41 PM To: ietf-types@alvestrand.no Subject: For review: application/atom+xml
One of the deliverables of the ATOMPUB WG is an xml-based format for Web syndication. Please review the proposed "application/atom+xml" media type therein; the registration template can be found below, and the complete draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
Regards,
---8<---- An Atom Document, when serialized as XML 1.0, can be identified with the following media type:
MIME media type name: application MIME subtype name: atom+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. [[anchor59: update upon publication]] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. [[anchor60: update upon publication]] Applications that use this media type: No known applications currently use this media type.
Additional information:
Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. File extension: .atom Fragment identifiers: As specified for "application/xml" in [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot@pobox.com> Intended usage: COMMON Author/Change controller: This specification's author(s). [[anchor61: update upon publication]] --->8---
-- Mark Nottingham http://www.mnot.net/
Will get this in -08 and re-circulate when it's ready. Thanks, On Apr 7, 2005, at 4:45 AM, Scott Hollenbeck wrote:
Mark,
One thing I didn't catch earlier (sorry): the change controller for types in the standards tree MUST be the IESG. It would be more appropriate to say it's the IETF community as described in RFC 2048 and the documents that will soon obsolete 2048, but the IESG is the standards process gatekeeper so that's what we've been using. We've also accepted text where people have said something like "The <foo> working group as designated by the IESG".
-Scott-
-----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net] Sent: Wednesday, April 06, 2005 11:41 PM To: ietf-types@alvestrand.no Subject: For review: application/atom+xml
One of the deliverables of the ATOMPUB WG is an xml-based format for Web syndication. Please review the proposed "application/atom+xml" media type therein; the registration template can be found below, and the complete draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
Regards,
---8<---- An Atom Document, when serialized as XML 1.0, can be identified with the following media type:
MIME media type name: application MIME subtype name: atom+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. [[anchor59: update upon publication]] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. [[anchor60: update upon publication]] Applications that use this media type: No known applications currently use this media type.
Additional information:
Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. File extension: .atom Fragment identifiers: As specified for "application/xml" in [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot@pobox.com> Intended usage: COMMON Author/Change controller: This specification's author(s). [[anchor61: update upon publication]] --->8---
-- Mark Nottingham http://www.mnot.net/
-- Mark Nottingham http://www.mnot.net/
Mark, I think you might want to mention somewhere - probably under Interop considerations - that application/atom+xml is already in use today with "Atom 0.3", which is incompatible (AIUI) with the new atompub syntax draft. Cheers, Mark. On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
Interoperability considerations: There are no known interoperability issues. [snip]
-- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
[ 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
participants (3)
-
Mark Baker -
Mark Nottingham -
Scott Hollenbeck