0.9

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2155 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0231.xml

@@ -19,6 +19,7 @@
     <spec>RFC 2045</spec>
     <spec>RFC 2111</spec>
     <spec>RFC 2965</spec>
+    <spec>RFC 3174</spec>
     <spec>RFC 4648</spec>
   </dependencies>
   <supersedes/>
@@ -26,6 +27,12 @@
   <shortname>NOT_YET_ASSIGNED</shortname>
   &stpeter;
   &pavlix;
+  <revision>
+    <version>0.9</version>
+    <date>2008-08-16</date>
+    <initials>psa/ps</initials>
+    <remark><p>Modified cid generation rules to use a hash of the data instead of a UUID (of the form algo+hash@bob.xmpp.org); modified caching rules to typically base checking on the hash, not the sender JID.</p></remark>
+  </revision>
   <revision>
     <version>0.8</version>
     <date>2008-08-07</date>
@@ -179,7 +186,7 @@
     <p>The default behavior is for the recipient to cache the data only for the life of the entity's application session (not a client's presence session with the server or the controlling user's communication session with the contact from whom the user received the data); that is, the recipient would clear the cache when the application is terminated or restarted.</p>
     <p>As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a &lt;data/&gt; element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from <cite>RFC 2965</cite>.</p>
     <p>If it is not suggested to cache the data (e.g., because it is ephemeral), the value of the 'max-age' attribute MUST be "0" (the number zero).</p>
-    <p>A recipient MUST cache based on the JID of the sender; this helps to prevent certain data poisoning attacks.</p>
+    <p>A recipient SHOULD cache data based on the hash of the data as encapsulated in the cid. However, if a hash cannot be extracted from the cid, if the recipient does not support the hashing algorithm used, or the recipient does not support hashes, then the recipient SHOULD cache based on the JID of the sender.</p>
   </section2>
 
   <section2 topic='Format of the &lt;data/&gt; Element' anchor='format'>
@@ -193,7 +200,7 @@
       </tr>
       <tr>
         <td>cid</td>
-        <td>A Content-ID that can be mapped to a cid: URL as specified in &rfc2111;. The 'cid' value MUST be generated so that the local-part is a UUID as specified in &rfc4122; and the domain is the XMPP domain identifier portion of the sender's JabberID.</td>
+        <td>A Content-ID that can be mapped to a cid: URL as specified in &rfc2111;. The 'cid' value SHOULD be of the form algo+hash@bob.xmpp.org, where the "algo" is the hashing algorithm used (e.g., "sha1" for the SHA-1 algorithm as specified in &rfc3174;) and the "hash" is the hex output of the algorithm applied to the binary data itself.</td>
         <td>REQUIRED</td>
       </tr>
       <tr>
@@ -252,7 +259,6 @@
 
 <section1 topic='Security Considerations' anchor='security'>
   <p>The ability to include arbitrary binary data implies that it is possible to send scripts, applets, images, and executable code, which may be potentially harmful. To reduce the risk of such exposure, an implementation MAY choose to not display or process such data but instead either completely ignore the data, show only the value of the 'alt' attribute, or prompt a human user for approval (either explicitly via user action or implicitly via a list of approved entities from whom the user will accept binary data without per-event approval).</p>
-  <p>The recipient MUST cache data based on the sender's JabberID; this helps to avoid data poisoning attacks.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
@@ -298,7 +304,7 @@
 </section1>
 
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to Rachel Blackman, Dave Cridland, and Tomasz Sterna for their feedback.</p>
+  <p>Thanks to Rachel Blackman, Dave Cridland, Zenon Kuder, and Tomasz Sterna for their feedback.</p>
 </section1>
 
 </xep>