Re: mailto: + parameters?

Daniel W. Connolly (
Fri, 19 Apr 1996 19:07:36 -0400

Message-Id: <>
To: Foteos Macrides <>
Subject: Re: mailto: + parameters? 
In-Reply-To: Your message of "Wed, 17 Apr 1996 09:46:39 CDT."
Date: Fri, 19 Apr 1996 19:07:36 -0400
From: "Daniel W. Connolly" <>

In message <01I3N5YZXAEG001840@SCI.WFBR.EDU>, Foteos Macrides writes:
>>Hmmm.. I wouldn't say that. This issue has been discussed at length,
>>and several proposals similar to mailto:foo@bar?subject=xxx have
>>been made. See, for example, the mailserver thread on the uri mailing list:
>	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:

   A mailto URL takes the form:


   where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
   specified in RFC 822 [6]. Within mailto URLs, there are no reserved

It's unfortunate that there are no reserved characters: that conflicts
with the notion of adding semantics to this ?foo=bar construct.

On the other hand, it seems that in practice, there are reserved
characters; at least %. I specified:


and netscape filled in "e" in the to: header field.

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.

The interoperability principle is only a few rungs above the
extensibility principle, after all.

>	That was also the reason, wasn't it, for adding nntp as an
>access type which accepts a host field, and leaving news as an access
>type which uses an independently configured host?

That was another bogus idea. There's nothing wrong with:


No conflict at all.

>  That's another
>interoperability principle, embodied in RFC 1738, which has been

How does this cause interoperability problems? Where is the
case where a conforming implementation will behave unreliably?