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

Peter Saint-Andre stpeter at stpeter.im
Wed Jun 17 23:03:37 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/17/09 4:31 PM, Alexey Melnikov wrote:
> 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.

OK. We can always change them to things like 2^32.

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

I fixed it up a bit in the previous revision:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u&%40diffWrap=s&r1=3253&r2=3259&u=3&ignore=&k=

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

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

>>> 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. I fixed the examples to make sure
that they all are consistent with that rule.

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

Right. I fixed the examples so that they are consistent in that regard,
but I will check them over again just to be sure.

> And my undestanding is that <r>s and <a>s are not counted.

Correct.

Peter

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5dkgACgkQNL8k5A2w/vxyuACgkIdkFJpufIj9GPOElm3aFYf+
b3kAoL2Lks5221aElSpfl7HGYCvagMwV
=3dPg
-----END PGP SIGNATURE-----



More information about the Standards mailing list