moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0300–XEP-0378: Fix DTD issues

hacx
Sam Whited 2017-01-01 16:34:35 -06:00
parent 78efd7c6a8
commit 95617b6be4
37 changed files with 437 additions and 535 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0300.xml
View File

@ -181,7 +181,7 @@
<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>
</section1>
http://dx.doi.org/10.6028/NIST.FIPS.202
<!-- http://dx.doi.org/10.6028/NIST.FIPS.202 -->
<section1 topic='Determining Support' anchor='disco'>
<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>
<example caption="Service discovery information request"><![CDATA[

133
xep-0301.xml
View File

@ -1,6 +1,7 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY R3TF "<span class='ref'><link url='http://realtimetext.org/'>Real-Time Text Taskforce</link></span> <note>Real-Time Text Taskforce (R3TF) &lt;<link url='http://realtimetext.org/'>http://realtimetext.org/</link>&gt;.</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -204,7 +205,7 @@
<p>Real-time text is transmitted via an &lt;rtt/&gt; child element of a &lt;message/&gt; stanza. The &lt;rtt/&gt; 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 &lt;body/&gt; 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 &lt;body/&gt; element (to remain <link url="#backwards_compatible">Backwards Compatible</link>):</p>
<p><strong>Example 1: Introductory Example</strong></p>
<p><code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
<code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
<t>Hello, </t>
</rtt>
@ -224,10 +225,7 @@
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a04'>
<body>Hello, my Juliet!</body>
</message>]]></code></p>
</message>]]></code>
<p>The &lt;rtt/&gt; element contains one or more child elements that represent <link url="#realtime_text_actions">Real-Time Text Actions</link> such as text being appended, inserted, or deleted. Example 1 illustrates only the &lt;t/&gt; <strong>action element</strong>, which appends text to the end of a message.</p>
<p>Transmission of the &lt;rtt/&gt; element occurs at a regular <link url="#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 &lt;rtt/&gt; element per &lt;message/&gt; stanza.</p>
@ -290,22 +288,24 @@
</section3>
</section2>
<section2 topic="Processing Rules" anchor="processing_rules">
<ul>
<li><p><strong>Initialize a new real-time message: &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt;</strong><br />
Sender clients MUST use an &lt;rtt/&gt; 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 <link url="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included within the &lt;rtt/&gt; 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 &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt; 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 <link url="#message_refresh">Message Refresh</link> or <link url="#simple_realtime_text">Simple Real-Time Text</link>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;<br /></strong>Sender clients SHOULD transmit this element at a regular <link url="#transmission_interval">Transmission Interval</link> while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;<br /></strong>Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If 'seq' increments as expected, the <link url="#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 <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Committing a real-time message: Delivery of a &lt;body/&gt; element</strong><br />
A real-time message is considered complete upon receiving &lt;body/&gt;. See <link url="#body_element">Body Element</link>.</p></li>
<li><p><strong>Starting real-time text: &lt;rtt event="init"/&gt;</strong><br />
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 <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Ending real-time text: &lt;rtt event="cancel"/&gt;</strong><br />
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending &lt;rtt/&gt; 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 <link url="#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 <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> and <link url="#simultaneous_logins">Simultaneous Logins</link>.</p></li>
</ul>
<ul>
<li><p><strong>Initialize a new real-time message: &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt;</strong></p>
<p>Sender clients MUST use an &lt;rtt/&gt; 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 <link url="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included within the &lt;rtt/&gt; 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 &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt; 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 <link url="#message_refresh">Message Refresh</link> or <link url="#simple_realtime_text">Simple Real-Time Text</link>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;</strong></p>
<p>Sender clients SHOULD transmit this element at a regular <link url="#transmission_interval">Transmission Interval</link> while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;</strong></p>
<p>Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If 'seq' increments as expected, the <link url="#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 <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Committing a real-time message: Delivery of a &lt;body/&gt; element</strong></p>
<p>A real-time message is considered complete upon receiving &lt;body/&gt;. See <link url="#body_element">Body Element</link>.</p></li>
<li><p><strong>Starting real-time text: &lt;rtt event="init"/&gt;</strong></p>
<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 <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Ending real-time text: &lt;rtt event="cancel"/&gt;</strong></p>
<p>Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending &lt;rtt/&gt; 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 <link url="#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 <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> and <link url="#simultaneous_logins">Simultaneous Logins</link>.</p></li>
</ul>
</section2>
<section2 topic="Body Element" anchor="body_element">
<p>The real-time message is considered complete upon receipt of a standard &lt;body/&gt; element (as qualified by the 'jabber:client' namespace in &xmppim;). The delivered text within &lt;body/&gt; is considered the final message text, and supersedes the real-time message. In the ideal case, the text within &lt;body/&gt; is redundant since it is identical to the final contents of the real-time message.</p>
@ -375,10 +375,10 @@
<section4 topic="Element &lt;t/&gt; – Insert Text" anchor="element_t_insert_text">
<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 &lt;body/&gt; element of a &lt;message/&gt;. If &lt;t/&gt; 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 <link url="#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>
@ -387,18 +387,18 @@
<section4 topic="Element &lt;e/&gt; – Erase Text" anchor="element_e_erase_text">
<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>
</section4>
<section4 topic="Element &lt;w/&gt; – Wait Interval" anchor="element_w_wait_interval">
<p>Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See <link url="#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 <link url="#transmission_interval">Transmission Interval</link>. Recipient clients MAY selectively shorten or ignore the pauses ('n') in &lt;w/&gt; action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of &lt;w/&gt; elements where the total of pauses exceeds a transmission interval cycle. See <link url="#receiving_realtime_text">Receiving Real-Time Text</link>.</p>
</section4>
</section3>
@ -436,9 +436,9 @@
</section3>
<section3 topic="Message Refresh" anchor="message_refresh">
<p>A message refresh is the sender's partially composed text being (re)transmitted via &lt;rtt event="reset"/&gt;. 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>
<p><code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
<code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
<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>
@ -484,16 +484,16 @@
<section1 topic="Determining Support" anchor="determining_support">
<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><code><![CDATA[<iq from='romeo@montague.lit/orchard'
<code><![CDATA[<iq from='romeo@montague.lit/orchard'
id='disco1'
to='juliet@capulet.lit/balcony'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></code></p>
]]></code>
<p><strong>Example 2. A disco#info response</strong></p>
<p><code><![CDATA[<iq from='juliet@capulet.lit/balcony'
<code><![CDATA[<iq from='juliet@capulet.lit/balcony'
id='disco1'
to='romeo@montague.lit/orchard'
type='result'>
@ -502,7 +502,7 @@
</query>
</iq>
]]></code></p>
]]></code>
<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 <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link> for more information, including implicit discovery.</p>
<section2 topic="Support for Groupchat" anchor="support_for_groupchat">
@ -595,7 +595,7 @@
</section3>
<section3 topic="Simple Real-Time Text" anchor="simple_realtime_text">
<p>It is possible for sender clients to use <link url="#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 <link url="#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 <link url="#transmission_interval">Transmission Interval</link> while the sender is typing.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hel</t>
</rtt>
@ -611,7 +611,7 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='789003' event='reset'>
<t>Hello there!</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>Note: The 'seq' attribute can be restarted at any value with &lt;rtt event="reset"/&gt; and &lt;rtt event="new"/&gt;. See <link url="#processing_rules">Processing Rules</link>.</p>
</section3>
</section2>
@ -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, <link url="#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>
<section2 topic="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 <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> and <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>HLL</t>
<e/><e/>
<t>ELLO</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>The example above sends the misspelled "<strong>HLL</strong>", then <strong>&lt;e/&gt;&lt;e/&gt;</strong> backspaces 2 times, then sends "<strong>HELLO</strong>".</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>HLL</t>
<e n='2'/>
<t>ELLO</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>The example above shows that <strong>&lt;e n='2'/&gt;</strong> does the same thing as <strong>&lt;e/&gt;&lt;e/&gt;</strong>.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>HLL</t>
</rtt>
@ -707,7 +707,7 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='123003'>
<t>ELLO</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
@ -718,7 +718,7 @@
Bob says: "Hello Alice"<br />
Bob says: "This is Bob"<br />
Bob says: "How are you?"</p>
<p><code><![CDATA[<message to='alice@example.com' from='bob@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='alice@example.com' from='bob@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello</t>
</rtt>
@ -763,7 +763,7 @@
<t>u?</t>
</rtt>
<body>How are you?</body>
</message>]]></code></p>
</message>]]></code>
@ -778,12 +778,12 @@
<p>These examples illustrate real-time message editing via <link url="#action_elements">Action Elements</link>.<br />
Note: In most situations, during normal human typing speeds at a normal <link url="#transmission_interval">Transmission Interval</link>, smaller fragments of text will be spread over multiple &lt;rtt/&gt; elements, than these demonstration examples below. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p>
<section3 topic="Deleting Text From Message" anchor="deleting_text_from_message">
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello Bob, this is Alice!</t>
<e n='4' p='9'/>
</rtt>
</message>]]></code></p>
</message>]]></code>
@ -794,12 +794,12 @@
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello, this is Alice!</t>
<t p='5'> Bob</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
@ -807,13 +807,13 @@
This is because this example outputs "<strong>Hello, this is Alice!</strong>" then the <strong>&lt;t p='5'&gt;</strong> inserts the specified text " <strong>Bob</strong>" at position 5, using <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>.</p>
</section3>
<section3 topic="Deleting and Replacing Text In Message" anchor="deleting_and_replacing_text_in_message">
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello Bob, tihsd is Alice!</t>
<e p='16' n='5'/>
<t p='11'>this</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
@ -822,7 +822,7 @@
</section3>
<section3 topic="Multiple Message Edits" anchor="multiple_message_edits">
<p>This is an example message containing multiple consecutive real-time message edits. This illustrates valid use of the &lt;rtt/&gt; element.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Helo</t>
<e/>
@ -832,7 +832,7 @@
<e n='3' p='8'/>
<t p='5'> there,</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
@ -894,13 +894,13 @@
<section2 topic="Examples of Key Press Intervals" anchor="examples_of_key_press_intervals">
<section3 topic="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 <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>HELLO</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>The above example outputs “<strong>HELLO</strong>” in a single action element (<link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>).</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>H</t>
<t>E</t>
@ -908,9 +908,9 @@
<t>L</t>
<t>O</t>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press.</p>
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>H</t><w n='101'/>
<t>E</t><w n='110'/>
@ -918,7 +918,7 @@
<t>L</t><w n='103'/>
<t>O</t><w n='110'/>
</rtt>
</message>]]></code></p>
</message>]]></code>
<p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press, while also <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. The <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> specifies the number of milliseconds between key presses, to allow smooth presentation in recipient clients that support &lt;w/&gt; action elements.</p>
</section3>
<section3 topic="Full Message Including Key Press Intervals" anchor="full_message_including_key_press_intervals">
@ -930,7 +930,7 @@
<li>Two correct key presses to correctly spell the word “there”.</li>
</ul>
<p>The use <link url="#element_w_wait_interval">Element &lt;w/&gt; – 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><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>H</t>
<w n='115'/><t>e</t>
@ -978,10 +978,7 @@
<w n='445'/><t p='12'/>
</rtt>
<body>Hello there!</body>
</message>]]></code></p>
</message>]]></code>
<p>This example also illustrates the following:</p>
<ul>
<li>Typing is done via <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>.</li>
@ -1049,7 +1046,7 @@
</section2>
</section1>
<section1 topic="XML Schema" anchor="xml_schema">
<p><code><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
<code><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
@ -1112,13 +1109,11 @@
</xs:restriction>
</xs:simpleType>
</xs:schema>]]></code></p>
</xs:schema>]]></code>
</section1>
<section1 topic="Acknowledgments" anchor="acknowledgments">
<p>The members of the Real-Time Text Taskforce (R3TF), <link class="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 <link url="#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 <link class="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 <link url="#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>
</section1>
</xep>

