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

XEP-0300–XEP-0378: Fix DTD issues

Sam Whited 2 years ago
parent
78efd7c6a8
commit
95617b6be4
37 changed files with 435 additions and 533 deletions
Split View Show Diff Stats
  1. 1
    1
      xep-0300.xml
  2. 64
    69
      xep-0301.xml
  3. 2
    3
      xep-0303.xml
  4. 1
    1
      xep-0310.xml
  5. 14
    12
      xep-0313.xml
  6. 8
    11
      xep-0314.xml
  7. 0
    1
      xep-0315.xml
  8. 2
    2
      xep-0318.xml
  9. 1
    1
      xep-0319.xml
  10. 1
    1
      xep-0323.xml
  11. 86
    128
      xep-0325.xml
  12. 6
    6
      xep-0327.xml
  13. 1
    1
      xep-0329.xml
  14. 71
    89
      xep-0330.xml
  15. 1
    4
      xep-0336.xml
  16. 51
    51
      xep-0337.xml
  17. 1
    1
      xep-0338.xml
  18. 1
    1
      xep-0339.xml
  19. 3
    3
      xep-0340.xml
  20. 3
    3
      xep-0344.xml
  21. 2
    2
      xep-0345.xml
  22. 1
    1
      xep-0346.xml
  23. 1
    1
      xep-0348.xml
  24. 1
    1
      xep-0349.xml
  25. 14
    7
      xep-0354.xml
  26. 0
    1
      xep-0358.xml
  27. 1
    1
      xep-0359.xml
  28. 1
    1
      xep-0360.xml
  29. 30
    38
      xep-0364.xml
  30. 9
    7
      xep-0367.xml
  31. 8
    18
      xep-0373.xml
  32. 10
    20
      xep-0374.xml
  33. 4
    6
      xep-0375.xml
  34. 8
    8
      xep-0376.xml
  35. 17
    13
      xep-0377.xml
  36. 9
    19
      xep-0378.xml
  37. 1
    0
      xep.ent

+ 1
- 1
xep-0300.xml View File 

@@ -181,7 +181,7 @@
181 181 
   <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>
182 182 
   <p>These recommendations ought to be reviewed yearly by the &COUNCIL;.</p>
183 183 
 </section1>
184 
-http://dx.doi.org/10.6028/NIST.FIPS.202
184 
+<!-- http://dx.doi.org/10.6028/NIST.FIPS.202 -->
185 185 
 <section1 topic='Determining Support' anchor='disco'>
186 186 
   <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>
187 187 
   <example caption="Service discovery information request"><![CDATA[

+ 64
- 69
xep-0301.xml View File 

@@ -1,6 +1,7 @@
1 1 
 <?xml version='1.0' encoding='UTF-8'?>
2 2 
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
3 3 
   <!ENTITY % ents SYSTEM 'xep.ent'>
4 
+  <!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>" >
4 5 
 %ents;
5 6 
 ]>
6 7 
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 
@@ -204,7 +205,7 @@
204 205 
     <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>
205 206 
     <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>
206 207 
     <p><strong>Example 1: Introductory Example</strong></p>
207 
-    <p><code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
208 
+    <code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
208 209 
   <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
209 210 
     <t>Hello, </t>
210 211 
   </rtt>
 
@@ -224,10 +225,7 @@
224 225
225 226 
 <message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a04'>
226 227 
   <body>Hello, my Juliet!</body>
227 
-</message>]]></code></p>
228 
-
229 
-
230 
-
228 
+</message>]]></code>
231 229 
     <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>
232 230 
     <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>
233 231 
     <p>There MUST NOT be more than one &lt;rtt/&gt; element per &lt;message/&gt; stanza.</p>
 
@@ -290,22 +288,24 @@
290 288 
     </section3>
291 289 
 </section2>
292 290 
     <section2 topic="Processing Rules" anchor="processing_rules">
293 
-    <ul>
294 
-      <li><p><strong>Initialize a new real-time message: &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt;</strong><br />
295 
-        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>
296 
-      <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 />
297 
-        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>
298 
-      <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>
299 
-      <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>
300 
-      <li><p><strong>Committing a real-time message: Delivery of a &lt;body/&gt; element</strong><br />
301 
-        A real-time message is considered complete upon receiving &lt;body/&gt;. See <link url="#body_element">Body Element</link>.</p></li>
302 
-      <li><p><strong>Starting real-time text: &lt;rtt event="init"/&gt;</strong><br />
303 
-        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>
304 
-      <li><p><strong>Ending real-time text: &lt;rtt event="cancel"/&gt;</strong><br />
305 
-        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>
306 
-      <li><p><strong>Starting value for seq attribute:</strong><br />
307 
-        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>
308 
-    </ul>
291 
+      <ul>
292 
+        <li><p><strong>Initialize a new real-time message: &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt;</strong></p>
293 
+          <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>
294 
+        <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>
295 
+          <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>
296 
+        <li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;</strong></p>
297 
+          <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>
298 
+        <li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;</strong></p>
299 
+          <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>
300 
+        <li><p><strong>Committing a real-time message: Delivery of a &lt;body/&gt; element</strong></p>
301 
+          <p>A real-time message is considered complete upon receiving &lt;body/&gt;. See <link url="#body_element">Body Element</link>.</p></li>
302 
+        <li><p><strong>Starting real-time text: &lt;rtt event="init"/&gt;</strong></p>
303 
+          <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>
304 
+        <li><p><strong>Ending real-time text: &lt;rtt event="cancel"/&gt;</strong></p>
305 
+          <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>
306 
+        <li><p><strong>Starting value for seq attribute:</strong></p>
307 
+          <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>
308 
+      </ul>
309 309 
     </section2>
310 310 
     <section2 topic="Body Element" anchor="body_element">
311 311 
     <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 @@
375 375 
         <section4 topic="Element &lt;t/&gt; – Insert Text" anchor="element_t_insert_text">
376 376 
     <p>Supports the transmission of text, including key presses, and text block inserts.<br />
377 377 
     <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>
378 
-    <p><code><![CDATA[<t>text</t>]]></code></p>
378 
+    <code><![CDATA[<t>text</t>]]></code>
379 379 
     <p>Append specified <strong>text</strong> at the end of message. ('p' defaults to message length).<br />
380 380 
     <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>
381 
-    <p><code><![CDATA[<t p='#'>text</t>]]></code></p>
381 
+    <code><![CDATA[<t p='#'>text</t>]]></code>
382 382 
     <p>Inserts specified <strong>text</strong> at position 'p' in the message text.</p>
383 383
384 384 
 
@@ -387,18 +387,18 @@
387 387 
     <section4 topic="Element &lt;e/&gt; – Erase Text" anchor="element_e_erase_text">
388 388 
     <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 />
389 389 
     <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>
390 
-    <p><code><![CDATA[<e/>]]></code></p>
390 
+    <code><![CDATA[<e/>]]></code>
391 391 
     <p>Remove 1 character from end of message. ('n' defaults to “1”, and 'p' defaults to message length)</p>
392 
-    <p><code><![CDATA[<e p='#'/>]]></code></p>
392 
+    <code><![CDATA[<e p='#'/>]]></code>
393 393 
     <p>Remove 1 character before character position 'p' in message. ('n' defaults to “1”)</p>
394 
-    <p><code><![CDATA[<e n='#'/>]]></code></p>
394 
+    <code><![CDATA[<e n='#'/>]]></code>
395 395 
     <p>Remove 'n' characters from end of message. ('p' defaults to message length)</p>
396 
-    <p><code><![CDATA[<e n='#' p='#'/>]]></code></p>
396 
+    <code><![CDATA[<e n='#' p='#'/>]]></code>
397 397 
     <p>Remove 'n' characters before character position 'p' in message.</p>
398 398 
     </section4>
399 399 
     <section4 topic="Element &lt;w/&gt; – Wait Interval" anchor="element_w_wait_interval">
400 400 
     <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>
401 
-    <p><code><![CDATA[<w n='#'/>]]></code></p>
401 
+    <code><![CDATA[<w n='#'/>]]></code>
402 402 
     <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>
403 403 
     </section4>
404 404 
 </section3>
 
@@ -436,9 +436,9 @@
436 436 
     </section3>
437 437 
     <section3 topic="Message Refresh" anchor="message_refresh">
438 438 
     <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>
439 
-    <p><code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
439 
+    <code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
440 440 
   <t>This is a retransmission of the entire real-time message.</t>
441 
-</rtt>]]></code></p>
441 
+</rtt>]]></code>
442 442 
     <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>
443 443 
     <ul>
444 444 
       <li>When the recipient starts sending messages from a different full JID (e.g., switched clients);</li>
 
@@ -484,16 +484,16 @@
484 484 
     <section1 topic="Determining Support" anchor="determining_support">
485 485 
     <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>
486 486 
     <p><strong>Example 1. A disco#info query</strong></p>
487 
-    <p><code><![CDATA[<iq from='romeo@montague.lit/orchard'
487 
+    <code><![CDATA[<iq from='romeo@montague.lit/orchard'
488 488 
     id='disco1'
489 489 
     to='juliet@capulet.lit/balcony'
490 490 
     type='get'>
491 491 
   <query xmlns='http://jabber.org/protocol/disco#info'/>
492 492 
 </iq>
493 493
494 
-]]></code></p>
494 
+]]></code>
495 495 
     <p><strong>Example 2. A disco#info response</strong></p>
496 
-    <p><code><![CDATA[<iq from='juliet@capulet.lit/balcony'
496 
+    <code><![CDATA[<iq from='juliet@capulet.lit/balcony'
497 497 
     id='disco1'
498 498 
     to='romeo@montague.lit/orchard'
499 499 
     type='result'>
 
@@ -502,7 +502,7 @@
502 502 
   </query>
503 503 
 </iq>
504 504
505 
-]]></code></p>
505 
+]]></code>
506 506 
     <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>
507 507 
     <p>See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link> for more information, including implicit discovery.</p>
508 508 
         <section2 topic="Support for Groupchat" anchor="support_for_groupchat">
 
@@ -595,7 +595,7 @@
595 595 
     </section3>
596 596 
     <section3 topic="Simple Real-Time Text" anchor="simple_realtime_text">
597 597 
     <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>
598 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
598 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
599 599 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
600 600 
     <t>Hel</t>
601 601 
   </rtt>
 
@@ -611,7 +611,7 @@
611 611 
   <rtt xmlns='urn:xmpp:rtt:0' seq='789003' event='reset'>
612 612 
     <t>Hello there!</t>
613 613 
   </rtt>
614 
-</message>]]></code></p>
614 
+</message>]]></code>
615 615 
     <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>
616 616 
     </section3>
617 617 
 </section2>
 
@@ -669,29 +669,29 @@
669 669 
     <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>
670 670 
         <section2 topic="Introductory Examples of Real-Time Text" anchor="introductory_examples_of_realtime_text">
