[Standards] Proposed XMPP Extension: Data Element

Sat Jan 12 15:55:15 CST 2008

Peter Saint-Andre wrote:
> Michael Laukner wrote:
>> Peter Saint-Andre wrote:
>>> XMPP Extensions Editor wrote:
>>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>>>
>>>> Title: Data Element
>>>>
>>>> Abstract: This document specifies a method for including small bits
>>>> of binary data in an XMPP stanza via the data: URL scheme.
>>>>
>>>> URL: http://www.xmpp.org/extensions/inbox/data-element.html
>>>
>>> See, that was easy, wasn't it? ;-)
>>>
>>> /psa
>>>
>>>
>>
>> This XEP seems to get close to what we want to achieve. A challenge for
>> the message exchange in our environment is the transmission of
>> structured information within a regular message. This structured
>> information may be geographic coordinates, date/time groups, or a
>> references to an data object, for example.
> 
> Traditionally, we have not worried very much about the transmission of 
> structured information, since XMPP is pure XML. The challenge has always 
> been to include unstructured (binary) information -- a problem that this 
> proposal seeks to address.
> 
>> To be able to embed various structured information in a message, the
>> message shall contain a "SmartTag". This "SmartTag" shall be as close to
>> text as "Emoticons" are, but structured enough for enhanced clients to
>> make some sense out of it.
> 
> OK. So basically you want a way to include your structured data in the 
> message stanza but define a convention for referring to it in the 
> plaintext message body. Correct?
> 
>> The example below was drafted before knowing the Data Element XEP:
>>
>> <message
>>    to="juliet at example.com/balcony"
>>    from="romeo at example.net"
>>    type="chat">
>>    <body>Juliet, I am at _1[47.8N,9.3E] and feeling kind of dizzy!
>>       You can find my new picture here _2[PIC-DB,4711].
>>    </body>
>>    <TagList xmlns="urn:xmpptag">
>>       <Tag ref="_1">
>>          <GeoPosition2D xmlns="urn:common">
>>             <Latitude units="degrees">47.8123</Latitude>
>>             <Longitude units="degrees">9.2947</Longitude>
>>          </GeoPosition2D>
>>       </Tag>
>>       <Tag ref="_2">
>>         <DRef libraryId="PIC-DB" productId="4711"/>
>>       </Tag>
>>    </TagList>
>> </message>
> 
> Hmm. We could use the same convention we're talking about using in 
> XHTML-IM, i.e., the cid: URL scheme. So your message would end up 
> looking like this perhaps:
> 
> <message
>   to="juliet at example.com/balcony"
>   from="romeo at example.net/orchard"
>   type="chat">
>   <body>Juliet, I am at 47.8N,9.3E and feeling kind of dizzy!
>      You can find my new picture here.
>   </body>
>   <html xmlns='http://jabber.org/protocol/xhtml-im'>
>     <body xmlns='http://www.w3.org/1999/xhtml'>
>       <p>Juliet, I am at <a href='cid:refcid1'>47.8N,9.3E</a>
>          and feeling kind of dizzy! You can find my new picture
>          <a href='cid:cidref2'>here</a>.</p>
>    </body>
>   </html>
>   <TagList xmlns="urn:xmpptag">
>      <Tag ref="cidref1">
>         <GeoPosition2D xmlns="urn:common">
>            <Latitude units="degrees">47.8123</Latitude>
>            <Longitude units="degrees">9.2947</Longitude>
>         </GeoPosition2D>
>      </Tag>
>      <Tag ref="cidref2">
>        <DRef libraryId="PIC-DB" productId="4711"/>
>      </Tag>
>   </TagList>
> </message>
> 
> I'm not quite seeing the need for the <TagList/> element. Why not just 
> include the markup for each attached data as an extension (it could be 
> MathML, SVG, geodata, or whatever -- each of those has its own special 
> namespace) instead of designing a generic "manifest" format?
> 
>> Could this XEP be designed to support more than just MIME-types???
> 
> It *could*, but I don't quite see the need yet. XMPP can handle all 
> sorts of structured data. All that you seem to need is a way to refer to 
> that structured data from within the message body, and cid: URLs may 
> give you that.
> 
>> i.e. geo data could be encoded using Geo URI:
>>
>>    http://www.ietf.org/internet-drafts/draft-mayrhofer-geo-uri-01.txt
>>
>>    'geo' URIs could (like any other URI scheme) also be embedded as
>>    hyperlinks in web pages.  A Hyper Text Markup Language (HTML) FIXME:
>>    ref snippet with such a hyperlink could look like:
>>
>>    <p>one of Vienna's most popular sights is the <a href=' geo:
>>    FIXME,FIXME,FIXME'>St. Stephans Cathedral</a>
>>
>>
>> In case of XMPP:
>>
>> <message
>>    to="juliet at example.com/balcony"
>>    from="romeo at example.net"
>>    type="chat">
>>    <body>Juliet, I am at geo:47.123,9.3 and feeling kind of dizzy!
>>    </body>
>>    <data xmlns='http:://www.xmpp.org/extensions/xep-xxxx.html#ns'
>>         alt='A spot'
>>         cid='f81d4fae-7dec-11d0-a765-00a0c91e6bf6 at shakespeare.lit'
>>         uri='geo'>
>>         FIXME,FIXME,FIXME
>>    </data>
>> </message>
> 
> Er, don't you really want this...?
> 
> <message
>   to="juliet at example.com/balcony"
>   from="romeo at example.net/orchard"
>   type="chat">
>   <body>
>     Juliet, I am at 47.8N,9.3E and feeling kind of dizzy!
>   </body>
>   <html xmlns='http://jabber.org/protocol/xhtml-im'>
>     <body xmlns='http://www.w3.org/1999/xhtml'>
>       <p>
>         Juliet, I am at <a href='geo:some-geo-uri'>47.8N,9.3E</a>
>         and feeling kind of dizzy!
>       </p>
>     </body>
>   </html>
> </message>

This message supports the consumer side. We can render the URI nicely as 
an image button and load the map application, but our end-nodes may also 
be producer. In this case we want to attach the geo-data directly (as 
gml, kml, geopriv) to a message, store them in the database on the 
server and send the URI to the MUC participants.

> 
> Now, whether the recipient supports the geo: URI scheme is another 
> matter. But I don't see a good reason to complicate the data element 
> when we already have a way to include URIs -- it's called XHTML-IM.
> 
> Peter
> 