On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote:
> On 7/5/05, Mark Baker <[EMAIL PROTECTED]> 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

Reply via email to