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.
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.
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".)
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.
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.
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.
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>
Matthias
