Re: Consensus call on last raft of issues

[Sam Ruby <rubys@xxxxxxxxxxxxxxxx>]

Sam Ruby wrote:
> 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.
>
> > =============================

I guess I wrote this too quickly last night, in any case, it wasn't 
clear to Paul, so it might not be clear to others.  Off list, I offered 
the following, and Paul suggested that I post it to the list:

    There seemed to be consensus that feeds needed something to identify
    them.  What there wasn't consensus on is which element should be
    that identifier.  The solution selected was to make none of the
    identifiers required - something I don't think has much support, and
    furthermore creates problems with the ability to cite a source.

Done!

- Sam Ruby