5
xep-0303.xml
View File

@ -83,15 +83,15 @@
<tr>
<th>Node</th>
<th>Natural Sort Order</th>
<th>Description</th>
</tr>
<tr>
<td>"info"</td>
<td>N/A</td>
<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 @@
<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>
</tr>
</table>

2
xep-0310.xml
View File

@ -38,7 +38,7 @@
<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. -->
<section1 topic='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>
</section1>

26
xep-0313.xml
View File

@ -218,18 +218,21 @@
]]></example>
<section2 topic='Filtering results' anchor='filter'>
<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 &lt;required/&gt; 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 &lt;required/&gt; element), regardless of whether they are
defined in this document or elsewhere.
</p>
<section3 topic='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 @@
</result>
</message>]]></example>
</section3>
</section2>
<section2 topic="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>
</section2>
</section1>

19
xep-0314.xml
View File

@ -115,7 +115,7 @@
<di>
<dt>Cleared</dt>
<dd>An entity is Cleared to access content if the Access Control Decision Function (ACDF) of
the server yields a <i>Grant</i> given the entity's Clearance, the Security Label of the
the server yields a <em>Grant</em> given the entity's Clearance, the Security Label of the
content and the governing security policy.</dd>
</di>
</dl>
@ -664,11 +664,11 @@ And by opposing end them?
</section1>
<section1 topic='Business Rules' anchor='rules'>
<ol>
<li id='rules-1'>An entity SHOULD NOT be aware of the existance of nodes or items that they do
<li>An entity SHOULD NOT be aware of the existance of nodes or items that they do
not have appropriate Clearance to view (But see <link url='#impl-access'>Implementation Notes:
Access to items for which the entity is not Cleared</link>)</li>
<li id='rules-2'>Items MUST only be accessible by entities with the appropriate Clearance</li>
<li id='rules-3'>If a node has an associated Clearance then the node MUST only deal with (i.e.
<li>Items MUST only be accessible by entities with the appropriate Clearance</li>
<li>If a node has an associated Clearance then the node MUST only deal with (i.e.
persist or notify) items which are compatible with the Clearance</li>
</ol>
</section1>
@ -677,7 +677,7 @@ And by opposing end them?
<p>The protocol defined has the intention that, as far as possible, an entity should be unaware of
the existence of any nodes or items which they are not Cleared to view. Therefore server
responses to a request for a node which the entity is not Cleared to view SHOULD be identical to
a response as if that node did not exist (See <link url="#rules-1">BR1</link>), i.e. an
a response as if that node did not exist (See <link url="#rules">BR1</link>), i.e. an
&ITEMNOTFOUND; error is returned</p>
<example caption="Request for a node that the entity is not Cleared to view"><![CDATA[
<iq from='pubsub.shakespeare.lit'
@ -772,7 +772,7 @@ And by opposing end them?
</options>
</pubsub>
</iq>
]]></example>
]]></example>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -791,10 +791,7 @@ And by opposing end them?
</ul>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
If the protocol defined in this specification undergoes a revision that is not fully
backwards-compatible with an older version, the XMPP Registrar shall increment the protocol
version number found at the end of the XML namespaces defined herein, as described in Section 4
of XEP-0053.
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -814,7 +811,7 @@ And by opposing end them?
XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
</xs:documentation>
</xs:annotation>
<xs:attribute name='label' type='xs:IDREF'>
<xs:annotation>
<xs:documentation>

