[Standards] XEP-0115 redux

[Dave Cridland]

On Tue Jan 15 18:35:48 2008, Peter Saint-Andre wrote:
> Well we left the friendly name out of the last version of the spec,  
> but if including it helps to prevent iq:version floods then I think  
> it's worth considering. Because that is simply evil.
> 
> Naturally, if we include the friendly name (which BTW might be  
> localized etc. etc.) then we lose re-usability of caps across  
> different clients. Is that important?

I think we're trying to solve two distinct problems in one protocol  
mechanism, and I think attempts to do this are likely going to lead  
to a compromise which we don't need.

The goal of having a secure method for optimizing the amount of disco  
queries used in typical scenarios has been met as well as I think it  
can be by XEP-0115. We can even ship clients with precalculated  
hashes, and all sorts.

Trying to blend in a reduction of iq:version queries is going to lead  
to a pessimization of the protocol.

As I undertsand things, the method for doing this with "old-skool"  
XEP-115 won't work no matter what we do at this point, which at least  
leaves the path clear for a new method.

Would it be reasonable to cache iq:version results against node+ver+v  
of the XEP-115 if the hash attribute exists? There's no security  
here, and I would note that it would be possible for malicious  
clients to poison the iq:version cache, I just can't see any point in  
doing so.

If this is a problem, can we think of another - new - method for  
solving the use-case?

I'm not 100% clear on the drivers for this kind of facility, so I  
won't mind if people shoot me down. (I usually don't).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade