Browse Source

XEP-0204–XEP-0298: DTD fixes

Sam Whited 2 years ago
parent
commit
8de3ee3a29
29 changed files with 401 additions and 398 deletions
  1. 34
    35
      xep-0204.xml
  2. 4
    5
      xep-0209.xml
  3. 26
    49
      xep-0214.xml
  4. 3
    3
      xep-0220.xml
  5. 8
    9
      xep-0224.xml
  6. 0
    1
      xep-0226.xml
  7. 24
    30
      xep-0244.xml
  8. 2
    2
      xep-0245.xml
  9. 10
    0
      xep-0248.xml
  10. 17
    17
      xep-0252.xml
  11. 56
    57
      xep-0255.xml
  12. 27
    28
      xep-0258.xml
  13. 1
    1
      xep-0260.xml
  14. 82
    68
      xep-0272.xml
  15. 18
    0
      xep-0273.xml
  16. 12
    10
      xep-0276.xml
  17. 18
    24
      xep-0278.xml
  18. 8
    9
      xep-0280.xml
  19. 2
    2
      xep-0281.xml
  20. 15
    13
      xep-0283.xml
  21. 1
    0
      xep-0284.xml
  22. 14
    16
      xep-0287.xml
  23. 0
    4
      xep-0289.xml
  24. 3
    5
      xep-0292.xml
  25. 8
    5
      xep-0293.xml
  26. 4
    1
      xep-0294.xml
  27. 2
    2
      xep-0295.xml
  28. 1
    1
      xep-0296.xml
  29. 1
    1
      xep-0298.xml

+ 34
- 35
xep-0204.xml View File

@@ -571,10 +571,10 @@ A CDO client can query the server to determine the specific state of a particula
571 571
      </query>
572 572
 </iq>
573 573
 ]]></example>
574
-Note an event type of info. This requires all attributes for the data-sync element and items be present
574
+<p>Note an event type of info. This requires all attributes for the data-sync element and items be present</p>
575 575
 </section2>
576 576
     <section2 topic="Query an endpoint for a list of CDOs" anchor="cdolist">
577
-In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.
577
+      <p>In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.</p>
578 578
 <example caption="Client A constructs an IQ get and sends it to Server X wishing to obtain the current state of all CDOs belonging to the CDO users chatroom"><![CDATA[
579 579
 <iq type='get' from='joe@mitre.org/Desktop' to='cdo_users@mitre.org' id='cdo_state_2>
580 580
     <query xmlns='http://www.xmpp.org/extensions/xep-0204.html#ns-state'>
@@ -595,18 +595,17 @@ In some cases a client may be interested in the state of all CDOs belonging to a
595 595
           type="cdo:Location" 
596 596
           event="info" 
597 597
           xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns"/>
598
-        ... 
599
-          
598
+        ...
600 599
      </query>
601 600
 </iq>
602 601
 ]]></example>
603
-Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs
602
+<p>Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs</p>
604 603
 <p>
605 604
 If desired, Client A can then query the Server for the details on the state of a specific CDO using the protocol described earlier.
606 605
 </p>
607 606
     </section2>
608 607
     <section2 topic="Create a new CDO" anchor="cdocreate">
609
-When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:
608
+      <p>When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:</p>
610 609
 <example caption="Client A creates a new CDO and sends it to client B"><![CDATA[
611 610
 <message
612 611
     to='joe@mitre.org/Desktop'
@@ -625,7 +624,7 @@ When two endpoints (client A and client B) wish to create a new CDO. Each client
625 624
    </data-sync>
626 625
 </message>
627 626
 ]]></example>
628
-Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero
627
+<p>Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero</p>
629 628
 <p>
630 629
 Next, the message is intercepted by Server X. Server X is the IM server that both clients are connected to. When the server receives 
631 630
 the message, it MUST increment the version number and assign a uuid for both the &lt;data-sync&gt; and &lt;item&gt;. Once processed
@@ -675,10 +674,10 @@ Server X MUST send a copy of the message back to client A as a receipt that the
675 674
    </data-sync>
676 675
 </message>
677 676
 ]]></example>
678
-Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.
677
+<p>Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.</p>
679 678
 </section2>
680 679
     <section2 topic="Create a new Item on an existing CDO" anchor="cdoitemcreate">
681
-When client A wishes to create a new Item on an existing CDO, he sends the following information to client B
680
+      <p>When client A wishes to create a new Item on an existing CDO, he sends the following information to client B</p>
682 681
 <example caption="Client A creates a new item on an existing CDO and sends it to client B"><![CDATA[
683 682
 <message
684 683
     to='joe@mitre.org/Desktop'
@@ -741,10 +740,10 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
741 740
    </data-sync>
742 741
 </message>
743 742
 ]]></example>
744
-Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.
743
+<p>Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.</p>
745 744
 </section2>
746 745
     <section2 topic="Update an Item on an existing CDO" anchor="cdoitemupdate">
747
-When client A wishes to update an item on an existing CDO, he sends the following information to client B
746
+      <p>When client A wishes to update an item on an existing CDO, he sends the following information to client B</p>
748 747
 <example caption="Client A updates an item on an existing CDO and sends it to client B"><![CDATA[
749 748
 <message
750 749
     to='joe@mitre.org/Desktop'
@@ -819,7 +818,7 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
819 818
    </data-sync>
820 819
 </message>
821 820
 ]]></example>
822
-Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.
821
+<p>Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.</p>
823 822
   <section3 topic="Update Styles">
824 823
         <p>
825 824
        There are two types of behaviors associated with an item update: inclusive and exclusive. For an inclusive update, the content of the item element 
@@ -832,35 +831,35 @@ Once this is completed, both clients have a synchronized CDO message with an upd
832 831
      Assume that client A has created a CDO cdo_1. This CDO has an item item_1 with the attribute named attr_1 set. If A wants to update item_1 with a value 
833 832
      for the attribute named attr_2 without destroying the previously set value for attr_1, the following data synchronization packets are equivalent:
834 833
      </p>
835
-        <pre><![CDATA[
836
-<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003" 
834
+        <code><![CDATA[
835
+<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003"
837 836
            event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
838
-  <item type="field" 
839
-           uuid="item_1" 
840
-           event="update" 
841
-           version="1" 
837
+  <item type="field"
838
+           uuid="item_1"
839
+           event="update"
840
+           version="1"
842 841
            updateStyle="inclusive">
843 842
     <attribute name="attr_1">old value</attribute>
844 843
     <attribute name="attr_2">new value</attribute>
845 844
   </item>
846 845
 </data-sync>
847
-     ]]></pre>
848
-        <pre><![CDATA[
849
-<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003" 
846
+]]></code>
847
+        <code><![CDATA[
848
+<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003"
850 849
            event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
851
-  <item type="field" 
852
-           uuid="item_1" 
853
-           event="update" 
854
-           version="1" 
850
+  <item type="field"
851
+           uuid="item_1"
852
+           event="update"
853
+           version="1"
855 854
            updateStyle="exclusive">
856 855
        <attribute name="attr_2">new value</attribute>
857
-  </item> 
856
+  </item>
858 857
 </data-sync>
859
-     ]]></pre>
858
+]]></code>
860 859
       </section3>
861 860
     </section2>
862 861
     <section2 topic="Delete an Item on an existing CDO" anchor="cdoitemdelete">
863
-When client A wishes to delete an item on an existing CDO, he sends the following information to client B
862
+      <p>When client A wishes to delete an item on an existing CDO, he sends the following information to client B</p>
864 863
 <example caption="Client A deletes an item on an existing CDO and sends it to client B"><![CDATA[
865 864
 <message
866 865
     to='joe@mitre.org/Desktop'
@@ -929,7 +928,7 @@ back to client A as a receipt that the message has been processed by Server X an
929 928
    </data-sync>
930 929
 </message>
931 930
 ]]></example>
932
-Once this is completed, both clients have a synchronized CDO message with a deleted item.
931
+<p>Once this is completed, both clients have a synchronized CDO message with a deleted item.</p>
933 932
 </section2>
934 933
     <section2 topic="Retire an existing CDO" anchor="cdoretire">
935 934
       <p>
@@ -990,7 +989,7 @@ message back to client A as a receipt that the message has been processed by Ser
990 989
    </data-sync>
991 990
 </message>
992 991
 ]]></example>
993
-Once this is completed, both clients have retired (deleted) the CDO.
992
+<p>Once this is completed, both clients have retired (deleted) the CDO.</p>
994 993
 </section2>
995 994
   </section1>
996 995
   <section1 topic="Errors" anchor="errors">
@@ -1590,12 +1589,12 @@ containing at least one overlapping item. When this occurs, the first packet to
1590 1589
 reported back to the client of the second packet MAY be extended to describe the notional conflict. This additional error information is meant to facilitate 
1591 1590
 collaboration between the clients.
1592 1591
 </p>
1593
-The additional error information provide includes:
1592
+<p>The additional error information provide includes:</p>
1594 1593
 <ul>
1595
-        <li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
1596
-        <li>The timestamp of when the originating data sync packet was executed.</li>
1597
-        <li>The item element of the originating data sync packet with which this error conflicts.</li>
1598
-      </ul>
1594
+  <li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
1595
+  <li>The timestamp of when the originating data sync packet was executed.</li>
1596
+  <li>The item element of the originating data sync packet with which this error conflicts.</li>
1597
+</ul>
1599 1598
       <example caption=""><![CDATA[
1600 1599
 <cdo:item-version-outdated identifier='I' version='V'>
1601 1600
    <cdo:conflict resource-identifier='R' execution-timestamp='T'>

+ 4
- 5
xep-0209.xml View File

@@ -54,11 +54,11 @@
54 54
   </ul>
55 55
 </section1>
56 56
 <section1 topic='Overview' anchor='overview'>
57
-  The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.
57
+  <p>The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.</p>
58 58
   <example caption='A metacontact tag'><![CDATA[
59 59
 <meta jid='romeo@montague.net' tag='d93nov' order='0'>
60 60
 ]]></example>
61
-    In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP). 
61
+    <p>In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP).</p>
62 62
 </section1>
63 63
 <section1 topic='Use Cases' anchor='usecases'>
64 64
   <p>Below are example of setting and retrieving metacontacts for an account. When using metacontacts across multiple accounts, the steps are identical and the 'tag' attributes and used across accounts (that is: when the same tag is used for multiple contacts, all entries with the tag are merged into a single metacontact whether they reside on the same of different accounts).</p>
@@ -114,7 +114,6 @@
114 114
 <!--As metacontacts are especially useful when used across multiple accounts, examples are also provided for actions across two accounts.
115 115
   <section2 topic='Retrieving metacontact data (account 1)' anchor='dualaccount-get1'>
116 116
      <example caption=''><![CDATA[
117
-      
118 117
       ]]></example>
119 118
   </section2>-->
120 119
 </section1>
@@ -122,10 +121,10 @@
122 121
 <section1 topic='Implementation Notes' anchor='impl'>
123 122
   <!--<p>Optional.</p>-->
