[standards-jig] XHTML-IM (JEP-0071) and in-band images
richard at dobson-i.net
Thu Jan 8 12:25:51 UTC 2004
> I've added AMP for the #inline image.
Why do you not want it to be stored offline? is there a particular reason
for this? I would think its more appropriate to not store the one where the
image needs to be retrieved via SI/IBB, since if the person is not online
when they retrieve the message when they do come back online if you are not
still online they will not be able to retrieve the images.
> But I don't think it's the way to go.
> In the proposed solution the sender determines if the picture should be
> transfered via SI
> or attaches it in the IOBJ. But it has no idea if the reciever would be
> able to get it. (NAT)
NAT doesnt present a problem as the point of using SI/filetransfer is that
it can transfer P2P is possible and if not fall back to IBB.
> There is no negotiation on the size of the IOBJ chunk.
Thats true, but the use I foresee for the inline IOBJ (imbedded object) is
for very small images such as custom emoticons, in the JEP that will be
produced after we do a bit of work on this in the Wiki we can define limits,
but there is not real way you can inforce it as you cannot stop people
sending large messages whether they contain attachments like this or just
bucket loads of plain text.
> I also would not like to introduce another type of large packet, that
> servers have to take care about.
> (Quota, Karma, etc.) We could stay with <data
> xmlns='http://jabber.org/protocol/ibb' />
Sure thats possible but IMO it would require changes to the IBB JEP (to
allow you to use the data packet of IBB without doing any of the session
setup stuff) and since its in Draft status I dont see that happening.
> It should be at the reciever discretion, to choose the metod (SI/IBB) of
> getting the image.
Sure you do that via disco or feature neg before sending.
> I assume the client already implements SI -> IBB fallback for
> filetransfer, so we don't have to
> consider it in Inband Images protocol.
> I would still advocate the generic Jabber File Transfer Protocol URL
> format. It would be
> usefull in more places than XHTML-IM.
> EX: jftp://user@server/resource/file.ext ?
> (slashes in resource to be considered :-) )
But that doesnt give you enough information to automatically and reliably
render the images, file extensions are not really a reliable way to
determine file types, also I was thinking of other things the IOBJ could be
used for such as sound effects like in ICQ chats, and chat window background
transfer like in MSN.
> If the image is small enough (one IBB packet) it could be attached
> directly with IBB
> if we add 'type' attribute to <data/> packet (which might be usefull
See above about the problem with IMO inapproriately reusing IBB. Also we
must really use cid: in the URL in the image tag as that is already an
internet standard for things such as this in RFC2111. The main reason for
having IOBJ was to have a standard way for the client to determine what the
referenced cid is in a similar way to the way it works in email, but with
the added option of not necessarly having to send the image imbedded in the
message but instead be able to retrieve the image.
> <message type="chat" to="dest at example.com" from="src at 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="sid:123456789">
> <data xmlns='http://jabber.org/protocol/ibb' sid='123456789' seq='0'
> <amp xmlns='http://jabber.org/protocol/amp'>
> <rule condition='deliver-at' value='stored' action='error'/>
> <rule condition='match-resource' value='exact' action='error'/>
More information about the Standards