I believe that if Jabber client developers want to see Jabber grow to the popularity of a system like AIM we need to consider what a Jabber system with 1 million users would look like and how to make that practical.
On the other hand, one of the goals of Jabber is to be more distributed, so that unlike existing monolithic services, not everyone in the world has to connect to the same server. Your ISP will have a Jabber server, my employer will have one, et cetera. There may be huge ISPs that have millions of users, but they already have phat pipes and massively replicated servers.
In-band file transfers are just not feasible using this approach.
Again, I disagree. The Jabber architecture is very much like SMTP, and SMTP servers have been handling "in-band" file transfers for decades. Even huge ISPs and mail services accept file enclosures, although they may impose limits on the file size.
How about this for a proposal. Define specifications for a separate oob server. To make it simple to convert any web server into a compliant oob server, we define the system using only httpd. It accepts file uploads given authentication, and allows file downloads using temporary URL links.
I don't see how this does anything but move the supposedly-intolerable burden of file transfer from one server onto another.
In any case, if we do design a relay server, I would prefer to see a more efficient solution where the server directly streams data from one client to another rather than having to store-and-forward the entire file.
Part of the standard should be incentives to run oob servers by people other than Jabber.
Well, this just sort of sweeps the issue under the rug by making it someone else's responsibility.
And anyway, who are "people other than Jabber" Or rather, who is "Jabber"? Jabber is a service that anyone can run. I repeat: when Jabber takes off it's not just going to be jabber.org and jabber.com hosting everyone in the world. Jabber will be a distributed piece of the infrastructure just like SMTP or HTTP.
In general I think this fear of in-band transfer performance is a classic example of premature optimization. When you're designing a large system you don't start off by guessing that something is going to be a bottleneck and immediately build an optimization ahead of time instead (especially not an optimization, like jabber:x:oob, that handles only the special case without firewalls or NAT). You build the basic, most robust case, then if it does turn out to be a bottleneck you add optimizations for specific circumstances.
�Jens
