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.
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.
To be read as "In which case, we could just deprecate both use of the
namespace to indicate support for dialback and piggybacking"
Mridul
Regards,
Mridul
I'll update rfc3920bis accordingly so we can see how it all looks.
Peter
