Fix references to RFC 3629

Some XEPs used &rfc3269; as reference which is

Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks
                  and Protocol Instantiation documents

while they should use RFC 3629 for that.

Simple typo, i.e. transpose of two characters, not
RFC 3269 but
RFC 3629.

inbox/dsig.xml

@@ -54,7 +54,7 @@
       <li>Constructs a cleartext version of the stanza, S.</li>
       <li>Notes the current UTC date and time N when this stanza is constructed, formatted as
         described in Section 5.</li>
-      <li>Converts the stanza to a UTF-8, as defined by &rfc3269;, encoded string, optionally
+      <li>Converts the stanza to a UTF-8, as defined by &rfc3629;, encoded string, optionally
         removing line breaks and other insignificant whitespace between elements and attributes,
         i.e., UTF8-encode(S) = S'. We call S' a "stanza-string" because for purposes of signing and
         verification it is treated not as XML but as an opaque string (this avoids the need for

xep-0078.xml

@@ -209,7 +209,7 @@
   </query>
 </iq>
 ]]></example>
-    <p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 6120</cite>, i.e., UTF-8 as defined in &rfc3269;).</p>
+    <p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 6120</cite>, i.e., UTF-8 as defined in &rfc3629;).</p>
     <p>The value of the &lt;digest/&gt; element MUST be computed according to the following algorithm:</p>
     <ol>
       <li>Concatenate the Stream ID received from the server with the password. <note>In Digest authentication, password characters that map to predefined XML entities SHOULD NOT be escaped as they are for plaintext passwords, but non-US-ASCII characters MUST be encoded as UTF-8 since the SHA-1 hashing algorithm operates on byte arrays.</note></li>

xep-0115.xml

@@ -297,7 +297,7 @@
             </li>
           </ol>
         </li>
-        <li>Ensure that S is encoded according to the UTF-8 encoding (&rfc3269;).</li>
+        <li>Ensure that S is encoded according to the UTF-8 encoding (&rfc3629;).</li>
         <li>Compute the verification string by hashing S using the algorithm specified in the 'hash' attribute (e.g., SHA-1 as defined in &rfc3174;). The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). <note>The OpenSSL command for producing such output with SHA-1 is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".</note></li>
       </ol>
       &ltwarning;

xep-0285.xml

@@ -82,7 +82,7 @@
       <li>Constructs a cleartext version of the stanza, S.</li>
       <li>Notes the current UTC date and time N when this stanza is constructed, formatted as
         described in Section 5.</li>
-      <li>Converts the stanza to a UTF-8, as defined by &rfc3269;, encoded string, optionally
+      <li>Converts the stanza to a UTF-8, as defined by &rfc3629;, encoded string, optionally
         removing line breaks and other insignificant whitespace between elements and attributes,
         i.e., UTF8-encode(S) = S'. We call S' a "stanza-string" because for purposes of signing and
         verification it is treated not as XML but as an opaque string (this avoids the need for