From 10d3f5af92ca286360caf0a1921e56608a666ef8 Mon Sep 17 00:00:00 2001 From: Justin Karneges Date: Wed, 3 Oct 2007 23:04:12 +0000 Subject: [PATCH] updates per devcon discussion git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1279 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0198.xml | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/xep-0198.xml b/xep-0198.xml index b14765f5..d237a0ff 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -18,6 +18,12 @@ None ack &infiniti; + + 0.3 + 2007-10-03 + jk +

Updates per devcon discussion.

 + 0.2 2007-04-05 @@ -53,7 +59,7 @@

&xmppcore; does not specify a way for entities in a stream (single-hop) to acknowledge successful receipt of a stanza. This specification proposes a mechanism for efficient and flexible acknowledgement of stanzas. The protocol is intended for use with both Client-to-Server and Server-to-Server streams.

-

It is important not to confuse the facilities provided by this specification with those provided by &xep0022;, &xep0079;, and &xep0184;. The other specifications cover end-to-end and multi-hop acknowledgements, which are useful in special scenarios, but unnecessary and overkill for general use. In contrast, this specification proposes a protocol intended for widespread, general use. It is also expected that this protocol will revive interest in AMP, as single-hop acknowledgements are necessary for AMP delivery receipts to function properly.

+

It is important not to confuse the facilities provided by this specification with those provided by &xep0079; and &xep0184;. The other specifications cover end-to-end and multi-hop acknowledgements, which are useful in special scenarios, but unnecessary and overkill for general use. In contrast, this specification proposes a protocol intended for widespread, general use. It is also expected that this protocol will revive interest in AMP, as single-hop acknowledgements are necessary for AMP delivery receipts to function properly.

