[Standards] XEP-0115 redux

[Rachel Blackman]

>> Right. So caps is *just* disco, and then we define some new caps- 
>> like protocol to encapsulate the OS+Software+Name+Version  
>> information? Or do we stick that into entity capabilities using a  
>> new hash?
>
> a) putting it into a separate, large presence extension, that has  
> all of the information spelled out in as many languages as possible,  
> including client name, os name, os version, cpu speed, etc.
> b) saying that if the sender doesn't include the information, you  
> MUST NOT query for it
> c) we all agree not to implement the sending side
>
> Seriously, we're talking about breaking a really good protocol for  
> information that is only mildly useful to the end user and has no  
> security implications, other than to leak info that the user might  
> not want leaked?  If we just say "cache on a per-node basis, if you  
> feel the need to query for it", we're done, right?

Sure, but then recognize some people will iq:version flood because  
they'll feel the need to query an entire contact list.

My only real point is that end-users /do/ want this functionality.   
And it's functionality which they presently have (being able to see  
the client info of one of their contacts).  Taking away existing  
functionality rarely goes over well with end-users.  If we're all fine  
with saying 'screw the end-users, they don't know what they really  
want,' that's fine, but I'm pretty sure at least one client author had  
chimed in earlier about how end-users were unhappy when they removed  
that information before.

Personally, I'm fine with just the 'query only on mouseover or message  
window open' or whatever, but I do then think we need to make a best- 
practices XEP.  Otherwise, we will have people who go, 'okay, I'll  
just query and cache for everyone when I first see them' and we're  
right back to version floods.  (Or if we're fine with the iq:version  
floods, that's cool too, but we need to explicitly be fine with that.)

Honestly, I think the best bet is an optional n='whatever' as a  
display name in the caps field; takes up very little additional space,  
and if it's there you use that for a display.  That can say 'MyClient'  
or 'MyClient 1.0 (Win32)' or whatever.  You just use the string.   
Otherwise, you just don't query.

But in the long run, I don't personally care how we do it, I just  
think we need to be clear on /what/ we're doing. (I.e., saying 'no,  
users, you can't have that info anymore,' or saying 'heck, just  
iq:version flood' or writing a best-practices XEP on when you query  
and cache on a per-JID basis.)

I do agree that this bit can be pulled out of the caps discussion at  
this point, though; the only bearing it had on caps was that  
previously the node#ver values of the original caps meant that you  
could map that to a specific disco#info identity string as well, so  
the functionality had (unintentionally) rolled into the old caps.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/