Tim Bray wrote:
On behalf of Paul and myself.
Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
The volume of correspondence was unfortunately high for an IETF Last Call that came after a Working Group Last call. It is quite possible, as always, that the co-chairs have mis-read the consensus of the group on one or more issues; in which case please push back.
We can work on this as long as is needed, and given the passion (and, in some cases, intransigence) we have seen so far, we do not expect to reach unanimity. When you respond to any of these readings of consensus, please do so with the intention of helping the chairs figure out whether or not we have determined consensus, not just to state an opinion one way or another. Thanks!
There is a danger of looking at changes in isolation. I will point out two instances that jump out at me. There may be more.
========================================================
PaceAllowDuplicateIDs
We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has been mostly against, but a close reading of his posts make it clear that his issue is in large part with atom:updated, he remains convinced that readers desire notification of every change however minor and are unwilling to trust publishers' opinions as expressed in atom:updated. He could live with this Pace if we re-introduced atom:modified or inserted wording in the spec emphasizing that if multiple entries with the same atom:id appear in a feed, software must treat them as XXX of the same entry; there was lively debate as to whether XXX was "versions", "instantiations", or "representations".
Conclusion: The Pace is accepted. The editors are directed to modify the phrase which starts "If multiple atom:entry elements..." as follows:
"If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such."
IIRC, much of this started due to an objection by Bob Wyman that treating atom:entries from different sources with the same atom:id as the same entry would cause problems for PubSub. What ever happened to that objection?
Also, it seemed to me that much of the discussion centered around distinguishing between multiple versions. Reintroducing modified was rejected, and atom:version never made it into a pace, but should there be some hint (perhaps non-normative) that software should look to atom:updated to resolve collisions?
=============================
PaceOptionalFeedLink
Lots of +1's, moderate objections from Ruby, accepted.
http://www.imc.org/atom-syntax/mail-archive/msg14896.html
If feed link becomes optional, there is nothing to anchor atom:source elements, which relates back to Bob's objection above.
=============================
Finally, I'm not sure what the next step is, but some determination of consensus on extensibility (also referred to as change control) is needed. There does seem to be a lot of voices in support of the following statement:
Only those elements defined in IETF RFCs may use the Atom namespace
- Sam Ruby
