xep-0390: clearly specify handling of xml:lang attributes

xep-0390.xml

@@ -51,6 +51,16 @@
     <email>jonas@wielicki.name</email>
     <jid>jonas@wielicki.name</jid>
   </author>
+  <revision>
+    <version>0.2</version>
+    <date>2017-06-14</date>
+    <initials>jwi</initials>
+    <remark>
+      <ul>
+        <li>Clearly specify handling of xml:lang attributes.</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2017-03-23</date>
@@ -109,7 +119,11 @@
 
   <section2 topic='Hash Function Input' anchor='algorithm-input'>
     <p>The input to this algorithm is a &xep0030; disco#info &lt;query/&gt; response. The output is an octet string which can be used as input to a hash function or an error.</p>
-    <p>General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 encoding as specified in &rfc3629; is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.</p>
+    <div class="box"><p>General remarks:</p>
+    <ul>
+      <li><p>The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 as specified in &rfc3629; encoding is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.</p></li>
+      <li><p>The algorithm uses the <tt>xml:lang</tt> attribute. Implementations must take implicit values for the <tt>xml:lang</tt> attribute into account, for example those inherited from the disco#info or the IQ element.</p></li>
+    </ul></div>
     <ol>
       <li>If the &lt;query/&gt; element contains any elements except &lt;identity/&gt;, &lt;feature/&gt; (both from the &xep0030; disco#info namespace) or &xep0128; data forms, abort with an error.</li>
       <li>If any &xep0128; &lt;x/&gt; element contains a data form which contains a &lt;reported/&gt; or &lt;item/&gt; element, abort with an error.</li>
@@ -739,6 +753,7 @@ cDp0aW1lHxw=</code>
       <p>Instead of issuing a &xep0030; disco#info &lt;query/&gt; with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the &lt;query/&gt; would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.</p>
       <p>An entity MUST NOT use &hashes; which were not included in the most recent &hashset; received from the target entity.</p>
       <p>An entity MAY use external data sources to fill the &hashcache;.</p>
+      <p>An entity MUST ensure that implicit values for <tt>xml:lang</tt> attributes is preserved when disco#info data is cached. This can for example happen by making the implicit values explicit in the storage.</p>
     </section3>
   </section2>
 
@@ -773,6 +788,7 @@ cDp0aW1lHxw=</code>
     <p>This was an issue with &xep0115; and has been addressed with a new algorithm for generating the hash function input which keeps the structural information of the disco#info input.</p>
     <p>An entity MUST NOT ever use disco#info which has not been verified to belong to a &hash; obtained from a cache using that &hash;. Using cache contents from a trusted source (at the discretion of the entity) counts as verifying.</p>
     <p>A malicious entity could send a large amount of &hashsets; in short intervals, while making sure that it provides matching disco#info responses. If a &procent; uses caching, this can overflow or thrash the caches. &procents; should be aware of this risk and apply proper rate-limiting for processing &hashsets;. To reduce the attack surface, an entity MAY choose to not cache &hashes; obtained from entities not in its roster.</p>
+    <p>As mentioned earlier, when storing disco#info data in a cache for later retrieval, implementations MUST ensure that implicit values for <tt>xml:lang</tt> attributes are reconstructed correctly when the disco#info is restored.</p>
   </section2>
 
   <section2 topic='Directed Presence' anchor='security-directed-presence'>