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

Joe Hildebrand hildjj at gmail.com
Tue Jul 3 17:58:28 UTC 2007


I just talked to stpeter IRL (he's all of 10 feet from me; should  
have done that first thing this morning!), and made sure he  
understood what I was after.  I'm replying to Rachel's mail, since it  
hits on the two (in my mind) remaining interesting questions, namely:

1) is it necessary to explicitly flag that we're doing hashes?

I like Kevin Smith's suggestion that the receiver should always do  
the hash.  For old clients, the hash will never match, but it's the  
same policy decision to allow old clients as to allow broken senders  
that send bad hashes.

2) do we need ext in the hash world?

Rachel makes a good point that without ext, more data has to be  
cached, since there will be redundant features associated with  
different ver's.  I think it's a toss-up; no ext's is considerably  
simpler for all involved; no partitioning of features on the sender  
side and no unions on the receiving side.


To be clear and explicit, all in one place, here is what I'm  
recommending:

<presence from='bard at shakespeare.lit/globe'>
   <c xmlns='http://jabber.org/protocol/caps'
      node='http://psi-im.org/caps'
      ver='big-long-hash-goes-here'/>
</presence>

Again, I think simplicity dictates that we pick a single hash  
algorithm and stick with it; I'm almost entirely disinterested in  
what that algorithm is, as long as it doesn't provide output that has  
too many bytes in it.

On Jul 3, 2007, at 10:40 AM, Rachel Blackman wrote:

>>>> 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.
>>
>> Ext is used in the wild.  My initial reaction is that it is still  
>> needed, but on further thought, I can't see why.
>
> If you remove ext, you create MORE separate things to cache, and  
> thus recreate more network traffic.  Because now, client Foo with  
> plugin Bar installed will have an entirely different hash than  
> client Foo without Bar installed.  With ext, client Foo has the  
> same capabilities hash in both cases, but one has an additional ext  
> hash for plugin Bar's capabilities.



More information about the Standards mailing list