[30796] in North American Network Operators' Group
Re: ARIN Policy on IP-based Web Hosting
daemon@ATHENA.MIT.EDU (Andrew Brown)
Thu Aug 31 09:37:08 2000
Date: Thu, 31 Aug 2000 09:34:43 -0400
From: Andrew Brown <twofsonet@graffiti.com>
To: "Edward S. Marshall" <emarshal@logic.net>
Cc: Jason Slagle <raistlin@tacorp.net>, nanog@merit.edu
Message-ID: <20000831093443.A21958@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0008310809420.2197-100000@labyrinth.local>; from emarshal@logic.net on Thu, Aug 31, 2000 at 08:22:52AM -0500
Errors-To: owner-nanog-outgoing@merit.edu
>> 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."
