On 4/20/11 7:42 AM, Philipp Hancke wrote: >>>> I am not sure if backward compability really matters, the last time I >>>> checked I offered EXTERNAL to three servers... jabber.org, >>>> dave.cridland.net and some host running prosody. >>> >>> Right. Let's get some feedback Dave Cridland and Matthew Wild, at the >>> least. I'm not sure that we have any implementations with which to be >>> backward compatible. :) >> >> Please see the latest version, reflecting what I think is the consensus >> from list discussions: >> >> http://xmpp.org/extensions/tmp/xep-0178-1.1.html >> >> http://xmpp.org/extensions/diff/api/xep/0178/diff/1.0/vs/1.1rc4 > > Not related to the diff, but I just spotted this: > S2S step 9: no match -> close => MAY close or may allow dialback?
Ah yes, TLS+Dialback? ;-) Changed in my working copy to: If no match is found, Server2 MAY either close Server1's TCP connection or continue with a Server Dialback [8] negotiation. > S2S step 10: I think MUST NOT is too strong. After all, XMPP is deployed > using the EXTERNAL mechanism (see the xmppwg charter :-), so > we can not change the rules that way. > MAY include (for interop reasons) with a note that a future version may > remove this (actually I think that EXTERNAL will be deprecated in favor > of d-w-d before that happens)? That way we have a clear migration path. OK. Changed in my working copy to: For server-to-server authentication, the <auth/> element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in RFC 6120). > Note #7 is obsolete, that spec is 0238 - which is deprecated so it does > not make sense to add a reference. True. And the dialback flows will be in d-w-d anyway, I'd think. Removed. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
