[standards-jig] IBB: Making it all "go"

Rachel Blackman rcb at ceruleanstudios.com
Fri Apr 11 02:24:05 UTC 2003

>> There's no technical reason (other than sheer 'eeew?  WHY?!' factor and
>> BASE64 encoding bloat) that I can't encode a webpage entirely in the
>> headers of an HTTP result as BASE64 strings either, and eliminate the 
>> HTTP stream.  But it's not what HTTP headers are designed for so (as 
>> well as being architecturally repulsive) it's not philosophically 
>> correct, and this doesn't seem like what IQ was designed for either. :)
> Neither <iq/> nor <message/> was meant for this. Let's face it, 
> <message/> is designed with delivering textmessages between *persons* 
> in mind. HTTP = Hyper Text Transport Protocol if I'm not mistaken. 
> Don't tell me you never used it to open a bytestream before. The points 
> "<iq/>, it's kinda like HTTP, we could do IBB with it" is just as much 
> correct as "<message/>, it's kind of like information pushing, we could 
> do IBB with it". Right now, <iq/> is the best tool for the job. It 
> might be a little bit more unefficient, but <message/> is not even safe 
> for use. That's why the JEP uses <iq/>, and that's why IMHO, it should 
> be accepted. 

Of course I've used HTTP to open a bytestream. :)  But you're actually sort
of making my point for me; <iq/> is the HTTP header data, which I send and
receive back, and thus have negotiated a stream.  <message/> is the stream

To put it another way, using psuedo-HTML:

iq get:
   GET /mystream HTTP/1.1

iq result:
   HTTP/1.1 200 OK
   Content-type: application/binary-stream

   Row, row, row your code.
   Gently down the stream...

If we want to carry the HTTP analogy further (since other people than me
are running with it now), what is being suggested with IQ is something very
loosely analogous to (using still more psuedo-HTML to draw a clearer

iq get:
   OPEN /mystream IBB/1.0

iq result:
   IBB/1.0 200 OPENED
   Content-type: application/binary-stream

iq set:
   PUT datablock IBB/1.0
   Data:Row, row, row, your code.

iq result:
   IBB/1.0 205 ACK

iq set:
   PUT datablock IBB/1.0
   Data:Gently down the stream...

iq result:
   IBB/1.0 205 ACK

...and so on.  It feels philosophically and architecturally /wrong/, at
least to me, to use the negotiation blocks for data transport.  I /can/ do
it; that doesn't mean I /should/. :)

The analogy's not a perfect one, of course, but to carry it a little
further... an HTTP proxy shouldn't need to know what kind of stream is
going across it.  Nor do I think IBB should need to inherently know what
the requirements of the data going across it are; that should be up to the
application once the stream's negotiated.  If I want to ack every packet,
then I should be able to.  If I want to ack every tenth packet, I should be
able to.  If I don't want to ack anything for whatever reason, I should
still be able to.

Hopefully that clarifies what I was trying to say.   (Look, I found more
pennies!  Have two!) :)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030410/74d139bf/attachment.sig>

More information about the Standards mailing list