[Standards] XEP-0115 redux

[Peter Saint-Andre]

Kevin Smith wrote:
> On Jan 17, 2008 6:42 AM, Rachel Blackman <rcb at ceruleanstudios.com> wrote:
>>> Seriously, we're talking about breaking a really good protocol for
>>> information that is only mildly useful...
>> Sure, but then recognize some people will iq:version flood because
>> they'll feel the need to query an entire contact list.
> 
> It is true that the users 'require' this.
> 
>> 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.
> 
> That was me, and yes - removing the full iq:version query from Psi
> caused quite an outcry when we replaced the iq:version flood with caps
> based versioning, and only doing iq:version when directly queried.
> 
>> 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.)
> 
> I confess that I'm starting to wonder what the difference is between
> iq version floods and presence floods when you log on.

I think we're trying to limit the number of floods. :)

>> 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.
> 
> The string seems fine, although we probably don't want to mandate not
> querying, since clients may withhold it from global presence, but let
> some people iq:version.

What about OS? I need to know that the other person is on Windows so I 
can hack into their machine!

>> 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.
> 
> I think it's pertinent in as far as if it drops from caps, the
> replacement needs to appear at the same time, but other than that,
> sure.

So we have four options:

1. Leave iq:version alone and accept the version flood

2. Define a way to get name+os+version via PEP (presumably the <query/> 
element from XEP-0092 could be a PEP payload, no?)

3. Define a way to put name+os+version into caps

4. Define a way to put name+os+version into presence

Personally, I don't care enough about knowing the name+os+version of the 
people in my roster to want this feature, but I realize that plenty of 
end users do want this.

I don't think the name+os+version changes often enough to put it into 
PEP, caps, or presence. In fact an IQ for this doesn't seem nearly so 
evil to me once I consider the alternatives...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080117/d4ef5cf2/attachment.bin