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

Alexey Melnikov alexey.melnikov at isode.com
Thu Jun 11 22:30:24 UTC 2009


XMPP Extensions Editor wrote:

>This message constitutes notice of a Last Call for comments on XEP-0198 (Stream Management).
>
>Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements, stream resumption, and throttling notifications.
>
>URL: http://www.xmpp.org/extensions/xep-0198.html
>
>This Last Call begins today and shall end at the close of business on 2009-06-12.
>
>Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
>
>1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
>  
>
Yes.

>2. Does the specification solve the problem stated in the introduction and requirements?
>  
>
Yes.

>3. Do you plan to implement this specification in your code? If not, why not?
>  
>
I think the answer to this is Yes, even though I have no real say in 
this :-). [Curtis/Dave might implement this.]

>4. Do you have any security concerns related to this specification?
>  
>
Yes, I think there is a missing security consideration: the receiving 
entity should disallow resuming sessions not belonging to the 
authenticated user.

>5. Is the specification accurate and clearly written?
>  
>
I think it is. I have some minor comments/questions.

>Your feedback is appreciated!
>  
>

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 
> <cid:part1.07060906.02010506 at isode.com>] (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.


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 
> <cid:part2.00080805.00080005 at isode.com>).


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"?

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

>     * 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?



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?

> 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'/>
>
>S: <iq id='ls72g593' type='result'>
>     <query xmlns='jabber:iq:roster'>
>       <item jid='juliet at capulet.lit'/>
>       <item jid='benvolio at montague.lit'/>
>     </query>
>   </iq>
>
>    
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090611/9f3ae884/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090611/9f3ae884/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090611/9f3ae884/attachment-0002.html>


More information about the Standards mailing list