moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-03 06:22:16 -05:00
Code Issues Releases Wiki Activity

XEP-0300–XEP-0378: Fix DTD issues

Browse Source
This commit is contained in:
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[

129
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>
@ -291,20 +289,22 @@
</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>
<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">
@ -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>

8
xep-0313.xml
View File

@ -221,15 +221,18 @@
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>
</ul>
<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>
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>

15
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'
@ -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'>

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>

50
xep-0325.xml
View File

@ -53,50 +53,6 @@
<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>
@ -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>

30
xep-0330.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 subscription "&lt;subscription/&gt;">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -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>
@ -144,7 +139,6 @@
</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">
@ -158,13 +152,9 @@
</item>
</publish>
</pubsub>
</iq>
]]>
</example>
</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'
@ -175,14 +165,9 @@
<item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'/>
</retract>
</pubsub>
</iq>
]]>
</example>
</p>
</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'
@ -198,14 +183,11 @@
</item>
</publish>
</pubsub>
</iq>
]]>
</example>
</p>
</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>

3
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>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>

4
xep-0337.xml
View File

@ -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>
<section1 topic="Introduction" anchor="intro">
<p>&rfc5888; defines a framework to group SDP 'm' lines for different purposes. A mapping to Jingle as an extension to &xep0166; is defined in this document.</p>

2
xep-0339.xml
View File

@ -20,6 +20,7 @@
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&fippo;
<revision>
<version>0.2</version>
<date>2015-11-09</date>
@ -38,7 +39,6 @@
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
&fippo;
</header>
<section1 topic="Introduction" anchor="intro">
<p>&rfc5576; provides a mechanism to describe attributes of individual media sources (identified by their synchronization source) within a media stream. A mapping to Jingle as an extension to &xep0167; is defined in this document.</p>

6
xep-0340.xml
View File

@ -24,22 +24,22 @@
<supersedes/>
<supersededby/>
<shortname>colibri</shortname>
<discuss>jingle</discuss>
<author>
<firstname>Emil</firstname>
<surname>Ivov</surname>
<org>jitsi.org</org>
<email>emcho@jitsi.org</email>
<jid>emcho@sip-communicator.org</jid>
<org>jitsi.org</org>
</author>
<author>
<firstname>Lyubomir</firstname>
<surname>Marinov</surname>
<org>jitsi.org</org>
<email>lubo@jitsi.org</email>
<jid>lubo@sip-communicator.org</jid>
<org>jitsi.org</org>
</author>
&fippo;
<discuss>jingle</discuss>
<revision>
<version>0.1</version>
<date>2014-01-08</date>

6
xep-0344.xml
View File

@ -20,7 +20,9 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>dwd</shortname>
<shortname>N/A</shortname>
&fippo;
&dcridland;
<revision>
<version>0.3</version>
<date>2015-03-23</date>
@ -65,8 +67,6 @@
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
&fippo;
&dcridland;
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although &xep0220; describes dialback as being run before any other negotiation, it is typically run over TLS where supported. This allows it to be used as a simple convenient fallback to X.509 Strong Authentication within the TLS layer, as described in &rfc6120;, and also affords greater protection to the exchange.</p>

6
xep-0345.xml
View File

@ -11,11 +11,11 @@
This specification outlines the form and mandatory content
of membership applications.
</abstract>
<number>0345</number>
<lastcall>2014-07-24</lastcall>
&LEGALNOTICE;
<type>Procedural</type>
<number>0345</number>
<status>Proposed</status>
<lastcall>2014-07-24</lastcall>
<type>Procedural</type>
<sig>None</sig>
<approver>Board</approver>
<dependencies/>

2
xep-0346.xml
View File

@ -208,7 +208,7 @@
<feature var='http://jabber.org/protocol/pubsub'/>
</query>
</iq>]]></example>
<p>Discovery of the template forms or completed form nodes happens using the protocol described in <a href="#usecases">Use Cases</a>.
<p>Discovery of the template forms or completed form nodes happens using the protocol described in <link url="#usecases">Use Cases</link>.
</p>
</section1>
<!-- <section1 topic='Implementation Notes' anchor='impl'>

2
xep-0348.xml
View File

@ -500,7 +500,7 @@
<p>
The &REGISTRAR; includes the following information in its registries.
</p>
<section2 topic='Field Standardization' ancor='fieldstandardization'>
<section2 topic='Field Standardization' anchor='fieldstandardization'>
<p>
&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use
field standardization in the context of service discovery. This section registers fields for server information scoped by the "urn:xmpp:xdata:signature:oauth1" FORM_TYPE.

