Re: mailto: + parameters?

Dave the Magni (
Sat, 20 Apr 1996 02:20:03 GMT

From: (Dave the Magni)
To: "Daniel W. Connolly" <>
Subject: Re: mailto: + parameters? 
Date: Sat, 20 Apr 1996 02:20:03 GMT
Message-Id: <>
In-Reply-To: <>

Daniel W. Connolly sent this to the www-html list:

>In message <01I3N5YZXAEG001840@SCI.WFBR.EDU>, Foteos Macrides writes:
>>	The mailserv proposal is an expired IETF draft (the finger
>>proposal also has expired, unfortunately, without replacement or
>>enhancement).  One reason for creating a new access type is to
>>provide such functionality without breaking mailto, i.e., to
>>maintain and cheerish the interoperability principle.
>I don't quite follow: how does this break mailto?
>In theory, I suppose you're right:
>In RFC1738, I see:

You omitted my favorite part of that section, which immediately precedes
what you quoted:

   The mailto URL scheme is used to designate the Internet mailing
   address of an individual or service. No additional information other
   than an Internet mailing address is present or implied.

>   A mailto URL takes the form:
>        mailto:<rfc822-addr-spec>
>   where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
>   specified in RFC 822 [6]. Within mailto URLs, there are no reserved
>   characters.
(snipped - example of non-compliance by Netscape)
>So if somebody wanted to put ? in their email address, they could,
>using %-escaping.
>In practice, then, I don't see any problem with extending the mailto:
>syntax to include subject (and perhaps reply-to and a few others)
>header fields.

It could be done that way, but I see advantages to taking RFC1738 as is
and adding a subject= (and other fields) as possible attributes of <a>.

1) Browsers already ignore attributes which they do not understand.  It
isn't likely that a browser which doesn't understand ?subject will know
to discard it.  Placing it contiguous to an email address is bound to
result in undeliverable mail.

2) It would dovetail into stylesheets.  mailto: could have the
reusability and convenience of being located in a single file or
document segment.

Also, spaces may be desirable in a subject, but they are already
meaningful in RFC822, upon which RFC1738 relies.  If we're going to
parse the subject out of the right side of mailto:, why not do it in an
RFC822 compliant manner, e.g., 

<a href=" :...)(Keywords :...)(etc.)">

The header fields would be just another comment unless the user agent
used them to create mail header fields.

--'s always midnight, somewhere on the net.