- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Fri, 19 Apr 1996 19:07:36 -0400
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: www-html@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
Received on Friday, 19 April 1996 19:07:43 UTC