[Standards] dialback: piggybacking
stpeter at jabber.org
Fri Jun 22 18:23:38 UTC 2007
Justin Karneges wrote:
> On Friday 22 June 2007 9:28 am, Peter Saint-Andre wrote:
>> Mridul Muralidharan wrote:
>>> Can we remove that for the bis specs ? Hasn't xmpp not been around long
>>> enough to outgrow the 0.9 compatibility ?
>> I think so. Move dialback off to a XEP and we can tinker with it there.
>> It made sense for us to include it in RFC 3920 but I don't think it
>> belongs in rfc3920bis (which will be published ~3 years after RFC 3920).
> Dialback is still the #1 way s2s happens.
The same was true of jabber:iq:auth for client-to-server connections in
2004, but it's not documented in RFC 3920 because the IETF said "use
SASL instead of this homegrown Jabber stuff for authentication". Since
dialback is not an authentication mechanism at all, I think our IETF
friends would look favorably on documenting it elsewhere.
> What good is implementing RFC 3920
> if you can't connect to anyone?
This would be in rfc3920bis, which will have a number like RFC 5420 or
whatever. RFC 3920 would always have the dialback documentation, but
we'd move canonical documentation for it to XEP-0220 or whatever.
And you'd be able to connect to other servers just fine, since
rfc3920bis would say "for historical reasons you really should implement
XEP-0220 if you want to connect to other servers", and the XSF's server
compliance specs would include pointers to XEP-0220 as well, and all the
server developers would know that you need to implement dialback in
order to interoperate. At least until 2010 or whatever.
> Also, it's not like we're going to "tinker" with it.
We're tinkering with it now! Stream features, better error handling,
clearer documentation, HMAC-SHA256 recommended for the key generation
algorithm, changing piggybacking to a MUST, etc.
> If anything is worthy of
> set-in-stone-forever RFC status, it would be dialback.
A XEP can be just as "set in stone forever" as an RFC.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards