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

[Ian Paterson]

Peter Saint-Andre wrote:
> I also agree with Dave that we want to future-proof
> this. What if 3 years from now we want to use SHA-256 and 7 years from
> now we want to use an algorithm that emerges from the current NIST work?
>  It might be good to include a 'hash' attribute whose value is one of
> the hash function text names from the IANA registry (but the value
> defaults to MD5 or whatever we settle on now so that you don't have to
> include it until we decide to allow alternate algorithms).
>   

+1 If we want to prevent malicious cache poisoning going forward, then 
clients need to be able to upgrade the hash they are using. MD5 is not 
secure enough even for this purpose. (I've read about attacks that 
require less than an hour of computing time!) IMHO, SHA256 is the most 
reasonable default.

>> 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.
>>     
>
> I don't think we need 'ext' in the hash world.
>   

+1 the protocol is far simpler to implement without extensions. More 
storage will be required. But I'm not sure that we'll hit the sweet spot 
for storage-challenged clients. i.e. It may well be that those clients 
that have insufficient storage to cache the hash for each combination of 
plugins also have insufficient storage to cache hashes for each separate 
extension (i.e. they can't use caps at all).

> Joe Hildebrand wrote:
>   
>> On Jul 3, 2007, at 6:48 AM, 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'
>>>       
>> No.  The other reason for caps is so that receivers can show a different
>> icon for each different client that they have received presence from. 
>> There has to be a URI to define the sending client.
>>     
>
> Yes, that cuts down on the old iq:version flood. Or so we hope. :)
>   

Hmm, going forward, are the clients that most people use going to 
continue showing these icons? Is this a feature we need to care about? 
Even though I'm one of the small group of people involved in the XMPP 
community, I really don't care what client my contacts are using. Will 
there ever be mass demand for this feature? On the rare occasions where 
people are interested, they'll probably be perfectly happy to explicitly 
ask their client to find out the other user's client version on a 
case-by-case basis.

IMHO the 'node' attribute could be repurposed to be the name of the hash 
function (for backwards compatibility). We could also add some language 
to the XEP stating that clients SHOULD NOT perform an iq:version flood. 
(IMHO, assuming the features hash is available via caps, there is little 
justification for such behavior.)

Dave Cridland wrote:
> 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.

I did mean base64, but if people think that is too hard to implement, 
then hex is fine (even though it is 50% longer). I don't understand how 
base64 could create clashes with Disco.

- Ian