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

Alexey Melnikov alexey.melnikov at isode.com
Thu Jun 18 10:04:59 UTC 2009


Peter Saint-Andre wrote:

>>>>>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.
>>    
>>
>
>In the previous revision I modified it to read:
>
>The SM-ID MUST NOT be reused for simultaneous or subsequent sessions
>(but the server need not ensure that SM-IDs are unique for all time,
>only for as long as the server is continuously running).
>  
>
This is better, thanks.

>>>>>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.
>>    
>>
>
>I had previously (in 0.10) adjusted the wording slightly here:
>
>A user-oriented client SHOULD try to silently resend the stanzas upon
>reconnection or inform the user of the failure via appropriate
>user-interface elements.
>  
>
This looks better, thanks.

>>>>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 :-).
>>    
>>
>Increment "h" for each stanza handled.
>
Yes, but I am talking about a corner case when the other end didn't 
handle any stanzas yet.
What is the value of "h" in such case?

>I fixed the examples to make sure
>that they all are consistent with that rule.
>  
>




More information about the Standards mailing list