[Standards-JIG] Inline Images for JEP-0071: XHTML-IM

[Andreas Monitzer]

Hi,

I'm the developer of the new XMPP plugin for Adium X 1.1 (part of  
Google Summer of Code 2006). This client supports multiple protocols,  
but we're trying to get people to switch to XMPP. For this  
undertaking, we're trying to support everything the other protocols  
can, plus some more. One of these issues are inline images in  
messages, which are supported by OSCAR (AIM/ICQ) and MSN (maybe  
others, I don't know).

JEP-0071: XHTML-IM supports <img/>-tags, which can be used for this  
purpose by using the data:-protocol (see http://www.ietf.org/rfc/ 
rfc2397.txt). However, we are aware that support for this protocol  
isn't ubiquitous in XHTML renderers. That's not really an issue for  
Adium, since we're using the great WebKit rendering framework for it,  
but others might be more limited.
Right now, there is no way to detect support for that feature on the  
other party's client, we can only detect support for XHTML-IM  
overall. It would be nice if there could be a specific disco#info- 
feature tag for this information.

Further, XHTML limits the data-protocol images to 1024 bytes in  
base64-encoding, including the header with the mime-type and encoding  
declaration. This is only suitable for very small images (custom  
emoticons perhaps, which is an important application for that). For  
larger images, a different solution has to be found. MIME-mails  
support this by allowing to reference images attached to the mail in  
<img/>-tags by using a "Content ID" in the attachment's header. Since  
XMPP doesn't support attachments (wouldn't make any sense), this  
isn't a suitable solution here. However, the image could be  
transparently transferred using a file transfer method (like JEP-0096  
or JEP-0166) and referenced from the XHTML inside the message packet.  
This would probably require a new JEP.

A simple solution which would work today would be to create a web  
server inside the IM client and use a regular HTTP-protocol reference  
in the <img/>-tag. However, NATs or restrictive firewalls would  
prevent this solution from working (where's IPv6?), and opening such  
a service without the user knowing about it would be a security issue.

What are your thoughts about this issue?

Regards,
Andreas Monitzer