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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 3 15:45:41 UTC 2007


Mridul wrote:
> 
> Joe Hildebrand wrote:
>> On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
>>
>>> Peter Saint-Andre wrote:
>>>> Mridul Muralidharan wrote:
>>>>> Forgot to add, change name from ver & ext to verh and exth ?
>>>> Why?
>>> Conflict with existing clients - too many of them in the wild dont use
>>> these semantics.
>> Others have already responded to this, but just to reinforce, I *did*
>> talk about backward compatibility.  Existing clients would continue to
>> work just fine. New clients just have to be able to detect other new
>> clients, to know if they are supposed to be able to check the hash. 
>> Presumably, new clients could choose by policy to ignore un-hashed caps
>> from old clients.
> 
> Not sure if anyone addressed the actual I was thinking of (need to read
> rest of thread).
> 
> Essentially, how would 'new' clients know is something exhibited in ver
> or ext is hash or 'old' value ? Aren't those identifiers not expected to
> be opaque (though consistent) ?
> 
> Considering an ext of "my_ext 1233ab" and "#hash1 #hash2" exhibited by
> two clients - how would the reciever know what is hashed as per 'new'
> idea and what is 'old' ver/ext ?

As I understand the proposal, there would not be "#hash1 #hash2" -- why
do you need multiple values here? You concatenate all the supported
namespaces according to some rule and then hash the whole thing. So
there's only one hash. But that means something different from 'ext' or
'node' or 'ver' so I think it needs to go in its own attribute.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070703/7e68cba4/attachment.bin>


More information about the Standards mailing list