2
xep-0349.xml
View File

@ -91,7 +91,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, presented as the external interface of the Gateway(s).</li>

21
xep-0354.xml
View File

@ -118,7 +118,11 @@ Examples for balancing algorithms include:
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Discovering Support'>
An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;.
<p>
An entity advertises support for this protocol by including the
'urn:xmpp:cmr:0' feature in its service discovery information features as
specified in &xep0030; or section 6.3 of &xep0115;.
</p>
<example caption='Service discovery information request'><![CDATA[
<iq xmlns='jabber:client'
@ -218,7 +222,11 @@ If the server is unable to change the message routing algorithm, then an error &
<section2 topic='Message Routing Hints'>
If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.
<p>
If allowed and supported by the server, clients are able to annotate message
stanza with a routing hint, that SHOULD affect the used message routing
algorithm for the annotated stanza.
</p>
<section3 topic='Determing support'>
@ -307,7 +315,7 @@ The CMR state, ie. the used routing algorithm, is identical for every session of
<p>
<strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:all'
</p>
Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.
<p>Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.</p>
</section3>
@ -315,7 +323,7 @@ Deliver to all non-negative resources with share the same maximum priority. And
<p>
<strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:mostactive'
</p>
Deliver the message to the "most available" resource or resources, depending on the server's implementation.
<p>Deliver the message to the "most available" resource or resources, depending on the server's implementation.</p>
</section3>
@ -323,7 +331,7 @@ Deliver the message to the "most available" resource or resources, depending on
<p>
<strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:roundrobin'
</p>
Deliver the message to the next resource selected by a round-robin algorithm.
<p>Deliver the message to the next resource selected by a round-robin algorithm.</p>
</section3>
@ -331,8 +339,7 @@ Deliver the message to the next resource selected by a round-robin algorithm.
<p>
<strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:weighted'
</p>
Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority.
<p>Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority.</p>
</section3>
</section2>
</section1>

1
xep-0358.xml
View File

@ -21,7 +21,6 @@
<supersedes/>
<supersededby/>
<shortname>jinglepub</shortname>
<schemaloc/>
&fippo;
&lance;
&stpeter;

2
xep-0359.xml
View File

@ -94,7 +94,7 @@
id='de305d54-75b4-431b-adb2-eb6b9e546013'
by='room@muc.xmpp.org'/>
]]></example>
In order to create a &stanza-id; extension element, the creating XMPP entity generates and sets the value of the 'id' attribute, and puts its own XMPP address as value of the 'by' attribute. The value of the 'id' attribute must be unique and stable, i.e. it MUST NOT change later for some reason within the scope of the 'by' value. Thus the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. It is RECOMMENDED that the ID generating service uses UUID and the algorithm defined in &rfc4122; to generate the IDs.
<p>In order to create a &stanza-id; extension element, the creating XMPP entity generates and sets the value of the 'id' attribute, and puts its own XMPP address as value of the 'by' attribute. The value of the 'id' attribute must be unique and stable, i.e. it MUST NOT change later for some reason within the scope of the 'by' value. Thus the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. It is RECOMMENDED that the ID generating service uses UUID and the algorithm defined in &rfc4122; to generate the IDs.</p>
</section2>
<section2 topic='Origin generated stanza IDs' anchor='origin-id'>
<p>

2
xep-0360.xml
View File

@ -63,11 +63,11 @@
<p>Nonzas sent before resource binding, as defined in RFC 6120 § 7., usually follow a request-response pattern. But after the client successfully bound a resource, they are used in a more "asynchronous" fashion, where a 'request' Nonza does not, or at least not immediately, trigger a 'result' Nonza sent back.</p>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>
<ol>
<li>Nonzas MUST NOT be routed, i.e. they are only exchanged between the two endpoints of an XMPP stream.</li>
<li>Nonzas SHOULD NOT have a &apos;from&apos; or &apos;to&apos; attribute.</li>
</ol>
<p>
Note that an exception from 2. are the the widely used &lt;db/&gt; Nonzas defined in &xep0220;.
</p>
</section1>

62
xep-0364.xml
View File

