[standards-jig] IBB: Making it all "go"
me at pgmillard.com
Thu Apr 10 19:21:54 UTC 2003
Tijl Houtbeckers wrote:
> As for 1: in almost every real world case you'll *want* to have an ack
> packet, for the various reasons mentioned (flowrate control,
> reliability). And as pointed out you won't save much bandwith with all
> the extensions, though in those (rare?) cases you don't want acks
> you'll get a few less packets. If you were in this because you want to
> save bandwith and packets you might want to look for a different
> protocol alltogether anyway.
I completely disagree here. Why does every real world application have to ack
every packet? It seems more than sufficient in almost all cases to say ack every
5th packet. This is especially true if we've negotiated a packet size and or "#
of packets per ack" parameters. (Which would be a nice addition to this JEP
I want less acks to get better throughput if desired. We should not always be
relegated to the worst case scenario (as Matt Miller already pointed out).
> As for 2: I don't see any "philosofical" reasons why we couldn't use
> <iq/>. Sure, if <message/> would be fixed the same would go for
This is a moot point given #1 above. I don't want to ack every packet. Which
means we can't use <iq>. It's really _THAT_ simple.
> As for 3: I think this is out of the scope of the JEP. The potential
> purposes can be solved through other means (for wich this JEP too could
> be used).
How so??? This seems like a cop-out to me.. I think it would be really nice to
be able to send a friend a small JPG and have it go offline. As for
disk-space/spool issues... This is just not reasonable. On jabber.org (one of
the busiest public jabberd14 implementations) users receive huge email fwds, or
RSS notifications which can be upwards of 40-50Kb. It's not that big a deal to
put a cap on this (it becomes an xdb/offline implementation detail). My xdb
instance may decide to limit your total allowable spool for offline, etc.. This
is a nice feature that we should NOT overlook and just say "its out of scope".
> - Even if there will be a JEP for proper delivery sematics etc. it will
> take very long before every server will support this. Even when most
> do, it's difficult for clients to find wich servers do and wich servers
> don't. Even if it *does* make it into XMPP Core rather quickly, this
> would still greatly hinder implementation and usage for this JEP. I'm
> not saying you can never do this with a new protocol, but here we have
> a perfect working alternative.
XMPP core defines stream features. It would be easy to add in additional
features which that server supports. This would be a prime candidate for this.
And yes, it takes time for standards to propogate through existing
implementations. This is not a "bad" thing, and should not be a driver for
protocol design. Saying something like: "we can't do that because it would take
too long for existing implementations to make it work correctly" is a lame
argument and an implementation issue. We're designing protocols here, not
> - 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?
We're not complicating things, we're trying to do it the _right_ way. Why rush
things?? We've made enough mistakes with protocol in the past, the whole point
of the JSF is to not make the same mistakes over again, and to standardize
> But in a way, with the XMPP Core docs we *are* writing that JEP. So I
> propose this JEP has it's final tweaks, and is then send to the council
> for voting. If it does get rejected then the council, like it should,
> can give it's opinion on the issues summerized here and all the things
> not mentioned in this post.
I'm giving you my opinion right here, before it goes to vote, so we don't waste
time and the author's time & energy. Here are my bullet points.
1. I don't like using <iq> and the fact it forces me to ack every packet. Using
<message> and delivery events is a more robust and flexible solution. <message>
IS designed to be our generic data envelope. PERIOD. If this has not been clear
in the paste, I'm doing so now :) If it's broken, lets fix it. (xref #4 below).
If we need to standardize message events, lets do that too. (xref #4 below).
2. I _REALLY_ don't like the precedant we'd be setting for other JEPs which want
to use <iq> as an envelope for other data. If we allow IBB to use <iq> for data,
then we're implicitly saying that <message> is only ever useful for text
messages. Which is obviously not true.
3. I don't like avoiding hard questions just to allow a JEP to proceed through
the process quickly. If you need something like IBB in a project soon then use
your own namespace, and just do it. Your proprietary extensions do NOT need to
4. I think we need to address the delivery semantics around <message>. IBB is
just the tip of the ice-berg in uses of sending data inside the message
envelope. We're going to have the same problem with lots of other applications
if we don't do this now.
[some stuff snipped]
> I think it's best to push ahead with <iq/>. Even if the council rejects
> it for good or for bad reasons, it will put some presure on that
> council or others to fix the message stanza so it can be used the way
> they think it should be used.
Matt Miller has already volunteered to write this JEP. I surely don't have the
bandwidth to do this (I'm currently trying to finish the pub-sub JEP). I agree,
this is a good discussion that we need to have as protocol developers.
> My advice to all client authors is, if you want IBB in your clients, go
> ahead and implement Justin's JEP, because waiting for a useable form of
> <message> is going to be a long, long wait. Wether it will be rejected
> or not, it's a good JEP that get's the job done, in theory and in the
> real world.
You know, I'm sick of hearing this crap. There is NO reason that IBB can't be
changed to use the <message> element and work with the author of the
delivery-semantics JEP to finalize a protocol. Both JEPs can be voted on at the
Why does it take so long to get stuff pushed through the process?? I can tell
you: It's because people don't drive their JEPs through the process. Look at how
many experimental JEP's we have in the JEP list. Most of these JEPs have never
been discussed or proposed for a last call. I have received only 1 request to
sponser a JEP so far, and that was verbally. If you want to push something
through quickly, then write the JEP, and drive discussion, find consensus, do a
last call, and have it voted. It's not really that hard.
More information about the Standards