[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Tue Nov 20 20:04:04 UTC 2007

Rachel Blackman wrote:
>>>> <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?
> 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. :)

Er, yes. We should've listened to Jacek Konieczny years ago.
Unfortunately we didn't, so we're in a bit of a fix now.

So I've added the 'v' attribute.

Updated version:


Diff from 1.5pre8:


Diff from 1.4:



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/4233a060/attachment.bin>

More information about the Standards mailing list