[standards-jig] IBB: Making it all "go"
dizzyd at jabber.org
Thu Apr 10 04:52:34 UTC 2003
On Wednesday, Apr 9, 2003, at 19:46 America/Denver, Rachel Blackman
> If the behavior adopted for <message/> in terms of offline storage and
> redirection is sufficiently troublesome in this situation, then maybe
> needs to be examined overall? Or else perhaps the definition of what
> IQ is
> and what message is needs to be clarified? :)
I suspect this is the root of the entire problem -- the semantics of
<message> are not sufficient for something which is/was very much
intended to be a generic data envelope. Consider that the _only_
positive thing that <iq> has going for it as a basis for IBB is the
delivery semantics. Beyond that, there is not much to recommend the
usage of <iq> for this particular protocol. Even <iq> proponents
acknowledge that ACK'ing every packet will likely be a bit much.
So, how do we fix the problem?
We need to provide the ability for a client to suggest preferred
delivery semantics to the server. We already have a primitive form of
this in jabber:x:expire -- what if we took it one step further? What if
we specified an extension namespace which provided the following
1.) Suggested message lifetime boundaries (expiration) -- Expires
immediately, Never Expires, Expires in X seconds
2.) Suggested handling for message bound to non-existent JIDs -- if a
specific address was unavailable, the message would be bounced
This extension namespace would replace jabber:x:expire, and be attached
to any <message> stanzas as a suggestion for how the client would like
the server to treat a particular stanza/packet. At the end of the day,
it is still the server's choice insofar as what it wants to do with the
packet -- that's true with any packet. This does neatly deal with all
the objections so far for using <message> and would make <message> much
more usable for non-IM applications..like IBB.
Of course, there will be two major concerns at this point:
1.) Why not "fix" IQs to not require a response?
IQ is the one packet we have available in the Jabber/XMPP repertoire
for doing structured conversations. It is useful for this task due to
the fact that it REQUIRES every request to be matched with a response.
At this point in time, we have found no problems with this behavior --
it simply works. The only reason there has been talk of "fixing" IQs of
late has been the fact that the other, natural protocol element
(<message>) which we normally use for general data delivery is broken.
So why not fix the protocol element that is actually behaving
incorrectly -- instead of trying to compensate by changing the behavior
of another perfectly good element?
2.) Even if we do introduce new routing semantics/hints for <message>,
they won't be immediately widespread..the problem will only be fixed in
This is a good point. However, first consider that IBB is unlikely to
actually encounter these problems of "rollover routing" and
unintentional off-lining in the wild -- at least in the first six
months. Even if every major client quickly adopts IBB, that doesn't
mean people will immediately use it for every transfer. Adoption by JSF
does not immediate adoption make -- look at x:data. It's a great
protocol, but there is still a significant portion of clients out there
that don't support it.
The second consideration for this point is that fixing <message> solves
future problems that we may run into. As more and more people deploy
Jabber for non IM centric applications they _will_ want the ability to
control message delivery semantics. Are we going to force all of them
to use <iq>?
Using <iq> may be quicker/easier in the short term, but we must be
designing protocols for the long haul -- and that means dealing with
the actual problems at hand and not doing one-offs to solve problems
we'd prefer not to think about it. It's the very nature of protocol
Just some additional thoughts...
More information about the Standards