On May 22, 2012, at 15:10, Peter Saint-Andre wrote: > 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. >
Ah, ok, I read "remove" and thought "add" (-: ALl is well! - 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
