mailto security and semantics

[Daniel LaLiberte <[e-mail]>]

Larry Masinter writes:
 >                         The mailto URL scheme

 >    For greater functionality, because interaction with some resources
 >    may require message headers to be specified as well as the mail
 >    address, the mailto URL scheme is extended to allow setting mail
 >    header fields.

I'm in favor of this extension, but I recall Roy Fielding's strong
objection last time it was suggested because of security concerns.  I
wonder if the sections on unsafe headers and security issues is
sufficient warning to implementors, or if something else is required,
such as stronger restrictions on the allowed headers.  It might help
to include some rationale as to why the unsafe headers might be
dangerous, or include a reference to a document with such discussion.

 > 3. Semantics and operations
 > 
 >    A mailto URL designates an "internet resource", which is the
 >    mailbox specified in the address. When additional headers are
 >    supplied, the resource designated is the same address, but with an
 >    additional profile for accessing the resource. While there are
 >    Internet resources that can only be accessed via electronic mail,
 >    the mailto URL is not intended as a way of retrieving such objects
 >    automatically.

... though it may be used to do so, at least asynchronously.  I think
this way of talking about a mailbox as a resource is confusing, and it
gets worse in the following.

 >    A "mailto" URL has unusual semantics because the operation of
 >    "GET"ing such a URL does not usually result in the immediate
 >    retrieval of an information object. Rather, the GET operation
 >    merely opens an interactive user session for mailing to the
 >    designated address with the various header fields set as default;

This seems to reflect an http bias.  Why should the action of clicking
on a mailto anchor (or the method associated with that action) be
called "GET".  The telnet URL is similar in not "GET"ing anything.  If
we want any kind of universal semantics of "GET" operations, it should
entail actually making a request to get a copy of some resource, not
doing some other operation such as sending a message or opening a
session.  If we need a name for the generic operation associated with
clicking on an anchor, how about "OPEN"?  (This issue has more to do
with the new guidelines for URL schemes.)

 >    the POST operation results in the sending of electronic mail to the
 >    designated address with the POSTed body replacing the body of the
 >    message. 

Is the "POST" operation in this case activated when the user submits
the message, as opposed to clicking on the anchor which you called "GET"?  

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