124 123
   <section2 topic='Creating a metacontact' anchor='creating'>
125
-    Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.
124
+    <p>Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.</p>
126 125
   </section2>
127 126
   <section2 topic='Removing a metacontact' anchor='removing'>
128
-    Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.
127
+    <p>Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.</p>
129 128
   </section2>
130 129
   <section2 topic='Uniqueness of order within a metacontact' anchor='uniqueness'>
131 130
 		<p>Although it is unavoidable that multiple contacts within a metacontact MAY have the same order (due to potentially unavailable information from other accounts), clients SHOULD NOT apply the same order to multiple members of the same metacontact where it is possible to avoid it. If multiple members of a metacontact have the same order, the behaviour is dependent upon the client; it MAY apply rules itself to determine which member to communicate with (based upon presence, recent activity or other methods) it MAY present the user with the option to sort the members such that the orders are again unique, or it MAY employ another appropriate action.</p>

+ 26
- 49
xep-0214.xml View File

@@ -12,7 +12,7 @@
12 12
   <number>0214</number>
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15
-  <jig>Standards JIG</jig>
15
+  <sig>Standards</sig>
16 16
   <approver>Council</approver>
17 17
   <dependencies>
18 18
     <spec>XMPP Core</spec>
@@ -98,16 +98,11 @@
98 98
   </table>
99 99
 </section1>
100 100
 <section1 topic='Use Cases' anchor='usecases'>
101
-    
102 101
     <p>The following use cases describe tasks which are already covered by &xep0060; in a more generic context. These tasks are again being provided here in order to demonstrate the functionality provided by this protocol and convey the structure and syntax of the file listing. As a result of this close relationship, many details of PubSub are omitted here for brevity. Consult &xep0060; and &xep0248; for the full specification of node and user management commands as well as their server responses.</p>
103
-  
104 102
   <section2 topic='File Listing' anchor='list'>
105
-    
106 103
     <section3 topic='Publication' anchor='list-publication'>
107
-      
108 104
       <p>Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:</p>
109
-      
110
-      <example caption='Creating a New File Listing'><code><![CDATA[<iq type='set'
105
+      <example caption='Creating a New File Listing'><![CDATA[<iq type='set'
111 106
     from='juliet@capulet.com/balcony'
112 107
     to='pubsub.shakespeare.lit'
113 108
     id='create3'>
@@ -140,11 +135,9 @@
140 135
     </configure>
141 136
   </pubsub>
142 137
 </iq>
143
-        ]]></code></example>
144
-      
138
+]]></example>
145 139
       <p>Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another PubSub Collection Node under the Root Node:</p>
146
-      
147
-      <example caption='Adding a Subsection to the Listing'><code><![CDATA[<iq type='set'
140
+      <example caption='Adding a Subsection to the Listing'><![CDATA[<iq type='set'
148 141
     from='juliet@capulet.com/balcony'
149 142
     to='pubsub.shakespeare.lit'
150 143
     id='create3'>
@@ -178,14 +171,11 @@
178 171
     </configure>
179 172
   </pubsub>
180 173
 </iq>
181
-        ]]></code></example>
182
-      
174
+]]></example>
183 175
     </section3>
184 176
     <section3 topic='Subscription' anchor='list-subscription'>
185
-      
186 177
       <p>Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:</p>
187
-      
188
-      <example caption='Subscription to entire File Listing'><code><![CDATA[<iq type='set'
178
+      <example caption='Subscription to entire File Listing'><![CDATA[<iq type='set'
189 179
     from='romeo@montague.net/orchard'
190 180
     to='pubsub.shakespeare.lit'
191 181
     id='collsub2'>
@@ -202,14 +192,11 @@
202 192
     </options>
203 193
   </pubsub>
204 194
 </iq>
205
-          ]]></code></example>
206
-      
195
+]]></example>
207 196
     </section3>
208 197
     <section3 topic='Addition' anchor='list-addition'>
209
-      
210 198
       <p>Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new PubSub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:</p>
211
-      
212
-      <example caption='Adding a new File'><code><![CDATA[<iq type='set'
199
+      <example caption='Adding a new File'><![CDATA[<iq type='set'
213 200
     from='juliet@capulet.com/balcony'
214 201
     to='pubsub.shakespeare.lit'
215 202
     id='create4'>
@@ -311,8 +298,7 @@
311 298
     </publish>
312 299
   </pubsub>
313 300
 </iq>
314
-]]></code></example>
315
-      
301
+]]></example>
316 302
       <p>The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.</p>
317 303
       <p>Node IDs MAY take the form of "path/to/file.ext", rather than the randomized string "a6190c5d38e22452041d1c5798eff3f5" provided in the above use case. For example, Juliet's sonnet MAY instead use a Node ID of "juliets_sonnets/sonnet.txt", as long as this ID is unique within the PubSub server. Randomized strings are used in this document to illustrate that Node IDs SHOULD NOT be used for providing information about files.</p> 
318 304
       <p>Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:</p>
@@ -326,8 +312,7 @@
326 312
         <tr><th>Mirrors</th><td>A list of mirrors; their properties are defined below. If no downloads are available, MAY be left empty or removed entirely.</td></tr>
327 313
       </table>
328 314
       <p>Because Romeo is now subscribed, he receives notice of Juliet's addition:</p>
329
-      
330
-      <example caption='Notification of Addition'><code><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
315
+      <example caption='Notification of Addition'><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
331 316
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
332 317
     <collection>
333 318
       <node id='a6190c5d38e22452041d1c5798eff3f5'>
@@ -374,16 +359,14 @@
374 359
     </items>
375 360
   </event>
376 361
 </message>
377
-]]></code></example>
378
-      
362
+]]></example>
379 363
       <p>The above examples give a listing of several possible file transfer protocols in example configurations. Only the sipub mirror type is REQUIRED; the other types are OPTIONAL. Here is a full listing of those protocols and their available settings:</p>
380
-      
381 364
       <table caption="Mirror Types And Their Settings">
382 365
         <tr><th>Protocol</th>
383 366
           <th>Description</th><th>Ref</th>
384 367
           <th>Address</th><th>Port (default)</th>
385 368
           <th>User</th><th>Pass</th></tr>
386
-        <tr><th><link url='#file-requests'>sipub (REQUIRED)</link></th>
369
+        <tr><th>sipub (REQUIRED)</th>
387 370
           <td>OPTIONAL</td><td>N/A</td>
388 371
           <td>N/A</td><td>N/A</td>
389 372
           <td>N/A</td><td>N/A</td></tr>
@@ -419,7 +402,7 @@
419 402
       
420 403
       <p>Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:</p>
421 404
       
422
-      <example caption='Adding a new Revision'><code><![CDATA[<iq type='set'
405
+      <example caption='Adding a new Revision'><![CDATA[<iq type='set'
423 406
     from='juliet@capulet.com/balcony'
424 407
     to='pubsub.shakespeare.lit'
425 408
     id='publish1'>
@@ -458,14 +441,11 @@
458 441
     </publish>
459 442
   </pubsub>
460 443
 </iq>
461
-          ]]></code></example>
462
-      
444
+]]></example>
463 445
     </section3>
464 446
     <section3 topic='Modification/Deletion' anchor='list-deletion'>
465
-      
466 447
       <p>Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:</p>
467
-      
468
-      <example caption='Modifying a Revision'><code><![CDATA[<iq type='set'
448
+      <example caption='Modifying a Revision'><![CDATA[<iq type='set'
469 449
     from='juliet@capulet.com/balcony'
470 450
     to='pubsub.shakespeare.lit'
471 451
     id='publish1'>
@@ -501,11 +481,10 @@
501 481
     </publish>
502 482
   </pubsub>
503 483
 </iq>
504
-          ]]></code></example>
484
+          ]]></example>
505 485
 
506 486
       <p>Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:</p>
507
-      
508
-      <example caption='Modifying Users'><code><![CDATA[<iq type='set'
487
+      <example caption='Modifying Users'><![CDATA[<iq type='set'
509 488
     from='juliet@capulet.com/balcony'
510 489
     to='pubsub.shakespeare.lit'
511 490
     id='ent3'>
@@ -516,11 +495,11 @@
516 495
     </affiliations>
517 496
   </pubsub>
518 497
 </iq>
519
-          ]]></code></example>
498
+]]></example>
520 499
 
521 500
       <p>Romeo uses his owner access to remove the older revision of Juliet's sonnet:</p>
522 501
 
523
-      <example caption='Deleting a Revision'><code><![CDATA[<iq type='set'
502
+      <example caption='Deleting a Revision'><![CDATA[<iq type='set'
524 503
     from='romeo@montague.net/orchard'
525 504
     to='pubsub.shakespeare.lit'
526 505
     id='retract1'>
@@ -530,18 +509,17 @@
530 509
     </retract>
531 510
   </pubsub>
532 511
 </iq>
533
-          ]]></code></example>
512
+]]></example>
534 513
 
535 514
       <p>Other deletion, modification, and user management operations are available as described in &xep0060; and &xep0248;.</p>
536 515
 
537 516
     </section3>
538 517
   </section2>
539
-  
540 518
   <section2 topic='File Requests' anchor='file-requests'>
541 519
 
542 520
     <p>Romeo is interested in seeing what files Juliet has made available. To do this, Romeo sends a request to Juliet for repositories which she is associated with:</p>
543 521
 
544
-    <example caption='Request for File Repository listing'><code><![CDATA[<iq type='get'
522
+    <example caption='Request for File Repository listing'><![CDATA[<iq type='get'
545 523
     from='romeo@montague.net/orchard'
546 524
     to='juliet@capulet.com'
547 525
     id='repolistreq'>
@@ -549,11 +527,11 @@
549 527
     <list/>
550 528
   </fileshare>
551 529
 </iq>
552
-        ]]></code></example>
530
+]]></example>
553 531
 
554 532
     <p>Juliet responds with a list of PubSub nodes where she has published files or which she believes would be interesting to Romeo. If no such locations exist, Juliet SHOULD respond with an empty list.</p>
555 533
 
556
-    <example caption='File Repository listing'><code><![CDATA[<iq type='get'
534
+    <example caption='File Repository listing'><![CDATA[<iq type='get'
557 535
     from='romeo@montague.net/orchard'
558 536
     to='juliet@capulet.com'
559 537
     id='repolist'>
@@ -564,18 +542,17 @@
564 542
     </list>
565 543
   </fileshare>
566 544
 </iq>
567
-        ]]></code></example>    
545
+]]></example>
568 546
 
569 547
     <p>After browsing Juliet's repository, Romeo has chosen to download her sonnet. The most recent revision of this file contains a listing of available mirrors, and Romeo sees that one of them is an SI stream. Romeo sends an SI request to that mirror:</p>
570
-    
571
-    <example caption='Request that a file be sent'><code><![CDATA[<iq type='get'
548
+    <example caption='Request that a file be sent'><![CDATA[<iq type='get'
572 549
     id='sipub-request-0'
573 550
     from='romeo@montague.net/orchard'
574 551
     to='fileserver@capulet.com'>
575 552
   <start xmlns='http://jabber.org/protocol/sipub'
576 553
          id='publish-sonnet2.txt'/>
577 554
 </iq>
578
-        ]]></code></example>
555
+        ]]></example>
579 556
 