@ -58,9 +58,9 @@
<p>
The Off-the-Record messaging protocol (OTR) was originally introduced in
the 2004 paper
<i><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
<em><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
Off-the-Record Communication, or, Why Not To Use PGP
</link></i>
</link></em>
<note>
Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
Communication, or, Why Not To Use PGP"
@ -74,9 +74,9 @@
</p>
<p>
The OTR protocol itself is currently described by the document:
<i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
<em><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
Off-the-Record Messaging Protocol version 3
</link></i>
</link></em>
<note>
"Off-the-Record Messaging Protocol version 3"
&lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
@ -118,30 +118,31 @@
whitespace tag in their messages. This tag can appear anywhere in the body
of the message stanza, but it is most often found at the end. The OTR tag
comprises the following bytes:
</p>
<example caption='OTR tag'>
<example caption='OTR tag'><![CDATA[
\x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
</example>
]]></example>
<p>
and is followed by one or more of the following sequences to indicate the
version of OTR which the client supports:
<example caption='OTR tag version 1'>
</p>
<example caption='OTR tag version 1'><![CDATA[
\x20\x09\x20\x09\x20\x20\x09\x20
</example>
]]></example>
<p>
Note that this version 1 tag must come before other version tags for
compatibility; it is, however, NOT RECOMMENDED to implement version 1 of
the OTR protocol.
<example caption='OTR tag version 2'>
\x20\x20\x09\x09\x20\x20\x09\x20
</example>
<example caption='OTR tag version 3'>
\x20\x20\x09\x09\x20\x20\x09\x09
</example>
</p>
<example caption='OTR tag version 2'><![CDATA[
\x20\x20\x09\x09\x20\x20\x09\x20
]]></example>
<example caption='OTR tag version 3'><![CDATA[
\x20\x20\x09\x09\x20\x20\x09\x09
]]></example>
<p>
When a client sees this special string in the body of a message stanza it
may choose to start an OTR session immediately, or merely indicate support
@ -150,11 +151,8 @@
which indicates the supported versions of OTR. In XMPP these are most
commonly version 2 and version 3, which would be indicated by a message
stanza which has a body that starts with the string:
<example caption='OTR query'>
?OTR?v23?
</example>
</p>
<example caption='OTR query'>?OTR?v23?</example>
<p>
Any message which begins with the afforementioned string (note that the
version number[s] may be different), postfixed with a payload should be
@ -192,25 +190,21 @@
XMPP servers. These hints are not hard and fast rules, but suggestions
which the servers may or may not choose to follow. Best practice is to
include the following hints on all OTR messages:
</p>
<code><![CDATA[
<no-copy xmlns="urn:xmpp:hints"/>
<no-permanent-store xmlns="urn:xmpp:hints"/>
]]></code>
</p>
<p>
Similarly the "private" directive from &xep0280; should also be included
to indicate that carbons are not necessary (since no other resource will
be able to read the message):
<code><![CDATA[
<private xmlns="urn:xmpp:carbons:2"/>
]]></code>
</p>
<code><![CDATA[<private xmlns="urn:xmpp:carbons:2"/>]]></code>
<p>
All together, an example OTR message might look like this (with the
majority of the body stripped out for readability):
</p>
<example caption='OTR message with processing hints'><![CDATA[
<message from='malvolio@stewardsguild.lit/countesshousehold'
to='olivia@countess.lit/veiled'>
@ -220,7 +214,6 @@
<private xmlns="urn:xmpp:carbons:2"/>
</message>
]]></example>
</p>
</section2>
<section2 topic='Delivery Receipts'>
<p>
@ -281,11 +274,10 @@
&xep0147; defines various query components for use with XMPP URI's. When
an entity has an associated OTR fingerprint it's URI is often formed with
"otr-fingerprint" in the query string. Eg.
<example caption='OTR Fingerprint'>
xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
</example>
</p>
<example caption='OTR Fingerprint'><![CDATA[
xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
]]></example>
<p>
The &REGISTRAR; maintains a registry of queries and key-value pairs for
use in XMPP URIs at &QUERYTYPES;. As of the date this document was

8
xep-0367.xml
View File

