plain text protocol [was: Re: Performance analysis questions]
Rick Troth (troth@rice.edu)
Fri, 3 Jun 1994 12:54:19 -0500 (CDT)
> 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 <troth@rice.edu>, Rice University, Information Systems