Re: Web and Mail integration: a few key connections.

Keith Moore <moore@cs.utk.edu>
Message-id: <9311100103.AA17803@thud.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch,
        ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu
Subject: Re: Web and Mail integration: a few key connections. 
In-reply-to: Your message of "Tue, 09 Nov 1993 15:08:44 PST."
             <93Nov9.150852pst.2795@golden.parc.xerox.com> 
Date: Tue, 09 Nov 1993 20:03:14 -0500
Sender: moore@cs.utk.edu
> On web and mail integration:
> 
> Perhaps we could extend what Mime is using for 'content-type' to a
> more general 'resource type'; some kinds of resources are actual files
> with a given format, but other things that we want are URLs for
> interactive services which will have a type of 'telnet/3270' vs
> 'telnet/vt220', or multicast audio and video channels.

I think that's appropriate, so long as we know how to draw the line between
the MIME types that can be carried in mail and those that don't.

Maybe the distinction (at the top-level) is interactive vs. non-interactive.

So:

interactive-text/telnet; TERM=vt220
interactive-text/tn3270 (this really is a different protocol)
interactive-text/rlogin
interactive-text/x25pad
interactive-text/lat
interactive-text/cterm
interactive-text/dialup; PN="+1.615.555.1212"
interactive-audio/vat
interactive-video/nv  (but the names should describe protocols, not
                       specific tools)

Remember, the main reason for the top-level MIME type is to give gateways an
clue as to whether than discard, convert, or retain the content.  If
gateways are willing to do protocol translations across network boundaries
the distinction might somehow still be useful.

Keith