moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

0.4

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2127 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-08-06 04:23:54 +00:00
parent f25c737771
commit f7dd451a94
1 changed files with 31 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
xep-0231.xml
View File

@ -18,12 +18,19 @@
<spec>XMPP Core</spec>
<spec>RFC 2045</spec>
<spec>RFC 2111</spec>
<spec>RFC 2965</spec>
<spec>RFC 4648</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.4</version>
<date>2008-08-05</date>
<initials>psa</initials>
<remark><p>Generalized text regarding inclusion of parameters in type attribute per RFC 2045; added max-age attribute, matching semantics from RFC 2965; added section on caching of data; more clearly specified generation of Content-ID.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2008-06-18</date>
@ -89,12 +96,17 @@
</tr>
<tr>
<td>cid</td>
<td>A Content-ID that can be mapped to a cid: URL as specified in &rfc2111;.</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 sending entity's JabberID.</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>max-age</td>
<td>A suggestion regarding how long (in seconds) to cache the data; the meaning matches the Max-Age attribute from &rfc2965;.</td>
<td>RECOMMENDED when sending a &lt;data/&gt; element containing XML character data</td>
</tr>
<tr>
<td>type</td>
<td>The MIME type of the data (e.g., "image/png") as described in &rfc2045;. The MIME type SHOULD be as registered in the &ianamedia;. The 'type' attribute MAY include the codecs parameter as specified in &rfc4281;, as shown in the example of the "audio/ogg" media type in the example below.</td>
<td>The value of the 'type' attribute MUST match the syntax specified in &rfc2045;. That is, the value MUST include a top-level media type, the "/" character, and a subtype; in addition, it MAY include one or more optional parameters (e.g., the "audio/ogg" MIME type in the example shown below includes a "codecs" parameter as specified in &rfc4281;). The "type/subtype" string SHOULD be registered in the &ianamedia;, but MAY be an unregistered or yet-to-be-registered value.</td>
<td>REQUIRED</td>
</tr>
</table>
@ -103,6 +115,7 @@
<data xmlns='urn:xmpp:tmp:data-element'
alt='A spot'
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'
max-age='86400'
type='image/png'>
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
@ -114,6 +127,15 @@
]]></example>
</section1>
<section1 topic='Caching of Data' anchor='caching'>
<p>When one party sends a data element to another party, it SHOULD NOT include the data itself unless the data is particularly small (e.g., less than 1k) or is ephemeral and therefore will never be used again. Instead, it SHOULD send an empty &lt;data/&gt; element with a 'cid' attribute, then depend on the receiving party to retrieve the data if not cached.</p>
<p>As a hint regarding the suggested period for caching the data, the sending party SHOULD include a 'max-age' attribute whenever it sends a non-empty &lt;data/&gt; element. The semantics of the 'max-age' attribute exactly matches that of the Max-Age attribute from <cite>RFC 2965</cite>.</p>
<p>It is RECOMMENDED for the receiving entity to cache data; however, the receiving entity MAY opt not to cache data, for example because it runs on an a device that does not have sufficient space for data storage.</p>
<p>The default behavior is for the receiving entity to cache the data only for the life of the entity's application session (not a controlling user'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 receiving entity would clear the cache when the application is terminated or restarted.</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 receiving entity MUST cache based on the JID of the sending entity; this helps to prevent certain data poisoning attacks.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='In-Band Images for XMPP Messaging' anchor='message'>
<p>The &lt;data/&gt; element can be used in conjunction with &xep0071; and the cid: URL scheme to point to binary data that is provided in-band within a &MESSAGE; stanza.</p>
@ -135,6 +157,7 @@
<data xmlns='urn:xmpp:tmp:data-element'
alt='A spot'
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'
max-age='86400'
type='image/png'>
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
@ -180,8 +203,7 @@
</uri>
<data xmlns='urn:xmpp:tmp:data-element'
alt='An audio file'
type='audio/ogg; codecs=speex'>
[ ... base64-encoded-audio ... ]
type='audio/ogg; codecs=speex'/>
</data>
</media>
]]></example>
@ -204,6 +226,7 @@
name='image.png'>
<data xmlns='urn:xmpp:tmp:data-element'
alt='There be dragons!'
cid='d8f904ac-636c-11dd-8a2f-001143d5d5db@montague.lit'
type='image/png'>
iVBORw0KGgoAAAANSUhEUgAAADkAAABACAIAAAAvV0jbAAAACXBIWXMAAA4mAAAOJgGi7yX8AAAc
SUlEQVRogX2aeYwlx33fv31V39d78+Y+d/a+eZMizcukKFlmTB2GEcmypQSJ7SBSnAOG4QAJEhix
@ -370,6 +393,7 @@
<data xmlns='urn:xmpp:tmp:data-element'
alt='A spot'
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'
max-age='86400'
type='image/png'>
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
@ -388,6 +412,7 @@
<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 receiving entity SHOULD cache data based on the sender's JabberID; this helps to avoid data poisoning attacks.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -432,6 +457,7 @@
<xs:extension base='xs:base64Binary'>
<xs:attribute name='alt' type='xs:string' use='optional'/>
<xs:attribute name='cid' type='xs:string' use='optional'/>
<xs:attribute name='max-age' type='xs:nonNegativeInteger' use='optional'/>
<xs:attribute name='type' type='xs:string' use='required'/>
</xs:extension>
</xs:simpleContent>
@ -443,7 +469,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, Pavel &#352;imerda, and Tomasz Sterna for their feedback.</p>
</section1>
</xep>