671 671 
     <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>
672 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
672 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
673 673 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
674 674 
     <t>HLL</t>
675 675 
     <e/><e/>
676 676 
     <t>ELLO</t>
677 677 
   </rtt>
678 
-</message>]]></code></p>
678 
+</message>]]></code>
679 679
680 680
681 681
682 682 
     <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>
683 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
683 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
684 684 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
685 685 
     <t>HLL</t>
686 686 
     <e n='2'/>
687 687 
     <t>ELLO</t>
688 688 
   </rtt>
689 
-</message>]]></code></p>
689 
+</message>]]></code>
690 690
691 691
692 692
693 693 
     <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>
694 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
694 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
695 695 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
696 696 
     <t>HLL</t>
697 697 
   </rtt>
 
@@ -707,7 +707,7 @@
707 707 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123003'>
708 708 
     <t>ELLO</t>
709 709 
   </rtt>
710 
-</message>]]></code></p>
710 
+</message>]]></code>
711 711
712 712
713 713 
 
@@ -718,7 +718,7 @@
718 718 
     Bob says: "Hello Alice"<br />
719 719 
     Bob says: "This is Bob"<br />
720 720 
     Bob says: "How are you?"</p>
721 
-    <p><code><![CDATA[<message to='alice@example.com' from='bob@example.com/home' type='chat' id='a01'>
721 
+    <code><![CDATA[<message to='alice@example.com' from='bob@example.com/home' type='chat' id='a01'>
722 722 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
723 723 
     <t>Hello</t>
724 724 
   </rtt>
 
@@ -763,7 +763,7 @@
763 763 
     <t>u?</t>
764 764 
   </rtt>
765 765 
   <body>How are you?</body>
766 
-</message>]]></code></p>
766 
+</message>]]></code>
767 767
768 768
769 769 
 
@@ -778,12 +778,12 @@
778 778 
     <p>These examples illustrate real-time message editing via <link url="#action_elements">Action Elements</link>.<br />
779 779 
     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>
780 780 
         <section3 topic="Deleting Text From Message" anchor="deleting_text_from_message">
781 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
781 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
782 782 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
783 783 
     <t>Hello Bob, this is Alice!</t>
784 784 
     <e n='4' p='9'/>
785 785 
   </rtt>
786 
-</message>]]></code></p>
786 
+</message>]]></code>
787 787
788 788
789 789 
 
@@ -794,12 +794,12 @@
794 794
795 795
796 796
797 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
797 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
798 798 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
799 799 
     <t>Hello, this is Alice!</t>
800 800 
     <t p='5'> Bob</t>
801 801 
   </rtt>
802 
-</message>]]></code></p>
802 
+</message>]]></code>
803 803
804 804
805 805 
 
@@ -807,13 +807,13 @@
807 807 
     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>
808 808 
     </section3>
809 809 
     <section3 topic="Deleting and Replacing Text In Message" anchor="deleting_and_replacing_text_in_message">
810 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
810 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
811 811 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
812 812 
     <t>Hello Bob, tihsd is Alice!</t>
813 813 
     <e p='16' n='5'/>
814 814 
     <t p='11'>this</t>
815 815 
   </rtt>
816 
-</message>]]></code></p>
816 
+</message>]]></code>
817 817
818 818
819 819 
 
@@ -822,7 +822,7 @@
822 822 
     </section3>
823 823 
     <section3 topic="Multiple Message Edits" anchor="multiple_message_edits">
824 824 
     <p>This is an example message containing multiple consecutive real-time message edits. This illustrates valid use of the &lt;rtt/&gt; element.</p>
825 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
825 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
826 826 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
827 827 
     <t>Helo</t>
828 828 
     <e/>
 
@@ -832,7 +832,7 @@
832 832 
     <e n='3' p='8'/>
833 833 
     <t p='5'> there,</t>
834 834 
   </rtt>
835 
-</message>]]></code></p>
835 
+</message>]]></code>
836 836
837 837
838 838 
 
@@ -894,13 +894,13 @@
894 894 
     <section2 topic="Examples of Key Press Intervals" anchor="examples_of_key_press_intervals">
895 895 
         <section3 topic="Comparison With and Without Intervals" anchor="comparison_with_and_without_intervals">
896 896 
     <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>
897 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
897 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
898 898 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
899 899 
     <t>HELLO</t>
900 900 
   </rtt>
901 
-</message>]]></code></p>
901 
+</message>]]></code>
902 902 
     <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>
903 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
903 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
904 904 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
905 905 
     <t>H</t>
906 906 
     <t>E</t>
 
@@ -908,9 +908,9 @@
908 908 
     <t>L</t>
909 909 
     <t>O</t>
910 910 
   </rtt>
911 
-</message>]]></code></p>
911 
+</message>]]></code>
912 912 
     <p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press.</p>
913 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
913 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
914 914 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
915 915 
     <t>H</t><w n='101'/>
916 916 
     <t>E</t><w n='110'/>
 
@@ -918,7 +918,7 @@
918 918 
     <t>L</t><w n='103'/>
919 919 
     <t>O</t><w n='110'/>
920 920 
   </rtt>
921 
-</message>]]></code></p>
921 
+</message>]]></code>
922 922 
     <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>
923 923 
     </section3>
924 924 
     <section3 topic="Full Message Including Key Press Intervals" anchor="full_message_including_key_press_intervals">
 
@@ -930,7 +930,7 @@
930 930 
       <li>Two correct key presses to correctly spell the word “there”.</li>
931 931 
     </ul>
932 932 
     <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>
933 
-    <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
933 
+    <code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
934 934 
   <rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
935 935 
     <t>H</t>
936 936 
     <w n='115'/><t>e</t>
 
@@ -978,10 +978,7 @@
978 978 
     <w n='445'/><t p='12'/>
979 979 
   </rtt>
980 980 
   <body>Hello there!</body>
981 
-</message>]]></code></p>
982 
-
983 
-
984 
-
981 
+</message>]]></code>
985 982 
     <p>This example also illustrates the following:</p>
986 983 
     <ul>
987 984 
       <li>Typing is done via <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>.</li>
 
@@ -1049,7 +1046,7 @@
1049 1046 
     </section2>
1050 1047 
 </section1>
1051 1048 
     <section1 topic="XML Schema" anchor="xml_schema">
1052 
-    <p><code><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
1049 
+    <code><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
1053 1050
1054 1051 
 <xs:schema
1055 1052 
     xmlns:xs='http://www.w3.org/2001/XMLSchema'
 
@@ -1112,13 +1109,11 @@
1112 1109 
     </xs:restriction>
1113 1110 
   </xs:simpleType>
1114 1111
1115 
-</xs:schema>]]></code></p>
1112 
+</xs:schema>]]></code>
1116 1113 
     </section1>
1117 1114 
     <section1 topic="Acknowledgments" anchor="acknowledgments">
1118 
-    <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>
1119 
-    <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>
1120 
-
1121 
-
1115 
+    <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>
1116 
+    <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>
1122 1117 
 </section1>
1123 1118
1124 1119 
 </xep>

+ 2
- 3
xep-0303.xml View File 

@@ -83,15 +83,15 @@
83 83 
       <tr>
84 84 
         <th>Node</th>
85 85 
         <th>Natural Sort Order</th>
86 
-
87 86 
         <th>Description</th>
88 87 
       </tr>
88 
+      <tr>
89 89 
         <td>"info"</td>
90 90 
         <td>N/A</td>
91 91 
         <td>Singleton node containing information about the conversation.</td>
92 
+      </tr>
92 93 
       <tr>
93 94 
         <td>"comments" (dynamic)</td>
94 
-
95 95 
         <td>modified-ascending</td>
96 96 
         <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>
97 97 
       </tr>
 
@@ -99,7 +99,6 @@
99 99 
         <td>"activity" (dynamic)</td>
100 100 
         <td>modified-ascending</td>
101 101 
         <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>
102 
-
103 102 
       </tr>
104 103 
     </table>
105 104

+ 1
- 1
xep-0310.xml View File 

@@ -38,7 +38,7 @@
38 38 
   <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>
39 39 
   <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>
40 40 
 </section1>
41 
-Appropriate action - alert user, attempt to rejoin MUC, whatever.
41 
+<!-- Appropriate action - alert user, attempt to rejoin MUC, whatever. -->
42 42 
 <section1 topic='Requirements' anchor='reqs'>
43 43 
   <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>
44 44 
 </section1>

+ 14
- 12
xep-0313.xml View File 

@@ -218,18 +218,21 @@
218 218 
 ]]></example>
219 219 
   <section2 topic='Filtering results' anchor='filter'>
220 220 
     <p>By default all messages match a query, and filters are used to request a subset of the archived
221 
-    messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field
222 
-    MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this
223 
-    XEP and MUST be supported by servers, though all of them are optional for the client. These fields are:
221 
+      messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field
222 
+      MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this
223 
+      XEP and MUST be supported by servers, though all of them are optional for the client. These fields are:
224 
+    </p>
224 225 
     <ul>
225 
-    	<li>start</li>
226 
-    	<li>end</li>
227 
-    	<li>with</li>
226 
+      <li>start</li>
227 
+      <li>end</li>
228 
+      <li>with</li>
228 229 
     </ul>
229 
-    Other fields may be used, but are not defined in this document - the naming of new fields MUST be
230 
-    consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as
231 
-    being required (i.e. with the data forms &lt;required/&gt; element), regardless of whether they are
232 
-    defined in this document or elsewhere.</p>
230 
+    <p>
231 
+      Other fields may be used, but are not defined in this document - the naming of new fields MUST be
232 
+      consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as
233 
+      being required (i.e. with the data forms &lt;required/&gt; element), regardless of whether they are
234 
+      defined in this document or elsewhere.
235 
+    </p>
233 236 
     <section3 topic='Filtering by JID' anchor='filter-jid'>
234 237 
       <p>If a 'with' field is present in the form, it contains a JID against which to match messages. The
235 238 
       server MUST only return messages if they match the supplied JID. A message in a user's archive matches if the JID matches either the to or from of the message. An item in a pubsub or MUC archive matches if the publisher of the item matches the JID; note that this should only be available to entities that would already have been allowed to know the publisher of the events (e.g. this could not be used by a visitor to a semi-anonymous MUC).</p>
 
@@ -562,10 +565,9 @@
562 565 
   </result>
563 566 
 </message>]]></example>
564 567 
   	</section3>
565 
-
566 568 
   </section2>
567 569 
   <section2 topic="IDs">
568 
-  	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).
570 
+    <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>
569 571 
   </section2>
570 572 
 </section1>
571 573

+ 8
- 11
xep-0314.xml View File 

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

+ 0
- 1
xep-0315.xml View File 

@@ -20,7 +20,6 @@
20 20 
   <supersedes/>
21 21 
   <supersededby/>
