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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
