Re: Old application/atom+xml issues
On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote:
On 7/5/05, Mark Baker <distobj@acm.org> wrote:
I wanted to point out that comments I've made on the application/atom+xml media type registration template have not yet been incorporated into the syntax draft, nor have I received any feedback about why they needn't be.
See comments from Tim here: http://www.imc.org/atom-syntax/mail-archive/msg14423.html
Sorry you didn't get direct feedback. :/
Ah, I should have thought to check the archives, thanks. It should have gone to ietf-types though, since that's where public review of media type registrations happen and where my comments were sent. I've CCd ietf-types on this message. Tim writes;
He's got a point on the namespace being mentioned, which creates some semi-circular dependencies, sigh. As to whether it's currently in use, largely due to lobbying from us, recent releases of both Apache and IIS tie the application/atom+xml media type to the .atom extension, so if people are creating 0.3 files and calling them whatever.atom, this could be right. Having said that, I think we should push back. Because any such current usage is unlicensed by any spec, & because we plan to aggressively deprecate Atom 0.3 once we get 1.0 out and since I suspect that 90% of 0.3 feeds come from one place we should have some success.
IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the "interoperability considerations" section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. As for the magic number, to keep it simple I'd suggest that none be defined by removing the "magic number" section. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Mark Baker wrote:
IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the "interoperability considerations" section of the template. Something like;
Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0.
In the spirit of that point about 0.3 being served with the media type being an interop issue - what are the behaviors which will lead to interoperation? The above text is only leads one to ask "and I should do what here?" and doesn't say anything useful about what to do. cheers Bill
Bill de hÓra wrote:
Mark Baker wrote:
IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the "interoperability considerations" section of the template. Something like;
Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0.
In the spirit of that point about 0.3 being served with the media type being an interop issue - what are the behaviors which will lead to interoperation? The above text is only leads one to ask "and I should do what here?" and doesn't say anything useful about what to do.
I'll also point out that there are atom 0.3 feeds being served with a mime type of text/html. And undoubtably there will be atom 1.0 feeds so served. The most we can do is to say that such things are invalid, and to work with the producers to correct this. The majority of the existing atom 0.3 feeds are produced by a relatively few producers. I am confident that these producers will convert over quickly. I am also committed to getting the word out quickly that atom 0.3 feeds are not to be considered valid. In particular, I plan to update the feedvalidator to note this as a problem (first as a warning, and later I will change this to an error). - Sam Ruby
participants (3)
-
Bill de hÓra -
Mark Baker -
Sam Ruby