Re: revised mailto spec

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Mon, 9 Dec 1996 15:59:12 -0600 (CST)


From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
Date: Mon, 9 Dec 1996 15:59:12 -0600 (CST)
Message-Id: <199612092159.PAA04133@void.ncsa.uiuc.edu>
To: Tim Berners-Lee <timbl@w3.org>
Cc: Larry Masinter <masinter@parc.xerox.com>, uri@bunyip.com, jwz@netscape.com
Subject: Re: revised mailto spec
In-Reply-To: <32AC7AF0.5EC5@w3.org>
 <32AC7AF0.5EC5@w3.org>

Tim Berners-Lee writes:
 > If this is the same proposal as has been around for a while
 > to make a mailto: URL a way of extracting data by email
 > reply, then I would oppose that.

By "extracting" I assume you mean something like an access as done by http.

The mailserver idea was not exactly to do a resource access.  Mail
would still be asynchronous.  In other words, you send mail to a mail
server *perhaps* expecting a response but certainly not an immediate
response within the same connection.  (Correct me if I am wrong.)

Do we need a vastly different user interface to support an
asynchronous but automatically generated response?  Asynchronous but
*manually* generated (human generated) responses need to be supported
in much the same way, I would argue, in that the association of a
message and its response should be made visible (optionally) to the
user.  With automatically generated responses that are automatically
*handled* by the recipients, we might get to the point of supporting
some form of agent technology via email messaging.  This is a
different conceptual space than mere humans sending messages, but our
current technology would still be useful.  E.g. we can still display a
list of messages sent to and from various addresses.  

I think what Larry was suggesting is that the features provided by the
mailserver URL (namely, additional mail header and body specification,
but nothing different in terms of expected response) could be added to
the mailto URL more easily.  I agree, but I recall that Roy Fielding
had a disagreement with the mailserver URL on the grounds of security
dangers.

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