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.
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://[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.
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.
