[Standards] Proposed XMPP Extension: Entity Versioning

Lance Stout lancestout at gmail.com
Wed Sep 2 04:34:51 UTC 2015


>> However, it's not clear from the specification how a server can signal
>> removal (or lack of visibility)
> 
> That was an oversight on my part; I appear to have dropped our
> mechanism for that somehow when compiling this from our internals
> system into an XEP. I'll update soon. Thanks.


This was where I got tripped up when reviewing, so thanks for sending the PR to fill in that missing piece :)




I do have some questions about Section 5.3 Aggregate Tokens.

The spec describes its use with MUC rooms, but is providing versioning for disco#items to do it (which makes sense given that providing this sort of universal API is one of the stated goals for entity versioning).

So, because this is versioning disco#items in addition to rosters, there are some things that need additional consideration when using aggregate tokens:

- Items could have a JID with a resource, so not just bare JIDs.
- Results might contain multiple items with the same JID, but different node values.
- Queries can specify a node

These concerns can still apply to MUC services, because a MUC host could include any of the above forms in its disco#items responses (even with no node specified). For example, I've worked with MUC domains that also provided PubSub, so the disco#items results included a mixture of PubSub nodes and MUC rooms.


The mechanism for requesting the aggregate token only accepts a namespace as input (or at least that is what I gathered from the examples, the text doesn't explain the relationship here). This is workable for rosters, but starts having issues with disco#items because we would also need to specify the queried node. Using this beyond disco#items could face additional challenges where there might be multiple request types under the same namespace but with different element names.


Given that, I would be tempted to explore something like the below, but even this has its drawbacks:

<iq type='get'>
  <protocol-el xmlns='urn:example:some-protocol' node='foo'>
    <aggregate xmlns='urn:xmpp:entityver:0' />
    <set xmlns='http://jabber.org/protocol/rsm'>
      <max>0</max>
    </set>
  </protocol>
</iq>

<iq type='result'>
  <protocol-el xmlns='urn:example:some-protocol' node='foo'>
    <aggregate xmlns='urn:xmpp:entityver:0'>0514fc90e6c7981b06bbb2173bb8ef03</aggregate>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <count>42</count>
    </set>
  </protocol>
</iq>

Meaning: use the existing protocol method to fetch the list, using RSM to request sending back 0 items, but include the aggregate token that would match the parameters of the query.

It was mentioned that there was a second piece to the versioning work HipChat has done to specify requesting/providing subsets, so these issues might already be solved in that portion, but I would like to see them addressed here.



For basic MUC, the situation is certainly simplified and is a good starting use case, but I don't see how I could reuse this part of the spec as-is to do aggregate tokens for, say, listing PubSub nodes and items.



- Lance



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4115 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150901/11114b7f/attachment.bin>


More information about the Standards mailing list