22 22 
   <shortname>media-element</shortname>
23 
-  <schemaloc/>
24 23 
   <author>
25 24 
     <firstname>Sergey</firstname>
26 25 
     <surname>Dobrov</surname>

+ 2
- 2
xep-0318.xml View File 

@@ -54,7 +54,7 @@
54 54 
 <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>
55 55 
 </section1>
56 56 
 <section1 topic='Use Cases' anchor='usecases'>
57 
-This section describes two major use cases of the described protocol, client initiated presence probes.
57 
+<p>This section describes two major use cases of the described protocol, client initiated presence probes.</p>
58 58 
 <section2 topic='Requesting up-to-date Presence of a XMPP Entity' anchor='presence-pull'>
59 59 
 <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>
60 60 
 <p>Initialilly a client requests the current presence information of a contact by sending out a presence probe.</p> 
@@ -75,7 +75,7 @@ This section describes two major use cases of the described protocol, client ini
75 75 
 <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>
76 76 
 <example caption='Request for Presence of a XMPP Server'><![CDATA[
77 77 
 <presence from='juliet@capulet.com/balcony' to='montague.com' type='probe' />]]></example>
78 
-In response, the requester receives a presence stanza, which contains &xep0203; information, indicating the time the server went online.
78 
+<p>In response, the requester receives a presence stanza, which contains &xep0203; information, indicating the time the server went online.</p>
79 79 
 <example caption='Response from XMPP Server indicating uptime'><![CDATA[
80 80 
 <presence from='montague.com' to='juliet@capulet.com/balcony'>
81 81 
   <delay xmlns='urn:xmpp:delay'

+ 1
- 1
xep-0319.xml View File 

@@ -73,7 +73,7 @@
73 73 
   <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>
74 74 
   </section2>
75 75 
   <section2 topic='Presence Indicating User Coming Back From Idle' anchor='back-from-idle'>
76 
-    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.
76 
+    <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>
77 77 
     <example caption='Presence Indicating Return to Device'><![CDATA[
78 78 
 <presence from='juliet@capulet.com/balcony' />
79 79 
     ]]></example>

+ 1
- 1
xep-0323.xml View File 

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

+ 86
- 128
xep-0325.xml View File 

@@ -5,132 +5,88 @@
5 5 
 ]>
6 6 
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
7 7 
 <xep>
8 
-    <header>
9 
-        <title>Internet of Things - Control</title>
10 
-        <abstract>This specification describes how to control devices or actuators in an XMPP-based sensor network.</abstract>
11 
-		&LEGALNOTICE;
12 
-        <number>0325</number>
13 
-        <status>Experimental</status>
14 
-        <type>Standards Track</type>
15 
-        <sig>Standards</sig>
16 
-        <approver>Council</approver>
17 
-        <dependencies>
18 
-            <spec>XEP-0001</spec>
19 
-            <spec>XEP-0004</spec>
20 
-            <spec>XEP-0030</spec>
21 
-            <spec>XEP-0122</spec>
22 
-            <spec>XEP-0137</spec>
23 
-            <spec>XEP-0141</spec>
24 
-            <spec>XEP-0323</spec>
25 
-            <spec>XEP-0324</spec>
26 
-			<spec>XEP-0331</spec>
27 
-			<spec>XEP-0336</spec>
28 
-		</dependencies>
29 
-        <supersedes/>
30 
-        <supersededby/>
31 
-        <shortname>sensor-network-control</shortname>
32 
-        &peterwaher;
33 
-		<revision>
34 
-			<version>0.4</version>
35 
-			<date>2015-11-09</date>
36 
-			<initials>psa</initials>
37 
-			<remark>
38 
-				<p>Updated contact information.</p>
39 
-				<p>Updated example JIDs to example.org</p>
40 
-			</remark>
41 
-		</revision>
42 
-		<revision>
43 
-			<version>0.3</version>
44 
-			<date>2014-04-07</date>
45 
-			<initials>pw</initials>
46 
-			<remark>
47 
-				<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>
48 
-				<p>The <strong>getFormResponse</strong> element has been removed.</p>
49 
-				<p>The <strong>setResponse</strong> is now only used when configuration is successful.</p>
50 
-				<p>The <strong>parameter</strong> subelement to <strong>setResponse</strong> has been reintroduced. Examples are provided in XEP-0324.</p>
51 
-				<p>The element <strong>paramError</strong> has been introduced, and can be used to provide error information that are linked to control parameters.</p>
52 
-				<p>Added anchors to all second level subsections.</p>
53 
-				<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>
54 
-				<p>Harmonization of data types between XEP-0323 and XEP-0325.</p>
55 
-				<p>The attribute <strong>writable</strong> used to correlate fields in XEP-0323 with control parameters is described.</p>
56 
-				<table caption='XMPP Errors when rejecting a readout request'>
57 
-					<tr>
58 
-						<th>Obsolete Code</th>
59 
-						<th>Error Type</th>
60 
-						<th>Error Element</th>
61 
-						<th>Namespace</th>
62 
-						<th>Description</th>
63 
-					</tr>
64 
-					<tr>
65 
-						<td>InsufficientPrivileges</td>
66 
-						<td>cancel</td>
67 
-						<td>forbidden</td>
68 
-						<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
69 
-						<td>If the caller lacks privileges to perform the action.</td>
70 
-					</tr>
71 
-					<tr>
72 
-						<td>NotFound</td>
73 
-						<td>cancel</td>
74 
-						<td>item-not-found</td>
75 
-						<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
76 
-						<td>If an item, parameter or data source could not be found.</td>
77 
-					</tr>
78 
-					<tr>
79 
-						<td>OtherError, FormError</td>
80 
-						<td>modify</td>
81 
-						<td>bad-request</td>
82 
-						<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
83 
-						<td>If the request was malformed. Examples can include trying to set a parameter to a value outside the allowed range.</td>
84 
-					</tr>
85 
-					<tr>
86 
-						<td>NotImplemented</td>
87 
-						<td>cancel</td>
88 
-						<td>feature-not-implemented</td>
89 
-						<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
90 
-						<td>If an action has not been implemented in the device.</td>
91 
-					</tr>
92 
-					<tr>
93 
-						<td>Locked</td>
94 
-						<td>wait</td>
95 
-						<td>conflict</td>
96 
-						<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
97 
-						<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>
98 
-					</tr>
99 
-				</table>
100 
-			</remark>
101 
-		</revision>
102 
-		<revision>
103 
-			<version>0.2</version>
104 
-			<date>2014-03-10</date>
105 
-			<initials>pw</initials>
106 
-			<remark>
107 
-				<p>Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.</p>
108 
-				<p>Corrected the namespace used for parameterGroup elements in the examples of the document.</p>
109 
-				<p>Added support for color values with alpha channel.</p>
110 
-				<p>Updated the schema to more strictly validate references to x-data forms.</p>
111 
-				<p>Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.</p>
112 
-				<p>Fixed links to documents with new numbers.</p>
113 
-				<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
114 
-				<p>Schema was corrected: The parameter sub-element in the setResponse element was removed.</p>
115 
-			</remark>
116 
-		</revision>
117 
-		<revision>
118 
-			<version>0.1</version>
119 
-			<date>2013-05-06</date>
120 
-			<initials>psa</initials>
121 
-			<remark>
122 
-				<p>Initial published version approved by the XMPP Council.</p>
123 
-			</remark>
124 
-		</revision>
125 
-		<revision>
126 
-            <version>0.0.1</version>
127 
-            <date>2013-03-27</date>
128 
-            <initials>pw</initials>
129 
-            <remark>
130 
-                <p>First draft.</p>
131 
-            </remark>
132 
-        </revision>
133 
-    </header>
8 
+  <header>
9 
+    <title>Internet of Things - Control</title>
10 
+    <abstract>This specification describes how to control devices or actuators in an XMPP-based sensor network.</abstract>
11 
+    &LEGALNOTICE;
12 
+    <number>0325</number>
13 
+    <status>Experimental</status>
14 
+    <type>Standards Track</type>
15 
+    <sig>Standards</sig>
16 
+    <approver>Council</approver>
17 
+    <dependencies>
18 
+      <spec>XEP-0001</spec>
19 
+      <spec>XEP-0004</spec>
20 
+      <spec>XEP-0030</spec>
21 
+      <spec>XEP-0122</spec>
22 
+      <spec>XEP-0137</spec>
23 
+      <spec>XEP-0141</spec>
24 
+      <spec>XEP-0323</spec>
25 
+      <spec>XEP-0324</spec>
26 
+      <spec>XEP-0331</spec>
27 
+      <spec>XEP-0336</spec>
28 
+    </dependencies>
29 
+    <supersedes/>
30 
+    <supersededby/>
31 
+    <shortname>sensor-network-control</shortname>
32 
+    &peterwaher;
33 
+    <revision>
34 
+      <version>0.4</version>
35 
+      <date>2015-11-09</date>
36 
+      <initials>psa</initials>
37 
+      <remark>
38 
+        <p>Updated contact information.</p>
39 
+        <p>Updated example JIDs to example.org</p>
40 
+      </remark>
41 
+    </revision>
42 
+    <revision>
43 
+      <version>0.3</version>
44 
+      <date>2014-04-07</date>
45 
+      <initials>pw</initials>
46 
+      <remark>
47 
+        <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>
48 
+        <p>The <strong>getFormResponse</strong> element has been removed.</p>
49 
+        <p>The <strong>setResponse</strong> is now only used when configuration is successful.</p>
50 
+        <p>The <strong>parameter</strong> subelement to <strong>setResponse</strong> has been reintroduced. Examples are provided in XEP-0324.</p>
51 
+        <p>The element <strong>paramError</strong> has been introduced, and can be used to provide error information that are linked to control parameters.</p>
52 
+        <p>Added anchors to all second level subsections.</p>
53 
+        <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>
54 
+        <p>Harmonization of data types between XEP-0323 and XEP-0325.</p>
55 
+        <p>The attribute <strong>writable</strong> used to correlate fields in XEP-0323 with control parameters is described.</p>
56 
+      </remark>
57 
+    </revision>
58 
+    <revision>
59 
+      <version>0.2</version>
60 
+      <date>2014-03-10</date>
61 
+      <initials>pw</initials>
62 
+      <remark>
63 
+        <p>Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.</p>
64 
+        <p>Corrected the namespace used for parameterGroup elements in the examples of the document.</p>
65 
+        <p>Added support for color values with alpha channel.</p>
66 
+        <p>Updated the schema to more strictly validate references to x-data forms.</p>
67 
+        <p>Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.</p>
68 
+        <p>Fixed links to documents with new numbers.</p>
69 
+        <p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
70 
+        <p>Schema was corrected: The parameter sub-element in the setResponse element was removed.</p>
71 
+      </remark>
72 
+    </revision>
73 
+    <revision>
74 
+      <version>0.1</version>
75 
+      <date>2013-05-06</date>
76 
+      <initials>psa</initials>
77 
+      <remark>
78 
+        <p>Initial published version approved by the XMPP Council.</p>
79 
+      </remark>
80 
+    </revision>
81 
+    <revision>
82 
+      <version>0.0.1</version>
83 
+      <date>2013-03-27</date>
84 
+      <initials>pw</initials>
85 
+      <remark>
86 
+        <p>First draft.</p>
87 
+      </remark>
88 
+    </revision>
89 
+  </header>
134 90 
     <section1 topic='Introduction' anchor='intro'>
135 91 
         <p>
136 92 
             Actuators are devices in sensor networks that can be controlled through the network and act with the outside world. In sensor networks and Internet of Things applications,
 
@@ -980,8 +936,10 @@
980 936 
             </section3>
981 937 
             <section3 topic='Setting a (partial) control form to multiple nodes'>
982 938 
                 <p>
983 
-                    You set a control form to multiple nodes controlled by a concentrator by adding <strong>node</strong> elements to the <string>set</string>
984 
-                    command sent to the concentrator, as is shown in the following example:
939 
+                  You set a control form to multiple nodes controlled by a
940 
+                  concentrator by adding <strong>node</strong> elements to the
941 
+                  <strong>set</strong> command sent to the concentrator, as is
942 
+                  shown in the following example:
985 943 
                 </p>
986 944 
                 <example caption='Setting a (partial) control form to multiple nodes'>
987 945 
                     <![CDATA[

+ 6
- 6
xep-0327.xml View File 

@@ -84,7 +84,7 @@
84 84 
   </revision>
85 85 
 </header>
86 86 
 <section1 topic='Introduction' anchor='intro'>
87 
-  <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>
87 
+  <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>
88 88
89 89 
   <ul>
90 90 
     <li>A Rayo server takes on the role of negotiating a media session between itself and some other endpoint, or between two external endpoints, by way of an implementation-specific means, be that Jingle, SIP, the public-switched telephone network, or anything else. The server may even bridge multiple networks.</li>
 
@@ -118,7 +118,7 @@
118 118 
 </presence>
119 119 
 ]]></example>
120 120
121 
-  <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>
121 
+  <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>
122 122
123 123 
   <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>
124 124 
 
@@ -293,7 +293,7 @@
293 293 
   </section2>
294 294
295 295 
   <section2 topic='Conventions' anchor='terms-conventions'>
296 
-    In examples, the following JIDs are used:
296 
+    <p>In examples, the following JIDs are used:</p>
297 297 
     <ul>
298 298 
       <li><strong>juliet@capulet.lit/balcony, romeo@montague.lit/orchard</strong> - Potential controlling parties</li>
299 299 
       <li><strong>shakespeare.lit</strong> - The root domain of the Rayo service</li>
 
@@ -1973,7 +1973,7 @@
1973 1973
1974 1974 
   <section2 topic='Instant Messages' anchor='session-im'>
1975 1975 
     <section3 topic='Call-bound Messages' anchor='session-im-call-bound'>
1976 
-      <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>
1976 
+      <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>
1977 1977
1978 1978 
       <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>
1979 1979 
 
@@ -4408,7 +4408,7 @@ Art thou not Romeo, and a Montague?
4408 4408 
   </section2>
4409 4409 
 </section1>
4410 4410 
 <section1 topic='History' anchor='history'>
4411 
-  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.
4411 
+  <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>
4412 4412
4413 4413 
   <p>Rayo was developed to satisfy three main desires:</p>
4414 4414 
   <ul>
 
@@ -4417,7 +4417,7 @@ Art thou not Romeo, and a Montague?
4417 4417 
     <li>To enable authenticated, federated, web-scale 3PCC on platforms with APIs only suitable for trusted internal use (Asterisk, FreeSWITCH, etc).</li>
4418 4418 
   </ul>
4419 4419
4420 
-  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.
4420 
+  <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>
4421 4421 
 </section1>
4422 4422 
 <section1 topic='Acknowledgements' anchor='acknowledgements'>
4423 4423 
   <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>

+ 1
- 1
xep-0329.xml View File 

@@ -23,13 +23,13 @@
23 23 
   <supersedes>
24 24 
     <spec>XEP-0135</spec>
25 25 
   </supersedes>
26 
+  <supersededby/>
26 27 
   <shortname>fis</shortname>
27 28 
   <author>
28 29 
       <firstname>Jefry</firstname>
29 30 
       <surname>Lagrange</surname>
30 31 
       <email>jefry.reyes@gmail.com</email>
31 32 
       <jid>j.lagrange@jabber.org</jid>
32 
-      <jid>j.lagrange@gajim.org</jid>
33 33 
   </author>
34 34 
   &lance;
35 35 
   <revision>

+ 71
- 89
xep-0330.xml View File 

@@ -1,39 +1,40 @@
1 1 
 <?xml version='1.0' encoding='UTF-8'?>
2 2 
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
3 3 
   <!ENTITY % ents SYSTEM 'xep.ent'>
4 
+  <!ENTITY subscription "&lt;subscription/&gt;">
4 5 
 %ents;
5 6 
 ]>
