[standards-jig] XHTML-IM (JEP-0071) and in-band images

Tomasz Sterna tomek at smoczy.net
Thu Jan 8 21:48:36 UTC 2004

W liście z czw, 08-01-2004, godz. 13:25, Richard Dobson pisze: 
> > I've added AMP for the #inline image.
> Why do you not want it to be stored offline?

Server offline storage place is limitted.
I would rather want to store plaintext messages there, not the images.
I don't want to lose some important plaintext messages, becouse someone
sent me a message fulled with smileys.

> 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.

Is that fallback defined and standard or at the client author

> > 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,

OK. But we cannot define what is "small".
What we consider "large" maybe "small" in two years, or less... ;-)
Available bandwitch is growing. There appears technologies like GPRS.

> 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.

We should be able to screen the client from IOBJ via privacy-rules.
And server-configuration should define allowable sizes of IOBJ/IBB.

> > 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.

That would delay sending of the message but it's an expected cost.

> > I would still advocate the generic Jabber File Transfer Protocol URL
> > format.
> 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,

Isn't this a flaw of the SI/filetransfer protocol?
I think the mime-type is a minimum of metadata, that should be attached
to the file.

> 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.

OK. I agree. We now have to define IOBJ payload. :-)

> 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,

OK. Now I see your reasoning.

JID:smoku at chrome.pl

More information about the Standards mailing list