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