580 557
     <p>The rest of the negotiation and file transfer occurs as described in &xep0137;.</p>
581 558
   </section2>

+ 3
- 3
xep-0220.xml View File

@@ -52,20 +52,20 @@
52 52
   </revision>
53 53
   <revision>
54 54
     <version>0.15</version>
55
-    <initials>psa/ph</initials>
56 55
     <date>2013-08-27</date>
56
+    <initials>psa/ph</initials>
57 57
     <remark><p>Addressed Last Call feedback and made editorial improvements.</p></remark>
58 58
   </revision>
59 59
   <revision>
60 60
     <version>0.14</version>
61
-    <initials>ph</initials>
62 61
     <date>2012-08-21</date>
62
+    <initials>ph</initials>
63 63
     <remark><p>Updated the Security Considerations to describe the 'Unsolicited Dialback Attack' and added recommendations to avoid this attack.</p></remark>
64 64
   </revision>
65 65
   <revision>
66 66
     <version>0.13</version>
67
-    <initials>ph/psa</initials>
68 67
     <date>2012-08-08</date>
68
+    <initials>ph/psa</initials>
69 69
     <remark>
70 70
       <ul>
71 71
         <li>Allowed same SRV target in multiplexing business</li>

+ 8
- 9
xep-0224.xml View File

@@ -91,15 +91,14 @@
91 91
   ]]></example>
92 92
 </section1>
93 93
 <section1 topic='Business Rules' anchor='rules'>
94
-  <p>The following rules apply to generating and processing of the attention extension.
95
-    <ol>
96
-      <li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
97
-      <li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
98
-      <li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
99
-      <li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
100
-      <li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
101
-    </ol>
102
-  </p>
94
+  <p>The following rules apply to generating and processing of the attention extension.</p>
95
+  <ol>
96
+    <li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
97
+    <li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
98
+    <li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
99
+    <li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
100
+    <li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
101
+  </ol>
103 102
 </section1>
104 103
 <section1 topic='Determining Support' anchor='disco'>
105 104
   <p>If an entity wishes to receive the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:attention:0":</p>

+ 0
- 1
xep-0226.xml View File

@@ -20,7 +20,6 @@
20 20
   <shortname>profiles</shortname>
21 21
   &infiniti;
22 22
   &stpeter;
23
-  <registry/>
24 23
   <revision>
25 24
     <version>0.3</version>
26 25
     <date>2008-11-05</date>

+ 24
- 30
xep-0244.xml View File

@@ -181,16 +181,14 @@ if (function instanceof IoDataFunction) {
181 181
 ]]></code>
182 182
 	
183 183
 	<section2 topic='Transaction Types' anchor='trans'>
184
-		<table border="1" caption='IO Data Transaction Types allowed for client to service stanzas'>
185
-			<thead>
186
-	    		<tr>
187
-					<th>Transaction Type</th>
188
-					<th>Purpose</th>
189
-					<th>Associated Ad-Hoc Command</th>
190
-					<th>REQUIRED for generic XEP compatibility</th>
191
-					<th>Contained Elements</th>
192
-				</tr>
193
-			</thead>
184
+		<table caption='IO Data Transaction Types allowed for client to service stanzas'>
185
+      <tr>
186
+        <th>Transaction Type</th>
187
+        <th>Purpose</th>
188
+        <th>Associated Ad-Hoc Command</th>
189
+        <th>REQUIRED for generic XEP compatibility</th>
190
+        <th>Contained Elements</th>
191
+      </tr>
194 192
 	 		<tr>
195 193
 				<th>io-schemata-get</th>
196 194
 				<th>To request the schemata of input and output.</th>
@@ -221,16 +219,14 @@ if (function instanceof IoDataFunction) {
221 219
 			</tr>
222 220
 		</table>
223 221
 		
224
-		<table border="1" caption='IO Data Transaction Types allowed for service to client stanzas'>
225
-			<thead>
226
-	    		<tr>
227
-					<th>Transaction Type</th>
228
-					<th>Purpose</th>
229
-					<th>Associated Ad-Hoc Command status value</th>
230
-					<th>REQUIRED for generic XEP compatibility</th>
231
-					<th>Contained Elements</th>
232
-				</tr>
233
-			</thead>
222
+		<table caption='IO Data Transaction Types allowed for service to client stanzas'>
223
+      <tr>
224
+        <th>Transaction Type</th>
225
+        <th>Purpose</th>
226
+        <th>Associated Ad-Hoc Command status value</th>
227
+        <th>REQUIRED for generic XEP compatibility</th>
228
+        <th>Contained Elements</th>
229
+      </tr>
234 230
 			<tr>
235 231
 				<th>io-schemata-result</th>
236 232
 				<th>To return the schemata of input and output.</th>
@@ -281,16 +277,14 @@ if (function instanceof IoDataFunction) {
281 277
 <section1 topic='Implementation Notes' anchor='impl'>
282 278
 	<p>Commands (= remote procedures) executed with Ad-Hoc Commands and IO Data SHOULD NOT keep the requester in an uncertain state. This means the responder SHOULD respond to the requester always as fast as possible. Thereby the requester acquires the sessionid. (As some remote procedures/calculations are cost-intensive and/or time-consuming the requester MUST "save" this sessionid for the case a network problem occurs.)</p>
283 279
 	<p>The Ad-Hoc Command logic applied for the IO Data data container should be associated with the following rules and keywords:</p>
284
-		<table border="1" caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
285
-			<thead>
286
-	    		<tr>
287
-					<th>Ad-Hoc Command</th>
288
-					<th>Keyword</th>
289
-					<th>Associated Transaction Type</th>
290
-					<th>Subsequently allowed commands</th>
291
-					<th>Status description</th>
292
-				</tr>
293
-			</thead>
280
+		<table caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
281
+      <tr>
282
+        <th>Ad-Hoc Command</th>
283
+        <th>Keyword</th>
284
+        <th>Associated Transaction Type</th>
285
+        <th>Subsequently allowed commands</th>
286
+        <th>Status description</th>
287
+      </tr>
294 288
 	 		<tr>
295 289
 				<th>execute</th>
296 290
 				<th>Get Schemata</th>

+ 2
- 2
xep-0245.xml View File

@@ -68,7 +68,7 @@
68 68
   ]]></example>
69 69
   <p>Each recipient's client would then show the message with a special presentation, such as:</p>
70 70
   <example caption="Presentation of /me Command">
71
-<span style='margin-left: 5%; font-style: italic; color: green;'>* Atlas shrugs in disgust</span>
71
+* Atlas shrugs in disgust
72 72
   </example>
73 73
   <p>If the receiving client does not find a match on the string "/me " in the first four characters of the message body, it SHOULD NOT present the text in a special way. For example, the following message bodies do not match:</p>
