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

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

Hash: SHA1

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


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



- --
Peter Saint-Andre

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


More information about the Standards mailing list