On Wed, Sep 2, 2015 at 10:03 PM, Lance Stout <[email protected]> wrote: > 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
Wow, yup... there it is... fixed in the PR. > 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. The list formatting was just chosen arbitrarily since it doesn't really matter. Having some separators probably makes reading error logs easier (that's a bit of a stretch as far as added value is concerned, but there's not really any down side to having the commas either). >> 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? I suppose it could; I think the idea in having both in the original implementation was that we were using deterministic version tokens at the time that were created from a digest of the various mutable properties, and there was a high chance of collision. We scrapped that in favor of the random tokens which are recommended in the implementation notes, but the JID:version pairs remained. I'd prefer to keep them just because we're already using them and I suspect that it could lower the likelyhood of a false positive aggregate token match due to low entropy version tokens (but yah, that's also a stretch... probably doesn't matter either way.). > 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" /> Ah, right. That's a great question, and one we don't have solved, I'll ask Doug (the original author of our internal tech spec) what he thinks tomorrow, but your solution looks reasonable. It also might be more flexible to just change how this works and wrap whatever the query you want an aggregate token hash for, eg: <query xmlns="urn:xmpp:entityver:0"> <query xmlns="http://jabber.org/protocol/disco#items"; node="archived-rooms" /> </query> (though that doesn't read very well... might have to think about how it works, but you get the idea) —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
