Re: Second round for new URL scheme (mailserver)

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Wed, 11 Jan 95 11:46:11 CST


Date: Wed, 11 Jan 95 11:46:11 CST
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9501111746.AA21862@void.ncsa.uiuc.edu>
To: uri@bunyip.com
Subject: Re: Second round for new URL scheme (mailserver)
In-Reply-To: <95Jan11.010728pst.2760@golden.parc.xerox.com>
 <95Jan11.010728pst.2760@golden.parc.xerox.com>

Larry Masinter writes:

 > Being able to supply multi-line data is important.

This reminds me of a suggestion I had awhile ago to support something
like an HTTP URL that is submitted with method POST.  With method
POST, several additional parameters are passed not on the URL itself
but as standard input to the server.  I was thinking that in HTML, one
could specify the content of standard input with additional fields in
the anchor tag.  How you would specify this outside of HTML I don't
know.

The mailserver URL is bound to be used in ways that bump into arbitary
length limits, and furthermore the cryptic encoding is a severe crimp
on human readability.  So maybe it is time to think about a more
general scheme.  What is the deal with putting the whole URL on one
logical line anyway?

MIME provides a means for specifying a package of things as a single
entity.  One very nice feature is that one need not further encrypt
the content between divisions.  So using this idea, a general mail
URL might look like:

  mail:--end of content--
To: liberte@ncsa.uiuc.edu
Subject: Whoa! Radical idea

Are you on drugs or what?
--end of content--

-----------------------------

Here is another related thought.  There seem to be three kinds of URLs
that correspond to the underlying communication modes.  The mailto and
mailserver schemes send a message but don't expect a message in return
(there may or may not be a return mail message).  Most schemes send a
message and expect a single return message (even if it may be
multi-part).  Some schemes, such as telnet and z3950s, start up a
session for sending and receiving multiple messages.  These three
modes of communication seem to cover the territory completely.  

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/