Some feedback following inlined. On 03.09.10 12:19, Dave Cridland wrote: >> ]]></example> >> <p>The <enabled/> element MAY include a 'max' attribute to >> specify the receiving entity's preferred maximum resumption time.</p> >> <p>The <enabled/> element MAY include a 'stanzas' attribute >> to specify the receiving entity's preferred number of stanzas between >> acks.</p> >> - <p>For client-to-server connections, the client SHOULD NOT attempt >> to enable stream management until after it has completed Resource >> Binding <em>unless it is resuming a previous session</em> (see <link >> url='#resumption'>Resumption</link>). The server MAY enforce this >> order and return a <failed/> element in response (see <link >> url='#errors'>Error Handling</link>).</p> >> + <p>In no case may an initiating entity negotiate stream management >> until it is authenticated, thus the client MUST NOT send an >> <enable/> element until after authentication (such as SASL, >> &xep78; or &xep220;) has been completed successfully.</p> >> + <p>For client-to-server connections, the client MUST NOT attempt >> to enable stream management until after it has completed Resource >> Binding <em>unless it is resuming a previous session</em> (see <link >> url='#resumption'>Resumption</link>).</p> >> + <p>The server SHALL enforce this order and return a >> <failed/> element in response (see <link url='#errors'>Error >> Handling</link>).</p> >> <example caption='Server returns error if client attempts to >> enable stream management before resource binding'><![CDATA[ >> S: <failed xmlns='urn:xmpp:sm:2'> >> <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > > I've tightened up the C2S requirement, because there's no signalling > to allow a client to know if it can enable 198 prior to resource > binding or not, and suck-it-and-see is not an extension mechanism. > > I've also specifically stated here about the requirement to enable > only after auth - previously this was implicit in the feature > announcement restriction. > +1 on these changes which make client and server enforce each others' correct behavior.
> >> @@ -217,11 +219,16 @@ S: <failed xmlns='urn:xmpp:sm:2'> >> <li>The 'h' attribute identifies the last >> <strong>handled</strong> stanza (i.e., the last stanza that the >> receiver will acknowledge as having received).</li> >> </ul> >> <p>An <a/> element MUST possess an 'h' attribute.</p> >> - <p>An <r/> element SHOULD NOT possess any attributes.</p> >> + <p>An <r/> element has no defined attributes.</p> > > Being picky. I don't care. Guess it makes only a difference for those who intent to break the spec. > >> <p class='def'><strong>Definition:</strong> Acknowledging a >> previously-received ack element indicates that the stanza(s) sent >> since then have been "handled" by the receiver. By "handled" we mean >> that the receiver has accepted responsibility for a stanza or stanzas >> (e.g., to process the stanza(s) directly, deliver the stanza(s) to a >> local entity such as another connected client on the same server, or >> route the stanza(s) to a remote entity at a different server); until >> a stanza has been affirmed as handled by the receiver, that stanza is >> the responsibility of the sender (e.g., to resend it or generate an >> error if it is never affirmed as handled by the receiver).</p> >> - <p>Note: The value of 'h' starts at zero before any stanzas are >> handled, is incremented to one for the first stanza handled, and is >> incremented again with each subsequent stanza handled. In the >> unlikely case that the number of stanzas handled during a stream >> management session exceeds the number of digits that can be >> represented by the unsignedInt datatype as specified in >> &w3xmlschema2; (i.e., 2<span class='super'>32</span>), the value of >> 'h' shall be reset from 2<span class='super'>32</span>-1 back to zero >> (rather than being incremented to 2<span class='super'>32</span>).</p> >> - <p>The following example shows a message sent by the client, a >> request for acknowledgement, and an ack of the stanza.</p> >> + <p>Receipt of an <r/> element does not imply that new stanzas >> have been transmitted by the peer; receipt of an <a/> elementonly >> indicates new stanzas have been processed if the 'h' attribute has >> incremented.</p> > > This para basically states that you can say <r/> at any time without > harm, and you can acknowledge stanzas as many times as you like. > > Tobias's code repeats <r/>'s at times, and I found it did no harm. Nor > did responding to them. Therefore I'm allowing the behaviour, since I > think it'll be quite common. > This is by accident. The way I implemented it in Psi is having a sending queue of unacked stanzas. If that has more than 5 or so elements in it I'll send an ack-request each 3 or so messages. This is so I don't send an ack-request for each message after more than 5 unacked messages are in the queue. In the case the user just enters one message Psi waits 30 seconds until it requests an ack even though the send queue has less than 6 stanzas in it. Why it repeats <r/>'s at times for a single stanza is up to be discovered in an investigation. > >> + <p>Note: The value of 'h' starts at zero at the point stream >> management is enabled or requested to be enabled, is incremented to >> one for the first stanza handled, and is incremented by one again >> with each subsequent stanza handled. In the unlikely case that the >> number of stanzas handled during a stream management session exceeds >> the number of digits that can be represented by the unsignedInt >> datatype as specified in &w3xmlschema2; (i.e., 2<span >> class='super'>32</span>), the value of 'h' shall be reset from 2<span >> class='super'>32</span>-1 back to zero (rather than being incremented >> to 2<span class='super'>32</span>).</p> > > So there's two 'h' values, which the text hadn't really made clear, > even though it's obvious. Less obvious is that they get reset to zero > at different times. > > Both Tobias and I reset our counts to zero on the <enable/>, and this > seemed sensible behaviour. Otherwise, you need to turn on 198 prior to > enabling it, which seems weird when you can't do anything useful at > that point. What also came to mind while implementing XEP-0198 is that it might be nice to have one value in the unsignedInt data type value range for an uninitialized/ack hasn't started yet value. One could start counting at 1 instead of 0 to archive this. In the end it also works without that, true. Wonder if it's worth a change. > >> + <p>(( Not quite... There are two values of h, one for the >> initiator, and one for the receiver. The Initiator's value needs to >> be intialized to 0 at the transmission or receipt of <enable/>, >> the receiver's at the transmission or receipt of <enabled/>. It is >> to be expected that the receiver will response immediately to >> <enable/> and reset both counters. ))</p> > > I forgot to remove this - a note to myself about what needed clarifying. > > >> + <p>The following annotated example shows a message sent by the >> client, a request for acknowledgement, and an ack of the stanza.</p> > > I annotated the example to make it clearer about what each actor does, > and when each counter is set. > > >> - <p>When a party returns an ack in response to an <r/> >> element or receives such an ack, it SHOULD keep a record of the 'h' >> value returned as the sequence number of the last handled stanza for >> the current stream (and discard the previous 'h' value).</p> >> - <p>If a stream ends and it is not resumed within the time >> specified in the original <enabled/> element, the sequence >> number and any associated state MAY be discarded by both parties. >> Before the session state is discarded, implementations SHOULD take >> alternative action regarding any unhandled stanzas (i.e., stanzas >> sent after the most recent 'h' value):</p> >> + <p>When a party receives an ack it SHOULD keep a record of the 'h' >> value returned as the sequence number of the last handled outbound >> stanza for the current stream (and discard the previous value).</p> >> + <p>If a stream ends and it is not resumed within the time >> specified in the original <enabled/> element, the sequence >> number and any associated state MAY be discarded by both parties. >> Before the session state is discarded, implementations SHOULD take >> alternative action regarding any unhandled stanzas (i.e., stanzas >> sent after the most recent 'h' value received):</p> > > Decided to make this clearer about which direction acks need > recording. I'm still unhappy with the parenthesis at the end, I think > that's actually somewhat misleading, depending on how it's read. > +1 >> <section1 topic='Resumption' anchor='resumption'> >> <p>It can happen that an XML stream is terminated unexpectedly >> (e.g., because of network outages). In this case, it is desirable to >> quickly resume the former stream rather than complete the tedious >> process of stream establishment, roster retrieval, and presence >> broadcast.</p> >> + <p>In addition, this allows entities to establish definitively >> which stanzas require resending and which do not, eliminating replay >> issues.</p> > > I thought I'd add this in, since it's not made clear elsewhere. > > XEP-0198 acking moves the error case from omission to duplication - > usually that's a preferably error - but resumption also removes the > duplication, as well as making everything a bit more predictable. > > It *also* does fast-reconnect, but that's almost a by-product. > >> @@ -419,6 +435,7 @@ C: <message/> >> C: <r/> >> S: <a h='9'/> >> ]]></example> >> + <p>In particular, on mobile networks, it is advisable to only >> request and/or send acknowledgements when there is other data to be >> sent, or in lieu of a &xep199 ping or whitespace probe.</p> >> </section2> > > Just a small comment there in the implementation notes. > > Dave. Some comment on the throttling part, which I haven't implemented. At the end of section 6 it says "If the number of unacknowledged stanzas is greater than or equal to the value of the 'stanzas' attribute, a throttled peer MUST NOT send any further stanzas.". It would be nice to mention possible UI consequences of this. Section 8 (Stream Closure) reads like it also applies to basic acking scenario without resumption support. However for a server it doesn't make any sense to keep the session after the client's TCP connection got closed since there's no way to continue the acking session with the corresponding h-values. In this case an unavailable presence should be send out like a abnormal disconnection of C2S TCP stream without usage of XEP-0198. Of course it makes sense to maintain the session if resumption is supported and the C2S TCP stream breaks for a limited amount of time. I think the XEP should recommend a time span here, while I don't know what could be useful here. Maybe 30 minutes or so? That's all the feedback I got for now. I've also noticed one issue in the XML->PDF translation when 2^32 is used (in PDF it renders to 232 which is a bit less than 2^32). I'll try to fix that in our publishing tool chain. Cheers, Tobi -- Tobias Markmann http://ayena.de
smime.p7s
Description: S/MIME Cryptographic Signature