6 7 
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
7 8 
 <xep>
8 
-<header>
9 
-  <title>Pubsub Subscription</title>
10 
-  <abstract>This specification describe a method that allow a user to share a list of nodes on which it is Pubsub registered</abstract>
11 
-  &LEGALNOTICE;
9 
+  <header>
10 
+    <title>Pubsub Subscription</title>
11 
+    <abstract>This specification describe a method that allow a user to share a list of nodes on which it is Pubsub registered</abstract>
12 
+    &LEGALNOTICE;
12 13 
     <number>0330</number>
13 14 
     <status>Experimental</status>
14 15 
     <type>Standards Track</type>
15 16 
     <sig>Standards</sig>
16 17 
     <approver>Council</approver>
17 18 
     <dependencies>
18 
-        <spec>XMPP Core</spec>
19 
-        <spec>XEP-0001</spec>
20 
-        <spec>XEP-0163</spec>
21 
-        <spec>XEP-0060</spec>
19 
+      <spec>XMPP Core</spec>
20 
+      <spec>XEP-0001</spec>
21 
+      <spec>XEP-0163</spec>
22 
+      <spec>XEP-0060</spec>
22 23 
     </dependencies>
23 24 
     <supersedes/>
24 25 
     <supersededby/>
25 26 
     <shortname>NOT_YET_ASSIGNED</shortname>
26 27 
     <author>
27 
-    <firstname>Christine</firstname>
28 
-    <surname>Ho</surname>
29 
-    <email>nodpounod@gmail.com</email>
30 
-    <jid>christine.ho.dev@gmail.com</jid>
28 
+      <firstname>Christine</firstname>
29 
+      <surname>Ho</surname>
30 
+      <email>nodpounod@gmail.com</email>
31 
+      <jid>christine.ho.dev@gmail.com</jid>
31 32 
     </author>
32 33 
     <author>
33 
-    <firstname>Timothée</firstname>
34 
-    <surname>Jaussoin</surname>
35 
-    <email>edhelas@gmail.com</email>
36 
-    <jid>edhelas@movim.eu</jid>
34 
+      <firstname>Timothée</firstname>
35 
+      <surname>Jaussoin</surname>
36 
+      <email>edhelas@gmail.com</email>
37 
+      <jid>edhelas@movim.eu</jid>
37 38 
     </author>
38 39 
     <revision>
39 40 
       <version>0.1</version>
 
@@ -47,7 +48,7 @@
47 48 
       <initials>psa</initials>
48 49 
       <remark><p>First draft.</p></remark>
49 50 
     </revision>
50 
-</header>
51 
+  </header>
51 52 
 <section1 topic='Introduction' anchor='intro'>
52 53 
     <p>
53 54 
     &xep0060; nodes are commonly used by XMPP users to subscribe to news feeds. This document describe a way, for them, to share some of the nodes to which they have subscribed with other users.
 
@@ -57,7 +58,7 @@
57 58 
     </p>
58 59 
 </section1>
59 60 
 <section1 topic='Protocol' anchor='protocol'>
60 
-    <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>
61 
+    <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>
61 62 
     <table caption='attributes'>
62 63 
         <tr>
63 64 
             <td><strong>Name</strong></td>
 
@@ -71,21 +72,18 @@
71 72 
             <td>Any server's address</td>
72 73 
             <td>REQUIRED</td>
73 74 
         </tr>
74 
-
75 75 
         <tr>
76 76 
             <td>node</td>
77 77 
             <td>attribute</td>
78 78 
             <td></td>
79 79 
             <td>REQUIRED</td>
80 80 
         </tr>
81 
-
82 81 
         <tr>
83 82 
             <td>id</td>
84 83 
             <td>node</td>
85 84 
             <td></td>
86 85 
             <td>RECOMMENDED</td>
87 86 
         </tr>
88 
-
89 87 
         <tr>
90 88 
             <td>title</td>
91 89 
             <td>node</td>
 
@@ -93,10 +91,8 @@
93 91 
             <td>OPTIONAL</td>
94 92 
         </tr>
95 93 
     </table>
96 
-
97 94 
     <section2 topic="Item ID generation method">
98 95 
         <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>
99 
-
100 96 
         <ol>
101 97 
             <li>Initialize an empty string S</li>
102 98 
             <li>Append the name of the server, followed by the '&lt;' character</li>
 
@@ -104,7 +100,6 @@
104 100 
             <li>Append the jid of the current account</li>
105 101 
             <li>Compute the ID by hashing the S string using the SHA1 algorythm</li>
106 102 
         </ol>
107 
-
108 103 
         <section3 topic="Generation Example">
109 104 
             <ol>
110 105 
                 <li>S = ''</li>
 
@@ -126,86 +121,73 @@
126 121 
     <dl>
127 122 
         <di>
128 123 
             <dt>Personnal Eventing</dt>
129 
-            <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
124 
+            <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
130 125 
                 <link url='http://xmpp.org/extensions/xep-0163.html'>Personal Eventing Protocol</link>.
131 126 
             </dd>
132 127 
         </di>
133 128 
     </dl>
134 129 
 </section1>
135 130 
 <section1 topic='Use Cases' anchor='usecases'>
136 
-    <section2 topic='Requesting the list of subscription' anchor='usecases'>
137 
-            <example caption='Requests the list of subscriptions'><![CDATA[
138 
-            <iq type='get'
139 
-                from='romeo@montague.lit'
140 
-                to='pubsub.shakespeare.lit'
141 
-                id='items1'>
142 
-              <pubsub xmlns='http://jabber.org/protocol/pubsub'>
143 
-                <items node='urn:xmpp:pubsub:subscription'/>
144 
-              </pubsub>
145 
-            </iq>]]></example>
131 
+  <section2 topic='Requesting the list of subscription' anchor='usecases'>
132 
+    <example caption='Requests the list of subscriptions'><![CDATA[
133 
+<iq type='get'
134 
+    from='romeo@montague.lit'
135 
+    to='pubsub.shakespeare.lit'
136 
+    id='items1'>
137 
+  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
138 
+    <items node='urn:xmpp:pubsub:subscription'/>
139 
+  </pubsub>
140 
+</iq>]]></example>
146 141 
     </section2>
