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.
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 + use/not
use of 'xmpp 1.0', and combinations seems to have issues across servers.
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.
Regards,
Mridul
I'll update rfc3920bis accordingly so we can see how it all looks.
Peter
