Peter Saint-Andre wrote:
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.
Yes, but it treats it as an error in case of sasl - which it is.
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/>).
This is tricky.
We have two cases now - 3920-bis server trying piggybacking with 3920
server & vice versa.
In the first case, since we go ahead and specify the behavior of
piggybacking and since we expect recipient to always support it ('cos of
the MUST), server will end up attempting piggybacking on a 3920 server
which does not support it. We have servers which do not support it, have
weird issues with it, or partially support it- and each case, the
behavior is impl specific as to what 'happens' : ranging from invalid,
error, stream termination, ignoring request, etc.
Reverse case was never specified properly - and so the 'error' would
most probably be ignored by 3920 server (since that is not what was
expected).
So we do have backward compatibility issue here.
On the flip side, removing piggyback would mean we remove a potentially
underspecified detail for a feature.
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.
yes, which is why we could possibly let it be as simple as possible
while removing complexities from it, and slowly push towards more robust
validation methods.
We now even have an xmpp ca now - so what is the excuse for not having
sasl external with tls :-)
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.
+100
+ 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.
And so i thought, until I was working with dialback with/without tls and
with/without sasl external - the combinations are weird and murky even
for two single server nodes talking to each other.
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?
yes ...
A general question would, especially considering that we have already
deprecated most of the xep's which are pre-xmpp, for long are we going
to continue supporting pre-xmpp protocol behavior (for client & server)
in the rfc's ?
Can we remove that for the bis specs ? Hasn't xmpp not been around long
enough to outgrow the 0.9 compatibility ?
Regards,
Mridul
Peter
