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

Robert Norris rob at cataclysm.cx
Fri Apr 11 01:53:10 UTC 2003

> PGM seems to feel though that "acks" make the protocol so seriously 
> flawed it can't be used at all. I'd like to know the opinion of the 
> rest of the community and council on this. 

You asked ;)

For just acks, my preference would that acks are not required. The use
(and frequency) of acks would ideally be a negotiated option - a kind of
measure of stream reliability, if you will.

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

I think your analogy to HTTP is somewhat flawed. A HTTP session has two
distinct parts - the setup, paramater exchange bit, and the actual data.

We have similar mechanisms in Jabber - we've traditionally used <iq/>
for exchange of meta-information (paramaters, etc), while using
<message/> for data transfer.

It seems to me if we're trying to draw an analogy to HTTP, then placing
both the stream metadata and the actual data in <iq/> is equivalent to
placing the data proper in the HTTP header.

> Maybe a name change to "reliable IBB"?

Why require it to be reliable? As I said above, provided the mechanisms
to select the desired reliability on a per-application basis.

> >> - It's a simple JEP and with it you can do perfectly what it's 
> >> designed for, both in theory and the real world. Why complicate 
> >> things? 
> >
> >Because taking the path of least resistance doesn't seem like the best 
> >way to ensure a solid protocol? 
> If anyone can point out something that is not solid about the JEP as it 
> is, please do so. Perhaps giving in to a questionable philosophical 
> argument and saying: "allright, if you want to use the message stanza 
> we'll wait another few months/years" is a path of even less resitance 
> ;) 

My other concerns about using <iq/> for data exchange is that it sets a
bad precedent for the future direction of the protocol, and brings into
question the worth of the <message/> stanza. At the moment, things are
very simple - <message/> is for data exchange, <iq/> is for metadata
exchange and negotiation.

I agree, we need facilities to add reliability to <message/> stanzas.
However, I don't beleive that IBB will be delayed significantly just
because these facilities don't exist. There's nothing stopping them
being developed in parallel, and indeed, we already have someone working
on such a JEP.

(I also note that the existing mechansims (jabber:x:event and
jabber:x:expire) are enough to get an initial version of this protocol
working, in a way that can be extended easily later. If done in this
way, IBB does not even have to depend on these reliability facilities).

I also don't see the urgency for IBB - we have one potential application
for it (JEP-0052, still experimental) and we have a solution that can
perform roughly the same tasks (JEP-0065, one vote needed before it goes
to Draft).

I'll state here for the record that if JEP-0047 were to go to Council
for a vote in its current state, I will vote -1 because I don't beleive
that its the right way to do it (gut feeling is a wonderful thing), and
it sets a bad precedent (as well as bringing into question the
long-term utility of <message/> as more than just a IM facility).

However, I will commit right now to implement (in jabberd2) any message
reliability mechanisms as soon as they are ratified by the Council (or a
few days after). I would hope that having a server that implements the
necessary pieces would help to speed adoption.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030411/9d82517a/attachment.sig>

More information about the Standards mailing list