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

[Dave Cridland]

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:

http://www.iana.org/assignments/hash-function-text-names

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade