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
