[Standards] LAST CALL: XEP-0198 (Stream Management)
stpeter at stpeter.im
Thu Jun 11 22:58:49 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
>> (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.
> 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?
>> 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
> 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.
>> The SM-ID SHOULD NOT be longer than 4000 bytes.
>> 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.
> In Section 8.1:
>> Example 16. Client sends a stanza and requests acknowledgement
>> C: <iq id='ls72g593' type='get'>
>> <query xmlns='jabber:iq:roster'/>
>> C: <r xmlns='urn:xmpp:sm:2'/>
> What should be the "h" value from the server below if "iq" and "r" are
>> 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
>> S: <a xmlns='urn:xmpp:sm:2' h='0'/>
Oops, that should be h="1" (two stanzas handled by the server).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards