Re: SUMMARY: Running X/Mosaic from behind a firewall
Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Dave Crocker <dcrocker@mordor.stanford.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: SUMMARY: Running X/Mosaic from behind a firewall
In-reply-to: Your message of "Tue, 28 Sep 1993 13:49:51 MST."
<9309282049.AA24086@Mordor.Stanford.EDU>
Date: Tue, 28 Sep 1993 16:22:50 -0500
Message-id: <695.749251370@hound.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Thus wrote: Dave Crocker
>Stylistic note:
>
> ---- Included message:
>
> I proposed something like this a while back, with Content-Types of
> "message/http-request" and "message/http-response". I probably still
> have the proposal someplace if people are interested.
>
>
>Probably should try to define only application/http and use the parm
>parameter to distinguish request from response.
application/http is pretty clearly the Wrong Thing. "application" is
a cop-out type to use when no other type seems to fit. Both HTTP
requests and HTTP responses, in 1.0, are MIME messages with an extra
line at the top. If you represent them as "application" then you end
up with multiple redundant encodings, while "message" will allow
gateways to tranfer the data appropriately, move data between
8-bit-clean MTAs and ones that aren't, and all the other benefits MIME
provides.
>There is an emerging preference to have the content sub-type have
>as large a scope as possible.
I suppose we could have "message/http" and have parms to distinguish
requets from responses.
>However, it occurs to me that the response might be a ... MIME
>object. This suggests that you might really want to have the core
>type be multipart/http!
The only real question in my mind is how to represent the one line of
data which isn't part of the MIME message body (i.e. the first line of
both the request and the reply.) It could go either in a multipart or
in the params; the former is cleaner but I think the latter is more
sensible.
- Marc
--
Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here