Browse Source

XEP-0101–XEP-0185: Fix DTD

Sam Whited 2 years ago
parent
commit
424dd6c59b
23 changed files with 394 additions and 372 deletions
  1. 1
    1
      xep-0101.xml
  2. 4
    4
      xep-0102.xml
  3. 2
    2
      xep-0103.xml
  4. 4
    1
      xep-0105.xml
  5. 3
    3
      xep-0106.xml
  6. 4
    1
      xep-0109.xml
  7. 1
    1
      xep-0119.xml
  8. 1
    1
      xep-0120.xml
  9. 1
    1
      xep-0121.xml
  10. 6
    1
      xep-0123.xml
  11. 1
    1
      xep-0125.xml
  12. 1
    1
      xep-0133.xml
  13. 1
    1
      xep-0137.xml
  14. 121
    121
      xep-0146.xml
  15. 175
    175
      xep-0151.xml
  16. 1
    1
      xep-0152.xml
  17. 6
    6
      xep-0157.xml
  18. 2
    2
      xep-0162.xml
  19. 42
    43
      xep-0171.xml
  20. 1
    0
      xep-0179.xml
  21. 12
    1
      xep-0180.xml
  22. 3
    3
      xep-0185.xml
  23. 1
    1
      xep.dtd

+ 1
- 1
xep-0101.xml View File

@@ -13,11 +13,11 @@
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>RFC 2616, RFC 2617, XEP-0030</dependencies>
17 16
   <dependencies>
18 17
     <spec>XMPP Core</spec>
19 18
     <spec>RFC 2616</spec>
20 19
     <spec>RFC 2617</spec>
20
+    <spec>XEP-0030</spec>
21 21
   </dependencies>
22 22
   <supersedes/>
23 23
   <supersededby/>

+ 4
- 4
xep-0102.xml View File

@@ -361,8 +361,8 @@
361 361
 </section1>
362 362
 <section1 topic="Authenticated Key Agreement">
363 363
 <section2 topic="Introduction">
364
-<p>The Diffie-Hellman key agreement algorithm <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref28269252">[10]</ulink> provides a mechanism to allow key establishment in a scalable and secure way. It allows two parties to agree on a shared value without requiring encryption. An Authenticated Key Agreement (AKE) is a secure protocol ensuring that in addition to securely sharing a secret, the two parties can be certain of each other&#8217;s identities, even when an active attacker exists.</p>
365
-<p>This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27748789">[1]</ulink> and the OAKLEY key determination protocol <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27750056">[2]</ulink>. The purpose is to negotiate and provide authenticated key material for security association (SA) in a protected manner. The basic mechanism is the Diffie-Hellman Key Exchange. It provides the following addition to base key agreement:</p>
364
+<p>The Diffie-Hellman key agreement algorithm provides a mechanism to allow key establishment in a scalable and secure way. It allows two parties to agree on a shared value without requiring encryption. An Authenticated Key Agreement (AKE) is a secure protocol ensuring that in addition to securely sharing a secret, the two parties can be certain of each other&#8217;s identities, even when an active attacker exists.</p>
365
+<p>This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) and the OAKLEY key determination protocol. The purpose is to negotiate and provide authenticated key material for security association (SA) in a protected manner. The basic mechanism is the Diffie-Hellman Key Exchange. It provides the following addition to base key agreement:</p>
366 366
 <ul>
367 367
 <li>it uses weak address validation mechanism (cookies) to avoid denial of service attacks.
368 368
 </li>
@@ -387,8 +387,8 @@
387 387
 <p>The anti clogging tokens, or cookies, provide a weak form of source address identification for both parties. The cookies exchange can be completed before they perform the expensive computations later in the protocol. The cookies are used also for key naming.</p>
388 388
 <ul>
389 389
 <li>The construction of the cookies is implementation dependent. It is recommended to make them the result of a one-way function applied to a secret value (changed periodically), and the local and remote addresses. In this way, the cookies remain stateless and expire periodically.  Note that this would cause the KEYID's derived from the secret value to also expire, necessitating the removal of any state information associated with it.  </li>
390
-<li>The encryption functions must be cryptographic transforms which guarantee privacy and integrity for the message data. They include any that satisfy this criteria and are defined for use with RFC2406 <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27753196">[3]</ulink>.  </li>
391
-<li>The one-way hash functions must be cryptographic transform which can be used as either keyed hash (pseudo-random) or non keyed transforms. They include any that are defined for use with RFC2406 <ulink url="TEC-STD-XML-2002-0011 XMPP Security Extensions.xml#_Ref27753196">[3]</ulink>.  </li>
390
+<li>The encryption functions must be cryptographic transforms which guarantee privacy and integrity for the message data. They include any that satisfy this criteria and are defined for use with &rfc2406;.</li>
391
+<li>The one-way hash functions must be cryptographic transform which can be used as either keyed hash (pseudo-random) or non keyed transforms. They include any that are defined for use with <cite>RFC2406</cite>.</li>
392 392
 <li>Where nonces are indicated they will be variable precision integers with an entropy value that match the strength attribute of the DH group used in the exchange.</li>
393 393
 </ul>
394 394
 </section2>

+ 2
- 2
xep-0103.xml View File

@@ -132,8 +132,8 @@
132 132
       <li>Once retrieval is complete, the Receiver responds to Sender (EUC).</li>
133 133
     </ol>
134 134
     <ul>
135
-      <li><b>E1:</b> The given URL is not supported/understood</li>
136
-      <li><b>E2:</b> Failure to connect to the given URL</li>
135
+      <li><strong>E1:</strong> The given URL is not supported/understood</li>
136
+      <li><strong>E2:</strong> Failure to connect to the given URL</li>
137 137
     </ul>
138 138
     <p>The sender starts with an SI request, using the semantics from XEP-0095:</p>
