[standards-jig] IBB: Making it all "go"
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
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
Size: 189 bytes
Desc: not available
More information about the Standards