74 74
   <example caption="Some Non-Commands"><![CDATA[
@@ -110,7 +110,7 @@
110 110
 <section1 topic='Security Considerations' anchor='security'>
111 111
   <p>&xep0045; rooms send XMPP presence stanzas when people leave and join the room, and receiving clients typically show these presence changes as the equivalent of in-room messages, such as the following transformation of a presence stanza of type unavailable:</p>
112 112
   <example caption="Presentation of In-Room Presence Notification">
113
-<span style='margin-left: 5%; font-style: italic; color: green;'>*** Atlas has left the room</span>
113
+*** Atlas has left the room
114 114
   </example>
115 115
   <p>A sender could attempt to spoof such a leave message by sending an XMPP groupchat message stanza whose body text is "/me has left the room". Although the presentation of presence joins and leaves is determined by the receiving client and therefore such a notification cannot be universally spoofed for all receivers, a client SHOULD differentiate between presence notifications and /me commands (e.g., with different colors and different prepended characters, such as several asterisks for presence notifications and one asterisk for /me commands).</p>
116 116
 </section1>

+ 10
- 0
xep-0248.xml View File

@@ -77,19 +77,29 @@
77 77
       <di>
78 78
         <dt>Collection Node</dt>
79 79
         <dd>A type of node that contains other nodes but no published items (<em>c.f.</em> Leaf Node).</dd>
80
+      </di>
80 81
 
82
+      <di>
81 83
         <dt>Leaf Node</dt>
82 84
         <dd>A type of node that contains published items but no other nodes (<em>c.f.</em> Collection Node).</dd>
85
+      </di>
83 86
 
87
+      <di>
84 88
         <dt>Node Graph</dt>
85 89
         <dd>The network of nodes emitting from a given node which contains all its descendants.</dd>
90
+      </di>
86 91
 
92
+      <di>
87 93
         <dt>Root Node</dt>
88 94
         <dd>An anonymous collection node used as the <em>de facto</em> beginning of a service's node graph.</dd>
95
+      </di>
89 96
 
97
+      <di>
90 98
         <dt>Subscription Depth</dt>
91 99
         <dd>How deep the collection node graph will be traversed when determining whether notifications will be sent. May be any integer, 0 or greater, or "all".</dd>
100
+      </di>
92 101
 
102
+      <di>
93 103
         <dt>Subscription Type</dt>
94 104
         <dd>The type of notification, either "nodes", "items", or "all" which the subscriber is interested in.</dd>
95 105
       </di>

+ 17
- 17
xep-0252.xml View File

@@ -101,23 +101,23 @@ Content-Length: 0
101 101
   </section2>
102 102
   <section2 topic='Changes to the Response Syntax' anchor='script-response'>
103 103
     <p>Connection managers MUST make the following changes to convert their responses to Script Syntax:</p>
104
-    <ol>
105
-      <li><p>Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
106
-        <table caption='Character Substitutions'>
107
-          <tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
108
-          <tr><td>"</td><td>U+0022</td><td>\"</td></tr>
109
-          <tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
110
-          <tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
111
-          <tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
112
-          <tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
113
-          <tr><td>\</td><td>U+005C</td><td>\\</td></tr>
114
-        </table>
115
-        <p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p></li>
116
-      <li><p>The following eight characters MUST be prepended to the &lt;body/&gt; element: <code>_BOSH_("</code></p></li>
117
-      <li><p>The following two characters MUST be appended to the &lt;body/&gt; element: <code>")</code></p></li>
118
-      <li><p>If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p></li>
119
-      <li><p>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li>
120
-    </ol>
104
+    <p>1. Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
105
+    <table caption='Character Substitutions'>
106
+      <tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
107
+      <tr><td>"</td><td>U+0022</td><td>\"</td></tr>
108
+      <tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
109
+      <tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
110
+      <tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
111
+      <tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
112
+      <tr><td>\</td><td>U+005C</td><td>\\</td></tr>
113
+    </table>
114
+    <p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p>
115
+    <p>2. The following eight characters MUST be prepended to the &lt;body/&gt; element:</p>
116
+    <code>_BOSH_("</code>
117
+    <p>3. The following two characters MUST be appended to the &lt;body/&gt; element:</p>
118
+    <code>")</code>
119
+    <p>4. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p>
120
+    <p>5. Include extra HTTP headers to prevent caching or storage by any intermediary.</p>
121 121
     <p>Note: All line breaks in the bodies of the HTTP responses in the following two examples are included only to improve readability. In practice there MUST be no line breaks.</p>
122 122
     <example caption="Session creation response in Script Syntax">
123 123
 <![CDATA[HTTP/1.1 200 OK

+ 56
- 57
xep-0255.xml View File

@@ -395,32 +395,31 @@
395 395
 </section1>
396 396
 
397 397
 <section1 topic='Data Format' anchor='format'>
398
-  <p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <i>get</i>.  The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <i>result</i>.  The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by  the 'http://jabber.org/protocol/geoloc' namespace (see <a href="../xep-0080.html">XEP-0080</a>).</p>
398
+  <p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <em>get</em>.  The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <em>result</em>.  The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by  the 'http://jabber.org/protocol/geoloc' namespace (see <link url="xep-0080.html">XEP-0080</link>).</p>
399 399
 
400 400
     <table caption='Location Query Child Elements'>
401
-      <tr class="body">
401
+      <tr>
402 402
          <th>Element Name</th>
403 403
          <th>Datatype</th>
404 404
          <th>Definition</th>
405 405
          <th>Example</th>
406
-
407 406
          <th>Notes</th>
408 407
       </tr>
409
-      <tr class="body">
408
+      <tr>
410 409
          <td>timestamp</td>
411 410
          <td>xs:datetime</td>
412 411
          <td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
413 412
          <td>2004-02-19T21:12Z</td>
414 413
          <td>Optional. If individual location references contain own timing information, this time-stamp shall represent GPS time only, otherwise it shall represent all provided info in the query. If not set, the server may assume current time.</td>
415 414
       </tr>
416
-      <tr class="body">
415
+      <tr>
417 416
          <td>publish</td>
418 417
          <td>xs:boolean</td>
419 418
          <td>A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user.</td>
420 419
          <td>true</td>
421 420
          <td>Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty &lt;iq&gt; stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a &lt;iq&gt; with type set to "result". Default is "false"</td>
422 421
       </tr>
423
-      <tr class="body">
422
+      <tr>
424 423
          <td>lat</td>
425 424
          <td>xs:decimal</td>
426 425
          <td>Latitude in decimal degrees
@@ -428,14 +427,14 @@
428 427
          <td>39.75</td>
429 428
          <td>Required if no location references present, otherwise optional. If present, this shall also be present in the result stanza.  If not present, the location server SHOULD estimate a value based on submitted reference data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on reference data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi references are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.</td>
430 429
       </tr>
431
-      <tr class="body">
430
+      <tr>
432 431
          <td>lon</td>
433 432
          <td>xs:decimal</td>
434 433
          <td>Longitude in decimal degrees East</td>
435 434
          <td>-104.99</td>
436
-         <td>See notes for <i>lat</i></td>
435
+         <td>See notes for <em>lat</em></td>
437 436
       </tr>
438
-      <tr class="body">
437
+      <tr>
439 438
          <td>alt</td>
440 439
          <td>xs:decimal</td>
441 440
          <td>Altitude in meters above or below sea level</td>
@@ -443,48 +442,48 @@
443 442
          <td>Optional. If present, this shall also be present in the result stanza with identical value.</td>
444 443
       </tr>
445 444
 
446
-      <tr class="body">
445
+      <tr>
447 446
          <td>bearing</td>
448 447
          <td>xs:decimal</td>
449 448
          <td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
450 449
          <td> </td>
451
-         <td>See notes for <i>alt</i></td>
450
+         <td>See notes for <em>alt</em></td>
452 451
 
453 452
       </tr>
454
-      <tr class="body">
453
+      <tr>
455 454
          <td>datum</td>
456 455
          <td>xs:string</td>
457 456
          <td>GPS datum (See XEP-0080)</td>
458 457
          <td> </td>
459
-         <td>See notes for <i>alt</i></td>
458
+         <td>See notes for <em>alt</em></td>
460 459
 
461 460
       </tr>
462
-      <tr class="body">
461
+      <tr>
463 462
          <td>accuracy</td>
464 463
          <td>xs:decimal</td>
465 464
          <td>Horizontal GPS accuracy in meters</td>
466 465
          <td>10</td>
467
-         <td>See notes for <i>lat</i></td>
466
+         <td>See notes for <em>lat</em></td>
468 467
 
469 468
       </tr>
470
-      <tr class="body">
469
+      <tr>
471 470
          <td>speed</td>
472 471
          <td>xs:decimal</td>
473 472
          <td>The speed at which the entity is moving, in meters per second</td>
474 473
          <td>52.69</td>
475
-         <td>See notes for <i>alt</i></td>
474
+         <td>See notes for <em>alt</em></td>
476 475
       </tr>
477
-      <tr class="body">
476
+      <tr>
478 477
          <td>references</td>
479 478
          <td>locationquery:reference</td>
480 479
          <td>A list of identifiable location references observed by the entity</td>
481 480
          <td> </td>
482
-         <td>Required if no <i>lat</i> and <i>lon</i> values specified, otherwise optional. See Table 2 for type definition.</td>
481
+         <td>Required if no <em>lat</em> and <em>lon</em> values specified, otherwise optional. See Table 2 for type definition.</td>
483 482
       </tr>
484 483
     </table>
485 484
 
486 485
     <table caption='Reference Child Elements'>
487
-      <tr class="body">
486
+      <tr>
488 487
          <th>Element Name</th>
489 488
          <th>Datatype</th>
490 489
          <th>Definition</th>
@@ -492,28 +491,28 @@
492 491
          <th>Notes</th>
493 492
 
494 493
       </tr>
495
-      <tr class="body">
494
+      <tr>
496 495
          <td>id</td>
497 496
          <td>xs:string</td>
498
-         <td>A world-wide unique reference identifier. This SHALL be composed as follows: <br/><br/>For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID.<br/><br/>For wireless access points and Bluetooth devices: The device MAC address.<br/><br/>For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
497
+         <td>A world-wide unique reference identifier. This SHALL be composed as follows: For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID. For wireless access points and Bluetooth devices: The device MAC address. For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
499 498
          <td>207:02:12643:78596</td>
500 499
          <td>Required</td>
501 500
       </tr>
502
-      <tr class="body">
501
+      <tr>
503 502
          <td>type</td>
504 503
          <td>xs:string</td>
505 504
          <td>Reference type as maintained in the registry specified under <link url='#registrar-reftypes'>Reference Types Registry</link></td>
506 505
          <td>"cell"</td>
507 506
          <td>Required.</td>
508 507
       </tr>
509
-      <tr class="body">
508
+      <tr>
510 509
          <td>signalstrength</td>
511 510
          <td>xs:int</td>
512 511
          <td>Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, Bluetooth devices)</td>
513 512
          <td>-64</td>
514 513
          <td>Optional.</td>
515 514
       </tr>
516
-      <tr class="body">
515
+      <tr>
517 516
          <td>timestamp</td>
518 517
          <td>xs:datetime</td>
519 518
          <td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
@@ -523,22 +522,22 @@
523 522
     </table>
524 523
 
525 524
     <table caption='Location Result Child Elements (Copied from XEP-0080 with notes added)'>
526
-      <tr class="body">
525
+      <tr>
527 526
          <th>Element Name</th>
528 527
          <th>Datatype</th>
529 528
          <th>Definition</th>
530 529
          <th>Example</th>
531 530
          <th>Notes</th>
532 531
       </tr>
533
-      <tr class="body">
532
+      <tr>
534 533
          <td>alt</td>
535 534
          <td>xs:decimal</td>
536 535
          <td>Altitude in meters above or below sea level</td>
537 536
          <td>1609</td>
538
-         <td>Piped directly through from query <i>alt</i> field if set.</td>
537
+         <td>Piped directly through from query <em>alt</em> field if set.</td>
539 538
       </tr>
540 539
 
541
-      <tr class="body">
540
+      <tr>
542 541
          <td>area</td>
543 542
          <td>xs:string</td>
544 543
          <td>A named area such as a campus or neighborhood</td>
@@ -546,15 +545,15 @@
546 545
          <td> </td>
547 546
 
548 547
       </tr>
549
-      <tr class="body">
548
+      <tr>
550 549
          <td>bearing</td>
551 550
          <td>xs:decimal</td>
552 551
          <td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
553 552
          <td> </td>
554
-         <td>Piped directly through from query <i>bearing</i> field if set.</td>
553
+         <td>Piped directly through from query <em>bearing</em> field if set.</td>
555 554
 
556 555
       </tr>
557
-      <tr class="body">
556
+      <tr>
558 557
          <td>building</td>
559 558
          <td>xs:string</td>
560 559
          <td>A specific building on a street or in an area</td>
@@ -562,7 +561,7 @@
562 561
          <td> </td>
563 562
 
564 563
       </tr>
565
-      <tr class="body">
564
+      <tr>
566 565
          <td>country</td>
567 566
          <td>xs:string</td>
568 567
          <td>The nation where the user is located</td>
@@ -570,14 +569,14 @@
570 569
          <td> </td>
571 570
 
572 571
       </tr>
573
-      <tr class="body">
572
+      <tr>
574 573
          <td>datum</td>
575 574
          <td>xs:string</td>
576 575
          <td>GPS datum (See notes for XEP-0080)</td>
577 576
          <td></td>
578
-         <td>Piped directly through from query <i>datum</i> field if set.</td>
577
+         <td>Piped directly through from query <em>datum</em> field if set.</td>
579 578
       </tr>
580
-      <tr class="body">
579
+      <tr>
581 580
          <td>description</td>
582 581
          <td>xs:string</td>
583 582
          <td>A natural-language name for or description of the location</td>
@@ -585,15 +584,15 @@
585 584
          <td>If location is mapped to a place in a place oriented service, this should hold the place description.</td>
586 585
 
587 586
       </tr>
588
-      <tr class="body">
587
+      <tr>
589 588
          <td>accuracy</td>
590 589
          <td>xs:decimal</td>
591 590
          <td>Horizontal GPS accuracy in meters</td>
592 591
          <td>10</td>
593
-         <td>Piped directly through from query <i>accuracy</i> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
592
+         <td>Piped directly through from query <em>accuracy</em> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
594 593
 
595 594
       </tr>
596
-      <tr class="body">
595
+      <tr>
597 596
          <td>floor</td>
598 597
          <td>xs:string</td>
599 598
          <td>A particular floor in a building</td>
@@ -601,16 +600,16 @@
601 600
          <td> </td>
602 601
 
603 602
       </tr>
604
-      <tr class="body">
603
+      <tr>
605 604
          <td>lat</td>
606 605
          <td>xs:decimal</td>
607 606
          <td>Latitude in decimal degrees
608 607
          North</td>
609 608
          <td>39.75</td>
610
-         <td>Piped directly through from query <i>lat</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
609
+         <td>Piped directly through from query <em>lat</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
611 610
 
612 611
       </tr>
613
-      <tr class="body">
612
+      <tr>
614 613
          <td>locality</td>
615 614
          <td>xs:string</td>
616 615
          <td>A locality within the administrative region, such as a town or city</td>
@@ -618,15 +617,15 @@
618 617
          <td> </td>
619 618
 
620 619
       </tr>
621
-      <tr class="body">
620
+      <tr>
622 621
          <td>lon</td>
623 622
          <td>xs:decimal</td>
624 623
          <td>Longitude in decimal degrees East</td>
625 624
          <td>-104.99</td>
626
-         <td>Piped directly through from query <i>lon</i> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
625
+         <td>Piped directly through from query <em>lon</em> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
627 626
 
628 627
       </tr>
629
-      <tr class="body">
628
+      <tr>
630 629
          <td>postalcode</td>
631 630
          <td>xs:string</td>
632 631
          <td>A code used for postal delivery</td>
@@ -634,7 +633,7 @@
634 633
          <td> </td>
635 634
 
636 635
       </tr>
637
-      <tr class="body">
636
+      <tr>
638 637
          <td>region</td>
639 638
          <td>xs:string</td>
640 639
          <td>An administrative region of the nation, such as a state or province</td>
@@ -642,7 +641,7 @@
642 641
          <td> </td>
643 642
 
644 643
       </tr>
645
-      <tr class="body">
644
+      <tr>
646 645
          <td>room</td>
647 646
          <td>xs:string</td>
648 647
          <td>A particular room in a building</td>
@@ -650,15 +649,15 @@
650 649
          <td> </td>
651 650
 
652 651
       </tr>
653
-      <tr class="body">
652
+      <tr>
654 653
          <td>speed</td>
655 654
          <td>The speed at which the entity is moving, in meters per second</td>
656 655
          <td>52.69</td>
657 656
          <td>xs:decimal</td>
658
-         <td>Piped directly through from query <i>speed</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
657
+         <td>Piped directly through from query <em>speed</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
659 658
 
660 659
       </tr>
661
-      <tr class="body">
660
+      <tr>
662 661
          <td>street</td>
663 662
          <td>xs:string</td>
664 663
          <td>A thoroughfare within the locality, or a crossing of two thoroughfares</td>
@@ -666,7 +665,7 @@
666 665
          <td> </td>
667 666
 
668 667
       </tr>
669
-      <tr class="body">
668
+      <tr>
670 669
          <td>text</td>
671 670
          <td>xs:string</td>
672 671
          <td>A catch-all element that captures any other information about the location</td>
@@ -674,15 +673,15 @@
674 673
          <td>Best practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)</td>
675 674
 
676 675
       </tr>
677
-      <tr class="body">
676
+      <tr>
678 677
          <td>timestamp</td>
679 678
          <td>xs:datetime</td>
680 679
          <td>UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of <cite>XEP-0082</cite>)</td>
681 680
          <td>2004-02-19T21:12Z</td>
682 681
 
683
-         <td>Piped directly through from query <i>timestamp</i> field.</td>
682
+         <td>Piped directly through from query <em>timestamp</em> field.</td>
684 683
       </tr>
685
-      <tr class="body">
684
+      <tr>
686 685
          <td>uri</td>
687 686
          <td>A URI or URL pointing to
688 687
          information about the location</td>
@@ -694,7 +693,7 @@
694 693
     </table>
695 694
 
696 695
     <p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
697
-   
696
+
698 697
 </section1>
699 698
 
700 699
 <section1 topic='Recommended Transport' anchor='transport'>
@@ -714,7 +713,7 @@
714 713
   </section2>
715 714
 
716 715
   <section2 topic='Client Implementation Notes' anchor='client_impl'>
717
-    <p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.<br/><br/> For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
716
+    <p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver. For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
718 717
   </section2>
719 718
 </section1>
720 719
 
@@ -729,7 +728,7 @@
729 728
 </section1>
730 729
 
731 730
 <section1 topic='IANA Considerations' anchor='iana'>
732
-  <p>This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span> [<a href="notes_iana">7</a>].</p>
731
+  <p>This document requires no interaction with the &IANA;.</p>
733 732
 
734 733
 </section1>
735 734
 

+ 27
- 28
xep-0258.xml View File

@@ -198,14 +198,16 @@
198 198
         <p>The document details when security label meta-data should or should not be provided, and
199 199
             how this meta-data is to be processed.</p>
200 200
 
201
-        <p>This document does not provide: <ul>
202
-                <li>any mechanism for a client to discover the security policy in force at its home
203
-                    server, or any other server;</li>
204
-                <li>any mechanism for a client to discover the user's clearance, or the clearance of
205
-                    associated with any resource; nor</li>
206
-                <li>any administrative mechanism for a client to configure configure policy,
207
-                    clearance, and labels of any resource.</li>
208
-            </ul> Such mechanisms may be introduced in subsequent documents.</p>
201
+          <p>This document does not provide:</p>
202
+          <ul>
203
+            <li>any mechanism for a client to discover the security policy in force at its home
204
+              server, or any other server;</li>
205
+            <li>any mechanism for a client to discover the user's clearance, or the clearance of
206
+              associated with any resource; nor</li>
207
+            <li>any administrative mechanism for a client to configure configure policy,
208
+              clearance, and labels of any resource.</li>
209
+          </ul>
210
+          <p>Such mechanisms may be introduced in subsequent documents.</p>
209 211
 
210 212
         <p>This document does not discuss how one might securely bind a security label to a stanza.
211 213
             It is expected a subsequent document will tackle this topic.</p>
@@ -320,10 +322,10 @@
320 322
             (based upon the user's authorization) in a particular context (such as in chat room). A
321 323
             catalog may not include the complete set of labels available for the use by the client
322 324
             in the context.</p>
323
-        <blockquote>Note: the single catalog per context approach used here is likely inadequate in
325
+          <p><em>Note:</em> the single catalog per context approach used here is likely inadequate in
324 326
             environments where there are a large number of labels in use. It is expected that a more
325 327
             sophisticated approach will be introduced in a subsequent revision of this
326
-            specification.</blockquote>
328
+            specification.</p>
327 329
         <p>As each service domain may have different support for security labels, servers should
328 330
             advertise and clients should perform appropriate discovery lookups on a per service
329 331
             basis.</p>
@@ -334,17 +336,14 @@
334 336
             attribute represents the item's placement in a hierarchical organization of the items.
335 337
             If one item has a <tt>selector=</tt> attribute, all items should have a
336 338
                 <tt>selector=</tt> attribute. The value of the <tt>selector=</tt> attribute conforms
337
-            to the <tt>selector-value</tt> ABNF production: <blockquote><tt>
338
-                <![CDATA[
339
-selector-value = (<item>"|")*<item>
340
-]]>
341
-            </tt></blockquote>
339
+                to the <tt>selector-value</tt> ABNF production:
342 340
         </p>
341
+        <code><![CDATA[selector-value = (<item>"|")*<item>]]></code>
343 342
         <p>where &ITEM; is a sequence of characters not including "|".</p>
344 343
         <p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
345 344
             subset of items. This information may be used, for instance, in generating label
346 345
             selection menus in graphical user interfaces.</p>
347
-        <blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
346
+        <p><em>Note:</em> use of unnecessarily deep hierarchies should be avoided.</p>
348 347
         <example caption="Label Catalog Feature Discovery request"><![CDATA[
349 348
 <iq type='get'
350 349
     to='example.com'
@@ -648,7 +647,6 @@ selector-value = (<item>"|")*<item>
648 647
     </section1>
649 648
     <section1 topic="XML Schemas" anchor="schema">
650 649
         <section2 topic="Extension Schema" anchor="schema-sl">
651
-            <p>
652 650
                 <code><![CDATA[
653 651
 <?xml version='1.0' encoding='UTF-8'?>
654 652
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0"
@@ -748,12 +746,12 @@ selector-value = (<item>"|")*<item>
748 746
         </xs:complexType>
749 747
     </xs:element>
750 748
 </xs:schema>
751
-    ]]></code> A copy of this schema is available at <link
752
-                    url="http://xmpp.org/schemas/sec-label.xsd">
753
-                    http://xmpp.org/schemas/sec-label.xsd</link>. </p>
749
+]]></code>
750
+<p>A copy of this schema is available at <link
751
+    url="http://xmpp.org/schemas/sec-label.xsd">
752
+    http://xmpp.org/schemas/sec-label.xsd</link>.</p>
754 753
         </section2>
755 754
         <section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog">
756
-            <p>
757 755
                 <code><![CDATA[
758 756
 <?xml version="1.0" encoding="UTF-8"?>
759 757
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0"
@@ -850,12 +848,12 @@ selector-value = (<item>"|")*<item>
850 848
         </xs:complexType>
851 849
     </xs:element>
852 850
 </xs:schema>
853
-    ]]></code> A copy of this schema is available at <link
854
-                    url="http://xmpp.org/schemas/sec-label-catalog.xsd">
855
-                    http://xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
851
+]]></code>
852
+<p>A copy of this schema is available at <link
853
+    url="http://xmpp.org/schemas/sec-label-catalog.xsd">
854
+    http://xmpp.org/schemas/sec-label-catalog.xsd</link>.</p>
856 855
         </section2>
857 856
         <section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess">
858
-            <p>
859 857
                 <code><![CDATA[
860 858
 <?xml version="1.0" encoding="UTF-8"?>
861 859
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0"
@@ -876,9 +874,10 @@ selector-value = (<item>"|")*<item>
876 874
         </xs:annotation>
877 875
     </xs:element>
878 876
 </xs:schema>
879
-    ]]></code> A copy of this schema is available at <link
880
-                    url="http://xmpp.org/schemas/sec-label-ess.xsd">
881
-                    http://xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
877
+]]></code>
878
+<p>A copy of this schema is available at <link
879
+    url="http://xmpp.org/schemas/sec-label-ess.xsd">
880
+    http://xmpp.org/schemas/sec-label-ess.xsd</link>.</p>
882 881
         </section2>
