>> 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
smime.p7s
Description: S/MIME cryptographic signature
