On Tuesday 15 January 2008 12:06 pm, Dave Cridland wrote: > Trying to blend in a reduction of iq:version queries is going to lead > to a pessimization of the protocol.
I started to get this impression as well. Peter is right that you could have localized client names. Also consider clients that run on multiple operating systems (caps doesn't currently specify a way to reveal the OS, but if it did then this would trip the hash). Worse (but rightly so), some clients allow customizing or hiding the version information, similar to the way browsers let you muck with the 'user agent' value. Finally, keep in mind that a client in beta or release-candidate phase may have capabilities that are set in stone, but a name string that isn't set in stone. This is enough for me to believe that capabilities and version information are distinct and should be tracked separately. > 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). My initial instinct is to add another hash to presence, which is resolved with an iq:version query. Arguably, a hash might be even longer than client + version + os combined, so maybe just putting iq:version content into presence would be enough. -Justin