883 882
     </section1>
884 883
 </xep>

+ 1
- 1
xep-0260.xml View File

@@ -127,7 +127,7 @@
127 127
 </section1>
128 128
 
129 129
 <section1 topic='Protocol' anchor='protocol'>
130
-  <para>The basic flow is as follows.</para>
130
+  <p>The basic flow is as follows.</p>
131 131
   <code><![CDATA[
132 132
 Initiator                        Responder 
133 133
   |                                  |

+ 82
- 68
xep-0272.xml View File

@@ -52,79 +52,89 @@
52 52
 </header>
53 53
 
54 54
 <section1 topic='Introduction' anchor='intro'>
55
-&xep0166; is used to negotiate peer to peer media sessions.
56
-Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions between a group of people.
57
-Muji conferences are held in &xep0045; rooms.
55
+  <p>
56
+    &xep0166; is used to negotiate peer to peer media sessions.
57
+    Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions
58
+    between a group of people.
59
+    Muji conferences are held in &xep0045; rooms.
60
+  </p>
58 61
 </section1>
59 62
 
60 63
 <section1 topic="How it Works" anchor="howitworks">
61 64
 
62
-A Muji conference has a number of contents, each of which has unique name.
63
-content type, and an encoding. Each participant may provide a stream for each
64
-content, and communicates which contents they are willing to provide streams
65
-for, along with encoding information, in their MUC presence. This serves two
66
-purposes. Firstly, so that each participant knows which contents every other
67
-participant provides. Secondly, so that there is a global payload type (PT)
68
-mapping for the various contents, so that clients only need to encode and
69
-payload each content that they provide once.
65
+  <p>
66
+    A Muji conference has a number of contents, each of which has unique name,
67
+    content type, and an encoding.
68
+    Each participant may provide a stream for each content, and communicates
69
+    which contents they are willing to provide streams for, along with encoding
70
+    information, in their MUC presence.
71
+    This serves two purposes. Firstly, so that each participant knows which
72
+    contents every other participant provides.
73
+    Secondly, so that there is a global payload type (PT) mapping for the
74
+    various contents, so that clients only need to encode and payload each
75
+    content that they provide once.
76
+  </p>
77
+
78
+  <p>
79
+    Participants are not required to participate all the contents that are
80
+    available.
81
+    For example, a Muji client might choose to only request audio streams.
82
+  </p>
70 83
 
71
-Participants are not required to participate all the contents that are
72
-available. For example, a Muji client might choose to only request audio
73
-streams.
74 84
 </section1>
75 85
 
76 86
 <section1 topic='Joining a Conference' anchor='joining'>
77 87
   <p>
78
-  Joining a conference is done in two stages. The first step is to
79
-  declare that preparations are being done to either join or start a muji
80
-  session inside the MUC. This is indicated by the client sending a presence
81
-  stanza to the MUC with a preparing element in muji section.
88
+    Joining a conference is done in two stages. The first step is to
89
+    declare that preparations are being done to either join or start a muji
90
+    session inside the MUC. This is indicated by the client sending a presence
91
+    stanza to the MUC with a preparing element in muji section.
92
+  </p>
82 93
 
83 94
   <code><![CDATA[
84
-    <presence from='wiccarocks@shakespeare.lit/laptop'
85
-      to='darkcave@chat.shakespeare.lit/oldhag'>
86
-      <c xmlns="http://jabber.org/protocol/caps"
87
-        node="http://telepathy.freedesktop.org/wiki/Muji"
88
-        ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
89
-        hash="sha-1" />
90
-      <muji xmlns='http://telepathy.freedesktop.org/muji'>
91
-        <preparing />
92
-      </muji>
93
-    </presence>
94
-  ]]></code>
95
-
96
-  The client MUST then wait until the MUC rebroadcasts its presence message,
97
-  after which it MUST wait for all other participants that had a preparing
98
-  element in their presence to finish preparation. Afterwards it should finish
99
-  it's own preparation by updating its presence with the contents it wants to
100
-  take part in.
95
+<presence from='wiccarocks@shakespeare.lit/laptop'
96
+  to='darkcave@chat.shakespeare.lit/oldhag'>
97
+  <c xmlns="http://jabber.org/protocol/caps"
98
+    node="http://telepathy.freedesktop.org/wiki/Muji"
99
+    ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
100
+    hash="sha-1" />
101
+  <muji xmlns='http://telepathy.freedesktop.org/muji'>
102
+    <preparing />
103
+  </muji>
104
+</presence>
105
+]]></code>
101 106
 
