[Foundation] Last Call standards

[Dave Waite]

Justin Karneges wrote:

>This doesn't sound like a problem, except let me share my experiences with the 
>council and DTCP.  Most of the council does not care about this sort of 
>thing.  The only person I can ever talk to about it is temas.  This number 
>should be higher.
>  
>
As a council member, I feel filetransfer is important. I have a number 
of friends who do not currently use Jabber because of glaring bugs in 
file-transfer (and not even so much that it is or is not there, but that 
it is there and works so horribly between different clients). I really 
would like to see a comprehensive out-of-band transfer document. in-band 
transfer is another matter, but I'm not really that opposed to it as 
long as out-of-band exists.

However, there are quite a few JEPS for file transfer and even more 
'theories' running around about how file transfer should/could work. I 
have shied away from participating in file transfer work because there 
are so many conflicting proposals and implementations out there - I want 
to see a single file-transfer standard finalized, and while I would be 
more than happy in providing advice to that JEP, I haven't seen the 
community rally behind just one yet. Taking a side in skirmishes just 
isn't worth my time. This is not saying I won't provide technical 
evaluation and help if asked for it - I will always do this. It is more 
that I have had faith that someone would set up and consolidate the 
issues and opinions and try to unite the camps - someone besides me. ;-)

That said, what I'm _hoping_ for in a filetransfer is:

- Use of standard network protocols for initiation and transfer. Most 
often when people think they can do it better themselves, they either 
can't or the existing mechanism didn't meet their precise needs. Using 
something like SIP for initiation or HTTP for transfer means I can use 
existing code in my language of choice for implementation, or at least 
as a major stepping stone.

- Proxied data transfer, with optional direct transfer. I mostly want to 
see file transfer work in all network configurations, not be overly 
complicated for the sake of optimization. Preferably, it would only fail 
if there was some sort of transient or policy error (remote user went 
offline, proxy service unavailable, file transfer exceeds maximum size 
or user quota). I also would like someone who exposes a flash client or 
java applet client to their user base to be able to support file 
transfer out-of-the-box, which is difficult with direct transfers.

I would prefer direct transfer, but understand that it would take quite 
a bit of logic in order to make this work. (For example, both entities 
could have real IPs but be behind firewalls which block ICMP - 
attempting a direct connection first would mean that the file transfer 
would sit idle until the operating system gives up on retrying the 
initial connection).

- Understanding that the client is supposed to be thin, and that 'server 
knows best'. For non-enterprise users, there should not be configuration 
required for getting a client to transfer files correctly. The 
configuration should be a function of the server and be performed by the 
service administrator. For corporate servers, administrators who want to 
enable file transfer can configure whether direct connections would work 
and even additional parameters required for direct connections. Having a 
proxy server open to the outside in this environment means that there is 
no additional network traffic, only additional latency in the transfer 
and load on that machine. Even on a public server, you can do 'tricks' 
like having the server attempt a dummy transfer operation whenever the 
client's session starts to determine if inbound communication is possible.

For a distributed client/server system, the logic for filetransfer 
belongs on the server. There also exists the possibility for offline 
file transfer - having files waiting for when the client connects again. 
Only the server would know if this sort of service is available for that 
user.

- Allows enterprise environments to disable or restrict file transfer. 
Some companies are required by law to track electronic communications, 
and they need to either be able to restrict file transfer to only be 
proxied, or disable file transfer thru IM altogether.

- Provides the option for later support for security and encryption.

- Is scalable at least to 10 TB files and 500k users connected to one 
server / farm (this is ignoring the network bandwidth issues, and 
focusing exclusively on the hardware requirements for the proxy service 
and whether the proxying can be adapted to this hardware)

I'm not hoping for people to dream up a generic tunnelling protocol or 
initiation protocol for non-Jabber protocols. If they wish to do this, I 
would hope they would do so under the IETF.

Also keep in mind that while I only want one 'standard' file transfer 
protocol, I wouldn't mind others being proposed as informational which 
provide additional functionality (e.g. a mac client using Rendezvous, or 
tftp transfers on a local network.)

-David Waite