147 
-
148 142 
     <section2 topic='Adding a subscription to the list' anchor='usecases'>
149 
-            <example caption='Add a subscription to the list '><![CDATA[
150 
-            <iq type="set" from="romeo@montague.lit" id="sub123">
151 
-            <pubsub xmlns="http://jabber.org/protocol/pubsub">
152 
-                <publish node="urn:xmpp:pubsub:subscription">
153 
-                  <item id="0bc0e76cb803b3b107aa369169d8c0d45086f844">
154 
-                    <subscription xmlns="urn:xmpp:pubsub:subscription:0"
155 
-            server="pubsub.shakespeare.lit" node="party">
156 
-                      <title>Party at the Capulets</title>
157 
-                    </subscription>
158 
-                  </item>
159 
-                </publish>
160 
-              </pubsub>
161 
-            </iq>
162 
-              ]]>
163 
-            </example>
143 
+      <example caption='Add a subscription to the list '><![CDATA[
144 
+<iq type="set" from="romeo@montague.lit" id="sub123">
145 
+<pubsub xmlns="http://jabber.org/protocol/pubsub">
146 
+    <publish node="urn:xmpp:pubsub:subscription">
147 
+      <item id="0bc0e76cb803b3b107aa369169d8c0d45086f844">
148 
+        <subscription xmlns="urn:xmpp:pubsub:subscription:0"
149 
+server="pubsub.shakespeare.lit" node="party">
150 
+          <title>Party at the Capulets</title>
151 
+        </subscription>
152 
+      </item>
153 
+    </publish>
154 
+  </pubsub>
155 
+</iq>]]></example>
164 156 
     </section2>
165 
-
166 157 
     <section2 topic='Removing a subscription from the list' anchor='usecases'>
167 
-        <p>
168 
-            <example caption='Remove a subscription from the list '><![CDATA[
169 
-            <iq type='set'
170 
-                from='romeo@montague.lit'
171 
-                to='pubsub.shakespeare.lit'
172 
-                id='unsub1'>
173 
-            <pubsub xmlns='http://jabber.org/protocol/pubsub'>
174 
-                <retract node='urn:xmpp:pubsub:subscription'>
175 
-                  <item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'/>
176 
-                </retract>
177 
-            </pubsub>
178 
-            </iq>
179 
-              ]]>
180 
-            </example>
181 
-        </p>
158 
+          <example caption='Remove a subscription from the list '><![CDATA[
159 
+<iq type='set'
160 
+    from='romeo@montague.lit'
161 
+    to='pubsub.shakespeare.lit'
162 
+    id='unsub1'>
163 
+<pubsub xmlns='http://jabber.org/protocol/pubsub'>
164 
+    <retract node='urn:xmpp:pubsub:subscription'>
165 
+      <item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'/>
166 
+    </retract>
167 
+</pubsub>
168 
+</iq>]]></example>
182 169 
     </section2>
183 
-
184 170 
     <section2 topic='Modifiying a subscription of the list' anchor='usecases'>
185 
-        <p>
186 
-            <example caption='Change the information of a subscription of the list '><![CDATA[
187 
-            <iq type='set'
188 
-                from='romeo@montague.lit'
189 
-                to='pubsub.shakespeare.lit'
190 
-                id='unsub1'>
191 
-            <pubsub xmlns='http://jabber.org/protocol/pubsub'>
192 
-             <publish node='urn:xmpp:pubsub:subscription'>
193 
-                  <item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'>
194 
-                    <subscription xmlns='urn:xmpp:pubsub:subscription:0'
195 
-            server='pubsub.shakespeare.lit' node='party'>
196 
-                      <title>Party at the Capulets [canceled !]</title>
197 
-                    </subscription>
198 
-                  </item>
199 
-            </publish>
200 
-            </pubsub>
201 
-            </iq>
202 
-              ]]>
203 
-            </example>
204 
-        </p>
171 
+      <example caption='Change the information of a subscription of the list '><![CDATA[
172 
+<iq type='set'
173 
+    from='romeo@montague.lit'
174 
+    to='pubsub.shakespeare.lit'
175 
+    id='unsub1'>
176 
+<pubsub xmlns='http://jabber.org/protocol/pubsub'>
177 
+ <publish node='urn:xmpp:pubsub:subscription'>
178 
+      <item id='0bc0e76cb803b3b107aa369169d8c0d45086f844'>
179 
+        <subscription xmlns='urn:xmpp:pubsub:subscription:0'
180 
+server='pubsub.shakespeare.lit' node='party'>
181 
+          <title>Party at the Capulets [canceled !]</title>
182 
+        </subscription>
183 
+      </item>
184 
+</publish>
185 
+</pubsub>
186 
+</iq>]]></example>
205 187 
     </section2>
206 188 
 </section1>
207 189 
 <section1 topic='Internationalization Considerations' anchor='i18n'>
208 
-  <p>The title element of a <subscription/> item SHOULD be in the same language as the contents of the node in question.</p>
190 
+  <p>The title element of a &subscription; item SHOULD be in the same language as the contents of the node in question.</p>
209 191 
 </section1>
210 192 
 <section1 topic='Security Considerations' anchor='security'>
211 193 
   <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>

+ 1
- 4
xep-0336.xml View File 

@@ -863,7 +863,6 @@
863 863 
 							available in the <strong>updated form</strong>, the flag stating that user input has occurred in the field can be cleared.
864 864 
 						</li>
865 865 
 					</ul>
866 
-					<br/>
867 866 
 				</li>
868 867 
 				<li>
869 868 
 					<p>
 
@@ -889,9 +888,7 @@
889 888 
         </p>
890 889 
     </section1>
891 890 
     <section1 topic='IANA Considerations' anchor='iana'>
892 
-        <p>
893 
-            <p>This document requires no interaction with &IANA;.</p>
894 
-        </p>
891 
+      <p>This document requires no interaction with &IANA;.</p>
895 892 
     </section1>
896 893 
     <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
897 894 
         <p>

+ 51
- 51
xep-0337.xml View File 

@@ -5,55 +5,55 @@
5 5 
 ]>
6 6 
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
7 7 
 <xep>
8 
-    <header>
9 
-        <title>Event Logging over XMPP</title>
10 
-        <abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
11 
-		&LEGALNOTICE;
12 
-        <number>0337</number>
13 
-        <status>Experimental</status>
14 
-        <type>Standards Track</type>
15 
-        <sig>Standards</sig>
16 
-        <approver>Council</approver>
17 
-        <dependencies>
18 
-            <spec>XMPP Core</spec>
19 
-            <spec>XEP-0001</spec>
20 
-        </dependencies>
21 
-        <supersedes/>
22 
-        <supersededby/>
23 
-        <shortname>eventlogging</shortname>
24 
-        &peterwaher;
25 
-		<revision>
26 
-			<version>0.2</version>
27 
-			<date>2015-11-09</date>
28 
-			<initials>pw</initials>
29 
-			<remark>
30 
-				<p>Updated contact information.</p>
31 
-				<p>Updated example JIDs to example.org</p>
32 
-			</remark>
33 
-		</revision>
34 
-  <revision>
35 
-    <version>0.1</version>
36 
-    <date>2014-01-08</date>
37 
-    <initials>psa</initials>
38 
-    <remark><p>Initial published version approved by the XMPP Council.</p></remark>
39 
-  </revision>
40 
-        <revision>
41 
-            <version>0.0.2</version>
42 
-            <date>2013-12-02</date>
43 
-            <initials>pw</initials>
44 
-            <remark>
45 
-                <p>Addressed pre-publication feedback from the XMPP Council.</p>
46 
-            </remark>
47 
-        </revision>
48 
-        <revision>
49 
-            <version>0.0.1</version>
50 
-            <date>2013-11-10</date>
51 
-            <initials>pw</initials>
52 
-            <remark>
53 
-                <p>First draft.</p>
54 
-            </remark>
55 
-        </revision>
56 
-    </header>
8 
+  <header>
9 
+    <title>Event Logging over XMPP</title>
10 
+    <abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
11 
+    &LEGALNOTICE;
12 
+    <number>0337</number>
13 
+    <status>Experimental</status>
14 
+    <type>Standards Track</type>
15 
+    <sig>Standards</sig>
16 
+    <approver>Council</approver>
17 
+    <dependencies>
18 
+      <spec>XMPP Core</spec>
19 
+      <spec>XEP-0001</spec>
20 
+    </dependencies>
21 
+    <supersedes/>
22 
+    <supersededby/>
23 
+    <shortname>eventlogging</shortname>
24 
+    &peterwaher;
25 
+    <revision>
26 
+      <version>0.2</version>
27 
+      <date>2015-11-09</date>
28 
+      <initials>pw</initials>
29 
+      <remark>
30 
+        <p>Updated contact information.</p>
31 
+        <p>Updated example JIDs to example.org</p>
32 
+      </remark>
33 
+    </revision>
34 
+    <revision>
35 
+      <version>0.1</version>
36 
+      <date>2014-01-08</date>
37 
+      <initials>psa</initials>
38 
+      <remark><p>Initial published version approved by the XMPP Council.</p></remark>
39 
+    </revision>
40 
+    <revision>
41 
+      <version>0.0.2</version>
42 
+      <date>2013-12-02</date>
43 
+      <initials>pw</initials>
44 
+      <remark>
45 
+        <p>Addressed pre-publication feedback from the XMPP Council.</p>
46 
+      </remark>
47 
+    </revision>
48 
+    <revision>
49 
+      <version>0.0.1</version>
50 
+      <date>2013-11-10</date>
51 
+      <initials>pw</initials>
52 
+      <remark>
53 
+        <p>First draft.</p>
54 
+      </remark>
55 
+    </revision>
56 
+  </header>
57 57 
     <section1 topic='Introduction' anchor='intro'>
58 58 
         <p>
59 59 
             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>
222 222 
       </log>
223 223 
    </message>]]>
224 224 
             </example>
225 
-            <strong>Note:</strong> Any <strong>tag</strong> elements must come after the <strong>message</strong> element.
225 
+            <p><strong>Note:</strong> Any <strong>tag</strong> elements must come after the <strong>message</strong> element.</p>
226 226 
         </section2>
227 227 
         <section2 topic='Specifying program module' anchor='modules'>
228 228 
             <p>
 
@@ -256,7 +256,7 @@ File2, Line2, ...
256 256 
       </log>
257 257 
    </message>]]>
258 258 
             </example>
