On Tue, 22 May 2012, Peter Saint-Andre wrote:
On 5/21/12 7:22 AM, Matthew Wild wrote:
On 21 May 2012 09:08, Philipp Hancke <[email protected]> wrote:
The argument of keeping the negotiation of stream features in one place
mentioned in my mail about 0198 applies to this, too.
(the root cause of both problems is the inability of dialback to renegotiate
stream features after authenti... err... whatever, but i don't
see any way how we could change that.
Yes, Prosody had this issue come up with both compression and 198
recently.
What are the costs and benefits of doing compression before dialback?
cost: you're more vulnerable to "certain denial of service
attacks" -- I'd note that you might already be vulnerable by
offering/using TLS compression to a peer that you can't authenticate.
benefits: stream compression is negotiated in one place
(<features/>). Additionally, compression doesn't break multiplexing.
I have to say it's pushing me over to the
we-need-to-deprecate-dialback camp... solving it in our code for each
individual case is possible, but hacky at best.
Designing something to replace dialback seems like "fun". Getting
everyone to implement and deploy it seems even more fun.
The xmppwg chairs will surely agree when you propose that!
Even if we keep the same authenti...thingy around, at least we should
have something more integrated into our normal feature negotiation.
like SASL is.
We had discussions long ago about defining a SASL mechanism for
dialback. That would slot in rather nicely, no?
The stream-restart model doesn't work with multiplexing.
