[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Peter Saint-Andre stpeter at jabber.org
Tue Jul 3 16:02:38 UTC 2007

Rachel Blackman wrote:
>>> That said, I think we can come up with some simpler logic.  If a given
>>> token is prefixed with 'h$', for instance, we know it's a hash and
>>> should be both validated against the result, and -- if it matches --
>>> cached globally instead of per-client.  But for backwards compatibility,
>>> a disco on node#h$<hash> would still give you the proper results, and
>>> COULD be cached on a per-client basis.
>> Possible. But where does the token go? It seems preferable to define a
>> new attribute for this. Hmph.
> Why?
> Let's say we have node='http://ceruleanstudios.com/astra/caps' and
> ver='h$someverylongstring' and ext='h$otherverylongstring'
> Why can't something like...
> http://ceruleanstudios.com/astra/caps#h$someverylongstring work just
> like an old ver='' would generate an
> http://ceruleanstudios.com/astra/caps# would under the old
> system, for an old client?  After all, you still have to query the hash
> to get the features represented, which you then hash to validate and --
> if it's valid -- store it globally so that /all/ clients which have
> 'h$someverylongstring' have that featureset.

Hmm, OK. On that model, what is the use of 'ext'? Do you put a hash of
all the "base" features in 'ver' and a hash of all the "extended"
features in 'ext'? That seems potentially sub-optimal, because different
clients might divide "base" and "extended" differently, which means
you'll need to send and receive a lot more disco queries. It seems
better to me if we have only one hash for all the features.

> Thus, old clients can use it just fine with old-style logic.  Only the
> new client needs to know that h$ means 'take everything after that $,
> and treat it as a hash;' old clients can still query seamlessly.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070703/12134eef/attachment.bin>

More information about the Standards mailing list