1
xep-0315.xml
View File

@ -20,7 +20,6 @@
<supersedes/>
<supersededby/>
<shortname>media-element</shortname>
<schemaloc/>
<author>
<firstname>Sergey</firstname>
<surname>Dobrov</surname>

4
xep-0318.xml
View File

@ -54,7 +54,7 @@
<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>
<section1 topic='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>
<section2 topic='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
<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>
<example caption='Request for Presence of a XMPP Server'><![CDATA[
<presence from='juliet@capulet.com/balcony' to='montague.com' type='probe' />]]></example>
In response, the requester receives a presence stanza, which contains &xep0203; information, indicating the time the server went online.
<p>In response, the requester receives a presence stanza, which contains &xep0203; information, indicating the time the server went online.</p>
<example caption='Response from XMPP Server indicating uptime'><![CDATA[
<presence from='montague.com' to='juliet@capulet.com/balcony'>
<delay xmlns='urn:xmpp:delay'

2
xep-0319.xml
View File

@ -73,7 +73,7 @@
<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>
<section2 topic='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 &lt;idle/&gt; 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 &lt;idle/&gt; element.</p>
<example caption='Presence Indicating Return to Device'><![CDATA[
<presence from='juliet@capulet.com/balcony' />
]]></example>

2
xep-0323.xml
View File

@ -1093,7 +1093,7 @@
<p>
Available quality of service flags, in order of importance:
</p>
<table topic='Quality of Service Flags'>
<table caption='Quality of Service Flags'>
<tr>
<th>QoS Flag</th>
<th>Description</th>

214
xep-0325.xml
View File

@ -5,132 +5,88 @@
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<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>
<table caption='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>
<section1 topic='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 @@
</section3>
<section3 topic='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>
<example caption='Setting a (partial) control form to multiple nodes'>
<![CDATA[

12
xep-0327.xml
View File

@ -84,7 +84,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<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 <a href='xep-0166.html'>Jingle</a> or even <a href='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 @@
</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 <a href='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 <link url='#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>
@ -293,7 +293,7 @@
</section2>
<section2 topic='Conventions' anchor='terms-conventions'>
In examples, the following JIDs are used:
<p>In examples, the following JIDs are used:</p>
<ul>
<li><strong>juliet@capulet.lit/balcony, romeo@montague.lit/orchard</strong> - Potential controlling parties</li>
<li><strong>shakespeare.lit</strong> - The root domain of the Rayo service</li>
@ -1973,7 +1973,7 @@
<section2 topic='Instant Messages' anchor='session-im'>
<section3 topic='Call-bound Messages' anchor='session-im-call-bound'>
<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 <a href="http://tools.ietf.org/html/draft-ietf-stox-im-06">draft-ietf-stox-im-06</a> with the exception of the &lt;thread/&gt; 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 <link url="http://tools.ietf.org/html/draft-ietf-stox-im-06">draft-ietf-stox-im-06</link> with the exception of the &lt;thread/&gt; 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 &lt;feature-not-implemented/&gt; 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?
</section2>
</section1>
<section1 topic='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?
<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>
</section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<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>

2
xep-0329.xml
View File

@ -23,13 +23,13 @@
<supersedes>
<spec>XEP-0135</spec>
</supersedes>
<supersededby/>
<shortname>fis</shortname>
<author>
<firstname>Jefry</firstname>
<surname>Lagrange</surname>
<email>jefry.reyes@gmail.com</email>
<jid>j.lagrange@jabber.org</jid>
<jid>j.lagrange@gajim.org</jid>
</author>
&lance;
<revision>

160
xep-0330.xml
View File

@ -1,39 +1,40 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY subscription "&lt;subscription/&gt;">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<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;
<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 @@
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
</header>
<section1 topic='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 @@
</p>
</section1>
<section1 topic='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>
<table caption='attributes'>
<tr>
<td><strong>Name</strong></td>
@ -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 @@
<td>OPTIONAL</td>
</tr>
</table>
<section2 topic="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 '&lt;' character</li>
@ -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>
<section3 topic="Generation Example">
<ol>
<li>S = ''</li>
@ -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
<link url='http://xmpp.org/extensions/xep-0163.html'>Personal Eventing Protocol</link>.
</dd>
</di>
</dl>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Requesting the list of subscription' anchor='usecases'>
<example caption='Requests the list of subscriptions'><![CDATA[
<iq type='get'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubsub:subscription'/>
</pubsub>
</iq>]]></example>
<section2 topic='Requesting the list of subscription' anchor='usecases'>
<example caption='Requests the list of subscriptions'><![CDATA[
<iq type='get'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubsub:subscription'/>
</pubsub>
</iq>]]></example>
</section2>
<section2 topic='Adding a subscription to the list' anchor='usecases'>
<example caption='Add a subscription to the list '><![CDATA[
<iq type="set" from="romeo@montague.lit" id="sub123">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="urn:xmpp:pubsub:subscription">
<item id="0bc0e76cb803b3b107aa369169d8c0d45086f844">
<subscription xmlns="urn:xmpp:pubsub:subscription:0"
server="pubsub.shakespeare.lit" node="party">
<title>Party at the Capulets</title>
</subscription>
</item>
</publish>
</pubsub>
</iq>
]]>
</example>
<example caption='Add a subscription to the list '><![CDATA[
<iq type="set" from="romeo@montague.lit" id="sub123">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="urn:xmpp:pubsub:subscription">
<item id="0bc0e76cb803b3b107aa369169d8c0d45086f844">
<subscription xmlns="urn:xmpp:pubsub:subscription:0"
server="pubsub.shakespeare.lit" node="party">
<title>Party at the Capulets</title>
</subscription>
</item>
</publish>
</pubsub>
</iq>]]></example>
</section2>
<section2 topic='Removing a subscription from the list' anchor='usecases'>
<p>
<example caption='Remove a subscription from the list '><![CDATA[
<iq type='set'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='unsub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='urn:xmpp:pubsub:subscription'>
<item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'/>
</retract>
</pubsub>
</iq>
]]>
</example>
</p>
<example caption='Remove a subscription from the list '><![CDATA[
<iq type='set'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='unsub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='urn:xmpp:pubsub:subscription'>
<item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'/>
</retract>
</pubsub>
</iq>]]></example>
</section2>
<section2 topic='Modifiying a subscription of the list' anchor='usecases'>
<p>
<example caption='Change the information of a subscription of the list '><![CDATA[
<iq type='set'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='unsub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubsub:subscription'>
<item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'>
<subscription xmlns='urn:xmpp:pubsub:subscription:0'
server='pubsub.shakespeare.lit' node='party'>
<title>Party at the Capulets [canceled !]</title>
</subscription>
</item>
</publish>
</pubsub>
</iq>
]]>
</example>
</p>
<example caption='Change the information of a subscription of the list '><![CDATA[
<iq type='set'
from='romeo@montague.lit'
to='pubsub.shakespeare.lit'
id='unsub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubsub:subscription'>
<item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'>
<subscription xmlns='urn:xmpp:pubsub:subscription:0'
server='pubsub.shakespeare.lit' node='party'>
<title>Party at the Capulets [canceled !]</title>
</subscription>
</item>
</publish>
</pubsub>
</iq>]]></example>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>The title element of a <subscription/> item SHOULD be in the same language as the contents of the node in question.</p>
<p>The title element of a &subscription; item SHOULD be in the same language as the contents of the node in question.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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>

5
xep-0336.xml
View File

@ -863,7 +863,6 @@
available in the <strong>updated form</strong>, the flag stating that user input has occurred in the field can be cleared.
</li>
</ul>
<br/>
</li>
<li>
<p>
@ -889,9 +888,7 @@
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>
<p>This document requires no interaction with &IANA;.</p>
</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>

102
xep-0337.xml
View File

@ -5,55 +5,55 @@
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Event Logging over XMPP</title>
<abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
&LEGALNOTICE;
<number>0337</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>eventlogging</shortname>
&peterwaher;
<revision>
<version>0.2</version>
<date>2015-11-09</date>
<initials>pw</initials>
<remark>
<p>Updated contact information.</p>
<p>Updated example JIDs to example.org</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2014-01-08</date>
<initials>psa</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2013-12-02</date>
<initials>pw</initials>
<remark>
<p>Addressed pre-publication feedback from the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-11-10</date>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<header>
<title>Event Logging over XMPP</title>
<abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
&LEGALNOTICE;
<number>0337</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>eventlogging</shortname>
&peterwaher;
<revision>
<version>0.2</version>
<date>2015-11-09</date>
<initials>pw</initials>
<remark>
<p>Updated contact information.</p>
<p>Updated example JIDs to example.org</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2014-01-08</date>
<initials>psa</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2013-12-02</date>
<initials>pw</initials>
<remark>
<p>Addressed pre-publication feedback from the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-11-10</date>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
@ -222,7 +222,7 @@ Object 10</message>
</log>
</message>]]>
</example>
<strong>Note:</strong> Any <strong>tag</strong> elements must come after the <strong>message</strong> element.
<p><strong>Note:</strong> Any <strong>tag</strong> elements must come after the <strong>message</strong> element.</p>
</section2>
<section2 topic='Specifying program module' anchor='modules'>
<p>
@ -256,7 +256,7 @@ File2, Line2, ...
</log>
</message>]]>
</example>
<strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.
<p><strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.</p>
</section2>
<section2 topic='Sending multiple events' anchor='multipleevents'>
<p>

2
xep-0338.xml
View File

@ -20,6 +20,7 @@
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&fippo;
<revision>
<version>0.1</version>
<date>2014-01-08</date>
@ -32,7 +33,6 @@
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
&fippo;
</header>