On May 22, 2012, at 14:58, Peter Saint-Andre wrote: > On 5/21/12 1:21 AM, Philipp Hancke wrote: >> On Thu, 26 Apr 2012, Philipp Hancke wrote: >> >>> old thread alert... >>> >>>> Version 1.3 of XEP-0198 (Stream Management) has been released. >>> >>> I implemented 0198 for s2s and am in general quite happy with it. Some >>> notes I wrote down while implementing this. Thanks Dave for listening >>> to my complaints and thanks Matthew for writing mod_smacks which was >>> useful as the evil peer who did not send acknowledgments. >>> >>> The only major issue is that the case of sm-after-dialback is not >>> explicitly covered... Section 3 has the following text: >>> The client MUST NOT attempt to negotiate stream management until it is >>> authenticated; i.e., it MUST NOT send an <enable/> element until after >>> authentication (such as SASL, Non-SASL Authentication [8] or Server >>> Dialback [9]) has been completed successfully. >>> >>> This does allow the usage of dialback together with session managment. >>> However, there should be at least one example which shows how this is >>> used, especially since the <enable/> element can only be sent after >>> the <db:result type='valid'/> has been received. >>> (this is violating my sense for protocol aesthetics but works >>> reasonbly well) >> >> I have to change my opinion after discovering similar issues related to >> stream compression... >> the requirement the client "MUST NOT attempt to negotiate" until after >> authentication is not necessary in the case of server dialback (which >> after all isn't an authentication mechanism anyway :-) and should be >> removed. >> >> There is no harm done if session managment is enabled before dialback. >> In fact, since there are no stanzas flowing without authentication, the >> counters won't get incremented. >> In terms of implementation this keeps the sm negotiation in one place >> (where stream features are handled). >> >> I've not seen my peer servers (prosody and m-link) send >> <failed><unexpected-request/></failed> so I think that changing this >> requirement is possible without breaking anything. > > I think you're right. I'd go farther and assert that it's wrong to say > that a client must not negotiate stream management before resource > binding (especially since resource binding uses stanzas!). So I suggest > that we remove this sentence: > > "For client-to-server connections, the client MUST NOT attempt to enable > stream management until after it has completed Resource Binding unless > it is resuming a previous session (see Resumption)." >
I think the proposed text goes too far. I am aware of code that would break with this change, because it negotiates after authentication completes but before binding a resource. - m&m Matthew A. Miller <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
