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

Richard Dobson richard at dobson-i.net
Fri Jan 16 14:15:37 UTC 2004

----- Original Message ----- 
>From: "Tomasz Sterna" <tomek at smoczy.net>
To: <standards-jig at jabber.org>
Sent: Friday, January 16, 2004 1:03 PM
Subject: Re: [standards-jig] XHTML-IM (JEP-0071) and in-band images

> Richard Dobson wrote:
> >I used "hash" because it matches up with the "hash" value of the file in
> >file transfer protocol, so I think it should be kept as hash e.g.
> >
> >
> Right.
> >I dont see any need to put the value into a sub node, it serves no real
> >purpose and unnecessarily increases the byte size of the xml.
> >
> >
> You mentioned that you want the <obj/> to serve more purposes than the
> <img/> tag.
> It should be easily extensible. Using attributes it isn't.
> >>
> >>
> >What I was thinking about to simplify things is to possibly put the hash
> >value as the cid e.g.
> >[...] And have the request like this, this keeps it nice and simple,
> >
> Some think Perl is nice and simple, but I see it cryptic.
> Same as puting the hash into the CID:

Huh??? Lets forget that the hash is even a hash for a moment, all it is is
an identifier.

> > <message type='chat' from='src at example.com/client'
to='dest 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='cid:552da749930852c69ae5d2141d3766b1'/>
> >         </body>
> >     </html>
> >     <obj xmlns='http://jabber.org/protocol/iobj'
> > </message>
> You are duplicating the information, gaining nothing.

Except telling the user that cid:552da749930852c69ae5d2141d3766b1 is an
embedded object, this way there is no reason other protocols couldnt be
built that could also use the cid: URI without impacting on IOBJ (e.g. a new
version of this protocol sometime in the future). I still see my example as
far cleaner and simpler than what you suggest and is functionally the same
as your suggestion. Also the cid does not necessarily have to be a hash,
thats up to the implementation, all a sending client has to do is keep a
list of the cid's its sent out and know which file they refer to when the
client comes to then request the file, I think most clients probably will
use hashes because its the simplest way to implement it, but try to keep in
mind that its just an identifier.

> And another thing. The hash '552da749930852c69ae5d2141d3766b1' is not
> really the attribute of <obj/>ect, but the attribute of file you want to
> get, so it does not belong to the <obj/> node.

I still dont get your reasoning, you seem to be wanting to make it far more
complex than it ever need be, how does having an extra element actually gain
anything, I dont see it gaining anything, when doing xml if you have one
piece of information to convey about something it is simpler to have an
attribute, but you only need to have an extra sub element if you are trying
to convey more than one piece of information about something i.e. the file
(which we arnt), I see the obj tag as representing the file itself anyway,
so I see no point in adding an extra sub element when it is clearly not

> I see it this way now:
>     <obj xmlns='http://jabber.org/protocol/iobj' cid='123456789'>
>         <file hash='552da749930852c69ae5d2141d3766b1'/>
>         [.. place for other iobj parameters ..]
>     </obj>
> and:
> <iq type='set' from='dest at example.com/res' to='src at example.com/client'
>     <query xmlns='http://jabber.org/protocol/iobj'>
>         <file hash='552da749930852c69ae5d2141d3766b1'/>
>     </query>
> </iq>

Read above, you are trying to make this far more complicated than it needs
to be, why do you have this need for the query element name? It can be
better used as I have demonstrated to make the protocol far more simple, not
just make it complex for the sake of it, "simple protocols are good" :).

> >Another extra protocol you might want could be thumbnail request for
> >images, so you can implement image transfer like in MSN6 and display
> >thumbnails in the chat window so a person can get a glace of what they
> >accepting before they accept.
> We are talking in context of HTML-IM.
> My browser does not show me thumbnails of <img> tags while I view the
> webpage.

Actually they can and do.

> So does not my wordprocessor with images inserted into text.

Yes it can.

> I don't see the reason of my IM client to behave diferently.

Why not an IM client is a communication mechanism it doesnt have much in
common with a web browser or word processor.

> The case you've mentioned belongs to the client-initiated file transfer
> (mostly batch file transfer), not the <iobj/> initiated case and not the
> <iobj/> object.

There is no reason we cant use it in the way I described, its a simple
functional extension.

> I would also like the preety dialog window with thumbnails, when my
> friend wants to send me some files. That's good. :-)
> But it is not the '<message><html/></message>' case.

Why not? It means you can re-use the rendering code, plus it was only an
example of possible expansion.

> >It should definately stay as "get" and not "query", it simplifies it and
> >allows it to be more extensible to have the action you are performing be
> >node name, using query is not a requirement in jabber iq protocols and is
> >to the protocol dev if they have a valid reason for it not to be.
> >
> >
> It simplifies the typing. But generally these are machine-generated

Simplifies typing?? Im not sure if it get what you mean.

> It does not simplify the parser.
> Now you can have the general IQ parser, that gets <query/> subnode and
> switch on its namespace.
> Your way it has to search a node for every "command" of every
> sub-protocol and check if the namespace is correct.

Im not sure what you are trying to get at here, im not sure if you really
understand the concept of XML namespacing, when processing an IQ tag and its
namespaced sub elements you should first only be looking at the namespace of
each sub element, at that stage the name of the node shouldnt matter, once
you find a namespace you understand you then process it according to the
specifications of that namespace, having names of the namespaced elements
other than "query" should not have any serious kind of impact on your parser
at all if you have coded it right and understood things right, just look at
protocols such as pubsub or file transfer, that show you dont need to
necessarily use a "query" top element.

> Same happens for IQ generation.
> APIs give you a function that you supply the iq type, query namespace,
> and subnodes, and you have the packet sent.

So??? If the API's cannot allow you to generate namespaced iq subelements
with whatever name and attributes you like then they are broken, so you wont
be able to use major new protocols such as pubsub that use a root node name
of "pubsub", or use filetransfer or SI.


More information about the Standards mailing list