259 
-            <strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.
259 
+            <p><strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.</p>
260 260 
         </section2>
261 261 
         <section2 topic='Sending multiple events' anchor='multipleevents'>
262 262 
             <p>

+ 1
- 1
xep-0338.xml View File 

@@ -20,6 +20,7 @@
20 20 
   <supersedes/>
21 21 
   <supersededby/>
22 22 
   <shortname>NOT_YET_ASSIGNED</shortname>
23 
+  &fippo;
23 24 
   <revision>
24 25 
     <version>0.1</version>
25 26 
     <date>2014-01-08</date>
 
@@ -32,7 +33,6 @@
32 33 
     <initials>ph</initials>
33 34 
     <remark><p>First draft.</p></remark>
34 35 
   </revision>
35 
-  &fippo;
36 36 
 </header>
37 37 
 <section1 topic="Introduction" anchor="intro">
38 38 
   <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>

+ 1
- 1
xep-0339.xml View File 

@@ -20,6 +20,7 @@
20 20 
   <supersedes/>
21 21 
   <supersededby/>
22 22 
   <shortname>NOT_YET_ASSIGNED</shortname>
23 
+  &fippo;
23 24 
   <revision>
24 25 
     <version>0.2</version>
25 26 
     <date>2015-11-09</date>
 
@@ -38,7 +39,6 @@
38 39 
     <initials>ph</initials>
39 40 
     <remark><p>First draft.</p></remark>
40 41 
   </revision>
41 
-  &fippo;
42 42 
 </header>
43 43 
 <section1 topic="Introduction" anchor="intro">
44 44 
   <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>

+ 3
- 3
xep-0340.xml View File 

@@ -24,22 +24,22 @@
24 24 
     <supersedes/>
25 25 
     <supersededby/>
26 26 
     <shortname>colibri</shortname>
27 
+    <discuss>jingle</discuss>
27 28 
     <author>
28 29 
       <firstname>Emil</firstname>
29 30 
       <surname>Ivov</surname>
31 
+      <org>jitsi.org</org>
30 32 
       <email>emcho@jitsi.org</email>
31 33 
       <jid>emcho@sip-communicator.org</jid>
32 
-      <org>jitsi.org</org>
33 34 
     </author>
34 35 
     <author>
35 36 
       <firstname>Lyubomir</firstname>
36 37 
       <surname>Marinov</surname>
38 
+      <org>jitsi.org</org>
37 39 
       <email>lubo@jitsi.org</email>
38 40 
       <jid>lubo@sip-communicator.org</jid>
39 
-      <org>jitsi.org</org>
40 41 
     </author>
41 42 
     &fippo;
42 
-    <discuss>jingle</discuss>
43 43 
     <revision>
44 44 
       <version>0.1</version>
45 45 
       <date>2014-01-08</date>

+ 3
- 3
xep-0344.xml View File 

@@ -20,7 +20,9 @@
20 20 
   </dependencies>
21 21 
   <supersedes/>
22 22 
   <supersededby/>
23 
-  <shortname>dwd</shortname>
23 
+  <shortname>N/A</shortname>
24 
+  &fippo;
25 
+  &dcridland;
24 26 
   <revision>
25 27 
     <version>0.3</version>
26 28 
     <date>2015-03-23</date>
 
@@ -65,8 +67,6 @@
65 67 
     <initials>ph</initials>
66 68 
     <remark><p>First draft.</p></remark>
67 69 
   </revision>
68 
-  &fippo;
69 
-  &dcridland;
70 70 
 </header>
71 71 
 <section1 topic='Introduction' anchor='intro'>
72 72 
   <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>

+ 2
- 2
xep-0345.xml View File 

@@ -11,11 +11,11 @@
11 11 
 			This specification outlines the form and mandatory content
12 12 
 			of membership applications.
13 13 
 		</abstract>
14 
+		&LEGALNOTICE;
14 15 
     <number>0345</number>
16 
+		<status>Proposed</status>
15 17 
   	<lastcall>2014-07-24</lastcall>
16 
-		&LEGALNOTICE;
17 18 
 		<type>Procedural</type>
18 
-		<status>Proposed</status>
19 19 
     <sig>None</sig>
20 20 
     <approver>Board</approver>
21 21 
     <dependencies/>

+ 1
- 1
xep-0346.xml View File 

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

+ 1
- 1
xep-0348.xml View File 

@@ -500,7 +500,7 @@
500 500 
 		<p>
501 501 
 			The &REGISTRAR; includes the following information in its registries.
502 502 
 		</p>
503 
-		<section2 topic='Field Standardization' ancor='fieldstandardization'>
503 
+		<section2 topic='Field Standardization' anchor='fieldstandardization'>
504 504 
 			<p>
505 505 
 				&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use
506 506 
 				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.

+ 1
- 1
xep-0349.xml View File 

@@ -91,7 +91,7 @@
91 91 
   </section2>
92 92
93 93 
   <section2 topic='Conventions' anchor='terms-conventions'>
94 
-    In examples, the following JIDs are used:
94 
+    <p>In examples, the following JIDs are used:</p>
95 95 
     <ul>
96 96 
       <li><strong>juliet@capulet.lit/balcony, romeo@montague.lit/orchard</strong> - Potential controlling parties</li>
97 97 
       <li><strong>shakespeare.lit</strong> - The root domain of the Rayo service, presented as the external interface of the Gateway(s).</li>

+ 14
- 7
xep-0354.xml View File 

@@ -118,7 +118,11 @@ Examples for balancing algorithms include:
118 118 
 <section1 topic='Protocol' anchor='protocol'>
119 119 
 <section2 topic='Discovering Support'>
120 120
121 
-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;.
121 
+  <p>
122 
+    An entity advertises support for this protocol by including the
123 
+    'urn:xmpp:cmr:0' feature in its service discovery information features as
124 
+    specified in &xep0030; or section 6.3 of &xep0115;.
125 
+  </p>
122 126
123 127 
 <example caption='Service discovery information request'><![CDATA[
124 128 
 <iq xmlns='jabber:client'
 
@@ -218,7 +222,11 @@ If the server is unable to change the message routing algorithm, then an error &
218 222
219 223 
 <section2 topic='Message Routing Hints'>
220 224
221 
-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.
225 
+  <p>
226 
+    If allowed and supported by the server, clients are able to annotate message
227 
+    stanza with a routing hint, that SHOULD affect the used message routing
228 
+    algorithm for the annotated stanza.
229 
+  </p>
222 230
223 231 
 <section3 topic='Determing support'>
224 232 
 
@@ -307,7 +315,7 @@ The CMR state, ie. the used routing algorithm, is identical for every session of
307 315 
 <p>
308 316 
 <strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:all'
309 317 
 </p>
310 
-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.
318 
+<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>
311 319
312 320 
 </section3>
313 321 
 
@@ -315,7 +323,7 @@ Deliver to all non-negative resources with share the same maximum priority. And
315 323 
 <p>
316 324 
 <strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:mostactive'
317 325 
 </p>
318 
-Deliver the message to the "most available" resource or resources, depending on the server's implementation.
326 
+<p>Deliver the message to the "most available" resource or resources, depending on the server's implementation.</p>
319 327
320 328 
 </section3>
321 329 
 
@@ -323,7 +331,7 @@ Deliver the message to the "most available" resource or resources, depending on
323 331 
 <p>
324 332 
 <strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:roundrobin'
325 333 
 </p>
326 
-Deliver the message to the next resource selected by a round-robin algorithm.
334 
+<p>Deliver the message to the next resource selected by a round-robin algorithm.</p>
327 335
328 336 
 </section3>
329 337 
 
@@ -331,8 +339,7 @@ Deliver the message to the next resource selected by a round-robin algorithm.
331 339 
 <p>
332 340 
 <strong>Algorithm Namespace:</strong> 'urn:xmpp:cmr:weighted'
333 341 
 </p>
334 
-Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority.
335 
-
342 
+<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>
336 343 
 </section3>
337 344 
 </section2>
338 345 
 </section1>

+ 0
- 1
xep-0358.xml View File 

@@ -21,7 +21,6 @@
21 21 
   <supersedes/>
22 22 
   <supersededby/>
23 23 
   <shortname>jinglepub</shortname>
24 
-  <schemaloc/>
25 24 
   &fippo;
26 25 
   &lance;
27 26 
   &stpeter;

+ 1
- 1
xep-0359.xml View File 

@@ -94,7 +94,7 @@
94 94 
            id='de305d54-75b4-431b-adb2-eb6b9e546013'
95 95 
            by='room@muc.xmpp.org'/>
96 96 
 ]]></example>
97 
-  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.
97 
+  <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>
98 98 
   </section2>
99 99 
   <section2 topic='Origin generated stanza IDs' anchor='origin-id'>
100 100 
 	<p>

+ 1
- 1
xep-0360.xml View File 

@@ -63,11 +63,11 @@
63 63 
   <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>
64 64 
 </section1>
65 65 
 <section1 topic='Business Rules' anchor='rules'>
66 
-  <p>
67 66 
 	<ol>
68 67 
 	  <li>Nonzas MUST NOT be routed, i.e. they are only exchanged between the two endpoints of an XMPP stream.</li>
69 68 
 	  <li>Nonzas SHOULD NOT have a &apos;from&apos; or &apos;to&apos; attribute.</li>
70 69 
 	</ol>
70 
+  <p>
71 71 
 	Note that an exception from 2. are the the widely used &lt;db/&gt; Nonzas defined in &xep0220;.
72 72 
   </p>
73 73 
 </section1>

+ 30
- 38
xep-0364.xml View File 

@@ -58,9 +58,9 @@
58 58 
     <p>
59 59 
       The Off-the-Record messaging protocol (OTR) was originally introduced in
60 60 
       the 2004 paper
61 
-      <i><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
61 
+      <em><link url='https://otr.cypherpunks.ca/otr-wpes.pdf'>
62 62 
           Off-the-Record Communication, or, Why Not To Use PGP
63 
-      </link></i>
63 
+      </link></em>
64 64 
       <note>
65 65 
         Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record
66 66 
         Communication, or, Why Not To Use PGP"
 
@@ -74,9 +74,9 @@
74 74 
     </p>
75 75 
     <p>
76 76 
       The OTR protocol itself is currently described by the document:
77 
-      <i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
77 
+      <em><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
78 78 
           Off-the-Record Messaging Protocol version 3
79 
-      </link></i>
79 
+      </link></em>
80 80 
       <note>
81 81 
         "Off-the-Record Messaging Protocol version 3"
82 82 
         &lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
 
@@ -118,30 +118,31 @@
118 118 
       whitespace tag in their messages. This tag can appear anywhere in the body
119 119 
       of the message stanza, but it is most often found at the end. The OTR tag
120 120 
       comprises the following bytes:
