-----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://[email protected]: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://[email protected]: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
>>>> <[email protected]/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-----
