[Standards] dialback: piggybacking

Mridul Muralidharan 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 
>>> 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.
> 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"


Mridul

> 
> Regards,
> Mridul
> 
> 
>>
>> I'll update rfc3920bis accordingly so we can see how it all looks.
>>
>> Peter
>>
> 



More information about the Standards mailing list