139 139
     <example caption='Requesting SI transfer'><![CDATA[

+ 4
- 1
xep-0105.xml View File

@@ -13,7 +13,10 @@
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>XEP-0095, XEP-0096</dependencies>
16
+  <dependencies>
17
+    <spec>XEP-0095</spec>
18
+    <spec>XEP-0096</spec>
19
+  </dependencies>
17 20
   <supersedes/>
18 21
   <supersededby/>
19 22
   <shortname>si-treetransfer</shortname>

+ 3
- 3
xep-0106.xml View File

@@ -204,9 +204,9 @@
204 204
   </section2>
205 205
   <section2 topic='Exceptions' anchor='bizrules-exceptions'>
206 206
     <p>In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored (with the exception of the escaping character '\' itself in the rare case when the source address includes the sequence '\5c').</p>
207
-    <example caption='Partial escape sequence'><strong>\2plus\2is\4</strong> is not modified by escaping or unescaping transformations.</example>
208
-    <example caption='Invalid escape sequence 1'><strong>foo\bar</strong> is not modified (to <strong>foo&#186;r</strong>) by escaping or unescaping transformations.</example>
209
-    <example caption='Invalid escape sequence 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) by escaping or unescaping transformations.</example>
207
+    <example caption='Partial escape sequence'>"\2plus\2is\4" is not modified by escaping or unescaping transformations.</example>
208
+    <example caption='Invalid escape sequence 1'>"foo\bar" is not modified (to "foo&#186;r") by escaping or unescaping transformations.</example>
209
+    <example caption='Invalid escape sequence 2'>"foob\41r" is not modified (to "foobAr") by escaping or unescaping transformations.</example>
210 210
     <p>However, \5c would be escaped if found in the source address (e.g., a source address of "c:\5commas@example.com" would be escaped to "c\3a\5c5commas@example.com") and unescaped if contained in the JID-on-the-wire (e.g., a JID-on-the-wire of "c\3a\5c5commas@example.com" would be unescaped back to "c:\5commas@example.com").</p>
211 211
   </section2>
212 212
   <section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>

+ 4
- 1
xep-0109.xml View File

@@ -13,7 +13,10 @@
13 13
   <status>Deferred</status>
14 14
   <type>Standards Track</type>
15 15
   <sig>Standards</sig>
16
-  <dependencies>XEP-0060, XEP-0163</dependencies>
16
+  <dependencies>
17
+    <spec>XEP-0060</spec>
18
+    <spec>XEP-0163</spec>
19
+  </dependencies>
17 20
   <supersedes/>
18 21
   <supersededby/>
19 22
   <shortname>ooo</shortname>

+ 1
- 1
xep-0119.xml View File

@@ -156,7 +156,7 @@ Service                |                   Manager
156 156
       <td>REQUIRED *</td>
157 157
     </tr>
158 158
   </table>
159
-  <p><em>* Note: The User Avatar specification (<cite>XEP-0084</cite>) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</em></p>
159
+  <p>* <em>Note:</em> The User Avatar specification (<cite>XEP-0084</cite>) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</p>
160 160
 </section1>
161 161
 <section1 topic='Node Discovery' anchor='discovery'>
162 162
   <p>Discovery of extended presence pubsub nodes is expedited through the use of <cite>Personal Eventing via Pubsub</cite> (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:</p>

+ 1
- 1
xep-0120.xml View File

@@ -16,7 +16,7 @@
16 16
   <status>Retracted</status>
17 17
   <type>Standards Track</type>
18 18
   <sig>Standards</sig>
19
-  <dependencies>XMPP Core</dependencies>
19
+  <dependencies><spec>XMPP Core</spec></dependencies>
20 20
   <supersedes/>
21 21
   <supersededby/>
22 22
   <shortname>infobits</shortname>

+ 1
- 1
xep-0121.xml View File

@@ -16,7 +16,7 @@
16 16
   <status>Retracted</status>
17 17
   <type>Informational</type>
18 18
   <sig>Standards</sig>
19
-  <dependencies>XEP-0120</dependencies>
19
+  <dependencies><spec>XEP-0120</spec></dependencies>
20 20
   <supersedes/>
21 21
   <supersededby/>
22 22
   <shortname>N/A</shortname>

+ 6
- 1
xep-0123.xml View File

@@ -16,7 +16,12 @@
16 16
   <status>Retracted</status>
17 17
   <type>Standards Track</type>
18 18
   <sig>Standards</sig>
19
-  <dependencies>XMPP Core, XMPP IM, XEP-0030, XEP-0120</dependencies>
19
+  <dependencies>
20
+    <spec>XMPP Core</spec>
21
+    <spec>XMPP IM</spec>
22
+    <spec>XEP-0030</spec>
23
+    <spec>XEP-0120</spec>
24
+  </dependencies>
20 25
   <supersedes/>
21 26
   <supersededby/>
22 27
   <shortname>N/A</shortname>

+ 1
- 1
xep-0125.xml View File

@@ -16,7 +16,7 @@
16 16
   <status>Retracted</status>
17 17
   <type>Informational</type>
18 18
   <sig>Standards</sig>
19
-  <dependencies>XEP-0120</dependencies>
19
+  <dependencies><spec>XEP-0120</spec></dependencies>
20 20
   <supersedes/>
21 21
   <supersededby/>
22 22
   <shortname>N/A</shortname>

+ 1
- 1
xep-0133.xml View File

@@ -132,7 +132,7 @@
132 132
     <li>Shut Down Service</li>
133 133
   </ol>
134 134
   <p>Naturally, not all of these use cases apply to all service types (e.g., adding a user may not apply to a multi-user chat service). An implementation or deployment MAY support any subset of the use cases defined herein. In addition, although this document aims to define common use cases, an implementation or deployment MAY support additional commands not defined herein, which may or may not be publicly registered.</p>
135
-  <p><em>Note: The text that follows assumes that implementors have read and understood <cite>XEP-0050: Ad-Hoc Commands</cite> and <cite>XEP-0004: Data Forms</cite>.</em></p>
135
+  <p><em>Note:</em> The text that follows assumes that implementors have read and understood <cite>XEP-0050: Ad-Hoc Commands</cite> and <cite>XEP-0004: Data Forms</cite>.</p>
136 136
   <section2 topic='Add User' anchor='add-user'>
137 137
     <p>A user is defined as any entity that has a persistent relationship with a service (most commonly through the creation a registered account with the service) and whose account is in some sense hosted by the service. Adding a user MUST result in the creation of an account, along with any implementation-specific data for such an account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-user".</p>
138 138
     <p>A sample protocol flow for this use case is shown below.</p>

+ 1
- 1
xep-0137.xml View File

@@ -237,7 +237,7 @@
237 237
     ]]></example>
238 238
   </section2>
239 239
 </section1>
240
-<section1 topic='Implementation Notes' achor='impl-notes'>
240
+<section1 topic='Implementation Notes' anchor='impl-notes'>
241 241
   <section2 topic='Publish ID versus SI ID'>
242 242
     <p>When publishing a stream via the &lt;sipub/&gt; element, the identifier SHOULD NOT be used as-is for the &lt;si/&gt; element, since a single publication will likely result in multiple &lt;si/&gt; requests, possibly from the same receiver.</p>
243 243
   </section2>

+ 121
- 121
xep-0146.xml View File

@@ -226,25 +226,29 @@
226 226
 
227 227
 
228 228
     <section2 topic='Forward Unread Messages Residing at a Remote Client' anchor='forward'>
229
-        <p>A user might want to forward all the unread messages residing at
230
-        the remote client to the local client (e.g. when the remote client was
231
-        accidentally left on-line, and has received messages in the meantime).</p>
232
-        
229
+      <p>
230
+        A user might want to forward all the unread messages residing at the
231
+        remote client to the local client (e.g. when the remote client was
232
+        accidentally left on-line, and has received messages in the meantime).
233
+      </p>
234
+      <p>
233 235
         For example, suppose Romeo sends a message to Juliet, thinking she is
234
-        still on her balcony. The balcony client receives the message:
235
-        <example caption='Remote Client Receives Message'><![CDATA[
236
-<message from='romeo@example.com/orchard' 
236
+        still on her balcony.
237
+        The balcony client receives the message:
238
+      </p>
239
+      <example caption='Remote Client Receives Message'><![CDATA[
240
+<message from='romeo@example.com/orchard'
237 241
          to='juliet@example.com/balcony'>
238
-  <subject>Just saying hi</subject>
239
-  <body>Hello Juliet!</body>
240
-</message>
241
-        ]]></example>
242
-
242
+    <subject>Just saying hi</subject>
243
+    <body>Hello Juliet!</body>
244
+</message>]]></example>
245
+      <p>
243 246
         However, Juliet is in her chamber, so she doesn't know about the message
244
-        (yet). Realizing she left her balcony client unattended, she sends a 
245
-        request to the remote client to forward all unread messages.
246
-
247
-        <example caption='Local Client Requests to Forward Unread Messages Currently Residing at the Remote Client'><![CDATA[
247
+        (yet).
248
+        Realizing she left her balcony client unattended, she sends a request to
249
+        the remote client to forward all unread messages.
250
+      </p>
251
+      <example caption='Local Client Requests to Forward Unread Messages Currently Residing at the Remote Client'><![CDATA[
248 252
 <iq from='juliet@example.com/chamber'
249 253
     to='juliet@example.com/balcony'
250 254
     type='set'
@@ -254,122 +258,120 @@
254 258
            action='execute'
255 259
            node='http://jabber.org/protocol/rc#forward'
256 260
            sessionid='forward:20040727T0337Z'/>
257
-</iq>
258
-        ]]></example>
259
-        
261
+</iq>]]></example>
262
+      <p>
260 263
         The client forwards all unread messages to the local client, adding
261
-        information about the origin of the message (using the 'ofrom' 
262
-		&xep0033; address, and the &xep0203; timestamp of the original message). 
263
-		The chamber client receives both these messages and a
264
-        confirmation that the command was completed.
265
-        <example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
264
+        information about the origin of the message (using the 'ofrom' &xep0033;
265
+        address, and the &xep0203; timestamp of the original message).
266
+        The chamber client receives both these messages and a confirmation that
267
+        the command was completed.
268
+      </p>
269
+      <example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
266 270
 <message from='juliet@example.com/balcony' 
267 271
          to='juliet@example.com/chamber'>
268 272
   <subject>Just saying hi</subject>
269 273
   <body>Hello Juliet!</body>
270 274
   <addresses xmlns='http://jabber.org/protocol/address'>
271 275
     <address type='ofrom' jid='romeo@example.com/orchard'/>
272
-  </addresses>  
276
+  </addresses>
273 277
   <delay xmlns='urn:xmpp:delay'
274 278
          from='juliet@capulet.com/balcony'
275 279
          stamp='2002-09-10T23:41:07Z'/>
276
-</message>
277
-        ]]></example>
278
-
279
-        <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
280
+</message>]]></example>
281
+      <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
280 282
 <iq from='juliet@example.com/balcony' 
281 283
     to='juliet@example.com/chamber' 
282 284
     type='result' 
283 285
     id='forward-1'
284 286
     xml:lang='en'>
285
-  <command xmlns='http://jabber.org/protocol/commands'
286
-           node='http://jabber.org/protocol/rc#forward'
287
-           sessionid='forward:20040727T0337Z'
288
-           status='completed'/>
289
-</iq>
290
-        ]]></example>
291
-
292
-		A client MAY provide a more fine-grained implementation, e.g. by
293
-		presenting the requester an extra form to select which messages
294
-		have to be forwarded.
287
+    <command xmlns='http://jabber.org/protocol/commands'
288
+      node='http://jabber.org/protocol/rc#forward'
289
+      sessionid='forward:20040727T0337Z'
290
+      status='completed'/>
291
+</iq>]]></example>
292
+      <p>
293
+        A client MAY provide a more fine-grained implementation, e.g. by
294
+        presenting the requester an extra form to select which messages have to
295
+        be forwarded.
296
+      </p>
295 297
     </section2>
296 298
 
297 299
 
298 300
     <section2 topic='Change Run-Time Options'>
299
-        <p>It might be desirable to remotely set some run-time options of
300
-        a client. For example, when neighbours complain about the sounds your 
301
-        client makes while you're at another location, you could turn the 
302
-        sounds off at the remote client.
303
-        </p>
304
-		<example caption='Local Client Requests to Change Options of a Remote Client'><![CDATA[
301
+      <p>
302
+        It might be desirable to remotely set some run-time options of a client.
303
+        For example, when neighbours complain about the sounds your client makes
304
+        while you're at another location, you could turn the sounds off at the
305
+        remote client.
306
+      </p>
307
+      <example caption='Local Client Requests to Change Options of a Remote Client'><![CDATA[
305 308
 <iq from='juliet@example.com/chamber'
306 309
     to='juliet@example.com/balcony'
307 310
     type='set'
308 311
     id='set-options-1'
309 312
     xml:lang='en'>
310
-  <command xmlns='http://jabber.org/protocol/commands' 
311
-           action='execute'
312
-           node='http://jabber.org/protocol/rc#set-options'/>
313
-</iq>
314
-        ]]></example>
315
-        <p>Unless an error occurs (see the 
316
-        <link url='#errors'>Error Handling</link> section below), the service 
317
-        SHOULD return the appropriate form.</p>
318
-        
319
-		<example caption='Remote Client Replies with a Form to Set its Options'><![CDATA[
320
-<iq from='juliet@example.com/balcony' 
321
-    to='juliet@example.com/chamber' 
322
-    type='result' 
323
-    id='set-options-1'
324
-    xml:lang='en'>
313
+    <command xmlns='http://jabber.org/protocol/commands' 
314
+             action='execute'
315
+             node='http://jabber.org/protocol/rc#set-options'/>
316
+</iq>]]></example>
317
+      <p>
318
+        Unless an error occurs (see the <link url='#errors'>Error
319
+          Handling</link> section below), the service SHOULD return the
320
+        appropriate form.
321
+      </p>
322
+      <example caption='Remote Client Replies with a Form to Set its Options'><![CDATA[
323
+<iq from='juliet@example.com/balcony'
324
+  to='juliet@example.com/chamber'
325
+  type='result'
326
+  id='set-options-1'
327
+  xml:lang='en'>
325 328
   <command xmlns='http://jabber.org/protocol/commands'
326
-             node='http://jabber.org/protocol/rc#set-options'
327
-             sessionid='set-options:20040727T0337Z'
328
-             status='executing'>
329
+    node='http://jabber.org/protocol/rc#set-options'
330
+    sessionid='set-options:20040727T0337Z'
331
+    status='executing'>
329 332
     <x xmlns='jabber:x:data' type='form'>
330 333
       <title>Set Options</title>
331 334
       <instructions>Set the desired options</instructions>
332 335
       <field type='hidden' var='FORM_TYPE'>
333 336
         <value>http://jabber.org/protocol/rc</value>
334 337
       </field>
335
-      <field label='Play sounds' 
336
-             type='boolean' 
337
-             var='sounds'>
338
+      <field label='Play sounds'
339
+        type='boolean'
340
+        var='sounds'>
338 341
         <value>1</value>
339 342
       </field>
340 343
       <field label='Automatically Go Offline when Idle' 
341
-             type='boolean' 
342
-             var='auto-offline'>
344
+        type='boolean' 
345
+        var='auto-offline'>
343 346
         <value>0</value>
344 347
       </field>
345 348
       <field label='Automatically Open New Messages' 
346
-             type='boolean' 
347
-             var='auto-msg'>
349
+        type='boolean' 
350
+        var='auto-msg'>
348 351
         <value>0</value>
349 352
       </field>
350 353
       <field label='Automatically Accept File Transfers' 
351
-             type='boolean' 
352
-             var='auto-files'>
354
+        type='boolean' 
355
+        var='auto-files'>
353 356
         <value>0</value>
354 357
       </field>
355 358
       <field label='Automatically Authorize Contacts' 
356
-             type='boolean' 
357
-             var='auto-auth'>
359
+        type='boolean' 
360
+        var='auto-auth'>
358 361
         <value>0</value>
359 362
       </field>
360 363
     </x>
361 364
   </command>
362
-</iq>
363
-        ]]></example>
364
-        <example caption='Local Client Submits Set Options Form to Remote Client'><![CDATA[
365
+</iq>]]></example>
366
+      <example caption='Local Client Submits Set Options Form to Remote Client'><![CDATA[
365 367
 <iq from='juliet@example.com/chamber'
366
-    to='juliet@example.com/balcony'
367
-    type='set'
368
-    id='set-options-2'
369
-    xml:lang='en'>
368
+  to='juliet@example.com/balcony'
369
+  type='set'
370
+  id='set-options-2'
371
+  xml:lang='en'>
370 372
   <command xmlns='http://jabber.org/protocol/commands' 
371
-           node='http://jabber.org/protocol/rc#set-options'
372
-           sessionid='set-options:20040727T0337Z'>
373
+    node='http://jabber.org/protocol/rc#set-options'
374
+    sessionid='set-options:20040727T0337Z'>
373 375
     <x xmlns='jabber:x:data' type='form'>
374 376
       <field type='hidden' var='FORM_TYPE'>
375 377
         <value>http://jabber.org/protocol/rc</value>
@@ -392,30 +394,30 @@
392 394
     </x>
393 395
   </command>
394 396
 </iq>
395
-        ]]></example>
396
-        <p>The remote client sets the values of the options to their requested
397
-		value. If a variable is omitted, the client SHOULD NOT change the value of the 
398
-		corresponding option.</p>
399
-
400
-        <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
401
-<iq from='juliet@example.com/balcony' 
402
-    to='juliet@example.com/chamber' 
403
-    type='result' 
397
+]]></example>
398
+      <p>
399
+        The remote client sets the values of the options to their requested
400
+        value.
401
+        If a variable is omitted, the client SHOULD NOT change the value of the
402
+        corresponding option.
403
+      </p>
404
+      <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
405
+<iq from='juliet@example.com/balcony'
406
+    to='juliet@example.com/chamber'
407
+    type='result'
404 408
     id='set-options-2'
405 409
     xml:lang='en'>
406
-  <command xmlns='http://jabber.org/protocol/commands'
407
-           node='http://jabber.org/protocol/rc#set-options'
408
-           sessionid='set-options:20040727T0337Z'
409
-           status='completed'/>
410
-</iq>
411
-        ]]></example>
412
-        <p>Notification of completion MAY include the processed data in a data 
413
-        form of type 'result'.</p>
410
+    <command xmlns='http://jabber.org/protocol/commands'
411
+             node='http://jabber.org/protocol/rc#set-options'
412
+             sessionid='set-options:20040727T0337Z'
413
+             status='completed'/>
414
+</iq>]]></example>
415
+      <p>
416
+        Notification of completion MAY include the processed data in a data form
417
+        of type 'result'.
418
+      </p>
414 419
     </section2>
415 420
 
416
-
417
-	<!-- ************************************************************************ -->
418
-
419 421
     <section2 topic='Accept Pending File Transfer Requests'>
420 422
         <example caption='Local Client Requests to Accept Pending File Transfer Requests on the Remote Client'><![CDATA[
421 423
 <iq from='juliet@example.com/chamber'
@@ -426,16 +428,16 @@
426 428
   <command xmlns='http://jabber.org/protocol/commands' 
427 429
            action='execute'
428 430
            node='http://jabber.org/protocol/rc#accept-files'/>
429
-</iq>
430
-        ]]></example>
431
-        <p>Unless an error occurs (see the 
432
-        <link url='#errors'>Error Handling</link> section below), the service 
433
-        SHOULD return the appropriate form.</p>
434
-        
431
+</iq>]]></example>
432
+<p>
433
+  Unless an error occurs (see the <link url='#errors'>Error Handling</link>
434
+  section below), the service SHOULD return the appropriate form.
435
+</p>
436
+
435 437
         <example caption='Remote Client Replies with a Form Containing Pending File Transfers'><![CDATA[
436
-<iq from='juliet@example.com/balcony' 
437
-    to='juliet@example.com/chamber' 
438
-    type='result' 
438
+<iq from='juliet@example.com/balcony'
439
+    to='juliet@example.com/chamber'
440
+    type='result'
439 441
     id='accept-files-1'
440 442
     xml:lang='en'>
441 443
   <command xmlns='http://jabber.org/protocol/commands'
@@ -464,8 +466,7 @@
464 466
       </field>
465 467
     </x>
466 468
   </command>
467
-</iq>
468
-        ]]></example>
469
+</iq>]]></example>
469 470
         <example caption='Local Client Submits Form to Remote Client'><![CDATA[
470 471
 <iq from='juliet@example.com/chamber'
471 472
     to='juliet@example.com/balcony'
@@ -484,11 +485,11 @@
484 485
       </field>
485 486
     </x>
486 487
   </command>
487
-</iq>
488
-        ]]></example>
489
-
490
-        The remote client accepts the selected file transfers, and informs
491
-        the local client of completion.
488
+</iq>]]></example>
489
+      <p>
490
+        The remote client accepts the selected file transfers, and informs the
491
+        local client of completion.
492
+      </p>
492 493
         <example caption='Remote Client Informs Local Client of Completion'><![CDATA[
493 494
 <iq from='juliet@example.com/balcony' 
494 495
     to='juliet@example.com/chamber' 
@@ -499,8 +500,7 @@
499 500
            node='http://jabber.org/protocol/rc#accept-files'
500 501
            sessionid='accept-files:20040727T0337Z'
501 502
            status='completed'/>
502
-</iq>
503
-        ]]></example>
503
+</iq>]]></example>
504 504
     </section2>
505 505
 
506 506
 

+ 175
- 175
xep-0151.xml View File

@@ -105,22 +105,20 @@
105 105
 
106 106
   <p>Meeting on virtual locations is very similar to meeting peers in a public chat room. But web pages can be regarded as 2 dimensional. They very often cover the entire screen. They use graphics elements for their content. Plainly speaking: representing users as figures or other images fits well to web pages. Once they are shown as individual figures, a line based chat and a chat window are not required any more (though a chat window can still be used). The figures can move around and talk in chat bubble style. Chat bubbles in turn enable incremental chat.</p>
107 107
 
108
-  <p>This document describes protocol elements for 
109
-    <ul>
110
-      <li>the visualization of users on web pages (animated avatars) and</li>
111
-      <li>communication beyond line based group chat (incremental or instant bubble chat)</li>
112
-    </ul>
113
-  </p>
108
+  <p>This document describes protocol elements for:</p>
109
+  <ul>
110
+    <li>the visualization of users on web pages (animated avatars) and</li>
111
+    <li>communication beyond line based group chat (incremental or instant bubble chat)</li>
112
+  </ul>
114 113
 
115 114
   <p>While users are browsing the web, they enter and leave many rooms. They meet many people and some of them multiple times. Minimum overall traffic and minimum traffic on the user connection are primary design goals. The user connection is limited by typical karma settings of jabber servers. Logging in to virtual locations (rooms) must be quick in terms of round trips and cheap in terms of traffic. Once logged in to a room, the traffic on the user connection should be independent of the number of peers already present. </p>
116 115
 
117
-  <p>The extensions have been designed to be:
118
-    <ul>
119
-      <li>compatible to the existing Jabber infrastructure and protocols,</li>
120
-      <li>lightweight with respect to the number of new elements,</li>
121
-      <li>lightweight with respect to the traffic generated.</li>
122
-    </ul>
123
-  </p>
116
+  <p>The extensions have been designed to be:</p>
117
+  <ul>
118
+    <li>compatible to the existing Jabber infrastructure and protocols,</li>
119
+    <li>lightweight with respect to the number of new elements,</li>
120
+    <li>lightweight with respect to the traffic generated.</li>
121
+  </ul>
124 122
 
125 123
   <p>The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.</p>
126 124
 
@@ -146,33 +144,31 @@
146 144
 
147 145
   <p>The mapping process should try to protect the privacy of the user. After all, virtual presence is a violation of privacy in general, because people know where other people are (virtually). This is critical, if compared to the totally un-observed Web without virtual presence. In the real world people are used to being seen in physical locations, but only by others who are physically present in the same location. The mapping process should emulate this restriction. The general idea is to include a one way function (message digest) during the mapping process to prohibit the discovery of &apos;interesting&apos; chat room names. In other words: observers must do the forward mapping and enter a room to see who is there or discover random room names without being able to re-create the source URL. So, they may be able to find people in random rooms, but do not know the virtual location.</p>
148 146
 
149
-  <p>This mapping process is designed to 
150
-    <ul>
151
-      <li>make the virtual presence service a distributed network of jabber servers, i.e. conference components,</li>
152
-      <li>allow for flexible mapping from URLs to JIDs, taking into account that
153
-        <ul>
154
-          <li>most URLs are path based,</li>
155
-          <li>URLs contain queries,</li>
156
-          <li>sometimes only the query part defines the virtual location,</li>
157
-          <li>groups of URLs map to a single JID,</li>
158
-          <li>a single virtual location may comprise multiple web servers,</li>
159
-          <li>groups of URLs may only cover a sub-folder of path based URLs,</li>
160
-          <li>not all URLs are known at config time,</li>
161
-        </ul>
162
-      </li>
163
-      <li>allow operators of websites to control the mapping for the URL-space they control,</li>
164
-      <li>let websites opt out of virtual presence,</li>
165
-      <li>allow for hierarchical configuration for file system path based URLs,</li>
166
-      <li>support delegation,</li>
167
-      <li>allow for virtual presence without the cooperation of the website,</li>
168
-      <li>allow for distribution of the load of the default configuration server,</li>
169
-      <li>support commercial virtual presence servers and rented rooms,</li>
170
-      <li>be extensible to other protocols as virtual presence transport,</li>
171
-      <li>be easily implemented by website operators,</li>
172
-      <li>at least limit the privacy issues associated with virtual presence.</li>
173
-    </ul>
174
-  </p>
175
-
147
+  <p>This mapping process is designed to:</p>
148
+  <ul>
149
+    <li>make the virtual presence service a distributed network of jabber servers, i.e. conference components,</li>
150
+    <li>allow for flexible mapping from URLs to JIDs, taking into account that
151
+      <ul>
152
+        <li>most URLs are path based,</li>
153
+        <li>URLs contain queries,</li>
154
+        <li>sometimes only the query part defines the virtual location,</li>
155
+        <li>groups of URLs map to a single JID,</li>
156
+        <li>a single virtual location may comprise multiple web servers,</li>
157
+        <li>groups of URLs may only cover a sub-folder of path based URLs,</li>
158
+        <li>not all URLs are known at config time,</li>
159
+      </ul>
160
+    </li>
161
+    <li>allow operators of websites to control the mapping for the URL-space they control,</li>
162
+    <li>let websites opt out of virtual presence,</li>
163
+    <li>allow for hierarchical configuration for file system path based URLs,</li>
164
+    <li>support delegation,</li>
165
+    <li>allow for virtual presence without the cooperation of the website,</li>
166
+    <li>allow for distribution of the load of the default configuration server,</li>
167
+    <li>support commercial virtual presence servers and rented rooms,</li>
168
+    <li>be extensible to other protocols as virtual presence transport,</li>
169
+    <li>be easily implemented by website operators,</li>
170
+    <li>at least limit the privacy issues associated with virtual presence.</li>
171
+  </ul>
176 172
   </section2>
177 173
 
178 174
 </section1>
@@ -207,11 +203,8 @@
207 203
   </section2>
208 204
 
209 205
   <section2 topic='Getting more information'>
210
-  
211 206
     <p>For more information about &apos;YoungHero&apos; beyond the nickname Juliet needs a JID (see below for anonymous variants of the avatar image). Non-anonymous rooms will supply the JIDs automatically. But we suggest that rooms, which make up the virtual presence network are configured to be anonymous so that users can choose if they want to disclose the JID. We propose an extension to the &PRESENCE; stanza for users to supply their JID automatically to peers in anonymous rooms with minimum traffic even for many participants. </p>
212
-    
213 207
     <p>Note: even though Romeo sends a JID, the systems is still anonymous. Romeo could send any JID. He may send a (fake) JID that is just the base address of his storage, but not his communication address. In anonymous rooms Juliet will use any JID Romeo provides. If the room is not anonymous, then Romeo&apos;s client may use Juliet&apos;s actual JID. </p>
214
-    
215 208
     <p>Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.</p>
216 209
 
217 210
     <example caption='Disclosing the JID'><![CDATA[
@@ -224,13 +217,12 @@
224 217
 
225 218
     <p>This tells the conference component to send the JID to all participants automatically. Romeo will receive the &PRESENCE; stanza including the JID element. Romeo may now fetch Juliet&apos;s avatar or add Juliet to a buddy list. </p>
226 219
 
227
-    <p>Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons:
228
-      <ol>
229
-        <li>to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,</li>
230
-        <li>to allow for caching of extended information.</li>
231
-      </ol>
232
-    Caching requires a persistent and unique id per user. While a message digest of the JID would be sufficient for caching extended information, it is not sufficient for retrieving extended information. 
233
-    </p>
220
+    <p>Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons:</p>
221
+    <ol>
222
+      <li>to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,</li>
223
+      <li>to allow for caching of extended information.</li>
224
+    </ol>
225
+    <p>Caching requires a persistent and unique id per user. While a message digest of the JID would be sufficient for caching extended information, it is not sufficient for retrieving extended information.</p>
234 226
 
235 227
   </section2>
236 228
 
@@ -464,17 +456,14 @@ as part of:
464 456
 
465 457
     <p>The video format is the common, widely used webcam format introduced by Netscape (JPEG server-pushed).</p>
466 458
 
467
-    <p>In the real world there are many Romeos and Juliets even on the same page at the same time. Some of them with a webcam. Depending on the default settings of VP clients all users (say 8) will automatically request the videos of the subset of users equipped with a webcam (say 3). This automatically creates many video streams, 3 streams on the dialup line of all users and 7 streams on the line of webcam users. We therefore suggest the following optimizations and limitations:
468
-      <ul>
469
-        <li>video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,</li>
470
-        <li>the frame rate should not exceed 3 frames per second for simple web browsing (special applications, especially assymmetric ones, like virtual class rooms, presentations may differ),</li>
471
-        <li>for small sizes, quantization tables and Huffman tables make much more data than the encoded image. Therefore, the DQT and DHT markers should be stripped from JPEG frames except for the first frame of a stream. Only the JPEG baseline algorithm is supported with static Huffman tables,</li>
472
-        <li>VP clients which support such a optimized JPEG server-push format should add a &apos;Accept: image/djpeg&apos; header to the HTTP request. (djpeg for differential JPEG)</li>
473
-      </ul>
474
-
475
-    The purpose of these limitations is to allow for webcams which send optimized streams of small images (reducing the data volume by a factor of 3) while supporting usual webcams.
476
-    </p>
477
-
459
+    <p>In the real world there are many Romeos and Juliets even on the same page at the same time. Some of them with a webcam. Depending on the default settings of VP clients all users (say 8) will automatically request the videos of the subset of users equipped with a webcam (say 3). This automatically creates many video streams, 3 streams on the dialup line of all users and 7 streams on the line of webcam users. We therefore suggest the following optimizations and limitations:</p>
460
+    <ul>
461
+      <li>video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,</li>
462
+      <li>the frame rate should not exceed 3 frames per second for simple web browsing (special applications, especially assymmetric ones, like virtual class rooms, presentations may differ),</li>
463
+      <li>for small sizes, quantization tables and Huffman tables make much more data than the encoded image. Therefore, the DQT and DHT markers should be stripped from JPEG frames except for the first frame of a stream. Only the JPEG baseline algorithm is supported with static Huffman tables,</li>
464
+      <li>VP clients which support such a optimized JPEG server-push format should add a &apos;Accept: image/djpeg&apos; header to the HTTP request. (djpeg for differential JPEG)</li>
465
+    </ul>
466
+    <p>The purpose of these limitations is to allow for webcams which send optimized streams of small images (reducing the data volume by a factor of 3) while supporting usual webcams.</p>
478 467
   </section2>
479 468
 
480 469
 </section1>
@@ -626,29 +615,29 @@ http://www.shakespeare.com/_vpi.xml]]>
626 615
 
627 616
   <p>This section is intended as a guideline for the implementation of the mapping process.</p>
628 617
 
629
-  <p>The mapping has 2 phases: 
630
-    <ol>
618
+  <p>The mapping has 2 phases:</p>
619
+  <ol>
631 620
     <li>finding the rule</li>
632 621
     <li>applying the rule</li>
633
-    </ol>
634
-  </p>
622
+  </ol>
635 623
 
636 624
   <section3 topic='Find the Rule'>
637 625
 
638
-  <p>
639
-      We get a URL from the web browser, say
640
-        <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
641
-      We try to fetch the configuration file from 
642
-        <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/_vpi.xml]]></code>
643
-      The request fails (the failure is noted in the cache), and we try
644
-        <code><![CDATA[http://www.shakespeare.com/market/_vpi.xml]]></code>
645
-      The request fails again (the failure is noted in the cache). We try
646
-        <code><![CDATA[http://www.shakespeare.com/_vpi.xml]]></code>
647
-      We do not find it (the failure is noted in the cache), and we revert to the 
648
-      global file (which one depends on the client configuration)
649
-        <code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml]]></code>
650
-      The request returns (and the data is stored in the cache): 
651
-      <code><![CDATA[
626
+    <p>We get a URL from the web browser, say:</p>
627
+    <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
628
+    <p>We try to fetch the configuration file from</p>
629
+    <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/_vpi.xml]]></code>
630
+    <p>The request fails (the failure is noted in the cache), and we try</p>
631
+    <code><![CDATA[http://www.shakespeare.com/market/_vpi.xml]]></code>
632
+    <p>The request fails again (the failure is noted in the cache). We try</p>
633
+    <code><![CDATA[http://www.shakespeare.com/_vpi.xml]]></code>
634
+    <p>
635
+      We do not find it (the failure is noted in the cache), and we revert to
636
+      the global file (which one depends on the client configuration)
637
+    </p>
638
+    <code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml]]></code>
639
+    <p>The request returns (and the data is stored in the cache):</p>
640
+    <code><![CDATA[
652 641
 <?xml version='1.0' ?>
653 642
 <vpi xmlns='http://schema.bluehands.de/virtual-presence-info'>
654 643
 
@@ -670,20 +659,25 @@ http://www.shakespeare.com/_vpi.xml]]>
670 659
       <digest/>
671 660
   </location>
672 661
 </vpi>]]></code>
673
-
674
-      We try to find a &lt;location/&gt; that matches our URL. We find:
675
-      <code><![CDATA[
662
+    <p>We try to find a &lt;location/&gt; that matches our URL. We find:</p>
663
+    <code><![CDATA[
676 664
 <location match='^http://.*\.com/.*'>
677 665
   <delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
678 666
 </location>]]></code>
679 667
 
680
-      This means that all .com domains are forwarded to a separate VPI file. 
668
+    <p>
669
+      This means that all .com domains are forwarded to a separate VPI file.
681 670
       We fetch:
682
-      <code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml]]></code>
683
-
684
-      We store the result in the cache and search for a matching &lt;location/&gt;
685
-      again. We find the default section (rest of the file omitted, the match-attribute is more general than the one of the previous &lt;delegate/&gt;, because here we are already in the .com domain):
686
-      <code><![CDATA[
671
+    </p>
672
+    <code><![CDATA[http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml]]></code>
673
+    <p>
674
+      We store the result in the cache and search for a matching
675
+      &lt;location/&gt; again.
676
+      We find the default section (rest of the file omitted, the match-attribute
677
+      is more general than the one of the previous &lt;delegate/&gt;, because
678
+      here we are already in the .com domain):
679
+    </p>
680
+    <code><![CDATA[
687 681
 ...
688 682
 <location match='^http://([^/]+)($|/.*$)'>
689 683
   <service>xmpp:location.virtual-presence.org</service>
@@ -693,90 +687,88 @@ http://www.shakespeare.com/_vpi.xml]]>
693 687
 </location>
694 688
 ...]]></code>
695 689
 
696
-      The &lt;location/&gt; matches, so we get a virtual presence 
697
-      service address and a set of rules. 
698
-      The virtual presence server is 
699
-        <code><![CDATA[location.virtual-presence.org]]></code>
700
-
701
-      The protocol to use is 
702
-        <code><![CDATA[xmpp]]></code>
703
-
704
-      There mapping rule is:
705
-      <code><![CDATA[
690
+    <p>
691
+      The &lt;location/&gt; matches, so we get a virtual presence service
692
+      address and a set of rules.
693
+      The virtual presence server is
694
+    </p>
695
+    <code><![CDATA[location.virtual-presence.org]]></code>
696
+    <p>The protocol to use is</p>
697
+    <code><![CDATA[xmpp]]></code>
698
+    <p>There mapping rule is:</p>
699
+    <code><![CDATA[
706 700
   match='^http://([^/]+)($|/.*$)'
707 701
   <name>\1</name>
708 702
   <digest/>]]></code>
709
-
710
-      The result of the first phase is a mapping rule, which will be 
711
-      applied to all URLs <em>in the same folder</em> as the original URL. In regex-speech:
712
-      <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/.*]]></code>
713
-
714
-      To apply the mask only to URLs in the same URL-path folder is a security 
715
-      requirement, so that &apos;inner&apos; VPI files 
716
-      from websites can not configure the mapping of &apos;outer&apos; folders or &apos;siblings&apos;.
717
-  </p>
718
-  <p>
719
-      The original URL was:
720
-      <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
721
-
722
-      So, the security mask is (the rule applies only to URLs in the same folder as the original URL):
723
-      <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code> 
724
-      If the security mask applies to a URL can be verified by a simple string-compare without using a regular expression.
725
-  </p>
726
-  <p>
727
-      The &lt;location/&gt; has a match attribute. This is the user supplied mask 
728
-      of the rule:
729
-      <code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
730
-  </p>
703
+    <p>
704
+      The result of the first phase is a mapping rule, which will be applied to
705
+      all URLs <em>in the same folder</em> as the original URL.
706
+      In regex-speech:
707
+    </p>
708
+    <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/.*]]></code>
709
+    <p>
710
+      To apply the mask only to URLs in the same URL-path folder is a security
711
+      requirement, so that &apos;inner&apos; VPI files from websites can not
712
+      configure the mapping of &apos;outer&apos; folders or
713
+      &apos;siblings&apos;.
714
+    </p>
715
+    <p>The original URL was:</p>
716
+    <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
717
+    <p>
718
+      So, the security mask is (the rule applies only to URLs in the same folder
719
+      as the original URL):
720
+    </p>
721
+    <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code> 
722
+    <p>
723
+      If the security mask applies to a URL can be verified by a simple
724
+      string-compare without using a regular expression.
725
+    </p>
726
+    <p>
727
+      The &lt;location/&gt; has a match attribute.
728
+      This is the user supplied mask of the rule:
729
+    </p>
730
+    <code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
731 731
 
732 732
   </section3>
733 733
 
734 734
   <section3 topic='Apply the Rule'>
735
-
736
-  <p>
737
-  
738
-    The URL where we want to meet people is:
739
-        <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
740
-
741
-    We got many rules with a security mask (from the folder of the original URL) and a regular expression 
742
-    (from the match-attribute). For each new URl we check the URL against the security mask and the regular expression.
743
-    One of the rules applies to the URL:
744
-        <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*
735
+    <p>The URL where we want to meet people is:</p>
736
+    <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
737
+    <p>
738
+      We got many rules with a security mask (from the folder of the original
739
+      URL) and a regular expression (from the match-attribute).
740
+      For each new URl we check the URL against the security mask and the
741
+      regular expression.
742
+      One of the rules applies to the URL:
743
+    </p>
744
+    <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*
745 745
 ^http://([^/]+)($|/.*$)]]></code>
746
-
747
-    The regular expression
748
-        <code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
749
-    
750
-    and the room &lt;name&gt;
746
+    <p>The regular expression</p>
747
+    <code><![CDATA[^http://([^/]+)($|/.*$)]]></code>
748
+    <p>and the room &lt;name&gt;</p>
751 749
     <code><![CDATA[\1-room]]></code>
752
-
753
-    will extract the first level folder from the URL. The URL
750
+    <p>will extract the first level folder from the URL. The URL</p>
754 751
     <code><![CDATA[http://www.shakespeare.com/market/ModernLibrary/index.html]]></code>
755
-
756
-    gives:
752
+    <p>gives:</p>
757 753
     <code><![CDATA[market-room]]></code>
758
-
759
-    The &lt;digest/&gt;-tag tells us to hash the regex replacement result with 
760
-    the default message digest SHA1. So we get:
754
+    <p>
755
+      The &lt;digest/&gt;-tag tells us to hash the regex replacement result with
756
+      the default message digest SHA1. So we get:
757
+    </p>
761 758
     <code><![CDATA[87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
762
-
763
-    The &lt;prefix/&gt;-tag tells us to prefix with 
759
+    <p>The &lt;prefix/&gt;-tag tells us to prefix with</p>
764 760
     <code><![CDATA[vp-]]></code>
765
-
766
-    and finally the ID of the virtual location (the room name) is:
761
+    <p>and finally the ID of the virtual location (the room name) is:</p>
767 762
     <code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3]]></code>
768
-
769
-    From the &lt;service/&gt;
763
+    <p>From the &lt;service/&gt;</p>
770 764
     <code><![CDATA[xmpp:location.virtual-presence.org]]></code>
771
-
772
-    the client knows the transport protocol and the address. The Jabber protocol will 
773
-    be used as transport protocol and the Jabber conference room JID is
765
+    <p>
766
+      the client knows the transport protocol and the address. The Jabber
767
+      protocol will be used as transport protocol and the Jabber conference room
768
+      JID is
769
+    </p>
774 770
     <code><![CDATA[vp-87d0c3e8d08f344375f22014c7cafe6527acbae3@location.virtual-presence.org]]></code>
775
-
776
-  </p>
777
-
778 771
   </section3>
779
-  
780 772
   </section2>
781 773
 
782 774
 </section1>
@@ -791,19 +783,21 @@ http://www.shakespeare.com/_vpi.xml]]>
791 783
 </section1>
792 784
 
793 785
 <section1 topic='XMPP Registrar Considerations'>
794
-  <p>These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document. 
795
-      <ul>
796
-        <li>firebat:user:jid</li>
797
-        <li>firebat:avatar:position</li>
798
-        <li>firebat:avatar:getpos</li>
799
-        <li>firebat:chat:state</li>
800
-        <li>firebat:icon:video</li>
801
-        <li>firebat:avatar:digest</li>
802
-        <li>firebat:avatar2:digest</li>
803
-        <li>storage:client:avatar</li>
804
-        <li>storage:client:avatar2</li>
805
-      </ul>
786
+  <p>
787
+    These namespaces need to be reviewed and/or registered with the XMPP
788
+    Registrar as a result of this document:
806 789
   </p>
790
+  <ul>
791
+    <li>firebat:user:jid</li>
792
+    <li>firebat:avatar:position</li>
793
+    <li>firebat:avatar:getpos</li>
794
+    <li>firebat:chat:state</li>
795
+    <li>firebat:icon:video</li>
796
+    <li>firebat:avatar:digest</li>
797
+    <li>firebat:avatar2:digest</li>
798
+    <li>storage:client:avatar</li>
799
+    <li>storage:client:avatar2</li>
800
+  </ul>
807 801
 </section1>
808 802
 
809 803
 <section1 topic='Formal Definition'>
@@ -815,14 +809,20 @@ http://www.shakespeare.com/_vpi.xml]]>
815 809
 <section1 topic='Conclusion'>
816 810
   <p>The virtual presence on Jabber has been designed to fit easily into the existing Jabber infrastructure including existing software components, clients, and protocols. It turns out that Jabber offers everything necessary for basic virtual presence. </p>
817 811
 
818
-  <p>This document proposes a mapping process in order to create a space for virtual presence on top of the URL based Web infrastructure. It also proposes namespace extensions for the protocol, which make virtual presence on web pages more convenient. The core features are: 
819
-    <ul>
820
-      <li>URL mapping and service discovery,</li>
821
-      <li>avatars standing and walking on a web page,</li>
822
-      <li>bubble chat,</li>
823
-      <li>iconic video.</li>
824
-    </ul>
825
-    There are definitely more features possible. Suggestions are welcome</p>
812
+  <p>
813
+    This document proposes a mapping process in order to create a space for
814
+    virtual presence on top of the URL based Web infrastructure.
815
+    It also proposes namespace extensions for the protocol, which make virtual
816
+    presence on web pages more convenient.
817
+    The core features are:
818
+  </p>
819
+  <ul>
820
+    <li>URL mapping and service discovery,</li>
821
+    <li>avatars standing and walking on a web page,</li>
822
+    <li>bubble chat,</li>
823
+    <li>iconic video.</li>
824
+  </ul>
825
+  <p>There are definitely more features possible. Suggestions are welcome</p>
826 826
 </section1>
827 827
 
828 828
 </xep>

+ 1
- 1
xep-0152.xml View File

@@ -254,7 +254,7 @@
254 254
 
255 255
 <section1 topic='Security Considerations' anchor='security'>
256 256
   <p>Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.</p>
257
-  <t>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</t>
257
+  <p>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</p>
258 258
 </section1>
259 259
 
260 260
 <section1 topic='IANA Considerations' anchor='iana'>

+ 6
- 6
xep-0157.xml View File

@@ -21,18 +21,18 @@
21 21
   <supersededby/>
22 22
   <shortname>N/A</shortname>
23 23
   &stpeter;
24
-  <revision>
25
-    <version>1.0</version>
26
-    <date>2007-01-31</date>
27
-    <initials>psa</initials>
28
-    <remark><p>Per a vote of the XMPP Council, advanced specification to Active.</p></remark>
29
-  </revision>
30 24
   <author>
31 25
     <firstname>Jacek</firstname>
32 26
     <surname>Konieczny</surname>
33 27
     <email>jajcus@jajcus.net</email>
34 28
     <jid>jajcus@jabber.bnet.pl</jid>
35 29
   </author>
30
+  <revision>
31
+    <version>1.0</version>
32
+    <date>2007-01-31</date>
33
+    <initials>psa</initials>
34
+    <remark><p>Per a vote of the XMPP Council, advanced specification to Active.</p></remark>
35
+  </revision>
36 36
   <revision>
37 37
     <version>0.6</version>
38 38
     <date>2007-01-25</date>

+ 2
- 2
xep-0162.xml View File

@@ -12,17 +12,17 @@
12 12
   <number>0162</number>
13 13
   <status>Deferred</status>
14 14
   <type>Informational</type>
15
+  <sig>Standards</sig>
15 16
   <dependencies/>
16 17
   <supersedes/>
17 18
   <supersededby/>
18
-  <sig>Standards</sig>
19
+  <shortname>N/A</shortname>
19 20
   <author>
20 21
     <firstname>Lucas</firstname>
21 22
     <surname>Nussbaum</surname>
22 23
     <email>lucas@lucas-nussbaum.net</email>
23 24
     <jid>lucas@nussbaum.fr</jid>
24 25
   </author>
25
-  <shortname>N/A</shortname>
26 26
   <revision>
27 27
     <version>0.2</version>
28 28
     <date>2005-12-06</date>

+ 42
- 43
xep-0171.xml View File

@@ -177,10 +177,10 @@
177 177
     <translation destination_lang='fr' source_lang='en'/>
178 178
   </x>
179 179
 </message>
180
-      ]]></example>
180
+]]></example>
181 181
     </section3>
182 182
     <section3 topic='Translation With Pivot' anchor='message-pivot'>
183
-      <p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no <x/> translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.</p>
183
+      <p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no &lt;x/&gt; translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.</p>
184 184
       <example caption='Entity sends a message translated from French to Russian via English using human translators'><![CDATA[
185 185
 <message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
186 186
   <subject xml:lang='fr'>Bonjour</subject>
@@ -194,7 +194,7 @@
194 194
     <translation destination_lang='ru' source_lang='en'/>
195 195
   </x>
196 196
 </message>
197
-      ]]></example>
197
+]]></example>
198 198
     </section3>
199 199
     <section3 topic='Translation With Pivot Specifying Details' anchor='message-pivot-details'>
200 200
       <p>A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity using pivot languages and machine translation. The source language is known because there is no &X; translation tag describing it.</p>
@@ -212,7 +212,7 @@
212 212
     <translation destination_lang='ru' engine='SYSTRANS' source_lang='en'/>
213 213
   </x>
214 214
 </message>
215
-      ]]></example>
215
+]]></example>
216 216
     </section3>
217 217
   </section2>
218 218
   <section2 topic='Discovering Translation Providers' anchor='disco'>
@@ -222,7 +222,7 @@
222 222
 <iq type='get' id='disco1' to='shakespeare.lit'>
223 223
   <query xmlns='http://jabber.org/protocol/disco#items'/>
224 224
 </iq>
225
-      ]]></example>
225
+]]></example>
226 226
       <example caption='Server returns items, including translation providers'><![CDATA[
227 227
 <iq type='result' id='disco1' from='shakespeare.lit' to='bard@shakespeare.lit/globe'>
228 228
   <query xmlns='http://jabber.org/protocol/disco#items'>
@@ -234,7 +234,7 @@
234 234
     ...
235 235
   </query>
236 236
 </iq>
237
-      ]]></example>
237
+]]></example>
238 238
     </section3>
239 239
     <section3 topic='Discovering Identity of Providers' anchor='disco-identity'>
240 240
       <p>Service Discovery is used to determine if a JID provides translation services. The JID can also be a bot (e.g., &lt;towerofbabel@shakespeare.lit&gt;) or a server component (e.g., &lt;translation.shakespeare.lit&gt;).</p>
@@ -242,7 +242,7 @@
242 242
 <iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
243 243
   <query xmlns='http://jabber.org/protocol/disco#info'/>
244 244
 </iq>
245
-      ]]></example>
245
+]]></example>
246 246
       <example caption='Service reports identity'><![CDATA[
247 247
 <iq type='result' to='bard@shakespeare.lit/globe' from='translation.shakespeare.lit'>
248 248
   <query xmlns='http://jabber.org/protocol/disco#info'>
@@ -252,7 +252,7 @@
252 252
     ...
253 253
   </query>
254 254
 </iq>
255
-      ]]></example>
255
+]]></example>
256 256
     </section3>
257 257
     <section3 topic='Discovering Language Support' anchor='disco-lang'>
258 258
       <p>The supported languages and other details for the service must be known to use it. It is permissible for a translation service to provide multiple translation engines for the same language pairing -- if this is done, then a separate &lt;item/&gt; tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific &lt;item/&gt;. In order to specify more than one dictionary for a given language pairing then a separate &lt;item/&gt; tag MUST be used for each dictionary specification for that language pairing.</p>
@@ -260,27 +260,27 @@
260 260
 <iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
261 261
   <query xmlns='urn:xmpp:langtrans:items'/>
262 262
 </iq>
263
-      ]]></example>
263
+]]></example>
264 264
       <example caption='Service replies with language details'><![CDATA[
265 265
 <iq type='result' to='bard@shakespeare.lit/globe' from=' translation.shakespeare.lit'>
266 266
   <query xmlns='urn:xmpp:langtrans:items'>
267
-    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='fr' 
267
+    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='fr'
268 268
           engine='SYSTRANS 2005 Release 2' pivotable='true'/>
269
-    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ko' 
269
+    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ko'
270 270
           engine='SYSTRANS 2005 Release 2' pivotable='true'/>
271
-    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' 
271
+    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru'
272 272
           engine='SYSTRANS 2005 Release 2' pivotable='true'/>
273
-    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' 
273
+    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru'
274 274
           engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='medical'/>
275
-    <item source_lang='fr' jid='translation.shakespeare.lit' destination_lang='en' 
275
+    <item source_lang='fr' jid='translation.shakespeare.lit' destination_lang='en'
276 276
           engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='standard'/>
277
-    <item source_lang='ru' jid='translation.shakespeare.lit' destination_lang='en' 
277
+    <item source_lang='ru' jid='translation.shakespeare.lit' destination_lang='en'
278 278
           engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='Medical 1.0'/>
279
-    <item source_lang='ko' jid='translation.shakespeare.lit' destination_lang='en' 
279
+    <item source_lang='ko' jid='translation.shakespeare.lit' destination_lang='en'
280 280
           engine='SYSTRANS 2005 Release 2' pivotable='true'/>
281 281
   </query>
282 282
 </iq>
283
-      ]]></example>
283
+]]></example>
284 284
     </section3>
285 285
   </section2>
286 286
   <section2 topic='Requesting a Translation from a Service' anchor='request'>
@@ -293,8 +293,7 @@
293 293
     <translation destination_lang='fr'/>
294 294
   </x>
295 295
 </iq>
296
-      ]]></example>
297
-      
296
+]]></example>
298 297
       <example caption='Translation is returned from translation provider'><![CDATA[
299 298
 <iq type='result' id='translationReq_2' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
300 299
   <x xmlns='urn:xmpp:langtrans'>
@@ -302,7 +301,7 @@
302 301
     <translation destination_lang='fr' source_lang='en' engine='default'>comment allez-vous?</translation>
303 302
   </x>
304 303
 </iq>
305
-      ]]></example>
304
+]]></example>
306 305
     </section3>
307 306
     <section3 topic='Requesting a Translation With Multiple Destination Languages' anchor='request-multiple'>
308 307
       <example caption='bard requests a translation from English to Italian and German'><![CDATA[
@@ -312,8 +311,8 @@
312 311
     <translation destination_lang='it'/>
313 312
     <translation destination_lang='de'/>
314 313
   </x>
315
-</iq> 
316
-      ]]></example>
314
+</iq>
315
+]]></example>
317 316
       <example caption='Translation is returned from translation provider'><![CDATA[
318 317
 <iq type='result' id='translationReq_4' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
319 318
   <x xmlns='urn:xmpp:langtrans'>
@@ -322,7 +321,7 @@
322 321
     <translation destination_lang='de' source_lang='en' engine='default'>Wie geht es Ihnen?</translation>
323 322
   </x>
324 323
 </iq>
325
-      ]]></example>
324
+]]></example>
326 325
     </section3>
327 326
     <section3 topic='Requesting a Translation With a Specific Dictionary' anchor='request-dictionary'>
328 327
       <p>If a specific dictionary is required you MAY request a dictionary. This SHOULD have been returned when discoing the server although a dictionary MAY be requested which was not. The dictionaries are translation engine specific and are free form text.</p>
@@ -333,20 +332,20 @@
333 332
     <translation destination_lang='fr' dictionary='medical'/>
334 333
   </x>
335 334
 </iq>
336
-      ]]></example>
335
+]]></example>
337 336
       <example caption='Translation provider returns translation with dictionary details'><![CDATA[
338 337
 <iq type='result' id='translationReq_6' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
339 338
   <x xmlns='urn:xmpp:langtrans'>
340 339
     <source xml:lang='en'>hello, how are you?</source>
341
-    <translation 
342
-        destination_lang='fr' 
343
-        dictionary='medical' 
340
+    <translation
341
+        destination_lang='fr'
342
+        dictionary='medical'
344 343
         engine='default'
345 344
         source_lang='en'>comment allez-vous?</translation>
346 345
   </x>
347 346
 </iq>
348
-      ]]></example>
349
-      <p>If the translation service cannot complete the translation it SHOULD return a <item-not-found/> error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.</p>
347
+]]></example>
348
+      <p>If the translation service cannot complete the translation it SHOULD return a &lt;item-not-found/&gt; error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.</p>
350 349
       <example caption='Translation could not be completed'><![CDATA[
351 350
 <iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
352 351
   <x xmlns='urn:xmpp:langtrans'>
@@ -357,8 +356,8 @@
357 356
     <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
358 357
   </error>
359 358
 </iq>
360
-      ]]></example>
361
-      <p>If privacy or security considerations make returning an <item-not-found/> error not feasible it SHOULD return a <service-unavailable/> error.</p>
359
+]]></example>
360
+      <p>If privacy or security considerations make returning an &lt;item-not-found/&gt; error not feasible it SHOULD return a &lt;service-unavailable/&gt; error.</p>
362 361
       <example caption='Service unavailable'><![CDATA[
363 362
 <iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
364 363
   <x xmlns='urn:xmpp:langtrans'>
@@ -369,7 +368,7 @@
369 368
     <service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
370 369
   </error>
371 370
 </iq>
372
-      ]]></example>
371
+]]></example>
373 372
     </section3>
374 373
   </section2>
375 374
 </section1>
@@ -408,11 +407,11 @@
408 407
     <code><![CDATA[
409 408
 <?xml version='1.0' encoding='UTF-8'?>
410 409
 <xs:schema
411
-    xmlns='urn:xmpp:langtrans' 
412
-    xmlns:xs='http://www.w3.org/2001/XMLSchema' 
413
-    targetNamespace='urn:xmpp:langtrans' 
410
+    xmlns='urn:xmpp:langtrans'
411
+    xmlns:xs='http://www.w3.org/2001/XMLSchema'
412
+    targetNamespace='urn:xmpp:langtrans'
414 413
     elementFormDefault='qualified'>
415
-    
414
+
416 415
   <xs:annotation>
417 416
     <xs:documentation>
418 417
       The protocol documented by this schema is defined in
@@ -453,7 +452,7 @@
453 452
       </xs:simpleContent>
454 453
     </xs:complexType>
455 454
   </xs:element>
456
-        
455
+
457 456
   <xs:simpleType name='empty'>
458 457
     <xs:restriction base='xs:string'>
459 458
       <xs:enumeration value=''/>
@@ -461,15 +460,15 @@
461 460
   </xs:simpleType>
462 461
 
463 462
 </xs:schema>
464
-    ]]></code>
463
+]]></code>
465 464
   </section2>
466 465
   <section2 topic='langtrans:items' anchor='schema-langtrans-items'>
467 466
     <code><![CDATA[
468 467
 <?xml version='1.0' encoding='UTF-8'?>
469 468
 <xs:schema
470
-    xmlns='urn:xmpp:langtrans:items' 
471
-    xmlns:xs='http://www.w3.org/2001/XMLSchema' 
472
-    targetNamespace='urn:xmpp:langtrans:items' 
469
+    xmlns='urn:xmpp:langtrans:items'
470
+    xmlns:xs='http://www.w3.org/2001/XMLSchema'
471
+    targetNamespace='urn:xmpp:langtrans:items'
473 472
     elementFormDefault='qualified'>
474 473
 
475 474
   <xs:annotation>
@@ -502,7 +501,7 @@
502 501
       </xs:simpleContent>
503 502
     </xs:complexType>
504 503
   </xs:element>
505
-        
504
+
506 505
   <xs:simpleType name='empty'>
507 506
     <xs:restriction base='xs:string'>
508 507
       <xs:enumeration value=''/>
@@ -510,7 +509,7 @@
510 509
   </xs:simpleType>
511 510
 
512 511
 </xs:schema>
513
-    ]]></code>
512
+]]></code>
514 513
   </section2>
515 514
 </section1>
516 515
 </xep>

+ 1
- 0
xep-0179.xml View File

@@ -8,6 +8,7 @@
8 8
 <header>
9 9
   <title>Jingle IAX Transport Method</title>
10 10
   <abstract>This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication.</abstract>
11
+  &LEGALNOTICE;
11 12
   <number>0179</number>
12 13
   <status>Deferred</status>
13 14
   <type>Standards Track</type>

+ 12
- 1
xep-0180.xml View File

@@ -7,7 +7,18 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Jingle Video via RTP</title>
10
-  <abstract>This specification defines a Jingle application type for negotiating a video chat or other video session. The application type uses the Real-time Transport Protocol (RTP) for the underlying media exchange and provides a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints. <em>Note: This specification has been retracted in favor of XEP-0167, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification; please refer to XEP-0167 for the most up-to-date definition of XMPP video chat.</em></abstract>
10
+  <abstract>
11
+    Note: This specification has been retracted in favor of XEP-0167, which now
12
+    consolidates both audio and video chat via RTP and therefore contains the
13
+    content originally published in this specification; please refer to XEP-0167
14
+    for the most up-to-date definition of XMPP video chat.
15
+
16
+    This specification defines a Jingle application type for negotiating a video
17
+    chat or other video session.
18
+    The application type uses the Real-time Transport Protocol (RTP) for the
19
+    underlying media exchange and provides a straightforward mapping to Session
20
+    Description Protocol (SDP) for interworking with SIP media endpoints.
21
+  </abstract>
11 22
   &LEGALNOTICE;
12 23
   <number>0180</number>
13 24
   <status>Retracted</status>

+ 3
- 3
xep-0185.xml View File

@@ -35,22 +35,22 @@
35 35
   </revision>
36 36
   <revision>
37 37
     <version>0.4</version>
38
-    <initials>psa/ph</initials>
39 38
     <date>2007-02-09</date>
39
+    <initials>psa/ph</initials>
40 40
     <remark><p>Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.</p>
41 41
     </remark>
42 42
   </revision>
43 43
   <revision>
44 44
     <version>0.3</version>
45
-    <initials>ph</initials>
46 45
     <date>2006-11-01</date>
46
+    <initials>ph</initials>
47 47
     <remark><p>Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match revisions to RFC 3920.</p>
48 48
     </remark>
49 49
   </revision>
50 50
   <revision>
51 51
     <version>0.2</version>
52
-    <initials>ph</initials>
53 52
     <date>2006-05-10</date>
53
+    <initials>ph</initials>
54 54
     <remark>
55 55
       <p>Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.</p>
56 56
     </remark>

+ 1
- 1
xep.dtd View File

@@ -128,7 +128,7 @@ THE SOFTWARE.
128 128
 <!ELEMENT acronym (#PCDATA)* >
129 129
 <!ELEMENT example (#PCDATA)* >
130 130
 <!ATTLIST example caption CDATA '' >
131
-<!ELEMENT code (#PCDATA | span | em)* >
131
+<!ELEMENT code (#PCDATA | span | em | strong)* >
132 132
 <!ATTLIST code caption CDATA '' >
133 133
 <!ELEMENT table (tr)* >
134 134
 <!ATTLIST table caption CDATA '' >

Loading…
Cancel
Save