[Standards] dialback: piggybacking

Mridul Muralidharan mridul at sun.com
Thu Jun 21 12:12:13 CDT 2007


Justin Karneges wrote:
> On Thursday 21 June 2007 8:42 am, Peter Saint-Andre wrote:
>> Matthias Wimmer wrote:
>>> Philipp Hancke schrieb:
>>>> Most of the complexity of piggybacking must be implemented on the
>>>> originating server. There are (lots of) pitfalls when deciding whether
>>>> to use piggybacking on 1.0 streams which are encrypted by TLS or
>>>> authenticated by SASL, etc.
>>>> Yet, as the spec does not mandate that you MUST reuse a connection, you
>>>> don't have to implement 'active' piggybacking.
>>>>
>>>> What about discouraging active usage ("you don't want to implement
>>>> that") while keeping 'passive' support (on the receiving  server) for
>>>> backward compability?
>>> I would not like to see active piggybacking discouraged. But maybe it
>>> would really be a good idea to make passive support a MUST (should not
>>> be hard to implement) while active support could get downgreaded from
>>> SHOULD to MAY.
>> It's worth considering.
> 
> Of all the places in Jabber to value backwards compatibility, dialback is 
> arguably the most important.  IMO, the real trouble is not the implementation 
> difficulty, but the fact that dialback is underspecified in the RFCs.  Let's 
> get this thing fully specified in the bis drafts, and then I agree with 
> Matthias: MUST for receiving and MAY for sending is the most compatible path 
> to take.
> 
> -Justin

MUST is a bit too strong. Unless the MUST is going to result in 'always 
return error saying piggybacking is not supported'.
Which would, imo, be against the spirit of introducing it anyway.

It is because dialback is important for bacjward compatibility (though 
something we should actively consider deprecating in favor of sasl 
external/etc) that I am not in favor of complicating it further.

Implementation fragility due to complexity is not a good thing to have 
in a spec - and dialback already allows various weird combinations 
possible in a cluster.

Mridul


More information about the Standards mailing list