[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