On 5/22/12 3:08 PM, Matthew Miller wrote: > > 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.
I was proposing to remove that text, which seems in line with what you report. Peter -- Peter Saint-Andre https://stpeter.im/
