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

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Marc Andreessen: "simple HTML list considered harmful"
• Previous message: Lou Montulli: "Re: simple HTML list considered harmful"
• In-reply-to: Dave Crocker: "Re: SUMMARY: Running X/Mosaic from behind a firewall "

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 14:36:38 MST."
             <9309282136.AA24991@Mordor.Stanford.EDU> 
Date: Tue, 28 Sep 1993 18:34:43 -0500
Message-id: <3909.749259283@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Dave Crocker
>Marc,
>
>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  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here