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)."

> typo in section 1: "By conStrast with stream management"

Fixed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


Reply via email to