There is a lot to be gained by adding this feature to the protocol, such as:

    @@ -80,13 +86,13 @@
  • The initiating entity opens a TCP connection and initiates the stream by sending the opening XML stream header to the receiving entity, including the 'version' attribute set to a value of at least "1.0".
  • The receiving entity responds by opening a TCP connection and sending an XML stream header to the initiating entity, including the 'version' attribute set to a value of at least "1.0".
  • The initiating entity authenticates itself to the receiving entity.
    • -
  • The receiving entity offers the acknowledgement feature to the initiating entity by including it with the list of other supported stream features. The acknowledgement feature MUST NOT be offered unless the initiating entity has been authenticated.
    • -
  • The initiating entity issues the enable command (an <enable/> element qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace) to instruct the receiving entity that it wishes to enable the acknowledgement feature. The element MAY contain a 'previd' attribute and a 'b' attribute, if the initiating entity wishes to recover a previously known acknowledgement session. The value of the 'previd' attribute is set to the same value as the 'id' attribute of the <stream> in the previous session. The value of the 'b' attribute, if applicable, is set to the last received sequence number (discussed below) by the initiating entity. If the initiating entity is not recovering a past session, the 'previd' and 'b' attributes MUST NOT be included.
    • -
  • The receiving entity MUST reply with an <enabled/> element qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace. If the initiating entity provided a 'previd' attribute in the <enable/> element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'b' attribute in the <enabled/> element. The value of this attribute is set to the last received sequence number (discussed below) by the receiving entity in the previous session. If the receiving entity does not support session recovery, or does not recognize the 'previd' as an earlier session, or there is no known last received sequence number for the session, then the attribute MUST NOT be included. If session recovery is used, and the receiving entity still has the previously-identified stream open at this time, the old stream SHOULD be terminated.
    • +
  • The receiving entity offers the acknowledgement feature to the initiating entity by including it with the list of other supported stream features. The acknowledgement feature MUST NOT be offered unless the initiating entity has been authenticated. The acknowledgement feature element MAY contain an 'id' attribute and a <reconnect/> child element, and together they indicate support for session recovery (if one is present, the other MUST be present). The 'id' attribute acts as a unique identifier for the acknowledgement session, if the session is enabled (see below). The <reconnect/> element MAY contain a 'max' attribute, which indicates the number of minutes that a session shall remain recoverable after disconnection.
    • +
  • The initiating entity issues the enable command (an <enable/> element qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace) to instruct the receiving entity that it wishes to enable the acknowledgement feature. The <enable/> element MAY contain a 'reconnect' attribute with value 'yes', to request that the acknowledgement session be made recoverable. The <enable/> element MAY also contain a 'previd' attribute and a 'b' attribute, if the initiating entity wishes to recover a previously known acknowledgement session. The value of the 'previd' attribute is set to the same value as the 'id' attribute of the acknowledgement feature element in the previous session. The value of the 'b' attribute, if applicable, is set to the last received sequence number (discussed below) by the initiating entity. If the initiating entity is not recovering a past session, the 'previd' and 'b' attributes MUST NOT be included.
    • +
  • The receiving entity MUST reply with an <enabled/> element or an <error/> element qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace. The <error/> element indicates that there was a problem enabling the acknowledgement session. The <enabled/> element indicates successful enabling of the acknowledgement session. If the initiating entity provided a 'reconnect' attribute in the <enable/> element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'reconnect' attribute (with value 'yes') in the <enabled/> element to indicate that the session shall be recoverable. If the initiating entity provided a 'previd' attribute in the <enable/> element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'b' attribute in the <enabled/> element. The value of this attribute is set to the last received sequence number (discussed below) by the receiving entity in the previous session. If the receiving entity does not support session recovery, or does not recognize the 'previd' as an earlier session, or there is no known last received sequence number for the session, then the attribute MUST NOT be included. If session recovery is used, and the receiving entity still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.
  • After enabling the feature, the initiating or receiving entity MAY send acknowledgement elements at any time over the stream. An acknowledgement element is either an <r/> element ("request ack") or an <a/> element ("gratuitous ack"), qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace. Both elements will hereby be referred to as simply "ack elements." An <r/> element MUST contain a 'c' attribute and MAY contain a 'b' attribute. An <a/> element MAY contain a 'c' attribute and/or a 'b' attribute. A 'c' attribute is used to indicate a sequence number. It is an integer value generated by the sender, and MUST be strictly increasing, however the sender MAY choose to reset the integer to a lower value if all stanzas sent have been acknowledged. The 'b' attribute acknowledges a previously-received sequence number from the other entity. Thus, an ack element is used to indicate a sequence number (contains 'c'), to acknowledge a sequence number (contains 'b'), or to do both at once (contains 'c' and contains 'b'). Acknowledging a previously-received ack element indicates stanza acceptance, in that all stanzas received up to that point are now safe in the receiver's hands and that the receiver will take care of them. Acks do not indicate successful delivery to a remote entity beyond the receiver.
  • When an <r/> element ("request ack") is received, the recipient MUST acknowledge it by sending an ack element back to the sender. The sender does not have to wait for an ack to continue sending stanzas. The response ack MUST contain a value of 'b' that is greater than or equal to the 'c' value given in the request ack. Acks SHOULD be sent as soon as possible, 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. As acks indicate stanza acceptance, a server that is throttling stanzas MUST defer the acks until the client is no longer being penalized.
    • -
  • When a sequence number is received (via the 'c' attribute), the recipient SHOULD keep a record of this value as the last received sequence number for the current stream. Everytime a new sequence number is received, the previous number can be discarded. If a stream ends, and it is not resumed within a reasonable time (15 minutes is RECOMMENDED), then the sequence number and any associated state MAY be discarded. Before the session state is discarded, implementations SHOULD take alternative action with any unacknowledged stanzas (e.g. stanzas sent after the latest sequence number reported by 'b'). A server implementation SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage. A user-oriented client implementation SHOULD inform the user of the failure via appropriate user-interface elements.
    • -
  • When a session is resumed, and resource binding is completed (if required), both the initiating entity and the receiving entity SHOULD retransmit any stanzas that were not accepted during the previous session, each based on the last received sequence number reported by the other.
    • +
  • When a sequence number is received (via the 'c' attribute), the recipient SHOULD keep a record of this value as the last received sequence number for the current stream. Everytime a new sequence number is received, the previous number can be discarded. If a stream ends, and it is not recovered within the time specified in the acknowledgement feature element, then the sequence number and any associated state MAY be discarded. Before the session state is discarded, implementations SHOULD take alternative action with any unacknowledged stanzas (e.g. stanzas sent after the latest sequence number reported by 'b'). A server implementation SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage. A user-oriented client implementation SHOULD inform the user of the failure via appropriate user-interface elements.
    • +
  • When a session is recovered, and resource binding is completed (if required), both the initiating entity and the receiving entity SHOULD retransmit any stanzas that were not accepted during the previous session, each based on the last received sequence number reported by the other. A client SHOULD NOT request the roster after recovering, as any changes to the roster while the client was disconnected will be sent to the client after it recovers. Similarly, the client SHOULD NOT resend presence stanzas in an act to restore its original presence state, as this state will have been retained by the server.

    • Examples of stanza acknowledgements are provided in the next section.

    @@ -95,17 +101,19 @@ - + + + ]]> + ]]> + ]]> ]]> + ]]> + ]]> @@ -163,6 +171,7 @@ ]]>
  • Ack elements should ideally be sent in the same TCP packet as other stanzas, to reduce the number of total packets sent. In particular, if a request ack is received, applications may want to wait a short period for something else to send before responding, so that the response ack may share a packet with the other data.
    • +
  • When performing acknowledgement session recovery and also utilizing TLS, it is recommended to take advantage of TLS session resuming to further optimize the reconnection process.