Re: Shipping Atom products prematurely

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

At 3:19 PM -0400 8/17/04, Robert Sayre wrote:
> As I understand it, the roadmap looks like this:
>
> Atom 0.3
> draft-ietf-atompub-00
> draft-ietf-atompub-01
> ...
> draft-ietf-atompub-NN
> Atom 1.0

Yes.

> I believe that the goal is for there not to be another widely 
> implemented draft until Last Call.

No! We do not want wide implementation until after the IESG approves 
of draft-ietf-atompub-NN. There are many reasons for this:

- Having a dozen set of eyes with lots of protocol experience looking 
at the document often uncovers actual protocol errors that we just 
never noticed because we got too used to them.

- They may say "this doesn't work the IETF way, but it would be fine 
if you change it to that way" and we make the change

- They sometimes ask a really good question about a particular 
feature, and in our answering the question we fix something unclear 
in the document, and in doing that we find two pre-implementers who 
disagree, and we need to decide what "we" "really meant".

When the IESG sends -NN to the RFC Editor for publication, -NN 
becomes 1.0. We can even have a special half-step in there where the 
IESG says "we're fine with this draft except for the cruddy version 
number wording, so change that and off it goes." The editors do the 
final change and everyone knows that the new draft is Really It.

>  Perhaps the chairs and secretary should explain this in more detail 
> (I believe they have, I can't remember where to look).

It's not well-documented anywhere. This might go into a new version 
of the Tao of the IETF, of which I am also co-author...

> My question is whether Mark N's proposal includes Atom 0.3. It's too 
> late for that, IMHO. Aggregator authors have told us that consumers 
> consider clients that don't support Atom 0.3 to be broken.

Fully agree.

We all have to live with the fact that Atom 0.3 is akin to RSS 0.9. 
Eventually, almost no creator software will emit it, but it will 
probably live on in reading software forever. The Internet is 
littered with such cases. For instance, most web browsers can still 
read Gopher sites even though almost no one has created one in over 
seven years.

Atom 0.3 had its purpose: it gave people something to talk about and 
look at before the Atom community came into the IETF. It showed that 
things were possible. It showed where there was massive disagreement. 
Atom 0.3 will exist forever, just like RSS 0.9 will.

It is not hard for us to prevent anything before Atom 1.0 to be 
deployed. The drafts are really clear about not implementing them. 
The folks on this list are really clear that we don't want them 
implemented. So far, we have been 100% successful in not having the 
drafts be implemented in an externally-visible way, and I don't see 
why that will stop until we tell the world "We think it's fully 
baked, and the IESG thinks it is fully baked, and we now have a 
reasonable version number and/or namespace, so now you can implement."

--Paul Hoffman, Director
--Internet Mail Consortium