[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Tue Nov 20 18:12:10 UTC 2007

Rachel Blackman wrote:
>>> ...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='romeo at montague.lit/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?

> 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, 

We didn't kill it, we repurposed it for backward compatibility.

> then put the value into a new v field.

Well sure. But sometimes maintaining backward compatibility means we
need to bend over backward.

> 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?

> 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.


Peter Saint-Andre

-------------- 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/20071120/53995ae5/attachment.bin>

More information about the Standards mailing list