Subject: Old application/atom+xml issues

From: Mark Baker <[email-masked]>
Date: Tue, 5 Jul 2005 10:03:14 -0400

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.

These are not show-stoppers by any means, but are also not exactly
insignificant IMO.

The comments are;

http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000713.html
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html

(the former was sent to the IESG, but again, I received no feedback)

Cheers,

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 5 Jul 2005 10:33:00 -0400

> 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

---

From: Mark Baker <[email-masked]>
Date: Tue, 5 Jul 2005 12:22:13 -0400

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

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Jul 2005 09:08:25 +0100

> 	 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

---

From: Sam Ruby <[email-masked]>
Date: Mon, 11 Jul 2005 09:59:19 -0400

> 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

---

From: Mark Baker <[email-masked]>
Date: Mon, 11 Jul 2005 10:45:44 -0400

> with the producers to correct this.

Sounds good to me.

> will change this to an error).

Nice.  Thanks for your vigilance, Sam.

Mark.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Jul 2005 16:41:21 +0100

> 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

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 11 Jul 2005 13:10:28 -0400

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 11 Jul 2005 14:05:26 -0400

> 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

---

From: Sam Ruby <[email-masked]>
Date: Mon, 11 Jul 2005 15:25:02 -0400

> 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

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Jul 2005 20:58:42 +0100

> of such text is pretty much nil. Long term, the text will actually be

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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 12 Jul 2005 21:19:53 +0200

* Bill de hÓra <[email-masked]> [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 // <http://plasmasturm.org/>