Re: mailto: + parameters?

Daniel W. Connolly (connolly@beach.w3.org)
Fri, 19 Apr 1996 19:07:36 -0400


Message-Id: <m0uAPH7-0002ThC@beach.w3.org>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: www-html@w3.org
Subject: Re: mailto: + parameters? 
In-Reply-To: Your message of "Wed, 17 Apr 1996 09:46:39 CDT."
             <01I3N5YZXAEG001840@SCI.WFBR.EDU> 
Date: Fri, 19 Apr 1996 19:07:36 -0400
From: "Daniel W. Connolly" <connolly@beach.w3.org>

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:
>>
>>http://www.altavista.digital.com/cgi-bin/query?pg=q&what=web&fmt=.&
>>	q=host%3Awww.acl.lanl.gov+%2Bmailserver
>
>	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:

        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.

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:

	mailto:%65

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:

	news://foo.com/comp.text.sgml

No conflict at all.

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

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

Dan