[Standards] dialback: piggybacking

[Peter Saint-Andre]

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.

I'll update rfc3920bis accordingly so we can see how it all looks.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070620/4d7fb40f/smime.bin