[30801] in North American Network Operators' Group
Re: ARIN Policy on IP-based Web Hosting
daemon@ATHENA.MIT.EDU (Andrew Brown)
Thu Aug 31 10:14:51 2000
Date: Thu, 31 Aug 2000 10:12:38 -0400
From: Andrew Brown <twofsonet@graffiti.com>
To: Jeff Mcadams <jeffm@iglou.com>
Cc: nanog@merit.edu
Message-ID: <20000831101237.A22275@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: <20000831094630.A36@iglou.com>; from jeffm@iglou.com on Thu, Aug 31, 2000 at 09:46:32AM -0400
Errors-To: owner-nanog-outgoing@merit.edu
>>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.
>
>Where on earth did you get the idea that mime typing requires all that?
not that it requires it, but that it usually happens. if i get a file
via http with a mime type that the browser "knows what to do with", i
usually don't get a choice. likewise if i get a file via email with a
octet-stream mime type, most readers won't show it to me by default.
>The mime type is just one side telling the other side what it thinks is
>in the file (and giving some other nice little benefits like encoding
>transformations and stuff). What you do with the file once you get it
>doesn't have anything to do with the mime type unless *you* configure
>your program to pay attention to the mime type and do something with it.
>If you want to tell your program to open a postscript file in RealMedia
>Player...so be it, you can do that...not to much effect I wouldn't
>think, but that's totally up to you to do it. If you want to set your
>program so every mime type just dumps out to a file, you can do that
>too.
the mime type is made up, usually based on the file's extension, which
is, of course, passed along with the contents of the file when you
transfer it. it's no extra information in this context.
>>my data belongs in a file, exactly as i requested it. with the
>>appropriate line-termination, of course, which http doesn't do.
>
>Again, conversion of line termination is controlled by the end system,
>not the protocol itself. FTP happens to have defined in the RFCs how it
>should be handled...there's no reason you can't do the same process with
>http-received files.
when you initiate an "ascii" mode transfer, the remote ftpd translates
the file from local line termination to network oriented line
termination (ie, cr, or crlf or lf becomes crlf). your ftp client
then translates back to local line termination from network line
termination. this is how you can transfer files between windows
machines, macs, and unix boxes, and always end up with something you
can read locally.
http doesn't do this.
--
|-----< "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."
