[Standards] XEP-0115 redux

[Justin Karneges]

On Tuesday 15 January 2008 1:33 pm, Rachel Blackman wrote:
> > My initial instinct is to add another hash to presence, which is
> > resolved with
> > an iq:version query.  Arguably, a hash might be even longer than
> > client +
> > version + os combined, so maybe just putting iq:version content into
> > presence
> > would be enough.
>
> My thought is that if there's a simple way to pick up the version
> information and cache in an intelligent manner, then better to rely on
> the clients interested in that to download the information.
>
> If not -- if, for instance, we want this still to be JID+node specific
> -- then I'd rather just put a simple client display name (the version
> can even be part of the display name) into the presence; if it's
> there, clients that care about it can display it, and if it's not, we
> can safely assume the client doesn't want that sort of information
> displayed.

Right, so we could have something like this:

<presence>
  <v xmlns='version' n='Psi' v='0.10' o='Windows XP'/>
</presence>

Such a protocol needn't have anything to do with caps.

However, we could opt to stuff that information into the caps element anyway, 
just to save ourselves from having to transmit another element/xmlns:

<presence>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://psi-im.org/'
     n='Psi'
     v='0.10'
     o='Windows XP'
     ver='uCoVCteRe3ty2wU2gHxkMaA7xhs='/>
</presence>

In either case, the version strings would be specific to a jid and have no 
bearing on the hash calculation.

We should probably keep the name/version/os fields split so that there's no 
feature loss compared to iq:version.

Conclusion: define optional 'n' and 'o' attributes for XEP-115?

-Justin