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

Mridul Muralidharan mridul at sun.com
Tue Jul 3 16:51:40 UTC 2007


Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> 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
> 
> What Joe Hildebrand proposed initially had hashes for node & ext's - I 
> was refering to that here.
> The approach has the advantage that, clients can query and validate (and 
> so independently cache) namespace#node_hash, namespace#ext1_hash, etc - 
> and so having multiple hash'es allows reuse of cap's info across clients 
> and allows them to modify ext's each independent of the others.
> Addition or removal of a plugin will not result in the entire hash being 
> invalidated - just a specific hash will be removed, or modified.
> 
> 
> A single hash has the drawback that it will either protect the entire 
> set, or none at all - and so effectively we lose ability of separating 
> node's from ext's since we cannot independently validate each.
> 
> Which is why my initial query was if this should be 'verh' and 'exth' to 
> indicate hash'es and not 'ver' & 'ext' for the data itself (because of 
> new clients rejecting caps from old clients) - and 'new' clients would 
> query for these instead of ver/ext. I am sure there would be better 
> ideas to tackle this problem.
> 
> Though cache pollution looks like a serious issue (especially server 
> cache for pep case), I am wondering if we are not taking this way too 
> seriously - I did not see so much discussion for esessions ;-)
> 
> Regards,
> Mridul


s/node/ver/g
Apologies.

Mridul



More information about the Standards mailing list