102
-  <code><![CDATA[
103
-    <presence from='wiccarocks@shakespeare.lit/laptop'
104
-      to='darkcave@chat.shakespeare.lit/oldhag'>
105
-      <c xmlns="http://jabber.org/protocol/caps"
106
-        node="http://telepathy.freedesktop.org/wiki/Muji"
107
-        ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
108
-        hash="sha-1" />
109
-      <muji xmlns='http://telepathy.freedesktop.org/muji'>
110
-        <content name='video'>
111
-          <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
112
-            <payload-type id='97' name='theora' clockrate='90000'/>
113
-          </description>
114
-        </content>
115
-        <content creator='initiator' name='voice'>
116
-          <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
117
-            <payload-type id='97' name='speex' clockrate='8000'/>
118
-            <payload-type id='18' name='G729'/>
119
-         </description>
120
-       </content>
121
-       </muji>
122
-    </presence>
123
-  ]]></code>
107
+  <p>
108
+    The client MUST then wait until the MUC rebroadcasts its presence message,
109
+    after which it MUST wait for all other participants that had a preparing
110
+    element in their presence to finish preparation. Afterwards it should finish
111
+    it's own preparation by updating its presence with the contents it wants to
112
+    take part in.
124 113
   </p>
114
+  <code><![CDATA[
115
+<presence from='wiccarocks@shakespeare.lit/laptop'
116
+  to='darkcave@chat.shakespeare.lit/oldhag'>
117
+  <c xmlns="http://jabber.org/protocol/caps"
118
+    node="http://telepathy.freedesktop.org/wiki/Muji"
119
+    ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
120
+    hash="sha-1" />
121
+  <muji xmlns='http://telepathy.freedesktop.org/muji'>
122
+    <content name='video'>
123
+      <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
124
+        <payload-type id='97' name='theora' clockrate='90000'/>
125
+      </description>
126
+    </content>
127
+    <content creator='initiator' name='voice'>
128
+      <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
129
+        <payload-type id='97' name='speex' clockrate='8000'/>
130
+        <payload-type id='18' name='G729'/>
131
+     </description>
132
+   </content>
133
+   </muji>
134
+</presence>
135
+]]></code>
125 136
 
126 137
   <p>
127
-
128 138
   When a client adds a payload ID to a content description, it MUST have the
129 139
   same codec name and receiving parameters as the corresponding entries in
130 140
   other participants' payload maps for that content. For instance, if Alice
@@ -171,9 +181,10 @@ streams.
171 181
 
172 182
 <section1 topic='Adding a Content Type' anchor='addcontent'>
173 183
   <p>
174
-  Adding a stream follows a process similar to the joining a conference. As a
175
-  first step an updated presence stanza MUST be send which contains a preparing
176
-  element as part of the Muji section.
184
+    Adding a stream follows a process similar to the joining a conference. As a
185
+    first step an updated presence stanza MUST be send which contains a
186
+    preparing element as part of the Muji section.
187
+  </p>
177 188
 
178 189
   <code><![CDATA[
179 190
     <presence from='wiccarocks@shakespeare.lit/laptop'
@@ -194,13 +205,17 @@ streams.
194 205
     </presence>
195 206
   ]]></code>
196 207
 
197
-  The client MUST then wait until the MUC rebroadcasts its presence message,
198
-  after which it MUST wait for all other participants that had a preparing
199
-  element in their presence to finish their changes.
208
+  <p>
209
+    The client MUST then wait until the MUC rebroadcasts its presence message,
210
+    after which it MUST wait for all other participants that had a preparing
211
+    element in their presence to finish their changes.
212
+  </p>
200 213
 
201
-  Afterwards the client should add the new content to the muji section of its
202
-  presence and add the content to all the Jingle sessions it had with
203
-  participants it shared the content with.
214
+  <p>
215
+    Afterwards the client should add the new content to the muji section of its
216
+    presence and add the content to all the Jingle sessions it had with
217
+    participants it shared the content with.
218
+  </p>
204 219
 
205 220
   <code><![CDATA[
206 221
     <presence from='wiccarocks@shakespeare.lit/laptop'
@@ -224,7 +239,6 @@ streams.
224 239
        </muji>
225 240
     </presence>
226 241
   ]]></code>
227
-  </p>
228 242
 </section1>
229 243
 
230 244
 <section1 topic='Removing a Content Type' anchor='removecontent'>

+ 18
- 0
xep-0273.xml View File

@@ -186,10 +186,16 @@
186 186
         <di>
187 187
           <dt>urn:xmpp:sift:stanzas:iq</dt>
188 188
           <dd>The server enables the client to sift all &IQ; stanzas or ones that match the specified criteria.</dd>
189
+        </di>
190
+        <di>
189 191
           <dt>urn:xmpp:sift:stanzas:message</dt>
190 192
           <dd>The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.</dd>
193
+        </di>
194
+        <di>
191 195
           <dt>urn:xmpp:sift:stanzas:presence</dt>
192 196
           <dd>The server enables the client to sift all &PRESENCE; notifications (i.e., presence stanzas with no 'type' or with a type of "unavailable") or ones that match the specified criteria.</dd>
197
+        </di>
198
+        <di>
193 199
           <dt>urn:xmpp:sift:stanzas:sub</dt>
194 200
           <dd>The server enables the client to sift all subscription-related &PRESENCE; stanzas (i.e., presence stanzas with a type of "subscribe", "subscribed", "unsubscribe", or "unsubscribed") or ones that match the specified criteria.</dd>
195 201
         </di>
@@ -201,12 +207,20 @@
201 207
         <di>
202 208
           <dt>urn:xmpp:sift:senders:all</dt>
203 209
           <dd>The server shall sift this kind of stanza no matter who the sender is. This is the <strong>default</strong>.</dd>
210
+        </di>
211
+        <di>
204 212
           <dt>urn:xmpp:sift:senders:local</dt>
205 213
           <dd>The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).</dd>
214
+        </di>
215
+        <di>
206 216
           <dt>urn:xmpp:sift:senders:others</dt>
207 217
           <dd>The server shall sift this kind of stanza only from other entities (not from the user itself).</dd>
218
+        </di>
219
+        <di>
208 220
           <dt>urn:xmpp:sift:senders:remote</dt>
209 221
           <dd>The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).</dd>
222
+        </di>
223
+        <di>
210 224
           <dt>urn:xmpp:sift:senders:self</dt>
211 225
           <dd>The server shall sift this kind of stanza only from the user itself (not from other entities).</dd>
212 226
         </di>
@@ -219,8 +233,12 @@
219 233
         <di>
220 234
           <dt>urn:xmpp:sift:recipients:all</dt>
221 235
           <dd>The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the <strong>default</strong>.</dd>
236
+        </di>
237
+        <di>
222 238
           <dt>urn:xmpp:sift:recipients:bare</dt>
223 239
           <dd>The server shall sift this kind of stanza only if the recipient is the bare JID &LOCALBARE; of the user.</dd>
240
+        </di>
241
+        <di>
224 242
           <dt>urn:xmpp:sift:recipients:full</dt>
225 243
           <dd>The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.</dd>
226 244
         </di>

+ 12
- 10
xep-0276.xml View File

@@ -173,15 +173,18 @@
173 173
   <p>To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the &lt;decloak/&gt; element. The following values for the 'reason' attribute are defined:</p>
174 174
 
175 175
   <dl>
