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

Mridul Muralidharan mridul at sun.com
Tue Jul 3 16:49:24 UTC 2007


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



More information about the Standards mailing list