[Standards] XEP-0178 1.1rc3

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 20 15:00:30 UTC 2011


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/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110420/1b94c10a/attachment.bin>


More information about the Standards mailing list