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

Dave Smith dizzyd at jabber.org
Thu Apr 10 04:52:34 UTC 2003


On Wednesday, Apr 9, 2003, at 19:46 America/Denver, Rachel Blackman 
wrote:

> If the behavior adopted for <message/> in terms of offline storage and
> redirection is sufficiently troublesome in this situation, then maybe 
> it
> 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 
capabilities:

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

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


Just some additional thoughts...

Diz




More information about the Standards mailing list