Re: mailto: + parameters?

"Daniel W. Connolly" <connolly@beach.w3.org> wrote:
>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.

	There is no reason to create those problems.  Both Anchors
and LINKs already have TITLE attributes, and Lynx "already" has it
as an attribute for FORMs.  The value of the TITLE attribute is
used if the document pointed to by the HREF or ACTION has no
TITLE tag.  It does not require any great leap of imagination or
intuition to equate the value of the TITLE attribute with the suggested
"Subject: " of a "document" the user will compose for an Anchor or
LINK with a mailto HREF, or the content the user will create when
filling out a FORM with a mailto ACTION.


	I am not recommending this, but here's how Lynx applies
the "extensibility principle", which cannot be made 100% reliable,
but to my knowledge has yet to fail in the real world:

	If a TITLE attribute was present and had a non-zero-length
value, that's what it uses for the suggested "Subject: ".  It does
an strrchr() for a '?' in the mailto address string, and if present,
checks whether it's followed by "subject" (case-insensitive) and an
'=', does an HTUnEscape() on what follows the '=' to get what is
probably the value for a Netscape interoperability trash, and sets
the '?' to '\0'.  Otherwise it leaves the '?' intact.  If a TITLE
attribute was present, it still uses that as the suggested "Subject: ".
Otherwise, it uses the trash.

	Then it parses the resultant address(es) string, looking
for ',' or ';' following each '@', which most likely are "list"
separators, since neither ',' nor ';' should be in host fields.
The it looks for and unescapes any hex escaped '%' or '#' in the
user field(s) -- just those two characters, not a full HTUnEscape()
of the user field(s), since those may have '%' characters that
are not escape tokens.


	I'll address what you wrote about news URLs later.  I
unfortunately have a one-track mind, and it's currently focused
on the 12-Apr-96 OBJECT (replaces INSERT, which replaces EMBED)
draft, and it was hard enought to get it off that track to write
the above.  8-) 


	I strongly suggest that the marketting deparments of the
Darwinean market force clients do an Alta Vista search for mailto
in the comp.infosystems.www.* news groups.  There is now a large
body of Webizens using mailto's because they do not have privileges
to set up CGI scripts, and a number of good programs for extracting
and decoding form content from email are now available.  I suspect
that the desire for reliable and "interoperable" handling of mailto
rivals, if not exceeds, any interest in the glitz.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Saturday, 20 April 1996 01:02:39 UTC