[Standards] LAST CALL: XEP-0198 (Stream Management)

Alexey Melnikov alexey.melnikov at isode.com
Wed Jun 17 22:31:36 UTC 2009


Peter Saint-Andre wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 6/11/09 4:30 PM, Alexey Melnikov wrote:
>
>  
>
>>HTML version, section 4 reads:
>>    
>>
>>>Note: The value of 'h' starts at zero for the first stanza handled and
>>>is incremented 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 XML Schema Part 2
>>><http://www.w3.org/TR/xmlschema-2/> [9
>>><imap://stpeter@mailhost.dizzyd.com:993/fetch%3EUID%3E.INBOX%3E152686?header=quotebody&part=1.1.2&filename=xep-0198.html>]
>>>(i.e., 232), the value of 'h' shall be reset from 232-1 back to zero
>>>(rather than being incremented to 232).
>>>      
>>>
>>I think 232 is 2**32, but it doesn't look this way.
>>    
>>
>
>What browser do you use? The superscript shows up in Firefox 3 and
>Safari 4 on my machine, but I have not tested this on all platforms.
>
Older Mozilla on Windows.

>>In Section 4:
>>    
>>
>>>When an <r/> element ("request") is received, the recipient MUST
>>>acknowledge it by sending an <a/> element to the sender containing a
>>>value of 'h' that is equal to the number of stanzas handled by the
>>>recipient of the <r/> element. The response SHOULD be sent as soon as
>>>possible after receiving the <r/> element, and MUST NOT be withheld
>>>for any condition other than a timeout. For example, a client with a
>>>slow connection might want to collect many stanzas over a period of
>>>time before acking, and a server might want to throttle incoming stanzas.
>>>      
>>>
>>Are these example of things that conform to the last SHOULD?    
>>
>
>Yes...
>  
>
For a moment I thought they were examples demonstrating MUST NOT :-).
I don't know if you can improve the text though.

>>>The sender does not have to wait for an ack to continue sending
>>>stanzas. Because acks indicate stanza acceptance, a server that is
>>>throttling stanzas MUST delay the response until the client is no
>>>longer being penalized (but SHOULD notify the client that it is
>>>throttling incoming stanzas, as described under Throttling
>>><imap://stpeter@mailhost.dizzyd.com:993/fetch%3EUID%3E.INBOX%3E152686?header=quotebody&part=1.1.3&filename=xep-0198.html>).
>>>      
>>>
>>In Section 5:
>>    
>>
>>>Definition: The 'id' attribute defines a unique identifier for
>>>purposes of stream management (an "SM-ID"). The SM-ID MUST be
>>>generated by the receiving entity (server). The initiating entity MUST
>>>consider the SM-ID to be opaque and therefore MUST NOT assign any
>>>semantic meaning to the SM-ID. The receiving entity MAY encode any
>>>information it deems useful into the SM-ID, such as the full JID
>>><localpart at domain.tld/resource> of a connected client (e.g., the full
>>>JID plus a nonce value). Any characters allowed in an XML attribute
>>>are allowed. The SM-ID MUST NOT be reused for simultaneous or
>>>subsequent sessions (as long as the receiving entity is available).
>>>      
>>>
>
>  
>
>>I am not sure I understand the comment in (). Should it read "as long as
>>the session is available"?
>>    
>>
>
>No, in practice it means that as long as the server does not crash the
>server MUST ensure that SM-IDs are unique, but if it crashes then it
>doesn't need to keep track of every SM-ID it has ever generated.
>  
>
Right. This makes more sense. I suggest you either expand the sentence, 
and/or avoid using the word "available" for the receiving entity.

>>>When a session is resumed, the parties SHOULD proceed as follows:      
>>>
>>I suggest removing SHOULD here, as all items below it are already SHOULDs.
>>    
>>
>
>OK, that's better.
>
>  
>
>>>    * Both parties SHOULD retransmit any stanzas that were not handled
>>>      during the previous session, based on the sequence number
>>>      reported by the peer.
>>>      
>>>
>>Why is this just a SHOULD?
>>    
>>
>
>I suppose the client might have returned an error to the user and the
>user might decide not to retransmit.
>
Ok.
It might be worth mentioning this example.

>>In Section 8.1:
>>    
>>
>>>Example 16. Client sends a stanza and requests acknowledgement
>>>C: <iq id='ls72g593' type='get'>
>>>     <query xmlns='jabber:iq:roster'/>
>>>   </iq>
>>>
>>>C: <r xmlns='urn:xmpp:sm:2'/>
>>>  
>>>      
>>>
>>What should be the "h" value from the server below if "iq" and "r" are
>>exchanged?
>>    
>>
You didn't answer my question :-).

>>>The server immediately sends an <a/> element to acknowledge handling
>>>of the stanza and then returns the roster.
>>>
>>>Example 17. Server acknowledges handling of client stanza and sends a
>>>stanza
>>>
>>>S: <a xmlns='urn:xmpp:sm:2' h='0'/>
>>>      
>>>
>
>Oops, that should be h="1" (two stanzas handled by the server).
>
No, I think h='0' is correct. The value starts with 0 for the first 
acknowledged stanza.
And my undestanding is that <r>s and <a>s are not counted.

>
>  
>



More information about the Standards mailing list