From: firstname.lastname@example.org (Dave the Magni) To: "Daniel W. Connolly" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: mailto: + parameters? Date: Sat, 20 Apr 1996 02:20:03 GMT Message-Id: <email@example.com> In-Reply-To: <m0uAPH7-0002ThC@beach.w3.org> 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 . 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="mailto:firstname.lastname@example.org(Subject :...)(Keywords :...)(etc.)"> The header fields would be just another comment unless the user agent used them to create mail header fields. -- email@example.com http://www.tezcat.com/~darsal/ ...it's always midnight, somewhere on the net.