121 
+    </p>
121 122
122 
-      <example caption='OTR tag'>
123 
+    <example caption='OTR tag'><![CDATA[
123 124 
 \x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20
124 
-      </example>
125 
+]]></example>
125 126
127 
+    <p>
126 128 
       and is followed by one or more of the following sequences to indicate the
127 129 
       version of OTR which the client supports:
128 
-
129 
-      <example caption='OTR tag version 1'>
130 
+    </p>
131 
+    <example caption='OTR tag version 1'><![CDATA[
130 132 
 \x20\x09\x20\x09\x20\x20\x09\x20
131 
-      </example>
133 
+]]></example>
132 134
135 
+    <p>
133 136 
       Note that this version 1 tag must come before other version tags for
134 137 
       compatibility; it is, however, NOT RECOMMENDED to implement version 1 of
135 138 
       the OTR protocol.
136 
-
137 
-      <example caption='OTR tag version 2'>
139 
+    </p>
140 
+      <example caption='OTR tag version 2'><![CDATA[
138 141 
 \x20\x20\x09\x09\x20\x20\x09\x20
139 
-      </example>
140 
-
141 
-      <example caption='OTR tag version 3'>
142 
+]]></example>
143 
+      <example caption='OTR tag version 3'><![CDATA[
142 144 
 \x20\x20\x09\x09\x20\x20\x09\x09
143 
-      </example>
144 
-    </p>
145 
+]]></example>
145 146 
     <p>
146 147 
       When a client sees this special string in the body of a message stanza it
147 148 
       may choose to start an OTR session immediately, or merely indicate support
 
@@ -150,11 +151,8 @@
150 151 
       which indicates the supported versions of OTR. In XMPP these are most
151 152 
       commonly version 2 and version 3, which would be indicated by a message
152 153 
       stanza which has a body that starts with the string:
153 
-
154 
-      <example caption='OTR query'>
155 
-?OTR?v23?
156 
-      </example>
157 154 
     </p>
155 
+      <example caption='OTR query'>?OTR?v23?</example>
158 156 
     <p>
159 157 
       Any message which begins with the afforementioned string (note that the
160 158 
       version number[s] may be different), postfixed with a payload should be
 
@@ -192,26 +190,22 @@
192 190 
         XMPP servers. These hints are not hard and fast rules, but suggestions
193 191 
         which the servers may or may not choose to follow. Best practice is to
194 192 
         include the following hints on all OTR messages:
195 
-
196 
-        <code><![CDATA[
193 
+      </p>
194 
+      <code><![CDATA[
197 195 
 <no-copy xmlns="urn:xmpp:hints"/>
198 196 
 <no-permanent-store xmlns="urn:xmpp:hints"/>
199 
-          ]]></code>
200 
-      </p>
201 
-
197 
+]]></code>
202 198 
       <p>
203 199 
         Similarly the "private" directive from &xep0280; should also be included
204 200 
         to indicate that carbons are not necessary (since no other resource will
205 201 
         be able to read the message):
206 
-
207 
-        <code><![CDATA[
208 
-<private xmlns="urn:xmpp:carbons:2"/>
209 
-          ]]></code>
210 
-
202 
+      </p>
203 
+      <code><![CDATA[<private xmlns="urn:xmpp:carbons:2"/>]]></code>
204 
+      <p>
211 205 
         All together, an example OTR message might look like this (with the
212 206 
         majority of the body stripped out for readability):
213 
-
214 
-        <example caption='OTR message with processing hints'><![CDATA[
207 
+      </p>
208 
+      <example caption='OTR message with processing hints'><![CDATA[
215 209 
 <message from='malvolio@stewardsguild.lit/countesshousehold'
216 210 
          to='olivia@countess.lit/veiled'>
217 211 
   <body>?OTR?v23?...</body>
 
@@ -219,8 +213,7 @@
219 213 
   <no-permanent-store xmlns="urn:xmpp:hints"/>
220 214 
   <private xmlns="urn:xmpp:carbons:2"/>
221 215 
 </message>
222 
-          ]]></example>
223 
-      </p>
216 
+]]></example>
224 217 
     </section2>
225 218 
     <section2 topic='Delivery Receipts'>
226 219 
       <p>
 
@@ -281,11 +274,10 @@
281 274 
       &xep0147; defines various query components for use with XMPP URI's. When
282 275 
       an entity has an associated OTR fingerprint it's URI is often formed with
283 276 
       "otr-fingerprint" in the query string. Eg.
284 
-
285 
-      <example caption='OTR Fingerprint'>
286 
-xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
287 
-      </example>
288 277 
     </p>
278 
+    <example caption='OTR Fingerprint'><![CDATA[
279 
+xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
280 
+]]></example>
289 281 
     <p>
290 282 
       The &REGISTRAR; maintains a registry of queries and key-value pairs for
291 283 
       use in XMPP URIs at &QUERYTYPES;. As of the date this document was

+ 9
- 7
xep-0367.xml View File 

@@ -134,10 +134,12 @@
134 134 
   </p>
135 135 
 </section1>
136 136 
 <section1 topic='Security Considerations' anchor='security'>
137 
-  Clients that implement message attachments MUST be careful not to display the
138 
-  attachments in such a way that they could be confused with the original
139 
-  message and cause someone viewing the conversation to assume they were sent
140 
-  by the sender of the message being attached to.
137 
+  <p>
138 
+    Clients that implement message attachments MUST be careful not to display
139 
+    the attachments in such a way that they could be confused with the original
140 
+    message and cause someone viewing the conversation to assume they were sent
141 
+    by the sender of the message being attached to.
142 
+  </p>
141 143 
 </section1>
142 144 
 <section1 topic='IANA Considerations' anchor='iana'>
143 145 
   <p>This document requires no interaction with &IANA;.</p>
 
@@ -150,14 +152,14 @@
150 152 
 	<p>
151 153 
     The &REGISTRAR; shall include the foregoing namespaces in its disco
152 154 
     features registry as defined in &xep0030;.
153 
-		<code caption='Registry Submission'><![CDATA[
155 
+	</p>
156 
+	<code caption='Registry Submission'><![CDATA[
154 157 
 <var>
155 158 
 	<name>urn:xmpp:message-attaching:0</name>
156 159 
 	<desc>Indicates support for attaching one message to another.</desc>
157 160 
 	<doc>XEP-xxxx</doc>
158 161 
 </var>
159 
-		]]></code>
160 
-	</p>
162 
+]]></code>
161 163 
 </section1>
162 164 
 <section1 topic='XML Schema' anchor='schema'>
163 165 
   <code><![CDATA[

+ 8
- 18
xep-0373.xml View File 

@@ -5,8 +5,6 @@
5 5 
   <!ENTITY crypt "&lt;crypt/&gt;">
6 6 
   <!ENTITY openpgp "&lt;openpgp/&gt;">
7 7 
   <!ENTITY payload "&lt;payload/&gt;">
8 
-  <!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>" >
9 
-  <!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>" >
10 8 
   <!ENTITY % ents SYSTEM 'xep.ent'>
11 9 
 %ents;
12 10 
 ]>
 
@@ -18,14 +16,7 @@
18 16 
   OpenPGP, announcement, discovery and retrieval of public keys and a
19 17 
   mechanism to synchronize secret keys over multiple
20 18 
   devices.</abstract>
21 
-  <legal>
22 
-    <copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2016 by the XMPP Standards Foundation (XSF).</copyright>
23 
-    <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
24 
-Standards Foundation.</permissions>
25 
-    <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>
26 
-    <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>
27 
-    <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>
28 
-  </legal>
19 
+  &LEGALNOTICE;
29 20 
   <number>0373</number>
30 21 
   <status>Experimental</status>
31 22 
   <type>Standards Track</type>
 
@@ -523,10 +514,10 @@ Standards Foundation.</permissions>
523 514 
         4-character chunks, e.g.,
524 515 
         <tt>TWNK-KD5Y-MT3T-E1GS-DRDB-KVTW</tt>. The characters MUST be
525 516 
         generated from cryptographically secure random. For example
526 
-        <link
527 
-        url='https://lwn.net/Articles/606141/'><tt>getrandom(2)</tt></link>,
528 
-        <link
529 
-        url='https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html'><tt>SecureRandom</tt></link>
517 
+        <tt><link
518 
+        url='https://lwn.net/Articles/606141/'>getrandom(2)</link></tt>,
519 
+        <tt><link
520 
+          url='https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html'>SecureRandom</link></tt>
530 521 
         or <tt>/dev/urandom</tt>. More information about the
531 522 
         randomness requirements for security can be found in &rfc4086;
532 523 
         </li>
 
@@ -691,8 +682,7 @@ Standards Foundation.</permissions>
691 682 
     additional checksum) and in favor for Base64, because
692 683 
     encoding should be part of the network application rather than the
693 684 
     crypto layer. Also XMPP, needs no additional error correction of payload.
694 
-    In "MIME Security with OpenPGP" (<link
695 
-    url='http://tools.ietf.org/html/rfc3156'>&rfc3156;</link>), ASCII Armor
685 
+    In "MIME Security with OpenPGP" (&rfc3156;), ASCII Armor
696 686 
     has only been chosen to be backwards compatible with legacy applications
697 687 
     supporting non-MIME OpenPGP emails only.</p>
698 688 
 
@@ -701,8 +691,8 @@ Standards Foundation.</permissions>
701 691 
   <section2 topic='OpenPGP User IDs' anchor='openpgp-user-ids'>
702 692
703 693 
     <p>OpenPGP User IDs normally consist of a name - email address pair, e.g.,
704 
-    "Juliet &lt;juliet@example.org&gt;" (<link
705 
-    url='http://tools.ietf.org/html/rfc4880#section-5.11'><cite>RFC 4880 § 5.11</cite></link>).
694 
+      "Juliet &lt;juliet@example.org&gt;" (<cite>RFC 4880</cite> <link
695 
+    url='http://tools.ietf.org/html/rfc4880#section-5.11'>§ 5.11</link>).
706 696 
     For this XEP, we require User IDs of the format "xmpp:juliet@example.org".
707 697 
     First, it is required to have at least one User ID indicating the use
708 698 
     of this OpenPGP key. When doing certification of keys (key signing),

+ 10
- 20
xep-0374.xml View File 

@@ -15,14 +15,7 @@
15 15 
   <title>OpenPGP for XMPP Instant Messaging</title>
16 16 
   <abstract>Specifies a OpenPGP for XMPP (XEP-0373) profile for the Instant
17 17 
     Messaging (IM) use case.</abstract>
18 
-  <legal>
19 
-    <copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2016 by the XMPP Standards Foundation (XSF).</copyright>
20 
-    <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
21 
-Standards Foundation.</permissions>
22 
-    <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>
23 
-    <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>
24 
-    <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>
25 
-  </legal>
18 
+  &LEGALNOTICE;
26 19 
   <number>0374</number>
27 20 
   <status>Experimental</status>
