<p>The current plan is to move SHA-1 to a SHOULD NOT, SHA-256, SHA3-256 and BLAKE2b256 to MUST, and SHA-512, SHA3-512, and BLAKE2b512 to SHOULD by the end of 2016.</p>
<p>These recommendations ought to be reviewed yearly by the &COUNCIL;.</p>
<p>If an entity supports the protocol defined herein, it MUST report that by including a &xep0030; feature of "urn:xmpp:hashes:1" in response to disco#info requests, along with one service discovery feature for each algorithm it supports:</p>
<examplecaption="Service discovery information request"><![CDATA[
<!ENTITY R3TF "<span class='ref'><linkurl='http://realtimetext.org/'>Real-Time Text Taskforce</link></span><note>Real-Time Text Taskforce (R3TF) <<linkurl='http://realtimetext.org/'>http://realtimetext.org/</link>>.</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -204,7 +205,7 @@
@@ -204,7 +205,7 @@
<p>Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender client while a message is being composed. This allows the recipient to see the latest message text from the sender, without waiting for the full message to be sent in a <body/> element.</p>
<p>This is a basic example of a <strong>real-time message</strong> "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a <body/> element (to remain <linkurl="#backwards_compatible">Backwards Compatible</link>):</p>
<p>The <rtt/> element contains one or more child elements that represent <linkurl="#realtime_text_actions">Real-Time Text Actions</link> such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/><strong>action element</strong>, which appends text to the end of a message.</p>
<p>Transmission of the <rtt/> element occurs at a regular <linkurl="#transmission_interval">Transmission Interval</link> whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs.</p>
<p>There MUST NOT be more than one <rtt/> element per <message/> stanza.</p>
<li><p><strong>Initialize a new real-time message: <rtt event="new"/> and <rtt event="reset"/></strong><br/>
Sender clients MUST use an <rtt/> element containing either event="new" or event="reset" in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all <linkurl="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included within the <rtt/> element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e., cleared prior to immediately processing action elements).</p></li>
<li><p><strong>Both <rtt event="new"/> and <rtt event="reset"/> are logically identical to recipients, except for presentation:</strong><br/>
For recipients, these differ only for optional presentation purposes (e.g., highlighting newly started incoming messages). Senders SHOULD use event="new" when sending the first text of a new message (e.g., the first key presses), and only use event="reset" when doing <linkurl="#message_refresh">Message Refresh</link> or <linkurl="#simple_realtime_text">Simple Real-Time Text</link>. See <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing <rtt event="edit"/> or <rtt/><br/></strong>Sender clients SHOULD transmit this element at a regular <linkurl="#transmission_interval">Transmission Interval</link> while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See <linkurl="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming <rtt event="edit"/> or <rtt/><br/></strong>Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received <rtt/> elements from the same sender. If 'seq' increments as expected, the <linkurl="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if 'seq' does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event="new" or event="reset". See <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Committing a real-time message: Delivery of a <body/> element</strong><br/>
A real-time message is considered complete upon receiving <body/>. See <linkurl="#body_element">Body Element</link>.</p></li>
Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The 'seq' attribute is ignored by recipient clients. See <linkurl="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until event="init" is used again), and handle any unfinished real-time messages appropriately (e.g., clearing or saving the message). The 'seq' attribute is ignored by recipient clients. See <linkurl="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Starting value for seq attribute:</strong><br/>
Sender clients MAY use any new starting value for 'seq' when initializing a real-time message using event="new" or event="reset". Recipient clients receiving such elements MUST use this 'seq' value as the new starting value. A random starting value is RECOMMENDED to improve reliability of <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <linkurl="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> and <linkurl="#simultaneous_logins">Simultaneous Logins</link>.</p></li>
</ul>
<ul>
<li><p><strong>Initialize a new real-time message: <rtt event="new"/> and <rtt event="reset"/></strong></p>
<p>Sender clients MUST use an <rtt/> element containing either event="new" or event="reset" in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all <linkurl="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included within the <rtt/> element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e., cleared prior to immediately processing action elements).</p></li>
<li><p><strong>Both <rtt event="new"/> and <rtt event="reset"/> are logically identical to recipients, except for presentation:</strong></p>
<p>For recipients, these differ only for optional presentation purposes (e.g., highlighting newly started incoming messages). Senders SHOULD use event="new" when sending the first text of a new message (e.g., the first key presses), and only use event="reset" when doing <linkurl="#message_refresh">Message Refresh</link> or <linkurl="#simple_realtime_text">Simple Real-Time Text</link>. See <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing <rtt event="edit"/> or <rtt/></strong></p>
<p>Sender clients SHOULD transmit this element at a regular <linkurl="#transmission_interval">Transmission Interval</link> while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See <linkurl="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming <rtt event="edit"/> or <rtt/></strong></p>
<p>Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received <rtt/> elements from the same sender. If 'seq' increments as expected, the <linkurl="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if 'seq' does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event="new" or event="reset". See <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Committing a real-time message: Delivery of a <body/> element</strong></p>
<p>A real-time message is considered complete upon receiving <body/>. See <linkurl="#body_element">Body Element</link>.</p></li>
<p>Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The 'seq' attribute is ignored by recipient clients. See <linkurl="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<p>Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until event="init" is used again), and handle any unfinished real-time messages appropriately (e.g., clearing or saving the message). The 'seq' attribute is ignored by recipient clients. See <linkurl="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Starting value for seq attribute:</strong></p>
<p>Sender clients MAY use any new starting value for 'seq' when initializing a real-time message using event="new" or event="reset". Recipient clients receiving such elements MUST use this 'seq' value as the new starting value. A random starting value is RECOMMENDED to improve reliability of <linkurl="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <linkurl="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> and <linkurl="#simultaneous_logins">Simultaneous Logins</link>.</p></li>
<p>The real-time message is considered complete upon receipt of a standard <body/> element (as qualified by the 'jabber:client' namespace in &xmppim;). The delivered text within <body/> is considered the final message text, and supersedes the real-time message. In the ideal case, the text within <body/> is redundant since it is identical to the final contents of the real-time message.</p>
<p>Supports the transmission of text, including key presses, and text block inserts.<br/>
<em>Note: Text can be any</em><em>subset of text allowed in the <body/> element of a <message/>. If <t/> is empty or blank, no text modification takes place.</em></p>
<p><code><![CDATA[<t>text</t>]]></code></p>
<code><![CDATA[<t>text</t>]]></code>
<p>Append specified <strong>text</strong> at the end of message. ('p' defaults to message length).<br/>
<em>Note: This action element is the minimum support REQUIRED for sender clients (i.e., speech transcription, chat bots, and <linkurl="#simple_realtime_text">Simple Real-Time Text</link> are still possible without supporting additional action elements).</em></p>
<p><code><![CDATA[<t p='#'>text</t>]]></code></p>
<code><![CDATA[<t p='#'>text</t>]]></code>
<p>Inserts specified <strong>text</strong> at position 'p' in the message text.</p>
<p>Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the backspace key, the delete key, and text block deletes.<br/>
<em>Note: Excess backspaces MUST be ignored by the receiving client. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.</em></p>
<p><code><![CDATA[<e/>]]></code></p>
<code><![CDATA[<e/>]]></code>
<p>Remove 1 character from end of message. ('n' defaults to “1”, and 'p' defaults to message length)</p>
<p><code><![CDATA[<e p='#'/>]]></code></p>
<code><![CDATA[<e p='#'/>]]></code>
<p>Remove 1 character before character position 'p' in message. ('n' defaults to “1”)</p>
<p><code><![CDATA[<e n='#'/>]]></code></p>
<code><![CDATA[<e n='#'/>]]></code>
<p>Remove 'n' characters from end of message. ('p' defaults to message length)</p>
<p><code><![CDATA[<e n='#' p='#'/>]]></code></p>
<code><![CDATA[<e n='#' p='#'/>]]></code>
<p>Remove 'n' characters before character position 'p' in message.</p>
<p>Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p><code><![CDATA[<w n='#'/>]]></code></p>
<code><![CDATA[<w n='#'/>]]></code>
<p>Wait 'n' milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large 'n' values that exceed the average <linkurl="#transmission_interval">Transmission Interval</link>. Recipient clients MAY selectively shorten or ignore the pauses ('n') in <w/> action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of <w/> elements where the total of pauses exceeds a transmission interval cycle. See <linkurl="#receiving_realtime_text">Receiving Real-Time Text</link>.</p>
<p>A message refresh is the sender's partially composed text being (re)transmitted via <rtt event="reset"/>. The recipient client(s) can seamlessly redisplay the real-time message as a result. This allows real-time text to resume quickly, without waiting for senders to start a new message:</p>
<t>This is a retransmission of the entire real-time message.</t>
</rtt>]]></code></p>
</rtt>]]></code>
<p>The message refresh SHOULD be transmitted at intervals during active typing or composing. The RECOMMENDED interval is 10 seconds. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval can be varied, or be set to a longer time period, in order to reduce average bandwidth (e.g., long messages, infrequent or minor message changes). To save bandwidth, message refreshes SHOULD NOT occur continuously while the sender is idle. To allow quicker resumption of real-time text, sender clients MAY adjust the timing of the message refresh to occur right after any of the following additional events:</p>
<ul>
<li>When the recipient starts sending messages from a different full JID (e.g., switched clients);</li>
<p>If a client supports this real-time text protocol, it MUST advertise that fact in its responses to &xep0030; information requests ("disco#info") by returning a feature of ‘<strong>urn:xmpp:rtt:0</strong>’.</p>
<p><strong>Example 1. A disco#info query</strong></p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
<p>See <linkurl="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link> for more information, including implicit discovery.</p>
<section2topic="Support for Groupchat"anchor="support_for_groupchat">
<p>It is possible for sender clients to use <linkurl="#message_refresh">Message Refresh</link> to simply re-transmit the whole real-time message, as a method of transmitting text changes. The advantage is very simple implementation. Disadvantages can include the lack of <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used. The below illustrates transmission of the real-time message “<strong>Hello there!</strong>” at a regular <linkurl="#transmission_interval">Transmission Interval</link> while the sender is typing.</p>
<p>Note: The 'seq' attribute can be restarted at any value with <rtt event="reset"/> and <rtt event="new"/>. See <linkurl="#processing_rules">Processing Rules</link>.</p>
</section3>
</section2>
@ -669,29 +669,29 @@
@@ -669,29 +669,29 @@
<p>Most of these examples are deliberately kept simple. In complete software implementations supporting key press intervals, transmissions will most resemble the last example, <linkurl="#full_message_including_key_press_intervals">Full Message Including Key Press Intervals</link>. For simplicity, these examples use a bare JID, even in situations where a full JID might be more appropriate.</p>
<section2topic="Introductory Examples of Real-Time Text"anchor="introductory_examples_of_realtime_text">
<p>All three examples shown below result in the same real-time message "<strong>HELLO</strong>" created by writing "<strong>HLL</strong>", backspacing two times, and then "<strong>ELLO</strong>". The action elements are <linkurl="#element_t_insert_text">Element <t/> – Insert Text</link> and <linkurl="#element_e_erase_text">Element <e/> – Erase Text</link>.</p>
<p>The example above sends the misspelled "<strong>HLL</strong>", then <strong><e/><e/></strong> backspaces 2 times, then sends "<strong>HELLO</strong>".</p>
<p>These examples illustrate real-time message editing via <linkurl="#action_elements">Action Elements</link>.<br/>
Note: In most situations, during normal human typing speeds at a normal <linkurl="#transmission_interval">Transmission Interval</link>, smaller fragments of text will be spread over multiple <rtt/> elements, than these demonstration examples below. See <linkurl="#sending_realtime_text">Sending Real-Time Text</link>.</p>
<section3topic="Deleting Text From Message"anchor="deleting_text_from_message">
This is because this example outputs "<strong>Hello, this is Alice!</strong>" then the <strong><t p='5'></strong> inserts the specified text " <strong>Bob</strong>" at position 5, using <linkurl="#element_t_insert_text">Element <t/> – Insert Text</link>.</p>
</section3>
<section3topic="Deleting and Replacing Text In Message"anchor="deleting_and_replacing_text_in_message">
<section2topic="Examples of Key Press Intervals"anchor="examples_of_key_press_intervals">
<section3topic="Comparison With and Without Intervals"anchor="comparison_with_and_without_intervals">
<p>All examples shown below, result in the same real-time message “<strong>HELLO</strong>”. Only the last example follows <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p>The above example outputs “<strong>HELLO</strong>” in a single action element (<linkurl="#element_t_insert_text">Element <t/> – Insert Text</link>).</p>
<p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press, while also <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. The <linkurl="#element_w_wait_interval">Element <w/> – Wait Interval</link> specifies the number of milliseconds between key presses, to allow smooth presentation in recipient clients that support <w/> action elements.</p>
</section3>
<section3topic="Full Message Including Key Press Intervals"anchor="full_message_including_key_press_intervals">
@ -930,7 +930,7 @@
@@ -930,7 +930,7 @@
<li>Two correct key presses to correctly spell the word “there”.</li>
</ul>
<p>The use <linkurl="#element_w_wait_interval">Element <w/> – Wait Interval</link>, between key presses, allows the receiving client to execute a small pause between action elements. This allows recipient clients to play back the sender's typing fluidly.</p>
<p>The members of the Real-Time Text Taskforce (R3TF), <linkclass="western"href="http://www.realtimetext.org/">www.realtimetext.org</link>, made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint-Andre and many others.</p>
<p>The technique of <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into this specification in compliance of the XSF's Intellectual Property Rights Policy at <linkclass="western"href="http://xmpp.org/extensions/ipr-policy.shtml">http://xmpp.org/extensions/ipr-policy.shtml</link>.</p>
<p>The members of the &R3TF; made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint-Andre and many others.</p>
<p>The technique of <linkurl="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into this specification in compliance with the &XSFIPR;.</p>
<td>Singleton node containing information about the conversation.</td>
</tr>
<tr>
<td>"comments" (dynamic)</td>
<td>modified-ascending</td>
<td>Contains comment items only. This node is primarily used for presenting conversations to the user. It is essentially a subset of the activity node.</td>
</tr>
@ -99,7 +99,6 @@
@@ -99,7 +99,6 @@
<td>"activity" (dynamic)</td>
<td>modified-ascending</td>
<td>Contains all activity items in the conversation, including comments. This node is primarily used for submitting comments and receiving mention events. Item persistence is OPTIONAL. Advanced implementations may choose to maintain full activity history of a conversation and expose it in this node.</td>
<p>Presence data received by a client &xmppim; are typically cached and displayed until they are replaced by an update (whereupon the new data will be cached and displayed...), for example graphically annotating availability of contacts in a roster. Where the entity from which the client has received the presence data is remote (residing upon a different server), unavailability of the server to server link will render the client unable to receive further presence updates from the entity but unaware that this is the case. Where the remote entity is a contact, it may cause the contact appear to be online (or offline, or away etc.) to the user of the client when they are not. Where the remote entity is a &xep0045; room the case is more severe, as the MUC room may have ejected the client due to the server-to-server (S2S) link being unavailable to send stanzas but the client may still consider itself present in the room.</p>
<p>This extension provides a simple mechanism by which the local server can resend previous presence data to the client, annotated such that the client knows it would be unable to receive future updates.</p>
</section1>
Appropriate action - alert user, attempt to rejoin MUC, whatever.
<!--Appropriate action - alert user, attempt to rejoin MUC, whatever.-->
<section1topic='Requirements'anchor='reqs'>
<p>Allow servers to annotate presence stanzas sent to clients indicating lack of availability of a client or server link necessary for receipt of updated presence.</p>
<p>By default all messages match a query, and filters are used to request a subset of the archived
messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field
MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this
XEP and MUST be supported by servers, though all of them are optional for the client. These fields are:
messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field
MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this
XEP and MUST be supported by servers, though all of them are optional for the client. These fields are:
</p>
<ul>
<li>start</li>
<li>end</li>
<li>with</li>
<li>start</li>
<li>end</li>
<li>with</li>
</ul>
Other fields may be used, but are not defined in this document - the naming of new fields MUST be
consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as
being required (i.e. with the data forms <required/> element), regardless of whether they are
defined in this document or elsewhere.</p>
<p>
Other fields may be used, but are not defined in this document - the naming of new fields MUST be
consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as
being required (i.e. with the data forms <required/> element), regardless of whether they are
defined in this document or elsewhere.
</p>
<section3topic='Filtering by JID'anchor='filter-jid'>
<p>If a 'with' field is present in the form, it contains a JID against which to match messages. The
server MUST only return messages if they match the supplied JID. A message in a user's archive matches if the JID matches either the to or from of the message. An item in a pubsub or MUC archive matches if the publisher of the item matches the JID; note that this should only be available to entities that would already have been allowed to know the publisher of the events (e.g. this could not be used by a visitor to a semi-anonymous MUC).</p>
@ -562,10 +565,9 @@
@@ -562,10 +565,9 @@
</result>
</message>]]></example>
</section3>
</section2>
<section2topic="IDs">
The IDs used within an archive MUST be unique per item stored and MUST NOT be reused, even if the original item with a given ID has since been removed from the archive. If a server provides multiple archives (e.g. many user archives, or many MUC archives), the IDs do not need to be unique across all of these archives unless the server also allows a single query to be run across multiple archives (e.g. searching of all MUC rooms), discussion of which is beyond the scope of this document. These IDs are strings that servers may construct in any manner, and clients must treat as opaque strings (e.g. is no requirement for them to be numeric, sequenced or GUIDs).
<p>The IDs used within an archive MUST be unique per item stored and MUST NOT be reused, even if the original item with a given ID has since been removed from the archive. If a server provides multiple archives (e.g. many user archives, or many MUC archives), the IDs do not need to be unique across all of these archives unless the server also allows a single query to be run across multiple archives (e.g. searching of all MUC rooms), discussion of which is beyond the scope of this document. These IDs are strings that servers may construct in any manner, and clients must treat as opaque strings (e.g. is no requirement for them to be numeric, sequenced or GUIDs).</p>
<p>Sending presence probes from the client should be based on human request, i.e. opening a chat dialog to an offline contact when messing full presence information for that contact. Clients MUST NOT send presence probes to all contacts that they think are offline after login.</p>
</section1>
<section1topic='Use Cases'anchor='usecases'>
This section describes two major use cases of the described protocol, client initiated presence probes.
<p>This section describes two major use cases of the described protocol, client initiated presence probes.</p>
<section2topic='Requesting up-to-date Presence of a XMPP Entity'anchor='presence-pull'>
<p>In some situations, after login, the client has incomplete presence information for offline contacts. The user might be interested in status text of the offline presence of a contact or when a contact went offline. This information can be requested, i.e. when the user opens a chat dialog to an offline user, using a client initiated presence probe and is described in the following two examples.</p>
<p>Initialilly a client requests the current presence information of a contact by sending out a presence probe.</p>
@ -75,7 +75,7 @@ This section describes two major use cases of the described protocol, client ini
@@ -75,7 +75,7 @@ This section describes two major use cases of the described protocol, client ini
<p>With this concept, any party could easily request the time a XMPP server or component went online, by sending a presence probe to it.</p>
<examplecaption='Request for Presence of a XMPP Server'><![CDATA[
<p>The amount of time the user has to be idle before a client sends this enhanced presence is application-specific; it is suggested that a sensible default interval of 5 minutes be used.</p>
</section2>
<section2topic='Presence Indicating User Coming Back From Idle'anchor='back-from-idle'>
When a user comes back and uses her device again the client informs user's contacts by sending a normal presence stanza like shown in the following example, omiting the <idle/> element.
<p>When a user comes back and uses her device again the client informs user's contacts by sending a normal presence stanza like shown in the following example, omiting the <idle/> element.</p>
<examplecaption='Presence Indicating Return to Device'><![CDATA[
<abstract>This specification describes how to control devices or actuators in an XMPP-based sensor network.</abstract>
&LEGALNOTICE;
<number>0325</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0001</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0122</spec>
<spec>XEP-0137</spec>
<spec>XEP-0141</spec>
<spec>XEP-0323</spec>
<spec>XEP-0324</spec>
<spec>XEP-0331</spec>
<spec>XEP-0336</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>sensor-network-control</shortname>
&peterwaher;
<revision>
<version>0.4</version>
<date>2015-11-09</date>
<initials>psa</initials>
<remark>
<p>Updated contact information.</p>
<p>Updated example JIDs to example.org</p>
</remark>
</revision>
<revision>
<version>0.3</version>
<date>2014-04-07</date>
<initials>pw</initials>
<remark>
<p>Response codes have been removed and replaced by XMPP compliant IQ error stanzas. The table below shows how old status codes map to XMPP IQ error elements.</p>
<p>The <strong>getFormResponse</strong> element has been removed.</p>
<p>The <strong>setResponse</strong> is now only used when configuration is successful.</p>
<p>The <strong>parameter</strong> subelement to <strong>setResponse</strong> has been reintroduced. Examples are provided in XEP-0324.</p>
<p>The element <strong>paramError</strong> has been introduced, and can be used to provide error information that are linked to control parameters.</p>
<p>Added anchors to all second level subsections.</p>
<p>The section 'Reading current control states' has been updated to include two methods: One simple method only using control forms, and a second, using Sensor Data (XEP-0323).</p>
<p>Harmonization of data types between XEP-0323 and XEP-0325.</p>
<p>The attribute <strong>writable</strong> used to correlate fields in XEP-0323 with control parameters is described.</p>
<tablecaption='XMPP Errors when rejecting a readout request'>
<tr>
<th>Obsolete Code</th>
<th>Error Type</th>
<th>Error Element</th>
<th>Namespace</th>
<th>Description</th>
</tr>
<tr>
<td>InsufficientPrivileges</td>
<td>cancel</td>
<td>forbidden</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
<td>If the caller lacks privileges to perform the action.</td>
</tr>
<tr>
<td>NotFound</td>
<td>cancel</td>
<td>item-not-found</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
<td>If an item, parameter or data source could not be found.</td>
</tr>
<tr>
<td>OtherError, FormError</td>
<td>modify</td>
<td>bad-request</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
<td>If the request was malformed. Examples can include trying to set a parameter to a value outside the allowed range.</td>
</tr>
<tr>
<td>NotImplemented</td>
<td>cancel</td>
<td>feature-not-implemented</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
<td>If an action has not been implemented in the device.</td>
</tr>
<tr>
<td>Locked</td>
<td>wait</td>
<td>conflict</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
<td>If an item was locked by another user or process and could not be accessed. The operation can be retried at a later point in time.</td>
</tr>
</table>
</remark>
</revision>
<revision>
<version>0.2</version>
<date>2014-03-10</date>
<initials>pw</initials>
<remark>
<p>Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.</p>
<p>Corrected the namespace used for parameterGroup elements in the examples of the document.</p>
<p>Added support for color values with alpha channel.</p>
<p>Updated the schema to more strictly validate references to x-data forms.</p>
<p>Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.</p>
<p>Fixed links to documents with new numbers.</p>
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
<p>Schema was corrected: The parameter sub-element in the setResponse element was removed.</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-05-06</date>
<initials>psa</initials>
<remark>
<p>Initial published version approved by the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-03-27</date>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<header>
<title>Internet of Things - Control</title>
<abstract>This specification describes how to control devices or actuators in an XMPP-based sensor network.</abstract>
&LEGALNOTICE;
<number>0325</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0001</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0122</spec>
<spec>XEP-0137</spec>
<spec>XEP-0141</spec>
<spec>XEP-0323</spec>
<spec>XEP-0324</spec>
<spec>XEP-0331</spec>
<spec>XEP-0336</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>sensor-network-control</shortname>
&peterwaher;
<revision>
<version>0.4</version>
<date>2015-11-09</date>
<initials>psa</initials>
<remark>
<p>Updated contact information.</p>
<p>Updated example JIDs to example.org</p>
</remark>
</revision>
<revision>
<version>0.3</version>
<date>2014-04-07</date>
<initials>pw</initials>
<remark>
<p>Response codes have been removed and replaced by XMPP compliant IQ error stanzas. The table below shows how old status codes map to XMPP IQ error elements.</p>
<p>The <strong>getFormResponse</strong> element has been removed.</p>
<p>The <strong>setResponse</strong> is now only used when configuration is successful.</p>
<p>The <strong>parameter</strong> subelement to <strong>setResponse</strong> has been reintroduced. Examples are provided in XEP-0324.</p>
<p>The element <strong>paramError</strong> has been introduced, and can be used to provide error information that are linked to control parameters.</p>
<p>Added anchors to all second level subsections.</p>
<p>The section 'Reading current control states' has been updated to include two methods: One simple method only using control forms, and a second, using Sensor Data (XEP-0323).</p>
<p>Harmonization of data types between XEP-0323 and XEP-0325.</p>
<p>The attribute <strong>writable</strong> used to correlate fields in XEP-0323 with control parameters is described.</p>
</remark>
</revision>
<revision>
<version>0.2</version>
<date>2014-03-10</date>
<initials>pw</initials>
<remark>
<p>Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.</p>
<p>Corrected the namespace used for parameterGroup elements in the examples of the document.</p>
<p>Added support for color values with alpha channel.</p>
<p>Updated the schema to more strictly validate references to x-data forms.</p>
<p>Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.</p>
<p>Fixed links to documents with new numbers.</p>
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
<p>Schema was corrected: The parameter sub-element in the setResponse element was removed.</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-05-06</date>
<initials>psa</initials>
<remark>
<p>Initial published version approved by the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-03-27</date>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>
Actuators are devices in sensor networks that can be controlled through the network and act with the outside world. In sensor networks and Internet of Things applications,
@ -980,8 +936,10 @@
@@ -980,8 +936,10 @@
</section3>
<section3topic='Setting a (partial) control form to multiple nodes'>
<p>
You set a control form to multiple nodes controlled by a concentrator by adding <strong>node</strong> elements to the <string>set</string>
command sent to the concentrator, as is shown in the following example:
You set a control form to multiple nodes controlled by a
concentrator by adding <strong>node</strong> elements to the
<strong>set</strong> command sent to the concentrator, as is
shown in the following example:
</p>
<examplecaption='Setting a (partial) control form to multiple nodes'>
<p>Rayo is a protocol to allow third-party remote control over media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike <ahref='xep-0166.html'>Jingle</a> or even <ahref='http://en.wikipedia.org/wiki/Session_Initiation_Protocol'>SIP</a>, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.</p>
<p>Rayo is a protocol to allow third-party remote control over media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike &xep0166; or even SIP (&rfc3261;), a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself.</p>
<ul>
<li>A Rayo server takes on the role of negotiating a media session between itself and some other endpoint, or between two external endpoints, by way of an implementation-specific means, be that Jingle, SIP, the public-switched telephone network, or anything else. The server may even bridge multiple networks.</li>
@ -118,7 +118,7 @@
@@ -118,7 +118,7 @@
</presence>
]]></example>
<p>In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate to be the client to whom the server delegates control of the call, and so has directed an <ahref='def-offer'>offer event</a> to her 'balcony' resource.</p>
<p>In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate to be the client to whom the server delegates control of the call, and so has directed an <linkurl='#def-offer'>offer event</link> to her 'balcony' resource.</p>
<p>The client, 'juliet@capulet.lit', then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring.</p>
<p>XMPP message stanzas directed to the call's JID with a type of 'normal' MAY be forwarded to the calling party by translating the message into the calling party's protocol. In the case of SIP, this SHOULD follow the conventions set out in <ahref="http://tools.ietf.org/html/draft-ietf-stox-im-06">draft-ietf-stox-im-06</a> with the exception of the <thread/> to Call-ID mapping, as the Call-ID will always be that of the calling party.</p>
<p>XMPP message stanzas directed to the call's JID with a type of 'normal' MAY be forwarded to the calling party by translating the message into the calling party's protocol. In the case of SIP, this SHOULD follow the conventions set out in <linkurl="http://tools.ietf.org/html/draft-ietf-stox-im-06">draft-ietf-stox-im-06</link> with the exception of the <thread/> to Call-ID mapping, as the Call-ID will always be that of the calling party.</p>
<p>If a message is directed to the call's JID with a type other than 'normal' then the server MUST return a <feature-not-implemented/> error with a type of 'modify'. If no translation is possible then the server SHOULD return the same error but with a type of 'cancel'.</p>
@ -4408,7 +4408,7 @@ Art thou not Romeo, and a Montague?
@@ -4408,7 +4408,7 @@ Art thou not Romeo, and a Montague?
</section2>
</section1>
<section1topic='History'anchor='history'>
Prior to the development of the Rayo protocol, the most widely-used 3PCC protocols were Asterisk's AGI and AMI. Unfortunately, these protocols have many drawbacks, not least in their inconsistency and relatively poor documentation, but also in that they are poorly secured and lacking in attributes required for significant scalability. Much 3PCC activity is also done using process-internal APIs rather than a wire protocol like XMPP.
<p>Prior to the development of the Rayo protocol, the most widely-used 3PCC protocols were Asterisk's AGI and AMI. Unfortunately, these protocols have many drawbacks, not least in their inconsistency and relatively poor documentation, but also in that they are poorly secured and lacking in attributes required for significant scalability. Much 3PCC activity is also done using process-internal APIs rather than a wire protocol like XMPP.</p>
<p>Rayo was developed to satisfy three main desires:</p>
<ul>
@ -4417,7 +4417,7 @@ Art thou not Romeo, and a Montague?
@@ -4417,7 +4417,7 @@ Art thou not Romeo, and a Montague?
<li>To enable authenticated, federated, web-scale 3PCC on platforms with APIs only suitable for trusted internal use (Asterisk, FreeSWITCH, etc).</li>
</ul>
Initial development of the Rayo specification and its reference implementation was sponsored by Tropo (formerly Voxeo Labs) and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols and FreeSWITCH EventSocket, native to FreeSWITCH (mod_rayo), as well as client library implementations in Node/CoffeeScript and Python.
<p>Initial development of the Rayo specification and its reference implementation was sponsored by Tropo (formerly Voxeo Labs) and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols and FreeSWITCH EventSocket, native to FreeSWITCH (mod_rayo), as well as client library implementations in Node/CoffeeScript and Python.</p>
<p>The authors would like to acknowledge the input of teams at Tropo (formerly Voxeo Labs), Mojo Lingo and Telefónica in the development of the initial specification, and Grasshopper in expanding the implementation landscape.</p>
<abstract>This specification describe a method that allow a user to share a list of nodes on which it is Pubsub registered</abstract>
&LEGALNOTICE;
<header>
<title>Pubsub Subscription</title>
<abstract>This specification describe a method that allow a user to share a list of nodes on which it is Pubsub registered</abstract>
&LEGALNOTICE;
<number>0330</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0163</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Christine</firstname>
<surname>Ho</surname>
<email>nodpounod@gmail.com</email>
<jid>christine.ho.dev@gmail.com</jid>
<firstname>Christine</firstname>
<surname>Ho</surname>
<email>nodpounod@gmail.com</email>
<jid>christine.ho.dev@gmail.com</jid>
</author>
<author>
<firstname>Timothée</firstname>
<surname>Jaussoin</surname>
<email>edhelas@gmail.com</email>
<jid>edhelas@movim.eu</jid>
<firstname>Timothée</firstname>
<surname>Jaussoin</surname>
<email>edhelas@gmail.com</email>
<jid>edhelas@movim.eu</jid>
</author>
<revision>
<version>0.1</version>
@ -47,7 +48,7 @@
@@ -47,7 +48,7 @@
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
</header>
<section1topic='Introduction'anchor='intro'>
<p>
&xep0060; nodes are commonly used by XMPP users to subscribe to news feeds. This document describe a way, for them, to share some of the nodes to which they have subscribed with other users.
@ -57,7 +58,7 @@
@@ -57,7 +58,7 @@
</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<p>Information about the subscribed node is provided by the user client. The subscription container is defined as a classic <subscription/> element with theses specific constraints :</p>
<p>Information about the subscribed node is provided by the user client. The subscription container is defined as a classic &subscription; element with theses specific constraints :</p>
<tablecaption='attributes'>
<tr>
<td><strong>Name</strong></td>
@ -71,21 +72,18 @@
@@ -71,21 +72,18 @@
<td>Any server's address</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>node</td>
<td>attribute</td>
<td></td>
<td>REQUIRED</td>
</tr>
<tr>
<td>id</td>
<td>node</td>
<td></td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>title</td>
<td>node</td>
@ -93,10 +91,8 @@
@@ -93,10 +91,8 @@
<td>OPTIONAL</td>
</tr>
</table>
<section2topic="Item ID generation method">
<p>The aim of this XEP is to handle a list of subscriptions. To simplify the managment of this list the ID of the &xep0060; items MUST be generated according to the following method :</p>
<ol>
<li>Initialize an empty string S</li>
<li>Append the name of the server, followed by the '<' character</li>
@ -104,7 +100,6 @@
@@ -104,7 +100,6 @@
<li>Append the jid of the current account</li>
<li>Compute the ID by hashing the S string using the SHA1 algorythm</li>
</ol>
<section3topic="Generation Example">
<ol>
<li>S = ''</li>
@ -126,86 +121,73 @@
@@ -126,86 +121,73 @@
<dl>
<di>
<dt>Personnal Eventing</dt>
<dd>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see
<dd>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see
<p>The publication of user tune information is not known to introduce any new security considerations above and beyond those defined in XEP-0060: Publish-Subscribe.</p>
Sam Whited
6 years ago