[Standards] XEP-0178 1.1rc3
stpeter at stpeter.im
Thu Apr 14 21:32:39 UTC 2011
On 4/14/11 3:30 PM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
>> I *think* that this discussion thread leads to the following text in
>> Section 3, but please double-check it.
>> 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For
>> server-to-server authentication the<auth/> element MUST NOT include an
>> authorization identity (thus Server1 includes an empty response of "="
>> as shown in RFC 6120).
>> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>> Interoperability Note: Previous versions of this specification relied on
>> the authorization identity being present on the receiving server. Even
>> though this is no longer required, the connecting server should include
>> it for backward compability.
> MUST NOT include but should include for backward compability?
> Include it always and blame it on me (even though I don't have the old
> logs from 2006).
> 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. :)
>> 11. Server2 determines if hostname is valid.
>> a. If the 'from' attribute of stream header sent by Server1 can be
>> matched against one of the identifiers provided in the certificate
>> following the matching rules from RFC 6125, Server2 returns success.
>> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
>> Implementation Note: If Server2 needs to assign an authorization
>> identity during SASL negotiation, it SHOULD use the value of the 'from'
>> attribute of the stream header sent by Server1.
Thanks for the review.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards