XEP-0290/0274 misc updates

also update xep.ent with updated title of XEP-0285.

xep-0274.xml

@@ -1,6 +1,7 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
   <!ENTITY % ents SYSTEM 'xep.ent'>
+  %ents;
   <!ENTITY SIGNATURE "&lt;Signature/&gt;">
   <!ENTITY REFERENCE "&lt;Reference/&gt;">
   <!ENTITY SIGNEDINFO "&lt;SignedInfo/&gt;">
@@ -14,7 +15,6 @@
   <!ENTITY CDCIE-CCP "<span class='ref'>CDCIE-CCP</span> <note>Cross Domain Collaborative Information Environment (CDCIE) Chat Client Protocol Specification, Version 2.0, Trident Systems, Inc., 12 March 2008</note>" >
   <!ENTITY XMLDSIG "<span class='ref'><link url='http://www.w3.org/TR/xmldsig-core/'>XMLDSIG</link></span> <note>XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 &lt;<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>&gt;.</note>" >
   <!ENTITY XPointer "<span class='ref'><link url='http://www.w3.org/TR/xptr'>XPointer</link></span> <note>XML Pointer Language (XPointer), W3C Recommendation, 8 June 2001 &lt;<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>&gt;.</note>" >
-  <!ENTITY xmpp-dsig-new "<span class='ref'><link url='http://xmpp.org/extensions/inbox/encapsulated-signatures.html'>XMPP DSIG</link></span> <note>Encapsulated Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/inbox/encapsulated-signatures.html'>http://xmpp.org/extensions/inbox/encapsulated-signatures.html</link>&gt;.</note>" >%ents;
 ]>
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
@@ -35,13 +35,21 @@
     <supersededby/>
     <shortname>N/A</shortname>
     &kdz;
+    <revision>
+      <version>0.4</version>
+      <date>2011-01-28</date>
+      <initials>kdz</initials>
+      <remark>
+        <p>Update/fix references.</p>
+      </remark>
+    </revision>
     <revision>
       <version>0.3</version>
       <date>2011-01-12</date>
       <initials>kdz</initials>
       <remark>
-        <p>Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP,
+        <p>Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, an
-	    an alternative to XEP-0285.</p>
+          alternative to XEP-0285.</p>
       </remark>
     </revision>
     <revision>
@@ -254,10 +262,18 @@
     </section2>
     <section2 topic="PGP signatures in XMPP" anchor="xmpp-e2e">
       <p>The &xep0027; (XMPP PGP), like the XMPP E2E, uses an encapsulating signature to protects
-        the signed content from alteration as it is exchanged over an XMPP network.  Like
+        the signed content from alteration as it is exchanged over an XMPP network. Like XMPP E2E,
-	XMPP E2E, it is intended to be an end-to-end solution.</p>
+        it is intended to be an end-to-end solution.</p>
       <p>At the time of this writing, XMPP PGP has not been widely implemented (though some
-        implementations do exist).  XMPP PGP appears to have limited applicability.</p>
+        implementations do exist). XMPP PGP appears to have limited applicability.</p>
+    </section2>
+    <section2 topic="Encapsulating Digital Signatures in XMPP" anchor="xmpp-e2e">
+      <p>The &xep0285; (XMPP EgDSIG), like the XMPP E2E and XMPP PGP, uses an encapsulating
+        signature to protects the signed content from alteration as it is exchanged over an XMPP
+        network.</p>
+      <p>Unlike XMPP E2E and XMPP PGP, the solution is not intended to be strictly end-to-end in
+        that multiple signers and verifiers where contemplated, now of which is necessarily an end
+        entity. However, like XMPP E2E, it does not supported <em>optimistic signing</em>.</p>
     </section2>
     <section2 topic="CDCIE-CCP" anchor="cdcie-ccp">
       <p>Alternative approaches have been developed. For instance, the Cross Domain Collaborative
@@ -273,11 +289,11 @@
         to have applicability limited to the CDCIE.</p>
     </section2>
     <section2 topic="Encapsulated Digitial Signatures in XMPP" anchor="xmpp-ed-dsig">
-      <p>The &xmpp-dsig-new; (XMPP DSIG) is an encapsulated signature proposal similar to
+      <p>The &xep0290; (XMPP DSIG) is an encapsulated signature proposal similar to that
-		that encapsulated approach suggested below.</p>
+        signed manifest approach suggested below. This approach is intended to support a wide range of
-	  <p>Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the
+        uses and applications including <em>optimistic signing</em> in general communciations.</p>
-		whole stanza but signatures over a manifest and descriptive objects detailing the stanza
+      <p>Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the
-	    contents.</p>
+        whole stanza but signatures over an object which details the stanza contents.</p>
     </section2>
   </section1>
 
@@ -285,9 +301,8 @@
     <section2 topic="Encapsulated v. Encapsulating Signatures" anchor="encap">
       <p>An encapsulating signature is a signature approach that encapsulates the signed content
         within the signature syntax. An encapsulated signature is a signature approach where the
-        signature syntax in encapsulated within the structure of the signed content. XMPP E2E
+        signature syntax in encapsulated within the structure of the signed content. XMPP E2E and
-	and XMPP PGP are examples of the former.  CDCIE-CCP and XMPP DSIG are examples
+        XMPP PGP are examples of the former. CDCIE-CCP and XMPP DSIG are examples of the latter.</p>
-        of the latter.</p>
 
       <p>The following example illustrates, using pseudo language, an encapsulating signature over a
         &MESSAGE; stanza.</p>
@@ -326,13 +341,13 @@
           </encapsulated-signature>
         </message>
         ]]></example>
-      <p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E
+      <p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and
-        and XMPP PGP, are generally limited to end-to-end use cases. That is, cases where the
+        XMPP PGP, are generally limited to end-to-end use cases. That is, cases where the originator
-        originator of a stanza signs the stanza and send it through the XMPP network to its intended
+        of a stanza signs the stanza and send it through the XMPP network to its intended recipient,
-        recipient, and only the intended recipient is expected to make use of the signed content.
+        and only the intended recipient is expected to make use of the signed content. Entities
-        Entities between the signer and the intended recipient are expected to forward of the stanza
+        between the signer and the intended recipient are expected to forward of the stanza without
-        without regard to the encapsulating signature, and without themselves signing the stanza.
+        regard to the encapsulating signature, and without themselves signing the stanza. The
-        The approach does not require forwarding entities to support the signing extension.</p>
+        approach does not require forwarding entities to support the signing extension.</p>
       <p>Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For
         instance, an occupant can sign its submissions to the service for the benefit of the service
         and the service can sign reflected stanzas to occupants. In providing non-anonymous chat
@@ -523,26 +538,26 @@
     <section2 topic="Optimistic Signing" anchor="optimistic">
       <p>Some users design the ability to <em>optimistic signing</em> of stanzas. That is, to sign
         all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key
-        aspect of optimistic signing is that receiving entities not supporting the signing
+        aspect of optimistic signing is that receiving entities not supporting the signing extension
-        extension should be able to make use the message content (excluding the signature
+        should be able to make use the message content (excluding the signature information) while
-        information) while those receiving entities supporting the extension can make use of the
+        those receiving entities supporting the extension can make use of the message content and
-        message content and the signature information.</p>
+        the signature information.</p>
       <p>Optimistic signing is available in E-mail through the use of S/MIME detached signatures.
         Use of S/MIME detached signatures can be problematic. Mail systems, especially restribution
         services such as mailing lists, are notorious for changing the signed content and hence
         breaking the signature.</p>
       <p>In XMPP, as stanzas are generally altered in transit and hence optimistic signing will be
         fragile at best. Through use of selective signing and manifesting, issues may be mitigated
-        to some degree.  It is doubtful that a solution exists that provides optimistic signing and
+        to some degree. It is doubtful that a solution exists that provides optimistic signing and
         reliability verification.</p>
       <section3 topic="Dual content" anchor="dual">
-        <p>One possible optimistic signing solution is for stanzas to carry <em>alternative</em> sets of
+        <p>One possible optimistic signing solution is for stanzas to carry <em>alternative</em>
-          content, an unsigned content alternative and a signed content alternative. The premise of
+          sets of content, an unsigned content alternative and a signed content alternative. The
-          this approach is that an entity supporting the signing extension could make use of the
+          premise of this approach is that an entity supporting the signing extension could make use
-          signed content alternative while an entity not supporting the signing extension could make
+          of the signed content alternative while an entity not supporting the signing extension
-          use of the unsigned content alternative. The approach has been suggested to as a mechanism
+          could make use of the unsigned content alternative. The approach has been suggested to as
-          for support extension-unaware entities downstream of extension-unware groupchat (or like)
+          a mechanism for support extension-unaware entities downstream of extension-unware
-          services use of the stanza content.</p>
+          groupchat (or like) services use of the stanza content.</p>
         <p>The following example not only illustrate this approach, but highlights some of the
           issues with this approach:</p>
         <example caption="Dual content message"><![CDATA[

xep-0290.xml

@@ -24,10 +24,20 @@
         <shortname>N/A</shortname>
         &kdz;
         <revision>
-          <version>0.1</version>
+            <version>0.2</version>
-          <date>2011-01-26</date>
+            <date>2011-01-28</date>
-          <initials>psa</initials>
+            <initials>kdz</initials>
-          <remark><p>Initial published version.</p></remark>
+            <remark>
+                <p>Merge manifest and schema-desc objects.</p>
+            </remark>
+        </revision>
+        <revision>
+            <version>0.1</version>
+            <date>2011-01-26</date>
+            <initials>psa</initials>
+            <remark>
+                <p>Initial published version.</p>
+            </remark>
         </revision>
         <revision>
             <version>0.0.1</version>
@@ -40,25 +50,30 @@
     </header>
 
     <section1 topic="Introduction" anchor="intro">
+        <p class="box"><em>This document is one of two proposals for digital signatures in XMPP. It
+                is expected that only one of these proposals be progressed beyond Experimental on
+                the Standards Track.</em></p>
+
         <p>This document provides a technical specification for Encapsulated Digital Signatures in
             Extensible Messaging and Presence Protocol (&xmpp;).</p>
         <p>XMPP Digital Signatures may be used to provide signer authentication, data integrity,
-	   non-repudiation, and other security services.</p>
+            non-repudiation, and other security services.</p>
-	<p>This extension is intended to be highly flexible, supporting a wide range of applications.
+        <p>This extension is intended to be highly flexible, supporting a wide range of
-	   The extension not only supports signing by the originator, but by other entities which
+            applications. The extension not only supports signing by the originator, but by other
-	   handle XMPP stanzas.  Multiple entities may independently sign a stanza.</p>
+            entities which handle XMPP stanzas. Multiple entities may independently sign a
-	<p>A signed manifest approach is used to allow selective signing (only select elements
+            stanza.</p>
-	   may be included in the manifest) and to allow flexibility in handling verification
+        <p>A signed manifest approach is used to allow selective signing (only select elements may
-	   errors.</p>
+            be included in the manifest) and to allow flexibility in handling verification
-	<p>This extension is intended to support <em>optimistic signing</em>.</p>
+            errors.</p>
+        <p>This extension is intended to support <em>optimistic signing</em>.</p>
         <p>This document offers an encapsulated signature approach based upon &w3xmlsig; (XMLDSIG).
             Implementations of this extension not required to fully implement the XML DSIG
             specification, they may implement only the minimal subset necessary to support this
             extension.</p>
         <p>It is noted that a number of object-level XMPP digital signature extensions have been
-	   specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP),
+            specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP), and
-	   and &xep0285;.  The limited applicability of encapsulating signature approaches in XMPP
+            &xep0285;. The limited applicability of encapsulating signature approaches in XMPP is
-	   is discussed in &xep0274;.</p>
+            discussed in &xep0274;.</p>
     </section1>
     <section1 topic="Signing XMPP Stanzas" anchor="stanza">
         <p>The process that a sending agent follows for securing stanzas is very similar regardless
@@ -76,10 +91,10 @@
 
         <p>This is modified prior to signing as follows:</p>
         <ul>
-            <li>Default attribute values are added.  (Namespace declarations are not modified.)</li>
+            <li>Default attribute values are added. (Namespace declarations are not modified.)</li>
-            <li>Each child element of the stanza is augmented by a <tt>id</tt> attribute
+            <li>Each child element of the stanza is augmented by a <tt>id</tt> attribute qualified
-                qualified in the <tt>urn:xmpp:dsig:0</tt> namespace. As these attributes are used to
+                in the <tt>urn:xmpp:dsig:0</tt> namespace. As these attributes are used to identify
-                identify the element within a manifest, they must be sufficient unique.</li>
+                the element within a manifest, they must be sufficient unique.</li>
         </ul>
         <example><![CDATA[
 <message from='juliet@capulet.net'
@@ -94,43 +109,25 @@
         <p>The signer builds a stanza description object containing a signer element, the stanza
             element, and a timestamp element. The signer element value is the bare JID of the
             signing entity. When the signing entity is a service entity, the JID may only contain
-            service domain. The stanza element is the stanza prepared above with each of its element
+            service domain. The stanza-desc element is the stanza prepared above with each of its
-            replaced by an reference element.</p>
+            child elements replaced by an reference element. The reference element references the
+            child element via a "urn:xmpp:dsig:ref:0" URI with an anchor of the value of child
+            element's <tt>d:id</tt>. The value of the reference element is the digest value produced
+            by the digest method after the specified transforms are applied.</p>
         <example><![CDATA[
-<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
+<stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
     <signer>juliet@capulet.net</signer>
+    <Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
+    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <message from='juliet@capulet.net'
             id='183ef129'
             to='romeo@montague.net'
             type='chat'>            
-        <reference>xxxx-1</reference>
+        <reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
-        <reference>xxxx-2</reference>
+        <reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
     </message>
     <timestamp>2010-11-11T13:33:00.123Z</timestamp>
-</stanza>
+</stanza-desc>
-]]></example>
-
-        <p>The signer then builds an XMLDSIG Manifest object which references each element via the
-                <tt>xmpp:dsig:ref:0</tt> URN and provides a digest over the element (after it has
-            been modified to include a <tt>d:id</tt> attribute) as transformed by the transformation
-            algorithm.</p>
-        <example><![CDATA[
-<Manifest id="manifest">
-    <Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
-        <Transforms>
-            <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-        </Transform>
-        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-        <DigestValue>...</DigestValue>
-    </Reference>
-    <Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
-        <Transforms>
-            <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-        </Transform>
-        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-        <DigestValue>...</DigestValue>
-    </Reference>
-</Manifest>
 ]]></example>
 
         <p>The signer then builds a SignedInfo element.</p>
@@ -145,13 +142,6 @@
         <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <DigestValue>...</DigestValue>
     </Reference>
-    <Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
-        <Transforms>
-            <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
-        </Transform>
-        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-        <DigestValue>...</DigestValue>
-    </Reference>
 </SignedInfo>
 ]]></example>
 
@@ -168,50 +158,27 @@
             <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
             <DigestValue>...</DigestValue>
         </Reference>
-        <Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
-            <Transforms>
-                <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
-            </Transforms>
-            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <DigestValue>...</DigestValue>
-        </Reference>
     </SignedInfo>
     <SignatureValue/>
     <Object>
-        <stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
+        <stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
             <signer>juliet@capulet.net</signer>
+            <Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
+            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
             <message from='juliet@capulet.net'
-                     id='183ef129'
+                    id='183ef129'
-                     to='romeo@montague.net'
+                    to='romeo@montague.net'
-                     type='chat'>            
+                    type='chat'>            
-                <reference>xxxx-1</reference>
+                <reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
-                <reference>xxxx-2</reference>
+                <reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
             </message>
             <timestamp>2010-11-11T13:33:00.123Z</timestamp>
-        </stanza>
+        </stanza-desc>
-    </Object>
-    <Object>
-        <Manifest id="manifest">
-            <Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
-                <Transforms>
-                    <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-                </Transform>
-                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-                <DigestValue>...</DigestValue>
-            </Reference>
-            <Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
-                <Transforms>
-                    <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-                </Transform>
-                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-                <DigestValue>...</DigestValue>
-            </Reference>
-        </Manifest>
     </Object>
 </Signature>
           ]]></example>
 
