XHTML Inband Images

From XMPP WIKI
Jump to: navigation, search

XHTML Inband Images is a way to embed images into an XHTML Jabber message that do not originate from an HTTP server, they are separately downloadable using File transfer.

SI-PUB defines a way to advertise file transfers. One of the ways is to include the advertisement inside a message. If this is combined with a future SI-PUB URI like "xmpp:alice@example.com?sipub=image.jpg", then we can have a completely XMPP/Jabber based method to do inband images.

An example message doing this would be:

 <message from='romeo@montague.net/pda' to='juliet@capulet.com'>
   <body>A rose</body>
   <html xmlns='http://jabber.org/protocol/xhtml-im'>
     <body xml:lang='en-US' xmlns='http://www.w3.org/1999/xhtml'>
        A <img src="xmpp:romeo@montague.net/pda?sipub=publish-0123" alt="rose"/>.
     </body>
   </html>
   <sipub xmlns='http://jabber.org/protocol/si-pub'
       id='publish-0123'
       mime-type='text/plain'
       profile='http://jabber.org/protocol/si/profile/file-transfer'>
     <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
           name='rose.jpg'
           size='1024'
           date='2005-07-21T11:21Z'>
       <desc>A rose</desc>
     </file>
   </sipub>
 </message>

From that a client could then use the protocol defined in SI-PUB to retrieve the image.

Open questions are:

 * What protocol needs to be defined to allow inband images to be received if the sender is offline?
 * Do we want thumbnail generation like what's mentioned below?

Note What follows was the original proposol for inband images.

Email already does something similar to this in multipart/related emails where the images are attached to the email and refered to in the img tags with a cid (content id).

e.g. <img src="cid:123456789">

We define a way of attaching auxiliary objects to the <message/>. One type of these objects is an "imbedded object" which is retrievable via Jabber File Transfer mechanizms.

Before any attempt to use the iobj protocol, client should check (using disco) if the recipient also supports iobj. If not, sender should not use the protocol, to not waste bandwidth.

TODO: define disco queries here

An example of protocol flow follows:

1. Sender sends the message containing in-line image.

 <message type='chat' from='src@example.com/client' to='dest@example.com'>
     <body>Hello mate :-)</body>
     <html xmlns='http://jabber.org/protocol/xhtml-im'>
         <body xmlns='http://www.w3.org/1999/xhtml'>
             Hello mate <img src='cid:id1'/>
         </body>
     </html>
     <obj xmlns='http://jabber.org/protocol/iobj' cid='id1' id='552da749930852c69ae5d2141d3766b1'/>
 </message>

"cid" is used as this is an already defined method in RFC2392 for related content linking. "id" is the file hash of the file which matches the hash later defined in the file transfer protocol, this can be used as a unique caching identifier so imbedded objects only need be transferred once.

2. Client requests offering of the file in question

 <iq type='set' from='dest@example.com/res' to='src@example.com/client' id='iobj1'>
     <get xmlns='http://jabber.org/protocol/iobj' id='552da749930852c69ae5d2141d3766b1'/>
 </iq>

3. Client responds with result or error

 <iq type='result' from='src@example.com/client' to='dest@example.com/res' id='iobj1'/>

4. src@example.com starts an SI file transfer offering of the file in question (JEP-0096).

Possible extensions:

1. File informations

Sometimes the image attached is large and we may want a preview of wgat we will get. So if the sender supports disco iobj#info extension, client could get file information first, before trying to fetch the file:

 <iq type='get' from='dest@example.com/res' to='src@example.com/client' id='iobj2'>
     <info xmlns='http://jabber.org/protocol/iobj' id='552da749930852c69ae5d2141d3766b1'/>
 </iq>

With a response of:

 <iq type='result' from='dest@example.com/res' to='src@example.com/client' id='iobj2'>
     <info xmlns='http://jabber.org/protocol/iobj' id='552da749930852c69ae5d2141d3766b1'>
         <type>image/gif</type>
         <size>123432</size>
         <width>12</width>
         <height>12</height>
     </info>
 </iq>

2. Thumbnail generation

If client decides that the image is to large to fetch and display it immediately, it could ask user for confirmation or if sender supports disco iobj#thumbs extension, client could request a thumbnail:

 <iq type='get' from='dest@example.com/res' to='src@example.com/client' id='iobj3'>
     <thumb xmlns='http://jabber.org/protocol/iobj' id='552da749930852c69ae5d2141d3766b1'>
         <type>image/gif</type>
         <width>32</width>
         <height>16</height>
     </thumb>
 </iq>

Sender responds with available thumbnails (possibly nearest requested)

 <iq type='result' from='src@example.com/client' to='dest@example.com/res' id='iobj3'>
     <thumbs xmlns='http://jabber.org/protocol/iobj'>
         <thumb type='image/gif' width='32' height='16' id='322da749930852c69ae5d4141d3866c1'/>
         <thumb type='image/jpeg' width='64' height='64' id='122da749930852c45ae5d4141d3866a1'/>
     </thumbs>
 </iq>

Recipient requests thumbnail using iobj protocol

 <iq type='set' from='dest@example.com/res' to='src@example.com/client' id='iobj4'>
     <get xmlns='http://jabber.org/protocol/iobj' id='322da749930852c69ae5d4141d3866c1'/>
 </iq>
 <iq type='result' from='src@example.com/client' to='dest@example.com/res' id='iobj4'/>

If the user decides to view the whole image (e.g. clicks on the thumbnail) client gets the file using the file id from the <obj/> of the <message/>