while implementing stream compression I found that 0170 requires me to do
compression after dialback. Actually I complained about that more than six
years ago, but only now I have a technical argument why this is a bad
idea. Conclusions at the bottom.
The reason why stream compression is after some kind of authentication is
probably to have an asserted idenity of the peer and avoid offering it to
parties whose trust level is not high enough (aka: you trust those parties
never to send zlib bombs). That concern is valid.
However, the recommended order requires a stream restart after dialback
which is somewhat uncommon and bothered me. This can go wrong under
certain circumstances related to multiplexing (aka piggybacking).
Suppose the following s2s scenario, R: stands for a stanza received by the
s2s client, S: for a stanza sent by the s2s client.
R:
<stream:features>
<compression xmlns='http://jabber.org/features/compress'/>
<method>zlib</method>
</compression>
</stream:features>
S:
<db:result from=one to=example>somekey</db:result>
<db:result from=sub.one to=example>someotherkey</db:result>
<db:result from=two to=example>yetanotherkey</db:result>
R:
<db:result from=example to=one type=valid/>
S:
<compress ...>...</compress>
R:
<db:result from=example to=two type=valid/>
(handling this should not be a problem)
R:
<compressed/>
after this there is a stream restart. That stream restart will change
the stream id. This means the receiving server _might_ have problems finding
the corresponding stream for delivering the verification result to
originating server (if it is using the combination of from/to/id for the
lookup).
During the stream restart, the originating server has to send an initial
stream header to the receiving stream header.
Now, there is still the result of the dialback for the domain pair
sub.one/example. If the verification result from the authorative server
arrives (timing issue!) before the receiving server sends the response
stream header then either
a) the receiving server has to do checks and hold back the <db:result/>
b) things go bad, i.e. the <db:result/> is sent before the stream header
Holding back the dialback result is a requirement I never not noticed
while implementing dialback and I doubt anyone does this.
I think that the benefit of having an asserted name instead of
an ip address is not worth the extra complexity that implementing this
order would require.
Hence I would propose to update 0170 (which might be necessary for things
like 0198 and 0288 anyway)
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.
:-/
philipp
