Re: Old application/atom+xml issues

[Robert Sayre]

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. :/

Robert Sayre

Re: Old application/atom+xml issues

[Mark Baker]

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

Re: Old application/atom+xml issues

[Bill de hÓra]

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

Re: Old application/atom+xml issues

[Sam Ruby]

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

Re: Old application/atom+xml issues

[Mark Baker]

On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> The most we can do is to say that such things are invalid, and to work 
> with the producers to correct this.

Sounds good to me.

> 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).

Nice.  Thanks for your vigilance, Sam.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.  http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Re: Old application/atom+xml issues

[Bill de hÓra]

Mark Baker wrote:
> On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> 
>>The most we can do is to say that such things are invalid, and to work 
>>with the producers to correct this.
> 
> 
> Sounds good to me.
> 
> 
>>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).
> 
> 
> Nice.  Thanks for your vigilance, Sam.

What Mark said. Now, that's the world as it might be outside the spec.
There is still proposed spec text, which I suggest is amended as follows:

[[[
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. Such feeds SHOULD be
considered invalid Atom 1.0.
]]]

cheers
Bill

Re: Old application/atom+xml issues

[Bill Kearney]

> [[[
> 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. Such feeds SHOULD be
> considered invalid Atom 1.0.
> ]]]

Seems reasonable.  When 1.0 goes final we'll be flipping the switch on
Syndic8 to start requiring it for a valid listing.  Not en-masse but in
pretty short order.  No sense "freaking anyone out" but we're not going to
go coddling things for very long.  Besides, all this is code or template
driven and is often quite easy to update.  It's being firm about pushing the
various things to update that's necessary.  And NOT wasting inordinate
amounts of time and message threads whinging about popular tools or sites
that "can't" be updated.  Tough, get with it.

-Bill Kearney
Syndic8.com

Re: Old application/atom+xml issues

[Robert Sayre]

> What Mark said. Now, that's the world as it might be outside the spec.
> There is still proposed spec text

There are also draft-05, draft-06, draft-07, draft-08, and draft-09
feeds in the wild, being produced by people who aren't WG members.
There are RSS feeds served as application/atom+xml.

All of these things are obviously invalid Atom 1.0, and MUST be
considered so, as they do not reside in the correct namespace. Someone
who's read the spec is in no danger of mistaking an Atom 0.3 feed for
an Atom 1.0, and no software that bothers to check the namespace of
the root element will be fooled.

I worry that any statement like Bill's suggested text will confer
legitimacy on Atom 0.3 as long as the RFC is available. *Every*
current implementor is aware of the issue, so the short term benefit
of such text is pretty much nil. Long term, the text will actually be
harmful.

So, -1 to mentioning Atom 0.3 at all.

Robert Sayre

Re: Old application/atom+xml issues

[Sam Ruby]

Robert Sayre wrote:


So, -1 to mentioning Atom 0.3 at all.


I agree with Robert.

Note how Atom 0.2 isn't a problem at all...  we can (and will) do the 
same thing with Atom 0.3.


- Sam Ruby

Re: Old application/atom+xml issues

[Bill de hÓra]

Robert Sayre wrote:

> I worry that any statement like Bill's suggested text will confer
> legitimacy on Atom 0.3 as long as the RFC is available. *Every*
> current implementor is aware of the issue, so the short term benefit
> of such text is pretty much nil. Long term, the text will actually be
> harmful.

+1 to this sentiment - I take it this means we're saying no to the
interop text in the spec?

Re: Old application/atom+xml issues

[A. Pagaltzis]

* Bill de hÓra <[EMAIL PROTECTED]> [2005-07-11 17:55]:
> [[[
> 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. Such
> feeds SHOULD be considered invalid Atom 1.0.
> ]]]

-1 first and foremost because of the SHOULD. I don’t see how
anything less than a MUST can be justified. Even if that was
changed, though, -1 anyway.

The only reason we’ll probably have 0.3 feeds in the wild for a
while to come is that MovableType users seem to be upgrade-lazy.
(I still frequently encounter MT 2.x installs with x as low as 5,
whereas I don’t remember the last time I stumbled across a site
still running WordPress <1.5.) Most everyone else who did not
craft their feed themselves will have it taken care of either by
their host or by their vendor’s next release, and those who craft
it themselves will fix it in short order anyway. (I know I intend
to as soon as my aggregator can eat it, and their effort for that
is already underway.)

However, the likelihood for sites with old MT installs to be
offering *only* an Atom 0.3 feed but no RSS (1.0|2.0) feed is
vanishingly small anyway, so even if all aggregators dropped
support for 0.3 tomorrow, very few people would actually be
affected worse than having to resubscribe some sites.

The worst to happen with an aggressive deprecation strategy is
that there’ll be a somewhat annoying transitory period of a few
months before aggregators and producers all support the new spec
in unison.

So in light of these and Robert’s arguments, there’s no apparent
reason to attempt to interoperate.

Regards,
-- 
Aristotle Pagaltzis //