Re: [Standards] XEP-0115: version 1.5 revisited
On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote: I.e., I think this method is kind of a mess, when just adding 'hash' in separately would've solved the backwards compatibility issue nicely. However, that ship has probably sailed, so even just including 'v' will solve the 'users will ask for this' concern I had about displaying version strings. :) And then new clients would need to respond to both new-style queries and old-style queries, as well as continuing to send ext for backward- compatibility. I agree that it's unfortunate that old clients will show the hash as the version number. Like stpeter said, though, I'm not convinced that the version number has general-purpose utility. -- Joe Hildebrand
Re: [Standards] XEP-0115: version 1.5 revisited
I.e., I think this method is kind of a mess, when just adding 'hash' in separately would've solved the backwards compatibility issue nicely. However, that ship has probably sailed, so even just including 'v' will solve the 'users will ask for this' concern I had about displaying version strings. :) And then new clients would need to respond to both new-style queries and old-style queries, as well as continuing to send ext for backward-compatibility. My backwards-compatibility concern was less about version display in this case and more about the use of that value. Old style, if I had node='http://foo.com/bar' and ver='somestring', then I could query on http://foo.com/bar#somestring and get that value (and of course, same with the exts). Now you are supposed to just do a straight out disco query against the user; http://foo.com/bar#somestring is not guaranteed to actually be a valid query you can perform, which means old-style clients that expect to do node#ver queries may not receive data at all. Thus, we broke backwards compatibility entirely. Hence my thought that including node/ver if you wanted to support the old style client queries, and including the hash differently if not, would have been more backwards-compatible. My talk about version display is just because I know users will ask for the version string, not because I think it has any inherent value. I just always think to myself 'will my users howl at me if I remove this,' and if the answer is 'yes,' I speak up. ;) But I think breaking the version string for a 'backwards compatibility' which we then proceeded to break by removing the 'query on the hash' aspect of things was not our best decision as a standards body. Because at this point, we've managed to confuse the issue AND ensure old implementations may not work, either. That's my concern there; over the course of a few revisions, we made the protocol more confusing, and then we sacrificed the backwards compatibility we supposedly gained by that confusion. I mean, I know how I will implement this (including generating my hash and then allowing it as a proper disco query to allow old-style clients to work with me), but the situation seems non-ideal. Given that we broke with backwards compatibility by removing the ability to query on the hash, we should have just kept node/ver with their old meanings, and added a separate hash attribute. Anyway, what's done is done; I point this out only to show that we shouldn't let this happen again when changing other bits and pieces, down the road. -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
Well, whatever it is, we should specify it. :) Joe Hildebrand wrote: I disagree with this. I think it should return not found. Think about a pub-sub service, for example... On Nov 21, 2007, at 11:18 AM, Peter Saint-Andre wrote: I don't think I agree. That is, I think if you receive a disco#info request at a node you don't know about, you should reply as if the node attribute had not been included. But I notice that this is not specified in XEP-0030. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
On Nov 21, 2007, at 10:37 AM, Rachel Blackman wrote: Now you are supposed to just do a straight out disco query against the user;http://foo.com/bar#somestring is not guaranteed to actually be a valid query you can perform, which means old-style clients that expect to do node#ver queries may not receive data at all. Thus, we broke backwards compatibility entirely. This is one of the (several) reasons why I *still* think that the request should still have http://foo.com/bar#somestring as the node. -- Joe Hildebrand
Re: [Standards] XEP-0115: version 1.5 revisited
Joe Hildebrand wrote: On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote: I.e., I think this method is kind of a mess, when just adding 'hash' in separately would've solved the backwards compatibility issue nicely. However, that ship has probably sailed, so even just including 'v' will solve the 'users will ask for this' concern I had about displaying version strings. :) And then new clients would need to respond to both new-style queries and old-style queries, as well as continuing to send ext for backward-compatibility. I agree that it's unfortunate that old clients will show the hash as the version number. Like stpeter said, though, I'm not convinced that the version number has general-purpose utility. I'm not either, but if 'v' is optional and end users love it then I have no objections. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
Rachel Blackman wrote: I.e., I think this method is kind of a mess, when just adding 'hash' in separately would've solved the backwards compatibility issue nicely. However, that ship has probably sailed, so even just including 'v' will solve the 'users will ask for this' concern I had about displaying version strings. :) And then new clients would need to respond to both new-style queries and old-style queries, as well as continuing to send ext for backward-compatibility. My backwards-compatibility concern was less about version display in this case and more about the use of that value. Old style, if I had node='http://foo.com/bar' and ver='somestring', then I could query on http://foo.com/bar#somestring and get that value (and of course, same with the exts). Now you are supposed to just do a straight out disco query against the user; http://foo.com/bar#somestring is not guaranteed to actually be a valid query you can perform, which means old-style clients that expect to do node#ver queries may not receive data at all. Thus, we broke backwards compatibility entirely. I don't think I agree. That is, I think if you receive a disco#info request at a node you don't know about, you should reply as if the node attribute had not been included. But I notice that this is not specified in XEP-0030. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
presence from='[EMAIL PROTECTED]/orchard' c xmlns='http://jabber.org/protocol/caps' node='http://code.google.com/p/exodus/' v='0.9.1' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ /presence AND... identity category='client' name='Exodus 0.9.1' type='pc'/ Then do you display the following? Software: Exodus 0.9.1 0.9.1 If the name string contains the version string... strcasestr(clientname,version) == 1 But how do you know what a version string is? Just lots of fancy regexes? name='Exodus 0.9.1' v='0.9.1' strcasestr(Exodus 0.9.1,0.9.1) == 1 Oh, they included the version in the client name information. I'll just use the name without appending. :) If we aren't adding version into presence, that's another thing, but I would expect that users will request this -- showing what version of a client the other person is on has been one of our own most-common requests. Well, the sense I got from the list discussion is that end users want to know what client the other person is using, but don't necessarily need or want to know which version of the client is in use. Did I misinterpret the list discussion? Not necessarily; I'm just noting from personal experience that users do want the version information too. There's no logical reason for it, and it may be a deal-breaker, but it's always something that gets asked for if I omit it. :) I agree there is no solid engineering reason for it, but it is functionality clients presently can have, and removing functionality will always generate end-user bug report/feature request tickets. And sometimes features are driven by 'what users want' rather than by any solid engineering goal. (Is there a real engineering benefit to avatars? No, but users demonstrably wanted them.) Just my $0.02, though. :) I don't disagree with that. So are you in favor of the 'v' attribute? I really don't care at this point, and I don't want to remove functionality, and I don't want to go back to the bad old days of the version flood. So if the little 'v' attribute saves the day, I'm +1 to that. I'm fine with the v. I still think that using version as it was before and then including a new forward-compatibility hash operator would've made more sense, as it would then continue to work with everything. New clients would use the hash field and could validate against that, old clients could still query as before AND use the ver field for display. Our newer method means we break backwards compatibility, as older clients will show the hash as the client version string (and may not be able to query against node#hash to cache, given the 1.4 recommendation that you just query with no disco node), and newer clients need to be able to determine if the ver string is a hash (and thus something they can validate against) or an old-style version (and thus something they need to query), and whether or not they can display it (old-style) or need to use the 'v' attribute, and so on. I.e., I think this method is kind of a mess, when just adding 'hash' in separately would've solved the backwards compatibility issue nicely. However, that ship has probably sailed, so even just including 'v' will solve the 'users will ask for this' concern I had about displaying version strings. :) -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
OK, I'm still trying to get to closure here... :) Rachel Blackman wrote: A version is only interesting if you know the software that it goes with. Unfortunately all we have is a URI, which means for any sane display I need a table of URI-software name mappings, and thus I can only display versions for software I know about. That seems limiting. Not really; you can just cache the identity part of a disco query when you cache the list of features. Usually the identity contains the client name, and you are already generally getting that when you do your disco query. In general, I see things like... identity category='client' name='Exodus' type='pc'/ ...coming back. You cache the name, and add the version. (Optionally, if the name string contains the version string, a'la 'Exodus 0.9.1' and version '0.9.1' you just use the name unmodified.) Hmm. What if you have this? presence from='[EMAIL PROTECTED]/orchard' c xmlns='http://jabber.org/protocol/caps' node='http://code.google.com/p/exodus/' v='0.9.1' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ /presence AND... identity category='client' name='Exodus 0.9.1' type='pc'/ Then do you display the following? Software: Exodus 0.9.1 0.9.1 [sic] That seems bad. Let's keep the version information in one place. I think it's safest to put it in the disco#info 'name' attribute and nowhere else (that is, if people really want this information -- the more I think about it, the less convinced I am that it is useful or important to provide the version information in caps). This way we don't clog up the caps data with version information, we don't need to add a new 'v' attribute to caps, and we can leave the naming to disco as it (perhaps) should have been all along. Granted, this becomes an issue if you have two clients with identical hashes but different names, so Justin's suggestion of an 'n' field in the caps is not without merit. But users do like this information -- and it can be useful to know that someone is on the Gmail web client, rather than Google Talk itself -- so having SOME way to convey it in a sensible and bandwidth-efficient manner (i.e., avoiding our old-school iq:version flood) is a good idea. Well, as Justin said, a client can maintain a mapping of node - name (derived from disco#info results) if it really cares, right? Then if you want to advertise different builds of the same or similar client, you could include different nodes (http://www.google.com/talk/win vs. http://www.google.com/talk/web or whatever). So folks, let's keep things in perspective: 1. What really matters here is the capabilities (in 1.4+, the 'ver' attribute). 2. The node is nice to have for certain use cases because it can give you a mapping to a client name (via disco#info) if you want it. 3. The version information may be desirable in certain odd situations, but I have not heard a compelling argument for it (most people want to show the software name but are not all that interested in the exact version). If you really really need the version, use XEP-0092 (but for Pete's sake don't flood every person in your roster for the damn version because no one really cares about it!). Therefore I argue for removing version from caps (i.e., not adding it back in version 1.5 -- we already removed it from 1.4). An updated copy (1.5pre8) of XEP-0115 is here: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html The SVN diffs are here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145r2=1403 Do we have consensus? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
...coming back. You cache the name, and add the version. (Optionally, if the name string contains the version string, a'la 'Exodus 0.9.1' and version '0.9.1' you just use the name unmodified.) Hmm. What if you have this? presence from='[EMAIL PROTECTED]/orchard' c xmlns='http://jabber.org/protocol/caps' node='http://code.google.com/p/exodus/' v='0.9.1' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ /presence AND... identity category='client' name='Exodus 0.9.1' type='pc'/ Then do you display the following? Software: Exodus 0.9.1 0.9.1 If the name string contains the version string... strcasestr(clientname,version) == 1 Thus, you just use 'Exodus 0.9.1' (the name field) since the version string is a substring of the name. I agree it's not necessarily ideal, but this is how many of us deal with things ANYWAY when sorting out version information. I still think, regardless, if we are adding version into presence, it is silly to kill the old ver field, then put the value into a new v field. If we aren't adding version into presence, that's another thing, but I would expect that users will request this -- showing what version of a client the other person is on has been one of our own most-common requests. I agree there is no solid engineering reason for it, but it is functionality clients presently can have, and removing functionality will always generate end-user bug report/feature request tickets. And sometimes features are driven by 'what users want' rather than by any solid engineering goal. (Is there a real engineering benefit to avatars? No, but users demonstrably wanted them.) Just my $0.02, though. :) -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
Peter Saint-Andre wrote: I will post version 1.5pre6 soon to incorporate the foregoing consensus. Well soon was rather immediate. :) http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html Diff from 1.5pre5: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1194r2=1362 Diff from 1.4: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145r2=1362 /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
Joe Hildebrand wrote: On Nov 8, 2007, at 4:12 PM, Peter Saint-Andre wrote: How exactly do 1.3 clients break if in 1.4+ the nodes are things like: http://code.google.com/p/exodus/#0.9.1 http://psi-im.org/#0.11 Again it's a special URL at the software website. The only potential problem is the inclusion of the '#' character, but we can change it (as we did before) to be ';' instead of '#'. In fact I think we should do that for backward compatibility. As I think about this a little more, it's annoying that the URI changes with each version. 1.3 clients that are using the URI to (for example) select an icon based on the client software would have to be updated every time the sending software has a new version, since they treat the URI as a more-or-less opaque identifier. If we think the version number is still interesting, perhaps we should just define a new attribute that 1.4+ clients could look at if they want it. You mean like this: *** Or it could be split out as a separate attribute. c xmlns='http://jabber.org/protocol/caps' node='http://exodus.jabberstudio.org/' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8=' v='0.9.1'/ Where the v attribute SHOULD be included. *** Quote from: http://mail.jabber.org/pipermail/standards/2007-August/016670.html Yes it seems a bit funny to have a 'v' attribute: http://mail.jabber.org/pipermail/standards/2007-August/016680.html But we're keeping 'ver' for backward-compatibility so it seems OK: http://mail.jabber.org/pipermail/standards/2007-August/016681.html Deja vu all over again. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
On Nov 8, 2007, at 4:24 PM, Peter Saint-Andre wrote: Yes it seems a bit funny to have a 'v' attribute: http://mail.jabber.org/pipermail/standards/2007-August/016680.html As usual, Rachel is the voice of reason. I don't mind her proposal; however, I still don't think the algorithm needs to be extensible. If we pick one and stick to it: c xmlns='http://jabber.org/protocol/caps' node='http://exodus.jabberstudio.org/' ver='0.9.1' hash='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ 1.3 clients will disco to node http://exodus.jabberstudio.org/#0.9.1. 1.5 clients will disco to node 8RovUdtOmiAjzj+xI7SK5BCw3A8=. Yes, I still think the queries need a node. My new use case for that is that I might want to send different folks different caps, or different caps when I join a room or something. This has the downside of every implementation for the near future having to implement listening for two different nodes, which could be avoided if the has was in ver and the version was in v. -- Joe Hildebrand
Re: [Standards] XEP-0115: version 1.5 revisited
On Nov 8, 2007, at 4:12 PM, Peter Saint-Andre wrote: How exactly do 1.3 clients break if in 1.4+ the nodes are things like: http://code.google.com/p/exodus/#0.9.1 http://psi-im.org/#0.11 Again it's a special URL at the software website. The only potential problem is the inclusion of the '#' character, but we can change it (as we did before) to be ';' instead of '#'. In fact I think we should do that for backward compatibility. As I think about this a little more, it's annoying that the URI changes with each version. 1.3 clients that are using the URI to (for example) select an icon based on the client software would have to be updated every time the sending software has a new version, since they treat the URI as a more-or-less opaque identifier. If we think the version number is still interesting, perhaps we should just define a new attribute that 1.4+ clients could look at if they want it. -- Joe Hildebrand
Re: [Standards] XEP-0115: version 1.5 revisited
A version is only interesting if you know the software that it goes with. Unfortunately all we have is a URI, which means for any sane display I need a table of URI-software name mappings, and thus I can only display versions for software I know about. That seems limiting. Not really; you can just cache the identity part of a disco query when you cache the list of features. Usually the identity contains the client name, and you are already generally getting that when you do your disco query. In general, I see things like... identity category='client' name='Exodus' type='pc'/ ...coming back. You cache the name, and add the version. (Optionally, if the name string contains the version string, a'la 'Exodus 0.9.1' and version '0.9.1' you just use the name unmodified.) Granted, this becomes an issue if you have two clients with identical hashes but different names, so Justin's suggestion of an 'n' field in the caps is not without merit. But users do like this information -- and it can be useful to know that someone is on the Gmail web client, rather than Google Talk itself -- so having SOME way to convey it in a sensible and bandwidth-efficient manner (i.e., avoiding our old-school iq:version flood) is a good idea. -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
However, from an user perspective... what is the interest of showing different icon per client. Imagine that it's a presence-only device, like a phone, for example. Arguably, this should be a defined value used in the identity element -- identity category='client' type='presence' name='PTT'/ or whatever -- and handled accordingly. (And yes, I think a presence- only device should respond to disco queries, even if some specialized server is responding on the device's behalf.) You can do the same thing with type='web' and type='pc' and so on. I like displaying the client/name version in contact tooltips as much as the next person, but only because users like that info. If they didn't, there wouldn't be options in BitTorrent clients to see what client all your connected peers use, and my temporary removal of those client tooltips from an early Astra build would not have been met with a hail of bug-report submissions demanding the feature back. But using that information for anything more than display to end-users is a mistake; the information is there not because it is functionally meaningful, but because end-users want it. /Why/ end-users want it is not particularly relevant to the point. :) -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
On Thursday 08 November 2007 4:03 pm, Joe Hildebrand wrote: On Nov 8, 2007, at 4:47 PM, Justin Karneges wrote: Maybe in addition to Peter's proposed 'v' attribute, we could have an 'n' attribute for the name. This should allow for generic display. Doesn't that come back in the identity tags in the disco#info response? If you want this info, you can cache it on a node#v basis. Oops. :) You're right, an 'n' is not needed for this. It feels weird to have the version in caps and the name in disco though. Perhaps the version would be better off in disco, too, but then maybe we'd rather not muck with disco.. -Justin
Re: [Standards] XEP-0115: version 1.5 revisited
Joe Hildebrand wrote: On Nov 8, 2007, at 4:24 PM, Peter Saint-Andre wrote: Yes it seems a bit funny to have a 'v' attribute: http://mail.jabber.org/pipermail/standards/2007-August/016680.html As usual, Rachel is the voice of reason. I know! I tried to convince her to run for XMPP Council but she wasn't buying it. :( I don't mind her proposal; Well either we're backward-compatible or we define a new namespace, at which point people will send both, at which point we've got too many bytes in our presence traffic. Ick. however, I still don't think the algorithm needs to be extensible. If we pick one and stick to it: Right. So SHA-1 forever. If we want something else, we define a new protocol. Call it the SHA2K problem. c xmlns='http://jabber.org/protocol/caps' node='http://exodus.jabberstudio.org/' ver='0.9.1' hash='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ Er, that's for xmlns='urn:xmpp:caps', the non-backward-compatible protocol that we won't pursue. For xmlns='http://jabber.org/protocol/caps' I think we'd have: c xmlns='http://jabber.org/protocol/caps' node='http://exodus.jabberstudio.org/' v='0.9.1' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/ 1.3 clients will disco to node http://exodus.jabberstudio.org/#0.9.1. 1.5 clients will disco to node 8RovUdtOmiAjzj+xI7SK5BCw3A8=. Right. Yes, I still think the queries need a node. We did that in 1.3 so we should do it in 1.5. Backward compatible. My new use case for that is that I might want to send different folks different caps, or different caps when I join a room or something. This has the downside of every implementation for the near future having to implement listening for two different nodes, which could be avoided if the has was in ver and the version was in v. Right. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0115: version 1.5 revisited
On Nov 8, 2007, at 4:49 PM, Olivier Goffart wrote: I think they should not use that XEP for that. Too late. There is jabber:iq:version for that. I hope not. That was the whole reason we wrote this XEP in the first place! And if we want to avoid sending a jabber:iq:version to each, we should come with a replacement that goes in the presence stanza (and would also benefit from server optimisations) See section 7 of XEP 115. However, from an user perspective... what is the interest of showing different icon per client. Imagine that it's a presence-only device, like a phone, for example. Remember that old client using version 1.3 of the xep use node#ver as key in their cache. So if two different clients (or different versions) share the same disco#info, they will not be able to share the cache entry, even if the hash is the same. (one may argue this is negligible, ok, but this is easy to avoid anyway) That's why I relented on which node new clients send to. They can send to node=hash, rather than node=node#hash, so that caching can be cross-client. -- Joe Hildebrand
Re: [Standards] XEP-0115: version 1.5 revisited
Olivier Goffart wrote: Le jeudi 8 novembre 2007, Peter Saint-Andre a écrit : 5. Objections to the Council change in version 1.4 specifying that the value of the 'node' attribute should be ProductURL#SoftwareVersion. I think we should not recommend to add the version number in the node at all, specially if the version may change while the disco#info does not. Why not? It's not clear to me what the problem is. I even think we should specify a fixed value for the node attribute. such as node=jabber.org/caps-x So client that support the 1.3 version of the XEP still works. In 1.3 the nodes were things like: http://exodus.jabberstudio.org/caps http://psi-im.org/caps So essentially it was a special URL at the website of the client project or company. How exactly do 1.3 clients break if in 1.4+ the nodes are things like: http://code.google.com/p/exodus/#0.9.1 http://psi-im.org/#0.11 Again it's a special URL at the software website. The only potential problem is the inclusion of the '#' character, but we can change it (as we did before) to be ';' instead of '#'. In fact I think we should do that for backward compatibility. Hardcoding the node so that it is the same for all clients seems like a bad idea. I consider that we recommend to use the version number in the node since examples show it. Correct. That's what the Council decided before we published 1.4 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