176
-    <dt>media</dt>
177
-    <dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
178
-
179
-    <dt>text</dt>
180
-
181
-    <dd>Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.</dd>
182
-
183
-    <dt>file</dt>
184
-    <dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
176
+    <di>
177
+      <dt>media</dt>
178
+      <dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
179
+    </di>
180
+    <di>
181
+      <dt>text</dt>
182
+      <dd>Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.</dd>
183
+    </di>
184
+    <di>
185
+      <dt>file</dt>
186
+      <dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
187
+    </di>
185 188
   </dl>
186 189
 
187 190
   <p>Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a session presence request.</p>
@@ -191,7 +194,6 @@
191 194
 <section1 topic='Business Rules' anchor='bizrules'>
192 195
 
193 196
   <p>To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:</p>
194
-  
195 197
   <ol>
196 198
     <li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li>
197 199
     <li><p>Establishment of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to a delay in call setup). As a result, it may be advantageous to have a way to configure unconditional sharing of session presence in certain deployments, at least within the same trust domain.</p></li>

+ 18
- 24
xep-0278.xml View File

@@ -118,8 +118,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring
118 118
     <stun policy='public' address='200.111.111.111' port='3857' protocol='udp'/>
119 119
  </services>
120 120
  </iq> ]]></example>
121
-<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
122
-    </section2>        
121
+ <p><em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em></p>
122
+    </section2>
123 123
 <section2 topic="Jingle Client Searches for Services on a Retrieved Tracker Service" anchor="clientcheckownserver">
124 124
       <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p>
125 125
        <example caption="Service List Request"><![CDATA[
@@ -137,8 +137,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring
137 137
     type='result'>
138 138
  <services xmlns='http://jabber.org/protocol/jinglenodes'/>
139 139
  </iq> ]]></example>
140
-<em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em>
141
-    </section2>        
140
+ <p><em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em></p>
141
+    </section2>
142 142
 <section2 topic="Jingle Client Searches for Services on online Roster Entries" anchor="clientcheckownserver">
143 143
       <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p>
144 144
        <example caption="Service List Request"><![CDATA[
@@ -157,10 +157,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
157 157
  <services xmlns='http://jabber.org/protocol/jinglenodes'>
158 158
     <relay policy='roster' address='juliet@capulet.lit/balcony' protocol='udp'/>
159 159
  </services>
160
- </iq> ]]></example>
160
+ </iq>]]></example>
161 161
 <p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p>
162
-<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
163
-    </section2>        
162
+<p><em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em></p>
163
+    </section2>
164 164
     <section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay">
165 165
       <p>A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
166 166
       <p>
@@ -188,7 +188,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
188 188
  maxkbps='120'
189 189
  expire='60'/>
190 190
  </iq> ]]></example>
191
-<em><p>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</p></em>
191
+<p><em>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</em></p>
192 192
     </section2>
193 193
   </section1>
194 194
     <section1 topic="Services Definitions" anchor="servicesdefinition">
@@ -234,30 +234,30 @@ All signalling, request, response and publishing is done via XMPP, not requiring
234 234
         <td>id</td>
235 235
         <td>A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production <note>See &lt;<link url='http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken'>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken</link>&gt;</note> so that XML character escaping is not needed for characters such as '&amp;'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness.</td>
236 236
         <td>REQUIRED on response, NOT RECOMMENDED on requests</td>
237
-      </tr>      
237
+      </tr>
238 238
       <tr>
239 239
         <td>host</td>
240
-        <td>The IP address or Host address of the Relay Channel.</td> 
240
+        <td>The IP address or Host address of the Relay Channel.</td>
241 241
         <td>REQUIRED on response</td>
242 242
       </tr>
243 243
       <tr>
244 244
         <td>localport</td>
245
-        <td>The port number to be used by the channel requester.</td> 
245
+        <td>The port number to be used by the channel requester.</td>
246 246
         <td>REQUIRED on response</td>
247 247
       </tr>
248 248
       <tr>
249 249
         <td>remoteport</td>
250
-        <td>The port number to be offered to the remote party.</td> 
250
+        <td>The port number to be offered to the remote party.</td>
251 251
         <td>REQUIRED on response</td>
252 252
       </tr>
253 253
       <tr>
254 254
         <td>protocol</td>
255
-        <td>The protocol supported by the retrieved channel.</td> 
255
+        <td>The protocol supported by the retrieved channel.</td>
256 256
         <td>REQUIRED on response</td>
257 257
       </tr>
258 258
       <tr>
259 259
         <td>maxkbps</td>
260
-        <td>The maximum bandwidth supported by the channel.</td> 
260
+        <td>The maximum bandwidth supported by the channel.</td>
261 261
         <td>OPTIONAL on response, NOT RECOMMENDED on requests.</td>
262 262
       </tr>
263 263
       <tr>
@@ -277,10 +277,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
277 277
   <section3 topic='Remoteport Attribute' anchor='def-remoteport'>
278 278
     <p>The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.</p>
279 279
     <p>For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)</p>
280
-  </section3>  
280
+  </section3>
281 281
   <section3 topic='Protocol Attribute' anchor='def-protocol'>
282 282
     <p>The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the <link url='#schema'>XML Schema</link></p>
283
-  </section3>  
283
+  </section3>
284 284
     <section3 topic='Maxkbps Attribute' anchor='def-maxkbps'>
285 285
     <p>The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.</p>
286 286
   </section3>
@@ -375,15 +375,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
375 375
           <p>Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.</p>
376 376
     <p>It is heavily recommended that the Super Node implements throttle:</p>
377 377
     <ul>
378
-      <p>
379 378
         <li>Based on JID, allowing the control of how many concurrent channels an specific JID can have.</li>
380
-      </p>
381
-      <p>
382 379
         <li>Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.</li>
383
-      </p>
384
-      <p>
385 380
         <li>Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.</li>
386
-      </p>
381
+    </ul>
387 382
       <example caption="Channel Returned by a Node with bandwidth throttle (stub)"><![CDATA[
388 383
 <channel component='1'
389 384
  id='el0747fg11'
@@ -392,8 +387,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
392 387
  remoteport='35802'
393 388
  protocol='udp'
394 389
  maxkbps='120'/>
395
-  ]]></example>
396
-    </ul>
390
+]]></example>
397 391
   </section1>
398 392
   <section1 topic='XML Schema' anchor='schema'>
399 393
   <code><![CDATA[

+ 8
- 9
xep-0280.xml View File

@@ -248,15 +248,14 @@
248 248
 
249 249
 <section1 topic='Messages Eligible for Carbons Delivery' anchor='which-messages'>
250 250
     <p>The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons. Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers. The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:</p>
251
-    <p>Possible delivery rules:
252
-        <ul>
253
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
254
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
255
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
256
-	    <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
257
-            <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
258
-        </ul>
259
-    </p>
251
+    <p>Possible delivery rules:</p>
252
+    <ul>
253
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
254
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
255
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
256
+      <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
257
+      <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
258
+    </ul>
260 259
     <p>As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.</p>
261 260
     <p>Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.</p>
262 261
     <p>Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.</p>

+ 2
- 2
xep-0281.xml View File

@@ -51,7 +51,7 @@
51 51
 
52 52
 <section1 topic='Introduction' anchor='intro'>
53 53
 
54
-  <p class='box'><em>Note: This document has been retracted by the author in favor of &xep0289;.</em></p>
54
+  <p><em>Note: This document has been retracted by the author in favor of &xep0289;.</em></p>
55 55
 
56 56
   <section2 topic='Motivation' anchor='motivation'>
57 57
     <p>&xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, <cite>XEP-0045</cite> assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.</p>
@@ -459,7 +459,7 @@
459 459
 </section1>
460 460
 
461 461
 <section1 topic='Determining Support' anchor='support'>
462
-    <p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to service discovery information requests.</p>
462
+  <p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to service discovery information requests.</p>
463 463
 </section1>
464 464
 
465 465
 <section1 topic='Security Considerations' anchor='security'>

+ 15
- 13
xep-0283.xml View File

@@ -110,18 +110,22 @@
110 110
 
111 111
 <section1 topic='The Move'>
112 112
   <p>In this scenario user@example.com moves to user2@example2.com. 
113
-  Both the user@example.com and user2@example2.com accounts have been
114
-  created and still exist. The roster for user@example2.com is empty
115
-  and the user wants to populate it with their entries from 
116
-  user@example.com.</p>
113
+    Both the user@example.com and user2@example2.com accounts have been
114
+    created and still exist. The roster for user@example2.com is empty
115
+    and the user wants to populate it with their entries from 
116
+    user@example.com.</p>
117 117
 
118 118
   <dl>
119
-  <dt><strong>original JID</strong></dt>
120
-  <dd>user@example.com</dd>
121
-  <dt><strong>new JID</strong></dt>
122
-  <dd>user2@example2.com</dd>
119
+    <di>
120
+      <dt>original JID</dt>
121
+      <dd>user@example.com</dd>
122
+    </di>
123
+    <di>
124
+      <dt>new JID</dt>
125
+      <dd>user2@example2.com</dd>
126
+    </di>
123 127
   </dl>
124
-  
128
+
125 129
   <section2 topic='Unsubscribing the original JID from outbound subscriptions'
126 130
             anchor='unsubscribe'>
127 131
     <p>Because the original JID is no longer going to be used, the user SHOULD 
@@ -140,14 +144,12 @@
140 144
     JID to the user. See the Security Considerations section for 
141 145
     details.</p>
142 146
 
143
-    <example caption='Client unsubscribes outbound subscriptions from original JID'>
144
-<![CDATA[
147
+    <example caption='Client unsubscribes outbound subscriptions from original JID'><![CDATA[
145 148
 <presence from='user@example.com' to='contact@example.com' type='unsubscribe'>
146 149
     <status>I've changed JIDs from user@example.com to user2@example2.com</status>
147 150
     <moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
148 151
 </presence>
149
-]]>
150
-    </example>
152
+]]></example>
151 153
 
152 154
   </section2>
153 155
 

+ 1
- 0
xep-0284.xml View File

@@ -12,6 +12,7 @@
12 12
   <number>0284</number>
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15
+  <sig>Standards</sig>
15 16
   <approver>Council</approver>
16 17
   <dependencies>
17 18
     <spec>XMPP Core</spec>

+ 14
- 16
xep-0287.xml View File

@@ -42,15 +42,14 @@
42 42
   </revision>
43 43
 </header>
44 44
 <section1 topic='Introduction' anchor='intro'>
45
-  <p>There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:
46
-    <ul>
47
-      <li>&xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.</li>
48
-      <li>&xep0158; interacts badly with automated software such as gateways.</li>
49
-      <li>&xep0268; implies trusted network of servers.</li>
50
-      <li>&xep0275; concentrates on ranking only.</li>
51
-    </ul>
52
-    Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from <em>false positives</em> - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.
53
-  </p>
45
+  <p>There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:</p>
46
+  <ul>
47
+    <li>&xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.</li>
48
+    <li>&xep0158; interacts badly with automated software such as gateways.</li>
49
+    <li>&xep0268; implies trusted network of servers.</li>
50
+    <li>&xep0275; concentrates on ranking only.</li>
51
+  </ul>
52
+  <p>Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from <em>false positives</em> - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.</p>
54 53
 </section1>
55 54
 <section1 topic='Requirements' anchor='reqs'>
56 55
   <p>An implementation compliant with this document MUST support spim markers as described in <link url='#spim-marker'>Spim Marker</link> use case. Support for spim reports, as described in <link url='#spim-report'>Spim Report</link> use case, is RECOMMENDED.</p>
@@ -142,13 +141,12 @@
142 141
 </section1>
143 142
 <section1 topic='Business Rules' anchor='rules'>
144 143
   <p>A filtering entity SHOULD only add &lt;mark/&gt; or &lt;report/&gt; elements and a receiving entity SHOULD only process those elements if the corresponding stanza envolves an interaction with a human user: subscription requests, messages, conference invites, voice calls, etc. For example, it doesn't make a lot of sense to mark &xep0232; stanzas.</p>
145
-  <p>To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add &lt;mark/&gt; or &lt;report/&gt; elements to a stanza and a receiving entity SHOULD ignore &lt;mark/&gt; and &lt;report/&gt; elements of a stanza if:
146
-    <ul>
147
-      <li>The receiving entity has the sender's subscription information of the type "both", "from" or "to".</li>
148
-      <li>The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.</li>
149
-      <li>The receiving entity has sent direct presence to the sender.</li>
150
-    </ul>
151
-  </p>
144
+  <p>To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add &lt;mark/&gt; or &lt;report/&gt; elements to a stanza and a receiving entity SHOULD ignore &lt;mark/&gt; and &lt;report/&gt; elements of a stanza if:</p>
145
+  <ul>
146
+    <li>The receiving entity has the sender's subscription information of the type "both", "from" or "to".</li>
147
+    <li>The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.</li>
148
+    <li>The receiving entity has sent direct presence to the sender.</li>
149
+  </ul>
152 150
 </section1>
153 151
 <section1 topic='Determining Support' anchor='support'>
154 152
   <p>If an entity supports the spim markers, it MUST report that by including a service discovery feature of "urn:xmpp:spim-marker:0" in response to a &xep0030; information request. If an entity supports the spim reports, it MUST report that by including a service discovery feature of "urn:xmpp:spim-report:0" in response to a &xep0030; information request:</p>

+ 0
- 4
xep-0289.xml View File

@@ -81,14 +81,12 @@
81 81
     <li>alice@wonderland.lit - User on wonderland.lit</li>
82 82
     <li>hatter@wonderland.lit - User on wonderland.lit</li>
83 83
     <li>rabbithole@rooms.wonderland.lit - MUC room / FMUC node.</li>
84
-    <br/>
85 84
     <li>denmark.lit - service, likely connected to wonderland.lit over constrained link</li>
86 85
     <li>talk.denmark.lit - MUC service on denmark.lit.</li>
87 86
     <li>hamlet@denmark.lit - User on denmark.lit</li>
88 87
     <li>ophelia@denmark.lit - User on denmark.lit</li>
89 88
     <li>elsinore@talk.denmark.lit - MUC room / FMUC node.</li>
90 89
   </ul>
91
-  <p></p>
92 90
 </section1>
93 91
 
94 92
 <section1 topic='Use Cases' anchor='usecases'>
@@ -371,8 +369,6 @@
371 369
 
372 370
 
373 371
 <section1 topic='Business Rules' anchor='rules'>
374
-  <ul>
375
-  </ul>
376 372
 </section1>
377 373
 <!--<section1 topic='Implementation Notes' anchor='impl'>
378 374
   <p>OPTIONAL.</p>

+ 3
- 5
xep-0292.xml View File

@@ -16,8 +16,8 @@
16 16
   <approver>Council</approver>
17 17
   <dependencies>
18 18
     <spec>XMPP Core</spec>
19
-    <spec><cite>RFC 6350</cite></spec>
20
-    <spec><cite>RFC 6351</cite></spec>
19
+    <spec>RFC 6350</spec>
20
+    <spec>RFC 6351</spec>
21 21
   </dependencies>
22 22
   <supersedes>
23 23
     <spec>XEP-0054</spec>
@@ -289,19 +289,17 @@
289 289
     </section3>
290 290
 
291 291
   </section2>
292
-  
293 292
   <section2 topic='Event Notifications' anchor='self-pubsub'>
294 293
     <p>&xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified.</p>
295 294
     <section3 topic='Location' anchor='self-pubsub-location'>
296 295
       <p>The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4".</p>
297 296
     </section3>
298 297
     <section3 topic='Subscribing to vCard Notifications' anchor='self-pubsub-subscribe'>
299
-      <p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
298
+      <p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:</p>
300 299
       <ol>
301 300
         <li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.</li>
302 301
         <li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service might send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
303 302
       </ol>
304
-    </p>
305 303
     </section3>
306 304
     <section3 topic='Receiving a vCard Notification'>
307 305
       <p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backward-compatibility with XMPP clients that are not pubsub-capable. This is in accordance with XEP-0060, second 6.1.7.</p>

+ 8
- 5
xep-0293.xml View File

@@ -21,16 +21,19 @@
21 21
     <spec>XEP-0167</spec>
22 22
     <spec>RFC 4585</spec>
23 23
   </dependencies>
24
+  <supersedes/>
25
+  <supersededby/>
26
+  <shortname>NOT_YET_ASSIGNED</shortname>
24 27
   <schemaloc>
25 28
     <url>http://xmpp.org/schemas/jingle-apps-rtp-rtcp-fb.xsd</url>
26 29
   </schemaloc>
30
+  <discuss>jingle</discuss>
27 31
   <author>
28 32
     <firstname>Olivier</firstname>
29 33
     <surname>Crête</surname>
30 34
     <email>olivier.crete@collabora.co.uk</email>
31 35
     <jid>olivier.crete@collabora.co.uk</jid>
32 36
   </author>
33
-  <discuss>jingle</discuss>
34 37
   <revision>
35 38
     <version>1.0</version>
36 39
     <date>2015-08-11</date>
@@ -110,10 +113,10 @@
110 113
     <td>The subtype (depends on the type)</td>
111 114
     <td>OPTIONAL (possibly REQUIRED depending on the type)</td>
112 115
     <td>
113
-      ack: rpsi, app<br/>
114
-      nack: sli, pli, rpsi, app, rai<br/>
115
-      ccm: fir, tmmbr, tstr, vbcm<br/>
116
-      app: depends on the application<br/>
116
+      ack: rpsi, app;
117
+      nack: sli, pli, rpsi, app, rai;
118
+      ccm: fir, tmmbr, tstr, vbcm;
119
+      app: depends on the application;
117 120
     </td>
118 121
   </tr>
119 122
 </table>

+ 4
- 1
xep-0294.xml View File

@@ -20,16 +20,19 @@
20 20
     <spec>XEP-0167</spec>
21 21
     <spec>RFC 5285</spec>
22 22
   </dependencies>
23
+  <supersedes/>
24
+  <supersededby/>
25
+  <shortname>NOT_YET_ASSIGNED</shortname>
23 26
   <schemaloc>
24 27
     <url>http://xmpp.org/schemas/jingle-apps-rtp-rtp-hdrext.xsd</url>
25 28
   </schemaloc>
29
+  <discuss>jingle</discuss>
26 30
   <author>
27 31
     <firstname>Olivier</firstname>
28 32
     <surname>Crête</surname>
29 33
     <email>olivier.crete@collabora.co.uk</email>
30 34
     <jid>olivier.crete@collabora.co.uk</jid>
31 35
   </author>
32
-  <discuss>jingle</discuss>
33 36
   <revision>
34 37
     <version>1.0</version>
35 38
     <date>2015-08-11</date>

+ 2
- 2
xep-0295.xml View File

@@ -20,7 +20,7 @@
20 20
     <spec>XMPP Core</spec>
21 21
   </dependencies>
22 22
   <supersedes/>
23
-  <supersededby>XEP-0335</supersededby>
23
+  <supersededby><spec>XEP-0335</spec></supersededby>
24 24
   <shortname>N/A</shortname>
25 25
   &ksmith;
26 26
   &mwild;
@@ -165,7 +165,7 @@
165 165
   <p>Beautiful, elegant <em>and</em> efficient at the same time.</p>
166 166
 </section1>
167 167
 <section1 topic='Internationalization Considerations' anchor='i18n'>
168
-  <p>It is hoped that this representation introduces no new internationalization considerations, although it is acknowledged that if there are cultures where the symbols <code>{}:</code> are considered to be more offensive than <code>&lt;>=</code> the legacy XML encoding may be preferred.</p>
168
+  <p>It is hoped that this representation introduces no new internationalization considerations, although it is acknowledged that if there are cultures where the symbols <tt>{}:</tt> are considered to be more offensive than <tt>&lt;>=</tt> the legacy XML encoding may be preferred.</p>
169 169
 </section1>
170 170
 <section1 topic='Security Considerations' anchor='security'>
171 171
   <p>Implementors should be aware that the JSON encoding involves 8 additional bytes for each stanza, and this introduces a considerable risk of buffer over-flow attacks. While new codebases will hopefully be designed with this in mind, existing codebases will need to be entirely upgraded, with every buffer increased in size by at least 8 bytes to address this potentially serious potential vulnerability.</p>

+ 1
- 1
xep-0296.xml View File

@@ -74,7 +74,7 @@
74 74
       <li>any &PRESENCE; update from any resource for the conversee's bare JID, including &lt;presence type='unavailable'/&gt;. The client SHOULD revert to the initial state,  sending any following correspondence to the conversee's bare JID.</li>
75 75
     </ul>
76 76
   </section2>
77
-  <section2 topic='Interactions with Chat States' id='interact-csn'>
77
+  <section2 topic='Interactions with Chat States' anchor='interact-csn'>
78 78
     <p>If a client supports &xep0085;, then the following additional considerations apply:</p>
79 79
     <ul>
80 80
       <li>If a client receives a &MESSAGE; with a &lt;gone xmlns='http://jabber.org/protocol/chatstates'/&gt; chat state, it SHOULD unlock the coversation.</li>

+ 1
- 1
xep-0298.xml View File

@@ -26,6 +26,7 @@
26 26
     <supersedes />
27 27
     <supersededby />
28 28
     <shortname>coin</shortname>
29
+    <discuss>jingle</discuss>
29 30
     <author>
30 31
       <firstname>Emil</firstname>
31 32
       <surname>Ivov</surname>
@@ -44,7 +45,6 @@
44 45
       <email>saul@ag-projects.com</email>
45 46
       <jid>saul@ag-projects.com</jid>
46 47
     </author>
47
-    <discuss>jingle</discuss>
48 48
     <revision>
49 49
       <version>0.2</version>
50 50
       <date>2015-07-02</date>

Loading…
Cancel
Save