nanog mailing list archives
Re: ARIN Policy on IP-based Web Hosting
From: Andrew Brown <twofsonet () graffiti com>
Date: Thu, 31 Aug 2000 09:34:43 -0400
Until this happens, I can see no viable alternative to FTP.HTTP, perchance? The only things missing are a machine-parsable file indexing method (which would be easy enough to standardize on if someone felt the need to do so; think a "text/directory" MIME type, which would benefit more than just HTTP, or use a multipart list of URLs), and server-to-server transfers coordinated from your client, which most people have disabled anyway for security reasons. But, you get the added benefit of MIME typing, human-beneficial markup, caching if you have a nearby cache, inherent firewall friendliness (no data connection foolishness), and simple negotiation of encrypted transfers (SSL). And for command-line people like myself, there's lynx, w3m, and wget.
http is a good idea, but... "mime typing"? i don't want a program that's gonna tell me what i have to do with my data, or with whihc program i will have to open it later. my data belongs in a file, exactly as i requested it. with the appropriate line-termination, of course, which http doesn't do. ""human-beneficial markup"? you just said we need a "machine-parsable file indexing method". what do we need humans for? caching usually gets in the way. "no data connection foolishness" translates to no way to abort a connection other than by dropping it, reconnecting, and exchanging authenticators again. highly inefficient.
FTP is disturbingly behind on features, some of which (decent certificate authentication, full-transaction encryption, data type labelling, and cache usefulness) are becoming more important today. Either the FTP RFC needs a near-complete overhaul, or the HTTP and other RFCs need to be updated to include the missing functionality.
two things would improve ftp: some sort of tls for the control channel (and maybe the data channel as well), and kernel support for the data channel. all i mean by this is the ftpd opens the file to be sent, the socket to which the data needs to be read, and passes them both to the kernel saying "splice these together, would you?" no more kernel- to-userland-and-back copies, the kernel will *know* when the receiver can take more data, and the ftpd can "abor" whenever it needs to by closing the data socket. this feature would, of course, be mutually exclusive with the optional encryption. -- |-----< "CODE WARRIOR" >-----| codewarrior () daemon org * "ah! i see you have the internet twofsonet () graffiti com (Andrew Brown) that goes *ping*!" andrew () crossbar com * "information is power -- share the wealth."
Current thread:
- Re: ARIN Policy on IP-based Web Hosting, (continued)
- Re: ARIN Policy on IP-based Web Hosting sigma (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Joe Shaw (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Bennett Todd (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Ron 'The InSaNe One' Rosson (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Joe Shaw (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Shawn McMahon (Aug 30)
- Re: ARIN Policy on IP-based Web Hosting Masataka Ohta (Aug 30)
- RE: ARIN Policy on IP-based Web Hosting Joe Shaw (Aug 30)
- RE: ARIN Policy on IP-based Web Hosting Jason Slagle (Aug 30)
- RE: ARIN Policy on IP-based Web Hosting Edward S. Marshall (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Andrew Brown (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Peter van Dijk (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Jeff Mcadams (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Andrew Brown (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Alex Kamantauskas (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Andrew Brown (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Steve Sobol (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Jim Mercer (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Steve Sobol (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Thomas Marshall Eubanks (Aug 31)
- Re: ARIN Policy on IP-based Web Hosting Mr. James W. Laferriere (Aug 31)