[Standards] XEP-0115: version 1.5 revisited

Peter Saint-Andre stpeter at stpeter.im
Thu Nov 8 23:58:23 UTC 2007

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'

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

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.



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/20071108/a0ccbcef/attachment.bin>

More information about the Standards mailing list