@ -134,10 +134,12 @@
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
Clients that implement message attachments MUST be careful not to display the
attachments in such a way that they could be confused with the original
<p>
Clients that implement message attachments MUST be careful not to display
the attachments in such a way that they could be confused with the original
message and cause someone viewing the conversation to assume they were sent
by the sender of the message being attached to.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
@ -150,6 +152,7 @@
<p>
The &REGISTRAR; shall include the foregoing namespaces in its disco
features registry as defined in &xep0030;.
</p>
<code caption='Registry Submission'><![CDATA[
<var>
<name>urn:xmpp:message-attaching:0</name>
@ -157,7 +160,6 @@
<doc>XEP-xxxx</doc>
</var>
]]></code>
</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[

26
xep-0373.xml
View File

@ -5,8 +5,6 @@
<!ENTITY crypt "&lt;crypt/&gt;">
<!ENTITY openpgp "&lt;openpgp/&gt;">
<!ENTITY payload "&lt;payload/&gt;">
<!ENTITY rfc3156 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3156'>RFC 3156</link></span> <note>RFC 3156: MIME Security with OpenPGP &lt;<link url='http://tools.ietf.org/html/rfc3156'>http://tools.ietf.org/html/rfc3156</link>&gt;.</note>" >
<!ENTITY rfc3629 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3629'>RFC 3629</link></span> <note>RFC 3629: UTF-8, a transformation format of ISO 10646 &lt;<link url='http://tools.ietf.org/html/rfc3629'>http://tools.ietf.org/html/rfc3629</link>&gt;.</note>" >
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
@ -18,14 +16,7 @@
OpenPGP, announcement, discovery and retrieval of public keys and a
mechanism to synchronize secret keys over multiple
devices.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2016 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP
Standards Foundation.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
&LEGALNOTICE;
<number>0373</number>
<status>Experimental</status>
<type>Standards Track</type>
@ -523,10 +514,10 @@ Standards Foundation.</permissions>
4-character chunks, e.g.,
<tt>TWNK-KD5Y-MT3T-E1GS-DRDB-KVTW</tt>. The characters MUST be
generated from cryptographically secure random. For example
<link
url='https://lwn.net/Articles/606141/'><tt>getrandom(2)</tt></link>,
<link
url='https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html'><tt>SecureRandom</tt></link>
<tt><link
url='https://lwn.net/Articles/606141/'>getrandom(2)</link></tt>,
<tt><link
url='https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html'>SecureRandom</link></tt>
or <tt>/dev/urandom</tt>. More information about the
randomness requirements for security can be found in &rfc4086;
</li>
@ -691,8 +682,7 @@ Standards Foundation.</permissions>
additional checksum) and in favor for Base64, because
encoding should be part of the network application rather than the
crypto layer. Also XMPP, needs no additional error correction of payload.
In "MIME Security with OpenPGP" (<link
url='http://tools.ietf.org/html/rfc3156'>&rfc3156;</link>), ASCII Armor
In "MIME Security with OpenPGP" (&rfc3156;), ASCII Armor
has only been chosen to be backwards compatible with legacy applications
supporting non-MIME OpenPGP emails only.</p>
@ -701,8 +691,8 @@ Standards Foundation.</permissions>
<section2 topic='OpenPGP User IDs' anchor='openpgp-user-ids'>
<p>OpenPGP User IDs normally consist of a name - email address pair, e.g.,
"Juliet &lt;juliet@example.org&gt;" (<link
url='http://tools.ietf.org/html/rfc4880#section-5.11'><cite>RFC 4880 § 5.11</cite></link>).
"Juliet &lt;juliet@example.org&gt;" (<cite>RFC 4880</cite> <link
url='http://tools.ietf.org/html/rfc4880#section-5.11'>§ 5.11</link>).
For this XEP, we require User IDs of the format "xmpp:juliet@example.org".
First, it is required to have at least one User ID indicating the use
of this OpenPGP key. When doing certification of keys (key signing),

30
xep-0374.xml
View File

