> This should be fine, I don't think I specified that it must use a bare > JID anywhere, but I may try to find an example later that uses a full > JID with resource part just to make it clear. I didn't throw it in > with this round of edits though.
There is this text about constructing the aggregate token:
This aggregate token is calculated by constructing a string of
comma separated "bare JID:version" pairs
I don't think this will affect anything, but there is the odd item
to note, which is that ',' is a valid character in the localpart of a
JID. If you are depending on that as a separator for some reason, that
might need to be adjusted.
> I've added a statement to make it clear how this should be handled.
> Since the actual value doesn't matter, we just sort as usual (and
> since we're constructing the JID:version pairs before sorting, we just
> end up sorting based on the version token).
Does that mean we really don't even need to use JIDs in the source string
for the aggregate token? Use a comma separated sorted list of version tokens?
> Unless I'm misunderstanding, this is already handled. You should be
> querying the same node for the aggregate token list (eg. if you're
> querying for a list of rooms, you query the MUC component or server,
> if you're querying for pubsub items, you might query the MUC component
> if it also provides pubsub, or you might query a separate entity which
> provides pubsub for that server. Wherever you would send a pubsub
> request would be where you'd query for a pubsub aggregate token).
Specifically, how would I request an aggregate token for the list that
this disco query would return:
<query xmlns="http://jabber.org/protocol/disco#items"; node="archived-rooms" />
I think that you'll need to update the aggregate token query to look like:
<query xmlns="urn:xmpp:entityver:0"
type="http://jabber.org/protocol/disco#items"; node="archived-rooms" />
— Lance
smime.p7s
Description: S/MIME cryptographic signature
