Subject: Last and final consensus pronouncement

From: Tim Bray <[email-masked]>
Date: Thu, 26 May 2005 10:26:54 -0700

<co-chair-mode>
On behalf of Paul and myself:  This is it.  The initial phase of the  
WG's work in designing the Atompub data format specification is  
finished over, pining for the fjords, etc.  Please everyone reach  
around and pat yourselves on the back, I think the community will  
generally view this as a fine piece of work.

Stand by for announcements on buckling down on Atom-Protocol.

Note that this is a pronouncement, not a "call for further debate".   
Here are the next steps:

1. Editors take the assembled changes and produce a format-09 I-D.   
Sooner is better.
2. They post the I-D.
3. Paul sends Scott a message, cc'ing the WG, that we're done.
4. At this point there may be objections from the WG.  We decide  
whether to accept the objections and pull the draft back, or tell the  
objectors they'll have to pursue the appeal process.
5. The IESG process takes over at this point and we'll eventually  
hear back from them.

Last two draft changes:

1. PaceAtomIdDOS

We think that the WG has consensus that it is of benefit to add a  
warning to section 8 "Security Considerations".  The language from  
PaceAtomIdDos is mostly OK, except that the late suggestion of  
talking about spoofing instead of DOS seemed to get general support.   
I reworded slightly.  We'll leave it up to the editors to decide  
whether a new subsection of section 8 is required.

"Atom Processors should be aware of the potential for spoofing  
attacks where the attacker publishes an atom:entry with the atom:id  
value of an entry from another feed, perhaps with a falsified  
atom:source element duplicating the atom:id of the other feed. Atom  
Processors which, for example, suppress display of duplicate entries  
by displaying only one entry with a particular atom:id value, perhaps  
by selecting the one with the latest atom:updated value, might also  
take steps to determine whether the entries originated from the same  
publisher before considering them to be duplicates."

2. PaceAtom10

http://www.intertwingly.net/wiki/pie/PaceAtom10

We just missed this one in the previous consensus call; seeing lots  
of +1's and no pushback, it's accepted.
</co-chair-mode>

---

From: Walter Underwood <[email-masked]>
Date: Thu, 26 May 2005 10:48:20 -0700

The atom:author element name is embarrassing. Make it atom:creator.
There were no objections to that.

wunder

--On May 26, 2005 10:26:54 AM -0700 Tim Bray <[email-masked]> wrote:

> 
> <co-chair-mode>
> On behalf of Paul and myself:  This is it.  The initial phase of the  WG's work in designing the Atompub data format specification is  finished over, pining for the fjords, etc.  Please everyone reach  around and pat yourselves on the back, I think the community will  generally view this as a fine piece of work.
> 
> Note that this is a pronouncement, not a "call for further debate".   Here are the next steps:
> 
> 1. Editors take the assembled changes and produce a format-09 I-D.   Sooner is better.
> 2. They post the I-D.
> 4. At this point there may be objections from the WG.  We decide  whether to accept the objections and pull the draft back, or tell the  objectors they'll have to pursue the appeal process.
> 5. The IESG process takes over at this point and we'll eventually  hear back from them.
> 
> Last two draft changes:
> 
> 1. PaceAtomIdDOS
> 
> We think that the WG has consensus that it is of benefit to add a  warning to section 8 "Security Considerations".  The language from  PaceAtomIdDos is mostly OK, except that the late suggestion of  talking about spoofing instead of DOS seemed to get general support.   I reworded slightly.  We'll leave it up to the editors to decide  whether a new subsection of section 8 is required.
> 
> "Atom Processors should be aware of the potential for spoofing  attacks where the attacker publishes an atom:entry with the atom:id  value of an entry from another feed, perhaps with a falsified  atom:source element duplicating the atom:id of the other feed. Atom  Processors which, for example, suppress display of duplicate entries  by displaying only one entry with a particular atom:id value, perhaps  by selecting the one with the latest atom:updated value, might also  take steps to determine
whether the entries originated from the same  publisher before considering them to be duplicates."
> We just missed this one in the previous consensus call; seeing lots  of +1's and no pushback, it's accepted.
> </co-chair-mode>
> 
> 
> 

--
Walter Underwood
Principal Architect, Verity