@ -15,14 +15,7 @@
<title>OpenPGP for XMPP Instant Messaging</title>
<abstract>Specifies a OpenPGP for XMPP (XEP-0373) profile for the Instant
Messaging (IM) use case.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2016 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP
Standards Foundation.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
&LEGALNOTICE;
<number>0374</number>
<status>Experimental</status>
<type>Standards Track</type>
@ -130,16 +123,14 @@ Standards Foundation.</permissions>
to store OpenPGP key information in the Domain Name
System (DNS). This specification does not restrict the mechanism
of key discovery and retrieval, but compliant clients MUST support
the public key announcement as described in <link
url='./xep-0373.html#announcing-discover-pubkey'><cite>XEP-0373
§ 4</cite></link>.</p>
the public key announcement as described in <cite>XEP-0373</cite>
<link url='./xep-0373.html#announcing-discover-pubkey'>§ 4</link>.</p>
<p>After the required public keys have been discovered, XMPP
clients engage in an OpenPGP secured IM
conversation by exchanging &openpgp; extension elements. They MUST
use the &signcrypt; OpenPGP content element specified in <link
url='./xep-0373.html#exchange'><cite>XEP-0373 §
3.1</cite></link>.</p>
use the &signcrypt; OpenPGP content element specified in
<cite>XEP-0373</cite><link url='./xep-0373.html#exchange'>§ 3.1</link>.</p>
<p>The child elements of the OpenPGP content element's &payload;
can be seen as stanza extension elements which are encrypted and
@ -245,11 +236,10 @@ Standards Foundation.</permissions>
</section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>Please refer to the <link
url='./xep-0373.html#acknowledgements'>Acknowledgements
section of <cite>XEP-0373</cite></link>, since the two XEPs where designed
together.</p>
<p>
Please refer to the
<link url='./xep-0373.html#acknowledgements'>Acknowledgements section</link>
of <cite>XEP-0373</cite> since the two XEPs where designed together.
</p>
</section1>
</xep>

2
xep-0375.xml
View File

@ -55,12 +55,10 @@
<date>2016-07-11</date>
<initials>ssw</initials>
<remark>
<p>
<ul>
<li>Add rationale.</li>
<li>Refactor suites to focus less on XEPs and more on features.</li>
</ul>
</p>
</remark>
</revision>
<revision>

16
xep-0376.xml
View File

@ -52,29 +52,29 @@
</section1>
<section1 topic='User Stories' anchor='stories'>
<section2 topic='Device Agility'>
<p><ul>
<ul>
<li>When a user subscribes to a publish-subscribe node (presumably via some higher-level abstraction), other online devices are aware of the new subscription immediately, and can choose to reflect the new subscription in their UI.</li>
<li>Not all devices may be capable of handling the particular payload and/or service, and therefore should signal which payload and/or service types they support.</li>
<li>The same capability as point 1 should be possible for unsubscribing.</li>
</ul></p>
</ul>
</section2>
<section2 topic='New Devices'>
<p><ul>
<ul>
<li>When a user brings a new device online, it should be able to quickly learn all the user's current subscriptions and present them to the user in its UI.</li>
</ul></p>
</ul>
</section2>
<section2 topic='Offline Capability'>
<p><ul>
<ul>
<li>When the device is offline for an extended period (beyond XEP-0198 resumption capability), it needs to be able to obtain all the events it missed, including when the events occured.</li>
<li>It should be able to tell which of these the user is unlikely to have seen on other devices.</li>
<li>Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.</li>
</ul></p>
</ul>
</section2>
<section2 topic='PEP'>
<p><ul>
<ul>
<li>A one-way subscription to a user should still allow PEP.</li>
<li>PEP should work the same way as now - users see filtered notifications about the things they care about.</li>
</ul></p>
</ul>
</section2>
</section1>
<section1 topic='Protocol' anchor='protocol'>

20
xep-0377.xml
View File

