mirror of https://github.com/moparisthebest/xeps
0.2
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1891 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
8794b36efa
commit
81fad5ff11
105
xep-0231.xml
105
xep-0231.xml
|
|
@ -24,6 +24,12 @@
|
|||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.2</version>
|
||||
<date>2008-05-29</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Added service discovery feature for in-band message images use case.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2008-01-30</date>
|
||||
|
|
@ -57,12 +63,12 @@
|
|||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Sometimes it is desirable to include a small bit of binary data in an XMPP stanza. Typical use cases might be inclusion of an icon or emoticon in a message, a thumbnail in a file transfer request, a rasterized image in a whiteboarding session, or a small bit of media in a data form. At present, there is no lightweight method for including such data in an XMPP stanza, since existing methods (e.g., &xep0047;) are designed for larger blobs of data and therefore require some form of negotiation (e.g., via &xep0096; or &xep0166;). Therefore, this document specifies just such a lightweight method, using a <data/> element that provides semantics similar to the data: URL scheme defined in &rfc2397;.</p>
|
||||
<p>Sometimes it is desirable to include a small bit of binary data in an XMPP stanza. Typical use cases might be inclusion of an icon or emoticon in a message, a thumbnail in a file transfer request, a rasterized image in a whiteboarding session, or a small bit of media in a data form. At present, there is no lightweight method for including such data in an XMPP stanza, since existing methods (e.g., &xep0047;) are designed for larger blobs of data and therefore require some form of negotiation (e.g., via &xep0096; or &xep0234;). Therefore, this document specifies just such a lightweight method, using a <data/> element that provides semantics similar to the data: URL scheme defined in &rfc2397;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Format' anchor='format'>
|
||||
<p>The format for including binary data is straightforward: the data is encapsulated as the XML character data of a <data/> element, where the data MUST be encoded as Base64 in accordance with Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set the number of pad bits to zero).</p>
|
||||
<p>The <data/> element SHOULD be used only to encapsulate small bits of binary data and SHOULD NOT be used for large data transfers. Naturally the definitions of "small" and "large" are rather loose. In general, it is recommended that the data should not be more than 8 kilobytes and that dedicated file transfer methods should be used for exchanging blobs of data larger than 8 kilobytes. Naturally, implementations or deployments may impose their own limits.</p>
|
||||
<p>The format for including binary data is straightforward: the data is encapsulated as the XML character data of a <data/> element qualified by the 'urn:xmpp:tmp:data-element' namespace &NSNOTE;, where the data MUST be encoded as Base64 in accordance with Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set the number of pad bits to zero).</p>
|
||||
<p>The <data/> element MUST be used only to encapsulate small bits of binary data and MUST NOT be used for large data transfers. Naturally the definitions of "small" and "large" are rather loose. In general, the data SHOULD NOT be more than 8 kilobytes, and dedicated file transfer methods (e.g., &xep0065; or &xep0047;) SHOULD be used for exchanging blobs of data larger than 8 kilobytes. Naturally, implementations or deployments may impose their own limits.</p>
|
||||
<p>The following attributes are defined for the <data/> element.</p>
|
||||
<table caption='Defined Attributes'>
|
||||
<tr>
|
||||
|
|
@ -103,8 +109,9 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Messaging' anchor='message'>
|
||||
<section2 topic='In-Band Images for XMPP Messaging' anchor='message'>
|
||||
<p>The <data/> 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>
|
||||
<p>Note: The sender SHOULD NOT include an in-band image unless the intended recipient advertises (via &xep0030; or &xep0115;) support for the "urn:xmpp:tmp:data-element:inband-image" service discovery feature &NSNOTE;.</p>
|
||||
<example caption='A message with included data'><![CDATA[
|
||||
<message from='ladymacbeth@shakespeare.lit/castle'
|
||||
to='macbeth@chat.shakespeare.lit'
|
||||
|
|
@ -132,7 +139,7 @@
|
|||
</data>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Once the data is provided, a subsequent message in the same session can refer to the data again without including it.</p>
|
||||
<p>Once the data is provided, a subsequent message in the same session can refer to the data again without including the data itself.</p>
|
||||
<example caption='A message with referenced data'><![CDATA[
|
||||
<message from='ladymacbeth@shakespeare.lit/castle'
|
||||
to='macbeth@chat.shakespeare.lit'
|
||||
|
|
@ -149,44 +156,10 @@
|
|||
</html>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>If the receiving entity has not cached the data, it can request the data as described in the next section.</p>
|
||||
<p>If the receiving entity has not cached the data, it can request the data as described in the <link url='#retrieve'>Retrieving Data</link> section of this document.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Retrieving Data' anchor='retrieve'>
|
||||
<p>Data can be requested and transferred using the XMPP &IQ; stanza type by making reference to the 'cid' of the data to be retrieved. In particular, the requesting entity can request data by sending an IQ-get containing an empty <data/> element with a 'cid' attribute.</p>
|
||||
<example caption='Requesting data'><![CDATA[
|
||||
<iq from='doctor@shakespeare.lit/pda'
|
||||
id='get-data-1'
|
||||
to='gentlewoman@shakespeare.lit/phone'
|
||||
type='get'>
|
||||
<data xmlns='urn:xmpp:tmp:data-element'
|
||||
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The responding entity then would either return an error (e.g., ¬found; if it does not have data matching the Content-ID) or return the data.</p>
|
||||
<example caption='Returning data'><![CDATA[
|
||||
<iq from='gentlewoman@shakespeare.lit/phone'
|
||||
id='get-data-1'
|
||||
to='doctor@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<data xmlns='urn:xmpp:tmp:data-element'
|
||||
alt='A spot'
|
||||
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'
|
||||
type='image/png'>
|
||||
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
|
||||
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
|
||||
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
|
||||
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
|
||||
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
|
||||
vr4MkhoXe0rZigAAAABJRU5ErkJggg==
|
||||
</data>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>This specification does not place limits on the entities from which data can be requested. In particular, such an entity need not be the "owner" of the data (e.g., it could be a peer in a chatroom or whiteboarding session).</p>
|
||||
<p>In addition, bits of data could be hosted by XMPP servers, distributed via &xep0060; nodes, or included in data collections that are available via HTTP (e.g., emoticon sets). Such data could be identified by the value of the 'cid' attribute, but methods for specifying those values are out of scope for this specification.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Data Form' anchor='form'>
|
||||
<section2 topic='Media Data in XMPP Data Forms' anchor='form'>
|
||||
<p>&xep0221; describes how to include a media element in &xep0004;, e.g. for the purpose of placing a human-viewable "CAPTCHA" in a form that is used for &xep0158; or &xep0077;. The <media/> element described in <cite>XEP-0221</cite> contains one or more <uri/> elements (which point to locations where the media can be downloaded, e.g. via HTTP) as well as a <data/> element that includes the data itself. The <media/> element would contain a <data/> element as described herein and shown in the following example.</p>
|
||||
<example caption='Audio Media Element'><![CDATA[
|
||||
<media xmlns='urn:xmpp:tmp:media-element'>
|
||||
|
|
@ -209,8 +182,9 @@
|
|||
<p>The media would then be included in a data form as illustrated in <cite>XEP-0221</cite>.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='File Transfer Preview' anchor='preview'>
|
||||
<p>A previous proposal <note>See <<link url='http://www.xmpp.org/extensions/inbox/file-preview.html'>http://www.xmpp.org/extensions/inbox/file-preview.html</link>>.</note> described a method for including a thumbnail or file preview in a file transfer request. Such a preview can be included using the <data/> element, as shown below. However, a preview SHOULD NOT be included unless the receiving entity advertises (via &xep0030; or &xep0115;) support for the "urn:xmpp:tmp:file-preview" service discovery feature &NSNOTE;.</p>
|
||||
<section2 topic='Previews for XMPP File Transfers' anchor='preview'>
|
||||
<p>A previous proposal <note>See <<link url='http://www.xmpp.org/extensions/inbox/file-preview.html'>http://www.xmpp.org/extensions/inbox/file-preview.html</link>>.</note> described a method for including a thumbnail or file preview in a file transfer request. Such a preview can be included using the <data/> element, as shown below.</p>
|
||||
<p>Note: The initiator SHOULD NOT include a file preview unless the receiving entity advertises (via <cite>XEP-0030</cite> or <cite>XEP-0115</cite>) support for the "urn:xmpp:tmp:data-element:file-preview" service discovery feature &NSNOTE;.</p>
|
||||
<example caption='File transfer offer with preview'><![CDATA[
|
||||
<iq from='romeo@montague.lit/home'
|
||||
id='offer1'
|
||||
|
|
@ -370,6 +344,40 @@
|
|||
]]></example>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Retrieving Uncached Media Data' anchor='retrieve'>
|
||||
<p>Data can be requested and transferred using the XMPP &IQ; stanza type by making reference to the 'cid' of the data to be retrieved. In particular, the requesting entity can request data by sending an IQ-get containing an empty <data/> element with a 'cid' attribute.</p>
|
||||
<example caption='Requesting data'><![CDATA[
|
||||
<iq from='doctor@shakespeare.lit/pda'
|
||||
id='get-data-1'
|
||||
to='gentlewoman@shakespeare.lit/phone'
|
||||
type='get'>
|
||||
<data xmlns='urn:xmpp:tmp:data-element'
|
||||
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The responding entity then would either return an error (e.g., ¬found; if it does not have data matching the Content-ID) or return the data.</p>
|
||||
<example caption='Returning data'><![CDATA[
|
||||
<iq from='gentlewoman@shakespeare.lit/phone'
|
||||
id='get-data-1'
|
||||
to='doctor@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<data xmlns='urn:xmpp:tmp:data-element'
|
||||
alt='A spot'
|
||||
cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'
|
||||
type='image/png'>
|
||||
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
|
||||
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
|
||||
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
|
||||
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
|
||||
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
|
||||
vr4MkhoXe0rZigAAAABJRU5ErkJggg==
|
||||
</data>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>This specification does not place limits on the entities from which data can be requested. In particular, such an entity need not be the "owner" of the data (e.g., it could be a peer in a chatroom or whiteboarding session, or the chatroom or whiteboarding service itself).</p>
|
||||
<p>In addition, bits of data could be hosted by XMPP servers, distributed via &xep0060; nodes, or included in data collections that are available via HTTP (e.g., emoticon sets). Such data could be identified by the value of the 'cid' attribute, but methods for specifying those values are out of scope for this specification.</p>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
|
|
@ -385,12 +393,17 @@
|
|||
<p>Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:data-element"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
<section2 topic='Service Discovery Features' anchor='registrar-features'>
|
||||
<p>If an entity is willing to accept data elements in file transfer requests for the purpose of previewing the file to be sent, it SHOULD advertise support for the "urn:xmpp:tmp:file-preview" feature.</p>
|
||||
<p>If an entity is willing to accept data elements in file transfer requests for the purpose of previewing the file to be sent, it SHOULD advertise support for the "urn:xmpp:tmp:data-element:file-preview" feature.</p>
|
||||
<p>The registry submission is as follows.</p>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<var>
|
||||
<name>urn:xmpp:tmp:file-preview</name>
|
||||
<desc>Willingness to accept data elements to preview file transfers</desc>
|
||||
<name>urn:xmpp:tmp:data-element:file-preview</name>
|
||||
<desc>Signals a willingness to accept data elements for previewing file transfers</desc>
|
||||
<doc>XEP-0230</doc>
|
||||
</var>
|
||||
<var>
|
||||
<name>urn:xmpp:tmp:data-element:inband-image</name>
|
||||
<desc>Signals a willingness to accept data elements for in-band message images</desc>
|
||||
<doc>XEP-0230</doc>
|
||||
</var>
|
||||
]]></code>
|
||||
|
|
|
|||
Loading…
Reference in New Issue