[Standards] LAST CALL: XEP-0220 (Server Dialback)
stpeter at stpeter.im
Wed Apr 13 23:00:11 UTC 2011
Old thread alert!
On 11/19/10 7:20 AM, Philipp Hancke wrote:
> David Richards wrote:
>> I would like to see the advertisement section (2.3) revised to be more
>> prescriptive about how to use the two forms. It seems to me that an XMPP
>> 1.0 stream should only advertise with the old dialback namespace
>> method on
>> the initial stream element of the negotiation in case it's a 0.9
When opening a stream to a peer server, you don't know if the peer is
XMPP-compliant (1.0) or pre-XMPP (0.9), so how can you know whether to
include the dialback namespace or not?
>> If the response is a 0.9 stream then keep going in that
>> mode. If the response is a 1.0 stream, it should not include the old
I don't see any harm in including the dialback namespace, so SHOULD NOT
might be too strong.
>> and then must include a dialback feature. Not including the
>> feature seems wrong - 0220 only says it is preferred, not required.
I'd be fine with that.
>> Preferably, the receiving server would not include the old namespace
>> at all
>> on the stream in response to a 1.0 stream. It just confuses matters.
>> on stream restarts, the old ns should not be used at all by either side.
Ah, I see what you mean -- if you *know* that the other side knows about
XMPP 1.0 then use the stream feature exclusively.
The problem is that no one behaves this way now, so in all likelihood
dialback negotiation would break if your server is strict about this
behavior, resulting in a lack of interoperability.
> This _might_ break things with good old jabberd1. At least not including
> the dialback namespace in the stream header on a 1.0 stream failed back
> in... 2006.
Perhaps we can do some testing? I'm sure there are still jabberd 1.4
servers and other "0.9" implementations on the network. I don't see a
good reason to break backward-compatiblity if we don't have to.
>> Also, why the recommendation to have dialback required and SASL
>> optional if
>> both are advertised? I'm not sure it matters, just curious about the
>> rationale. Seems like the server would mark as required the one that it
>> prefers since it doesn't make sense to do both - sort of a makeshift
>> priority indicator.
> I think we can just remove the <required/> and <optional/>, since that
> is no longer defined in 3920bis :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards