[Standards] Re: [jdev] XEP-0115: Entity Capabilities
dave at cridland.net
Tue Jul 3 14:01:38 UTC 2007
On Tue Jul 3 13:48:59 2007, Ian Paterson wrote:
> Rachel Blackman wrote:
>> Let's say we have node='http://ceruleanstudios.com/astra/caps' and
>> ver='h$someverylongstring' and ext='h$otherverylongstring'
> Or how about simply:
> node='$' ver='base64encodedHashOfFeatures'
> The benefits being it is more compact, and since all modern clients
> will advertise the same node, even legacy clients will effectively
> end up storing modern clients' caps globaly rather than on a
> per-client basis.
This sounds very sane. (Assuming you didn't really mean base64, since
hashes are typically represented as strings simply as hex digits.
Base64 would be smaller, but unusual, and potentially include
character-space clashes with Disco).
For hash agility, node might be "$hashname".
You can take hashname from the IANA registry:
Even though we need to mandate one as an MTI, for now.
> The XEP could also specify that if a client sets the value of the
> 'node' attribute to "$" then it MUST NOT include an 'ext' attribute.
Not sure about this, it really depends on how ext is actually used in
the wild, as Joe said. I'd be tempted to leave this somewhat open, at
least for now. It could be that we could grow a set of extensions of
commonly co-implemented features, bearing no actual relation to
client plugins, and cut down traffic that way. But such things
require quite a bit of research.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards