Re: SUMMARY: Running X/Mosaic from behind a firewall

Marc VanHeyningen <>
From: Marc VanHeyningen <>
To: Dave Crocker <>
Subject: Re: SUMMARY: Running X/Mosaic from behind a firewall 
In-reply-to: Your message of "Tue, 28 Sep 1993 14:36:38 MST."
Date: Tue, 28 Sep 1993 18:34:43 -0500
Message-id: <>
Thus wrote: Dave Crocker
>It's ironic to have been the offendor in suggesting content-type
>application, since it turns out that I, too, don't like it very
>much -- and for the same reasons as you.
>On reflection, I guess that type 'message' is entirely reasonable.
>I'd like to lobby against it, however, for two reasons.  (This isn't
>religion, just a desire to facilitate wide-ranging interoperability.)
>1.  Type 'message' has turned out to be rather strange.  At a minimum,
>it suffers the same fate as Application in having no commonality
>among the sub-types.  
>2.  A recipient that does not understand subtype 'http' will be
>frozen solid if the content-type is 'application' or 'message'.  I
>would like to find a way for MIME-aware, http-UNaware recipients
>to be able to still have some access to the information. 

I must disagree strongly with both of the above points.  If the
initial line of HTTP requests and responses is removed, it is a MIME
message.  Since the initial line will be endoed in the params,
message/http could be treated as message/rfc822 (which well behaved
gateways and MUAs should do anyway, since rfc822 is the primary
subtype of message) and it would still work fine; e.g. if the HTTP
response contains a GIF, a well-behaved MUA would treat message/http
as message/rfc822 and decode and display the GIF.

>While the original motivation for all of this is to support
>program-to-program exchanges, it might seem strange to worry about
>handling non-web-software recipients, but it doesn't hurt to allow such
>support and it MIGHT help.
>Given that almost all of the data are MIME-based, then defining the
>subtype to be under Multipart means that the data are still highly
>accessible, even for an unenlightened, non-http recipient.

I agree completely, which is why I believe a subtype of message is
what is most appropriate.

- Marc
Marc VanHeyningen  MIME, RIPEM & HTTP spoken here