[Standards] dialback: piggybacking
stpeter at jabber.org
Wed Jun 20 21:29:19 UTC 2007
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".)
>> 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.
> 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.
I'll update rfc3920bis accordingly so we can see how it all looks.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards