plain text protocol [was: Re: Performance analysis questions]

Rick Troth <>
Date: Fri, 3 Jun 1994 19:56:24 +0200
Message-id: <>
Precedence: bulk
From: Rick Troth <>
To: Multiple recipients of list <>
Subject: plain text protocol [was: Re: Performance analysis questions] 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Mime-Version: 1.0
Mime-Version: 1.0
> Gee... I didn't mean to crush anybody!
	I'll get over it.  I'm in a state (again; this happens to me 
a lot) where this thing is intuitively obvious to me,  and I feel 
strongly that it's right,  but I lack the formal argument which would 
persuade you (or at least the HTTP spec editor). 
>  ...  so it's really up to somebody else to decide
> what to deploy. I might try to influence the HTTP spec editor,
> though :-)
	Likewise, of course.   ;-) 
	I'd like to know if there's some forum other than  www-talk 
where this can be properly hammered out.   Then,  hopefully,  HTTP 
will follow that common lead.  (as will,  hopefully,  whatever else 
new and wonderful comes up,  maybe even  son-of-SMTP)   But where? 
> I disagree. Internet mail and USENET news serve a community
> that is not tied together by reliable 8-bit protocols. HTTP
> does. I see no reason to support multiple representations
> of the same information in HTTP headers.
	IP ties together a community of machines have radically 
different local representations of  "plain text",  floating point, 
integer,  sound,  image,  etc.   You mentioned EBCDIC.   I have a whole 
raft of logs that confirm that HTML is regularly stored and processed 
in EBCDIC  (though sent on the wire as ASCII,  because that's what we 
agreed to in the community).   There's also that weird charset that 
CDC used for the Cyber.   Dunno if it's still alive.   If so, 
then it's just as viable for representation for HTML as ASCII, 
but we speak ASCII "on the wire". 
> For example, look at XDR (part of NFS, etc.). Some systems
> are little-endian and some are big-endian, but they all write
> the bytes on the wire in the same order.
	Right.   And I say that  "plain text on the wire" 
is  "ASCII, delimited by CR+LF".   I think you agree,  right? 
But we try to make our servers  "liberal about what they accept" 
by making the CR optional.   Fine.   I say,  take that one step 
further and make trailing white space insignificant.   If you 
accept the former,  how do you justify rejecting the latter? 
> Dan 
Rick Troth <>, Rice University, Information Systems