Mridul Muralidharan wrote:
Peter Saint-Andre wrote:Matthias Wimmer wrote:Hi Peter!Peter Saint-Andre schrieb:1. Dialback itself is not mandatory to implement, so a change to dialback would not affect the XMPP versioning.Well ... I think it would be okay to just remove dialback without changing the versioning. But if you advertize support for dialback by including its namespace, you have to be compatible with dialback as specified in RFC 3920.Right, everything in rfc3920bis will be backward-compatible with RFC3920.2. Removing piggybacking from the specification would not mean that an implementation MUST NOT do piggybacking, only that such behavior is not specified.Just removing specification would not make the situation better, I think.I agree. Nothing says that piggybacking must be specified in rfc3920bis, but I think it's always better to document things than not to document them (well, except for the route and log stuff from jabberd 1.x).Piggybacking was woefully underspecified in RFC 3920. The only text I can find is this:******After successful dialback negotiation, the Receiving Server SHOULD accept subsequent <db:result/> packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables "piggybacking" of the original validated connection in one direction.******It is really interesting that it is only a SHOULD. I expected it to be a MUST. In the SHOULD case we indeet might be able to remove it. But still SHOULD means that it should be implemented as long as there are no "valid reasons in particular circumstances" not to implement it. (It's not the term "MAY".)Correct.We have tried to specify it more completely in rfc3920bis:[...]Reads okay ... but as you said it should be specified how error flows are handled. I.e. how a server not supporting piggybacking does refuse its use and how a server trying to do piggybacking has to react when the other server refuses its use.Yes, let's fix that up.The error flows are not well specified here. In particular:1. What does the Receiving Server return to the Originating Server if it does not accept <db:result/> over the validated connection?My first thought was <db:result type='invalid'/>, but this would not allow to differentiate between a failed dialback and a dialback that is just not accepted on this connection.Yes, and I think it would be good to differentiate between those two cases.2. What does the Authoritative Server return to the Receiving Server if it does not accept <db:verify/> over the validated connection?Same with <db:verify type='invalid'/>Presumably, if the Receiving Server in #1 or the Authoritative Server in #2 does not want to do piggybacking, they would close the streams in question. But it is still possible for the Originating Server in #1 or the Receiving Server in #2 to send a <db:result/> or <db:verify/> before the stream is closed, so we need to specify how these are handled. A <not-authorized/> or <policy-violation/> stream error?I think that in this case the stream should not be closed. The server just refused to do additional authentication on this stream. It can still be used for the already authenticated domain.Ah, OK.Also the server should notify which db:result/db:verify was not accepted. So maybe it should return something like this:<db:result type='error' to='example.com' from='example.net'>98AF014EDC0...</db:result>or<db:verify type='error' to='example.com' from='example.net' id='457F9224A0...'>98AF014EDC0...</db:verify>That works for me.This would also be change of behavior from 3920.Either way, it looks like we are going to introduce incompatibility with 3920.
A change of behavior can be backward-compatible. For example, rfc3920bis introduces a new SASL error condition and two new stanza error conditions. Those changes are backward-compatible since an older implementation knows that there is an error, but it doesn't understand the new error condition.
In the case of dialback, error handling was never specified very well. The only thing the Receiving Server can return to the Originating Server is a <db:result/> element of type='valid' or type='invalid' (same for what the Authoritative Server returns to the Receiving server, except the element is <db:verify/>).
So naturally we could stick with those values of the 'type' attribute rather than introducing type='error'. A server that wants to piggyback on an existing stream would simply get type='invalid' back if its peer does not support piggybacking. That doesn't tell you very much, does it? But the fundamental problem is with dialback as it has been defined since the year 2000, since it never had good error handling. What's in RFC 3920 is essentially informational documentation of what was in use at that time.
So it would be better to just remove support for piggybacking.I am not sure what sort of gain we get by having piggybacking around, but the relative increased complexity does lead to fragile implementations in s2s - even vanilla dialback + tls required
Well naturally the real solution is to use domain certificates.
+ use/not use of 'xmpp 1.0', and combinations seems to have issues across servers.
The use of the '1.0' flag is pretty clearly specified in RFC 3920, I think.
Btw, are we not moving to using the stream feature instead of the db namespace in the stream to advertise dialback ? In which case, we could just deprecate both use of the namespace, and support for dialback.
Removing the namespace is backward-incompatible with 0.9 servers, no? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
