moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

0.2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@726 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-04-05 17:54:32 +00:00
parent d561e3c05a
commit a22283f666
1 changed files with 47 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
xep-0198.xml
View File

@ -18,6 +18,12 @@
<supersededby>None</supersededby>
<shortname>ack</shortname>
&infiniti;
<revision>
<version>0.2</version>
<date>2007-04-05</date>
<initials>jk</initials>
<remark><p>Require c attribute on &lt;r/&gt; element. Describe minimal implementation. Switch to standard temporary namespace.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-11-21</date>
@ -65,7 +71,7 @@
<p>The following rules apply:</p>
<ol>
<li>An initiating entity that complies with this specification MUST include the 'version' attribute set to a value of "1.0" in the initial stream header.</li>
<li>When a receiving entity that complies with this specification receives an initial stream header that includes the 'version' attribute set to a value of at least "1.0", after sending a stream header in reply (including the version flag), and if the initiating entity has been authenticated, then the receiving entity MUST include an &lt;ack/&gt; element (qualified by the 'http://jabber.org/protocol/ack' namespace) along with the list of other stream features it supports.</li>
<li>When a receiving entity that complies with this specification receives an initial stream header that includes the 'version' attribute set to a value of at least "1.0", after sending a stream header in reply (including the version flag), and if the initiating entity has been authenticated, then the receiving entity MUST include an &lt;ack/&gt; element (qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace) along with the list of other stream features it supports.</li>
</ol>
</section2>
<section2 topic='Narrative' anchor='narrative'>
@ -75,10 +81,10 @@
<li>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".</li>
<li>The initiating entity authenticates itself to the receiving entity.</li>
<li>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.</li>
<li>The initiating entity issues the enable command (an &lt;enable/&gt; element qualified by the 'http://jabber.org/protocol/ack' 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 &lt;stream&gt; 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.</li>
<li>The receiving entity MUST reply with an &lt;enabled/&gt; element qualified by the 'http://jabber.org/protocol/ack' namespace. If the initiating entity provided a 'previd' attribute in the &lt;enable/&gt; element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'b' attribute in the &lt;enabled/&gt; 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.</li>
<li>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 &lt;r/&gt; element ("request ack") or an &lt;a/&gt; element ("gratuitous ack"), qualified by the 'http://jabber.org/protocol/ack' namespace. Both elements will hereby be referred to as simply "ack elements." An ack 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. 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'). As a special exception, an &lt;r/&gt; element that does not contain a 'c' attribute can be used to indicate a hard synchronization point. It is acknowledeged by an ack element that does not contain a 'b' attribute. 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.</li>
<li>When an &lt;r/&gt; 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. If the element received has a 'c' attribute, then the response ack MUST contain a value of 'b' that is greater than or equal to the 'c' value given. If the element received has no 'c' attribute, then the response ack MUST NOT have a 'b' attribute. Thus, it is possible for ack elements to contain no attributes, if the entities don't wish to track sequence numbers. 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.</li>
<li>The initiating entity issues the enable command (an &lt;enable/&gt; 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 &lt;stream&gt; 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.</li>
<li>The receiving entity MUST reply with an &lt;enabled/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace. If the initiating entity provided a 'previd' attribute in the &lt;enable/&gt; element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'b' attribute in the &lt;enabled/&gt; 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.</li>
<li>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 &lt;r/&gt; element ("request ack") or an &lt;a/&gt; 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 &lt;r/&gt; element MUST contain a 'c' attribute and MAY contain a 'b' attribute. An &lt;a/&gt; 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.</li>
<li>When an &lt;r/&gt; 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.</li>
<li>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.</li>
<li>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.</li>
</ol>
@ -89,17 +95,17 @@
<section1 topic='Examples' anchor='examples'>
<example caption='Server responds by sending a stream header to client:'><![CDATA[
<stream:features>
<ack xmlns='http://jabber.org/protocol/ack'/>
<ack xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'/>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
</stream:features>
]]></example>
<example caption='Client enables stanza acknowledgements:'><![CDATA[
<enable xmlns='http://jabber.org/protocol/ack'/>
<enable xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'/>
]]></example>
<example caption='Server informs client that the feature is enabled:'><![CDATA[
<enabled xmlns='http://jabber.org/protocol/ack'/>
<enabled xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'/>
]]></example>
<example caption='Client sends a message, requesting an ack from the server:'><![CDATA[
<message from='laurence@example.net/churchyard'
@ -107,21 +113,10 @@
xml:lang='en'>
<body>I'll send a friar with speed, to Mantua, with my letters to thy lord.</body>
</message>
<r xmlns:ack='http://jabber.org/protocol/ack'/>
<r xmlns:ack='http://www.xmpp.org/extensions/xep-0198.html#ns' c='1'/>
]]></example>
<example caption='Server responds with ack:'><![CDATA[
<a xmlns='http://jabber.org/protocol/ack'/>
]]></example>
<example caption='Client sends a message, requesting an ack from the server using a sequence number:'><![CDATA[
<message from='laurence@example.net/churchyard'
to='juliet@example.com'
xml:lang='en'>
<body>I'll send a friar with speed, to Mantua, with my letters to thy lord.</body>
</message>
<r xmlns:ack='http://jabber.org/protocol/ack' c='1'/>
]]></example>
<example caption='Server responds with sequence number ack:'><![CDATA[
<a xmlns='http://jabber.org/protocol/ack' b='1'/>
<example caption='Server responds with ack:'><![CDATA[
<a xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns' b='1'/>
]]></example>
<example caption='Client sends a message, with attached sequence number:'><![CDATA[
<message from='laurence@example.net/churchyard'
@ -129,58 +124,67 @@
xml:lang='en'>
<body>I'll send a friar with speed, to Mantua, with my letters to thy lord.</body>
</message>
<a xmlns:ack='http://jabber.org/protocol/ack' c='7'/>
<a xmlns:ack='http://www.xmpp.org/extensions/xep-0198.html#ns' c='7'/>
]]></example>
<example caption='Client enables stanza acknowledgements, attempting to recover a previous session:'><![CDATA[
<enable xmlns='http://jabber.org/protocol/ack' previd='c2s_345'/>
<enable xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns' previd='c2s_345'/>
]]></example>
<example caption='Server informs client that the feature is enabled:'><![CDATA[
<enabled xmlns='http://jabber.org/protocol/ack' b='7'/>
<enabled xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns' b='7'/>
]]></example>
</section1>
<section1 topic='Pinging' anchor='pinging'>
<p>Either entity can also ping the other, useful for ensuring that the TCP connection is still up and working, and also determining latency. The procedure should replace the legacy behavior of sending whitespace. Pinging is done by sending a 'ping' element:</p>
<example caption='Pinging the Peer'><![CDATA[
<ping xmlns='http://jabber.org/protocol/ack'/>
<ping xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'/>
]]></example>
<p>The peer then MUST reply immediately with a 'pong' element.</p>
<example caption='Replying to a Ping'><![CDATA[
<pong xmlns='http://jabber.org/protocol/ack'/>
<pong xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'/>
]]></example>
<p>A server that is throttling stanzas (and thus withholding acks until later) SHOULD still immediately reply to pings.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<ul>
<li>
<p>To save bandwidth, it is recommended that implementations specify an XML namespace prefix assignment in the initial &lt;stream&gt; element for the 'http://jabber.org/protocol/ack' namespace.</p>
<example caption='Setting a Namespace Prefix'><![CDATA[
<ul>
<li>
<p>To save bandwidth, it is recommended that implementations specify an XML namespace prefix assignment in the initial &lt;stream&gt; element for the 'http://www.xmpp.org/extensions/xep-0198.html#ns' namespace.</p>
<example caption='Setting a Namespace Prefix'><![CDATA[
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
xmlns:ack='http://jabber.org/protocol/ack'
xmlns:ack='http://www.xmpp.org/extensions/xep-0198.html#ns'
version='1.0'>
]]></example>
<example caption='Acking'><![CDATA[
<example caption='Acking'><![CDATA[
<ack:a/>
]]></example>
</li>
<li>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.</li>
</ul>
</li>
<li>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.</li>
</ul>
</section1>
<section1 topic='Minimal Implementation Guideline' anchor='guideline'>
<p>The Stanza Acknowledgements protocol has a complex appearance, and indeed it is complex to implement if you want to perform all of the optimizations allowed. However, a basic implementation is not very difficult, if you just want simple acking and don't care about sequence numbers too much. Here is what a basic implementation would do:</p>
<ul>
<li>As an initiating entity, send &lt;enable/&gt; with no attributes, and ignore the attributes on the &lt;enabled/&gt; response.</li>
<li>As a receiving entity, ignore the attributes on the &lt;enable/&gt; element received, and respond using &lt;enabled/&gt; with no attributes.</li>
<li>When receiving an &lt;r/&gt; or &lt;a/&gt; element with a 'c' attribute, immediately respond with an &lt;a/&gt; element with a value of 'b' equal to the value of 'c' received.</li>
<li>Keep an integer X for this stream session, initially set to zero. When you are about to send a stanza, first put the stanza (paired with the current value of X) in an "unacknowleged" queue. Then send the stanza over the wire followed by &lt;r c='[value of X]'/&gt;, and increment X by 1. When receiving an &lt;r/&gt; or &lt;a/&gt; element with a 'b' attribute, all stanzas whose paired value (X at the time of queuing) is less than or equal to the value of 'b' can be removed from the queue.</li>
</ul>
<p>This is enough of an implementation to minimally satisfy the remote entity, and allows basic tracking of your own stanzas sent. If the stream connection is broken, you have a queue of unacknowledged stanzas that you can choose to do something with.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This XEP requires no interaction with &IANA;. </p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>Upon approval of this XEP, the Jabber Registrar shall add 'http://jabber.org/features/ack' to its registry of stream features.</p>
<p>Upon approval of this XEP, the Jabber Registrar shall add 'http://www.xmpp.org/extensions/xep-0198.html#ns' to its registry of stream features.</p>
</section2>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Upon approval of this XEP, the &REGISTRAR; shall add 'http://jabber.org/protocol/ack' to its registry of protocol namespaces.</p>
<p>Upon approval of this XEP, the &REGISTRAR; shall add 'http://www.xmpp.org/extensions/xep-0198.html#ns' to its registry of protocol namespaces.</p>
</section2>
</section1>
@ -191,8 +195,8 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/features/ack'
xmlns='http://jabber.org/features/ack'
targetNamespace='http://www.xmpp.org/extensions/xep-0198.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'
elementFormDefault='qualified'>
<xs:element name='ack'/>
@ -206,8 +210,8 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/ack'
xmlns='http://jabber.org/protocol/ack'
targetNamespace='http://www.xmpp.org/extensions/xep-0198.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0198.html#ns'
elementFormDefault='qualified'>
<xs:element name='enable' type='empty'/>