On 5/22/12 3:20 PM, Matt Miller wrote: > > On May 22, 2012, at 15:11, Matthew Miller wrote: > >> >> 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! >> > > Actually, I'm backtracking (-: > > The code I'm thinking of is wrong anyway, and such a spec change > would have larger ramifications; a (client) client that tried to > enable before bind (which would be valid with the proposed removal) > would get <failed/> against a server that is strictly following the > current text.
Truly I don't have a strong preference for change here... Peter -- Peter Saint-Andre https://stpeter.im/