@ -12,9 +12,8 @@
abuse to a server operator or other spam service.
</abstract>
&LEGALNOTICE;
<status>Experimental</status>
<number>0377</number>
<status>Standards Track</status>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -58,6 +57,7 @@
the relavant specifications. Eg. a response from a server that supports
reporting and understands the abuse and spam reasons defined later in this
specification might look like the following:
</p>
<example caption="Service discovery information response"><![CDATA[
<iq from='shakespeare.lit'
id='ku6e51v3'
@ -68,9 +68,7 @@
<feature var='urn:xmpp:reporting:reason:abuse:0'/>
<feature var='urn:xmpp:reporting:reason:spam:0'/>
</query>
</iq>
]]></example>
</p>
</iq>]]></example>
</section1>
<section1 topic='Payload' anchor='payload'>
<p>
@ -90,10 +88,14 @@
This document defines the following reasons for a report:
</p>
<dl>
<di>
<dt>&lt;spam/&gt;</dt>
<dd>Used for reporting a JID that is sending unwanted messages.</dd>
</di>
<di>
<dt>&lt;abuse/&gt;</dt>
<dd>Used for reporting general abuse.</dd>
</di>
</dl>
<p>
Clients MUST include only one reason per report.
@ -205,19 +207,21 @@
Upon advancement of this specification from a status of Experimental to
a status of Draft, the &REGISTRAR; shall add the following definition to
the abuse reporting reasons registry, as described in this document:
<code><![CDATA[<reason>
</p>
<code><![CDATA[
<reason>
<name>Spam</name>
<urn>urn:xmpp:reporting:reason:spam:0</urn>
<desc>Used to report a JID that was sending spam messages.</desc>
<doc>XEP-0377</doc>
</reason>]]></code>
<code><![CDATA[<reason>
<code><![CDATA[
<reason>
<name>Abuse</name>
<urn>urn:xmpp:reporting:reason:abuse:0</urn>
<desc>Used to report general abuse that is not covered by a more specific reason.</desc>
<doc>XEP-0377</doc>
</reason>]]></code>
</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>

24
xep-0378.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 otr3 "<span class='ref'><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>Off-the-Record Messaging Protocol version 3</link></span> <note>Off-the-Record Messaging Protocol (OTR) version 3 &lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html</link>&gt; (Accessed 2015-08-30).</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -59,21 +60,11 @@
<section1 topic='Discovering support' anchor='disco'>
<p>
If an entity supports OTR it MUST advertise the fact by returning a
feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030;
information request. This indicates support for OTRv3 as defined by
<i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
Off-the-Record Messaging Protocol version 3
</link></i>
<note>
(Accessed 2015-08-30). "Off-the-Record Messaging Protocol version 3"
&lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
</link>&gt;
</note>.
<example caption='Disco response'><![CDATA[
<feature var='urn:xmpp:otr:0' />
]]></example>
feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030; information
request. This indicates support for OTRv3 as defined by &otr3;.
</p>
<example caption='Disco response'><![CDATA[
<feature var='urn:xmpp:otr:0' />]]></example>
<p>
If older versions of OTR are required, they may be discovered out of band
using OTRs built in mechanism which is beyond the scope of this document.
@ -100,13 +91,12 @@
<p>
The &REGISTRAR; shall include the foregoing namespaces in its disco
features registry as defined in &xep0030;.
</p>
<code caption='Registry Submission'><![CDATA[
<var>
<name>urn:xmpp:otr:0</name>
<desc>Indicates support for Off-the-Record Messaging (OTR) version 3</desc>
<doc>XEP-0378</doc>
</var>
]]></code>
</p>
</var>]]></code>
</section1>
</xep>

1
xep.ent
View File

@ -482,6 +482,7 @@ THE SOFTWARE.
<!ENTITY rfc3067 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3067'>RFC 3067</link></span> <note>RFC 3067: TERENA&apos;s Incident Object Description and Exchange Format Requirements &lt;<link url='http://tools.ietf.org/html/rfc3067'>http://tools.ietf.org/html/rfc3067</link>&gt;.</note>" >
<!ENTITY rfc3080 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3080'>RFC 3080</link></span> <note>RFC 3080: The Blocks Extensible Exchange Protocol Core (BEEP) &lt;<link url='http://tools.ietf.org/html/rfc3080'>http://tools.ietf.org/html/rfc3080</link>&gt;.</note>" >
<!ENTITY rfc3117 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3117'>RFC 3117</link></span> <note>RFC 3117: On the Design of Application Protocols &lt;<link url='http://tools.ietf.org/html/rfc3117'>http://tools.ietf.org/html/rfc3117</link>&gt;.</note>" >
<!ENTITY rfc3156 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3156'>RFC 3156</link></span> <note>RFC 3156: MIME Security with OpenPGP &lt;<link url='http://tools.ietf.org/html/rfc3156'>http://tools.ietf.org/html/rfc3156</link>&gt;.</note>" >
<!ENTITY rfc3174 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3174'>RFC 3174</link></span> <note>RFC 3174: US Secure Hash Algorithm 1 (SHA1) &lt;<link url='http://tools.ietf.org/html/rfc3174'>http://tools.ietf.org/html/rfc3174</link>&gt;.</note>" >
<!ENTITY rfc3217 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3217'>RFC 3217</link></span> <note>RFC 3217: Triple-DES and RC2 Key Wrapping &lt;<link url='http://tools.ietf.org/html/rfc3217'>http://tools.ietf.org/html/rfc3217</link>&gt;.</note>" >
<!ENTITY rfc3261 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3261'>RFC 3261</link></span> <note>RFC 3261: Session Initiation Protocol (SIP) &lt;<link url='http://tools.ietf.org/html/rfc3261'>http://tools.ietf.org/html/rfc3261</link>&gt;.</note>" >