[Standards] dialback: piggybacking
mridul at sun.com
Thu Jun 21 00:41:46 CDT 2007
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
>> 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".)
>>>> 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
>>>> 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
>>> 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'
>>> <db:verify type='error' to='example.com' from='example.net'
>> 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
> 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"
>> I'll update rfc3920bis accordingly so we can see how it all looks.
More information about the Standards