Subject: PROCESS QUESTION: are we done yet?

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 May 2005 12:02:49 -0700

Wearing my co-chair hat:

We had a WG Last Call. It brought out a lot of issues, and we dealt 
with each of them (not always to the satisfaction of the person who 
brought up the issue, of course).

We had an IETF-wide Last Call. It brought out a lot of issues, and we 
dealt with each of them (not always to the satisfaction of the person 
who brought up the issue, of course).

New issues for the format spec are now being brought up, issues that 
existed *before* the WG Last Call, much less the IETF-wide Last Call. 
The IETF process allows for this. If we make any technical changes 
after the IETF last call is over (that is, weeks ago), we will 
probably have to go through an IETF Last Call again. Good engineering 
design allows for this. Many of us work for, or have worked for, 
companies whose product ship dates slipped for months or even years 
as improvements were made before shipping 1.0.

Rob and Mark are nearly done with the version of the draft that 
answers IETF Last Call issues. Tim and I planned on taking that to 
the IESG as soon as it was published.

HOWEVER, since it is clear that many people in the WG want to 
continue to add or change technical features in the document, we need 
to decide NOW what the process should be.

Does the WG want to be able to open up new topics, or re-open old 
topics with a twist? If so, do we all agree to the delay in 
publication that comes with that? Also, how long should this opening 
and re-opening last? Are there any limits on which parts of the spec 
we are willing to change?

These are serious questions. No one will be surprised that Tim and I 
want to follow the normal process and finish with the results of the 
IETF-wide Last Call, nor that we dread the idea of the WG opening new 
issues that could have been dealt with long ago and reopening issues 
that were actively closed. We are here to serve the Working Group, 
and if the Working Group wants a significant delay in finishing the 
spec, we can (probably grumpily) ask Scott for that change to our 
charter if there is rough consensus in the WG that that is what you 
want.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 05:35:49 +1000

On 21/5/05 5:02 AM, "Paul Hoffman" <[email-masked]> wrote:

> continue to add or change technical features in the document,
> we need to decide NOW what the process should be.

maybe it's time for all of us to take the draft we have, take it away from
the table, and do some real-world code implementations with real-world data.

take a break to breathe.

get some perspective before we lock ourselves in.

let the embers die down a bit ;-)

e.

---

From: Graham <[email-masked]>
Date: Fri, 20 May 2005 21:38:46 +0100

On 20 May 2005, at 8:02 pm, Paul Hoffman wrote:

> publication that comes with that? Also, how long should this  
> opening and re-opening last? Are there any limits on which parts of  
> the spec we are willing to change?

I think the last deadline was premature and totally out of sync with  
the WG, and if anything is responsible for the delay, because of the  
temporary cessation of new Paces. There probably needs to be one more  
round of discussion on recent changes like duplicate IDs, but  
everything else seems finished. I think there will be a natural  
ending soon enough.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 17:20:29 -0400

> > the spec we are willing to change?

I think we're done. The multiple IDs issue was raised in last call and
we need to resolve the wording. Everything else is fine.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Fri, 20 May 2005 23:42:10 +0100

Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote:

> publication that comes with that?

What would the minimum delay be out of interest?  4 weeks?  6 weeks?

> Also, how long should this opening

I'd be more comfortable with another round. A major motivation of Atom
was to avoid the ambiguities of RSS, so we'd better not have any
ourselves. I have some concerns about these issues still:

a) PaceAllowDuplicateIDs was made after Last Call and is a pretty
fundamental change to the Atom model. Its effect, that entries can
have multiple instances, is an invention that none of the RSS specs
cover. I think that we're rushing this without having time to think
what effects it might have. (I'm basically in favour of it, but I
think that it needs a bit more thought). I think that the debate on
atom:version/atom:modified was curtailed prematurely (within 3 days)
and should be re-opened.

b) Hopefully we wouldn't try to add new features to Atom if we did
another round, but allowing multiple authors seems to have some merit
to it. The current text inhibits multiple authors being described even
by extensions. Hopefully we can get a minimal base that would allow
multiple authors to be described, deferring as much as we can to
extensions.  Robert Sayer's suggestion looked promising, but
inheritance issues would need to be considered.

And a few issues that are probably editorial:

c) The language introduced by PaceAllowDuplicateIDs implies important
properties of entries that ought to be made explicit. Throwing the
word "revision/version/whatever" into the spec somewhere would make
things clearer, and would be a useful vocabulary term for people who
plan to write further specifications for extensions etc. (In the same
way that Jeff Mogul's paper, "Clarifying the Fundamentals of HTTP" [1]
defines the term "instance" for HTTP in a way that gave a basis for
RFC3229 - "Delta encoding in HTTP" [2]

d) The MIME specs don't give us very good terminology to describe what is
allowed in places that allow "MIME types". I think we should
explicitly say that we mean a MIME type to be composed of a main type
and subtype with no parameters.  It wouldn't do any harm.

e) Inheritance of things like atom:copyright and atom:author seems
rather subtle. They appear to work in slightly different ways, and I'm
not sure that the spec is clear enough on exactly how this inheritance
is supposed to work. As Dan Brickley said recently, "Atom's job [...]
is to be clear about what the document means." I was planning to
methodically enumerate some possible effects of inheritance, and to
check whether the spec is ambiguous about any of these (it might all
be fine).

Eg: should an impeccably behaved Atom implementation treat these two
the same (eg should a server record the two differently in its
database):

<feed>
<atom:entry>
<atom:author><atom:name>David Powell</atom:name></atom:author>
[...]

vs:

<feed>
<atom:author><atom:name>David Powell</atom:name></atom:author>
<atom:entry>
<atom:author><atom:name>David Powell</atom:name></atom:author>
[...]

Apart from that, I think things are pretty solid.

[1] http://research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.pdf
[2] http://www.ietf.org/rfc/rfc3229.txt

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 11:08:34 -0400

> If we make any technical changes

How long of a delay can we expect? I'm thinking 2 months, minimum.
Does that sound about right?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 18:41:44 -0400

> charter if there is rough consensus in the WG that that is what you

Discussion since you sent this email indicates that the people who
currently think they constitute the Atompub WG don't think they need
to respect any previous consensus. The people sending emails after
last call are, by and large, not the same people who were posting in
October (when we settled the dates issues). I suggest we seriously
consider closing the WG if basic decisions cannot respected or
declared out of order.

Would the WG tolerate another evaluation of RDF? Everyone insists that
their pet problem, no matter how divergent from current syndication
usage, must be addressed. So, RDF must be allowed as well. That leads
me to believe that no useful work has been accomplished in the past
year. Our deadlines are passed.

 Why shouldn't the IETF close this WG down?

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 May 2005 18:06:27 -0700

At 6:41 PM -0400 5/21/05, Robert Sayre wrote:
>to respect any previous consensus.

s/any/some/. Agree. Sometimes people change their mind. 
(s/Sometimes/Quite often/ ...)

>  The people sending emails after

Fully disagree. This WG has made the basic spec much stronger and 
more complete than any individually-submitted RFC could possibly be.

>  Why shouldn't the IETF close this WG down?

Because it is still improving on a specification that is important to the IETF.

--Paul Hoffman, Director