Tim's suggested format for email URL:
Seems fine to me, except I would prefer the prefix "email:", as in
<A TITLE="add www-announce" HREF="email:email@example.com">
I too am doubtful about including the mail headers as part of the URL,
but note that the optional TITLE attribute for anchors can be used to
specify a title field. Clicking this link would bring up a mail-window
(e.g. "xterm elm firstname.lastname@example.org") so that the user can then
type the body of the message and modify the headers.
Peter Lister's suggestion for the equivalent of a "paper reply-paid card"
with boxes to be filled out by the customer, would be a good fit for a
form, invoked by clicking the link. In this case the form would be specified
as a separate document, which when completed is mailed rather than being
sent back to the server.
> * The To: and From: fields of messages would be treatable
> as hypertext links, just as the Newsgroup: and Reference: fields
> are now.
> * A link type <LINK REL="AUTHOR" HREF="email@example.com"> would be
> a formal way of attributing responsability.
This is not at neat - the parser needs to know that REL="AUTHOR" implies
that the HREF is an email address. It would be more straightforward to
stick to the previous format and require the presence of the "email:" prefix.
<LINK REL="AUTHOR" HREF="email:firstname.lastname@example.org">
Jim Davis comments:
> So though I have no specific syntactic proposal to make I
> suggest reply mail might be either
> 1) a special case of general programmatic invocation
> 2) a special case of form-filling-queries
> On the other hand I recognize the trend of late in WWW to
> implement special purpose features in an adhoc manner without
> trying to design the ultimate feature set; and this may even
> be a good idea given our lack of experience in the matter.
Jim, there is no need to implement special purpose features for this. We will
be able to handle forms in a general way with HMML and the new HTRQ and HTTP
protocols. The addition of "email:" (or mailto) to the URL format is
a logical extension.
n.b. Jim, I am currently drafting a proposed standard for HMML (aka HTML+)
and will distribute the results real soon now. Send your input to
me c/o www-talk discussion group.