-        <p> The signer than computes the SignatureValue element, processing the Signature element as
+        <p>The signer than computes the SignatureValue element, processing the Signature element as
             a detached signature, and replaces the empty Signature element with it. Finally, the
             signer inserts the Signature element into stanza and forwards the stanza as it normally
             would.</p>
@@ -233,45 +200,22 @@
                 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                 <DigestValue>...</DigestValue>
             </Reference>
-            <Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
-                <Transforms>
-                    <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
-                </Transforms>
-                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-                <DigestValue>...</DigestValue>
-            </Reference>
         </SignedInfo>
         <SignatureValue>...</SignatureValue>
         <Object>
-            <stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
+            <stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
                 <signer>juliet@capulet.net</signer>
+                <Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
+                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                 <message from='juliet@capulet.net'
-                         id='183ef129'
+                    id='183ef129'
-                         to='romeo@montague.net'
+                    to='romeo@montague.net'
-                         type='chat'>            
+                    type='chat'>            
-                    <reference>xxxx-1</reference>
+                    <reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
-                    <reference>xxxx-2</reference>
+                    <reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
                 </message>
                 <timestamp>2010-11-11T13:33:00.123Z</timestamp>
-            <stanza>
+           </stanza-desc>
-        </Object>
-        <Object>
-            <Manifest id="manifest">
-                <Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
-                    <Transforms>
-                        <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-                    </Transform>
-                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-                    <DigestValue>...</DigestValue>
-                </Reference>
-                <Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
-                    <Transforms>
-                        <Transform Algorithm="urn:xmpp:dsig:transform:0"/>
-                    </Transform>
-                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-                    <DigestValue>...</DigestValue>
-                </Reference>
-            </Manifest>
         </Object>
     </Signature>
  </message>

xep.ent

@@ -1168,7 +1168,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
 <!ENTITY xep0282 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0282.html'>DMUC2: Distributed MUC</link></span> <note>XEP-0282: DMUC2: Distributed MUC &lt;<link url='http://xmpp.org/extensions/xep-0282.html'>http://xmpp.org/extensions/xep-0282.html</link>&gt;.</note>" >
 <!ENTITY xep0283 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0283.html'>Moved</link></span> <note>XEP-0283: Moved &lt;<link url='http://xmpp.org/extensions/xep-0283.html'>http://xmpp.org/extensions/xep-0283.html</link>&gt;.</note>" >
 <!ENTITY xep0284 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0284.html'>Shared XML Editing</link></span> <note>XEP-0284: Shared XML Editing &lt;<link url='http://xmpp.org/extensions/xep-0284.html'>http://xmpp.org/extensions/xep-0284.html</link>&gt;.</note>" >
-<!ENTITY xep0285 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0285.html'>Digital Signatures in XMPP</link></span> <note>XEP-0285: Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>&gt;.</note>" >
+<!ENTITY xep0285 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0285.html'>Encapsulating Digital Signatures in XMPP</link></span> <note>XEP-0285: Encapsulating Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>&gt;.</note>" >
 <!ENTITY xep0286 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0286.html'>XMPP on Mobile Devices</link></span> <note>XEP-0286: XMPP on Mobile Devices &lt;<link url='http://xmpp.org/extensions/xep-0286.html'>http://xmpp.org/extensions/xep-0286.html</link>&gt;.</note>" >
 <!ENTITY xep0287 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0287.html'>Spim Markers and Reports</link></span> <note>XEP-0287: Spim Markers and Reports &lt;<link url='http://xmpp.org/extensions/xep-0287.html'>http://xmpp.org/extensions/xep-0287.html</link>&gt;.</note>" >
 <!ENTITY xep0288 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0288.html'>Bidirectional Server-to-Server Connections</link></span> <note>XEP-0288: Bidirectional Server-to-Server Connections &lt;<link url='http://xmpp.org/extensions/xep-0288.html'>http://xmpp.org/extensions/xep-0288.html</link>&gt;.</note>" >