28 21 
   <type>Standards Track</type>
 
@@ -130,16 +123,14 @@ Standards Foundation.</permissions>
130 123 
     to store OpenPGP key information in the Domain Name
131 124 
     System (DNS). This specification does not restrict the mechanism
132 125 
     of key discovery and retrieval, but compliant clients MUST support
133 
-    the public key announcement as described in <link
134 
-    url='./xep-0373.html#announcing-discover-pubkey'><cite>XEP-0373
135 
-    § 4</cite></link>.</p>
126 
+    the public key announcement as described in <cite>XEP-0373</cite>
127 
+    <link url='./xep-0373.html#announcing-discover-pubkey'>§ 4</link>.</p>
136 128
137 129 
     <p>After the required public keys have been discovered, XMPP
138 130 
     clients engage in an OpenPGP secured IM
139 131 
     conversation by exchanging &openpgp; extension elements. They MUST
140 
-    use the &signcrypt; OpenPGP content element specified in <link
141 
-    url='./xep-0373.html#exchange'><cite>XEP-0373 §
142 
-    3.1</cite></link>.</p>
132 
+    use the &signcrypt; OpenPGP content element specified in
133 
+    <cite>XEP-0373</cite><link url='./xep-0373.html#exchange'>§ 3.1</link>.</p>
143 134
144 135 
     <p>The child elements of the OpenPGP content element's &payload;
145 136 
     can be seen as stanza extension elements which are encrypted and
 
@@ -245,11 +236,10 @@ Standards Foundation.</permissions>
245 236 
 </section1>
246 237
247 238 
 <section1 topic='Acknowledgements' anchor='acknowledgements'>
248 
-
249 
-  <p>Please refer to the <link
250 
-  url='./xep-0373.html#acknowledgements'>Acknowledgements
251 
-  section of <cite>XEP-0373</cite></link>, since the two XEPs where designed
252 
-  together.</p>
253 
-
239 
+  <p>
240 
+    Please refer to the
241 
+    <link url='./xep-0373.html#acknowledgements'>Acknowledgements section</link>
242 
+    of <cite>XEP-0373</cite> since the two XEPs where designed together.
243 
+  </p>
254 244 
 </section1>
255 245 
 </xep>

+ 4
- 6
xep-0375.xml View File 

@@ -55,12 +55,10 @@
55 55 
       <date>2016-07-11</date>
56 56 
       <initials>ssw</initials>
57 57 
       <remark>
58 
-        <p>
59 
-          <ul>
60 
-            <li>Add rationale.</li>
61 
-            <li>Refactor suites to focus less on XEPs and more on features.</li>
62 
-          </ul>
63 
-        </p>
58 
+        <ul>
59 
+          <li>Add rationale.</li>
60 
+          <li>Refactor suites to focus less on XEPs and more on features.</li>
61 
+        </ul>
64 62 
       </remark>
65 63 
     </revision>
66 64 
     <revision>

+ 8
- 8
xep-0376.xml View File 

@@ -52,29 +52,29 @@
52 52 
 </section1>
53 53 
 <section1 topic='User Stories' anchor='stories'>
54 54 
   <section2 topic='Device Agility'>
55 
-    <p><ul>
55 
+    <ul>
56 56 
       <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>
57 57 
       <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>
58 58 
       <li>The same capability as point 1 should be possible for unsubscribing.</li>
59 
-    </ul></p>
59 
+    </ul>
60 60 
   </section2>
61 61 
   <section2 topic='New Devices'>
62 
-    <p><ul>
62 
+    <ul>
63 63 
       <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>
64 
-    </ul></p>
64 
+    </ul>
65 65 
   </section2>
66 66 
   <section2 topic='Offline Capability'>
67 
-    <p><ul>
67 
+    <ul>
68 68 
       <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>
69 69 
       <li>It should be able to tell which of these the user is unlikely to have seen on other devices.</li>
70 70 
       <li>Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.</li>
71 
-    </ul></p>
71 
+    </ul>
72 72 
   </section2>
73 73 
   <section2 topic='PEP'>
74 
-    <p><ul>
74 
+    <ul>
75 75 
       <li>A one-way subscription to a user should still allow PEP.</li>
76 76 
       <li>PEP should work the same way as now - users see filtered notifications about the things they care about.</li>
77 
-    </ul></p>
77 
+    </ul>
78 78 
   </section2>
79 79 
 </section1>
80 80 
 <section1 topic='Protocol' anchor='protocol'>

+ 17
- 13
xep-0377.xml View File 

@@ -12,9 +12,8 @@
12 12 
     abuse to a server operator or other spam service.
13 13 
   </abstract>
14 14 
   &LEGALNOTICE;
15 
-  <status>Experimental</status>
16 15 
   <number>0377</number>
17 
-  <status>Standards Track</status>
16 
+  <status>Experimental</status>
18 17 
   <type>Standards Track</type>
19 18 
   <sig>Standards</sig>
20 19 
   <approver>Council</approver>
 
@@ -58,7 +57,8 @@
58 57 
     the relavant specifications. Eg. a response from a server that supports
59 58 
     reporting and understands the abuse and spam reasons defined later in this
60 59 
     specification might look like the following:
61 
-    <example caption="Service discovery information response"><![CDATA[
60 
+  </p>
61 
+  <example caption="Service discovery information response"><![CDATA[
62 62 
 <iq from='shakespeare.lit'
63 63 
     id='ku6e51v3'
64 64 
     to='kingclaudius@shakespeare.lit/castle'
 
@@ -68,9 +68,7 @@
68 68 
     <feature var='urn:xmpp:reporting:reason:abuse:0'/>
69 69 
     <feature var='urn:xmpp:reporting:reason:spam:0'/>
70 70 
   </query>
71 
-</iq>
72 
-    ]]></example>
73 
-  </p>
71 
+</iq>]]></example>
74 72 
 </section1>
75 73 
 <section1 topic='Payload' anchor='payload'>
76 74 
   <p>
 
@@ -90,10 +88,14 @@
90 88 
     This document defines the following reasons for a report:
91 89 
   </p>
92 90 
   <dl>
93 
-    <dt>&lt;spam/&gt;</dt>
94 
-    <dd>Used for reporting a JID that is sending unwanted messages.</dd>
95 
-    <dt>&lt;abuse/&gt;</dt>
96 
-    <dd>Used for reporting general abuse.</dd>
91 
+    <di>
92 
+      <dt>&lt;spam/&gt;</dt>
93 
+      <dd>Used for reporting a JID that is sending unwanted messages.</dd>
94 
+    </di>
95 
+    <di>
96 
+      <dt>&lt;abuse/&gt;</dt>
97 
+      <dd>Used for reporting general abuse.</dd>
98 
+    </di>
97 99 
   </dl>
98 100 
   <p>
99 101 
     Clients MUST include only one reason per report.
 
@@ -205,19 +207,21 @@
205 207 
         Upon advancement of this specification from a status of Experimental to
206 208 
         a status of Draft, the &REGISTRAR; shall add the following definition to
207 209 
         the abuse reporting reasons registry, as described in this document:
208 
-        <code><![CDATA[<reason>
210 
+      </p>
211 
+      <code><![CDATA[
212 
+<reason>
209 213 
   <name>Spam</name>
210 214 
   <urn>urn:xmpp:reporting:reason:spam:0</urn>
211 215 
   <desc>Used to report a JID that was sending spam messages.</desc>
212 216 
   <doc>XEP-0377</doc>
213 217 
 </reason>]]></code>
214 
-        <code><![CDATA[<reason>
218 
+      <code><![CDATA[
219 
+<reason>
215 220 
   <name>Abuse</name>
216 221 
   <urn>urn:xmpp:reporting:reason:abuse:0</urn>
217 222 
   <desc>Used to report general abuse that is not covered by a more specific reason.</desc>
218 223 
   <doc>XEP-0377</doc>
219 224 
 </reason>]]></code>
220 
-      </p>
221 225 
     </section2>
222 226 
   </section1>
223 227 
   <section1 topic='XML Schema' anchor='schema'>

+ 9
- 19
xep-0378.xml View File 

@@ -1,6 +1,7 @@
1 1 
 <?xml version='1.0' encoding='UTF-8'?>
2 2 
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
3 3 
 <!ENTITY % ents SYSTEM 'xep.ent'>
4 
+<!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>" >
4 5 
 %ents;
5 6 
 ]>
6 7 
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 
@@ -58,22 +59,12 @@
58 59 
 	</section1>
59 60 
 	<section1 topic='Discovering support' anchor='disco'>
60 61 
 		<p>
61 
-			If an entity supports OTR it MUST advertise the fact by returning a
62 
-			feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030;
63 
-			information request. This indicates support for OTRv3 as defined by
64 
-			<i><link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
65 
-				Off-the-Record Messaging Protocol version 3
66 
-			</link></i>
67 
-			<note>
68 
-				(Accessed 2015-08-30). "Off-the-Record Messaging Protocol version 3"
69 
-				&lt;<link url='https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html'>
70 
-					https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
71 
-				</link>&gt;
72 
-			</note>.
73 
-			<example caption='Disco response'><![CDATA[
74 
-<feature var='urn:xmpp:otr:0' />
75 
-			]]></example>
62 
+      If an entity supports OTR it MUST advertise the fact by returning a
63 
+      feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030; information
64 
+      request. This indicates support for OTRv3 as defined by &otr3;.
76 65 
 		</p>
66 
+    <example caption='Disco response'><![CDATA[
67 
+<feature var='urn:xmpp:otr:0' />]]></example>
77 68 
 		<p>
78 69 
 			If older versions of OTR are required, they may be discovered out of band
79 70 
 			using OTRs built in mechanism which is beyond the scope of this document.
 
@@ -100,13 +91,12 @@
100 91 
 	<p>
101 92 
 		The &REGISTRAR; shall include the foregoing namespaces in its disco
102 93 
 		features registry as defined in &xep0030;.
103 
-		<code caption='Registry Submission'><![CDATA[
94 
+	</p>
95 
+	<code caption='Registry Submission'><![CDATA[
104 96 
 <var>
105 97 
 	<name>urn:xmpp:otr:0</name>
106 98 
 	<desc>Indicates support for Off-the-Record Messaging (OTR) version 3</desc>
107 99 
 	<doc>XEP-0378</doc>
108 
-</var>
109 
-		]]></code>
110 
-	</p>
100 
+</var>]]></code>
111 101 
 </section1>
112 102 
 </xep>

+ 1
- 0
xep.ent View File 

@@ -482,6 +482,7 @@ THE SOFTWARE.
482 482 
 <!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>" >
483 483 
 <!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>" >
484 484 
 <!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>" >
485 
+<!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>" >
485 486 
 <!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>" >
486 487 
 <!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>" >
487 488 
 <!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>" >

Write Preview
Loading…
Cancel
Save