On 11/19/09 1:54 PM, Andy Skelton wrote: > On Wed, Nov 18, 2009 at 5:20 PM, Peter Saint-Andre <[email protected]> wrote: >> I've added text about the 'ver' attribute to XEP-0060. It's perhaps a >> bit underspecified right now. Feedback welcome. See also: >> >> http://xmpp.org/extensions/tmp/xep-0060-1.13.html > > First up, my confusion. The title of 7.1.2.4 Item Versioning tells me > that each item has its own version. Then I see the ver attribute on > the <items/> element. Then I read that the version ID can be "a hash > of the published data (e.g., of all the current items cached at the > node)" and I understand that it's really more like Node Versioning.
Correct. Will fix. > This expands the version concept in two directions. First, should this > versioning then also apply to Collection Nodes? The version ID e.g. > could be "a hash of the collection" or "a hash of the versions > contained in the collection", take your pick. Collection nodes make my head hurt. > Second, should > versioning also apply to items, as the section title implies? Possibly. <message from='pubsub.shakespeare.lit' to='[email protected]' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='princely_musings' ver='some-version-string-for-the-node'> <item id='ae890ac52d0df67ed7cfdf51b644e901' publisher='[email protected]' ver='another-version-string-for-the-item'> [ ... ENTRY ... ] </item> </items> </event> </message> > Next up, a request on behalf of publishers. If the publisher is not > allowed to determine the version, shouldn't it at least be able to > learn the resulting version when it publishes, modifies, or retracts > an item? Yes. That would be in the notification, as above. > Combining these two issues, we could have something like this: > > 7.1.2 Success Case > If the pubsub service can successfully process the request, it MUST > inform the publisher of success. If the publish request did not > include an ItemID, the IQ-result SHOULD include an empty <item/> > element that specifies the ItemID of the published item. +++If the > service is configured to include version information with > notifications (see 7.1.2.4 Item Versioning), the IQ-result SHOULD > specify the new version in the 'ver' attribute of the <publish/> > element and/or the <item/> element.+++ > > Example 101. Service replies with success > > <iq type='result' > from='pubsub.shakespeare.lit' > to='[email protected]/blogbot' > id='publish1'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > <publish node='princely_musings'+++ ver='1a8b6e5'+++> > <item id='ae890ac52d0df67ed7cfdf51b644e901'+++ ver='39ae70f'+++/> > </publish> > </pubsub> > </iq> > > Similar changes to 7.2.2 and 8.5.2. WFM. Text appreciated. :) > Related question: how does Wave do this? Sorry if it's too OT. Wave does something called Operational Transformation ("OT"). So it's very OT. ;-) But seriously, they have a more heavyweight technology for information versioning, including signing of modifications. It's described here: http://www.waveprotocol.org/whitepapers/operational-transform Fixes on the way for XEP-0060. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
