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