There was a long discussion about possible variations on 'mailto:' in
the URI working group, culminating in the issuance of:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-mailserver-02.txt
which, unfortunately, failed to progress because it was not clear
that there was any consensus among the community of implementors.
I've been intending to put together a revision of RFC 1738 and 1808
that bring them more into line with current practice. Along the way,
separating out the description of individual URL schemes into separate
documents seems like a good idea.
If you were to draft a proposal for a revision to the 'mailto:' URL
scheme, we could probably fast track it through the IETF standards
process if we can get the participation of the implementor community.
================================================================
Date: Sun, 19 Nov 1995 18:30:32 -0800
From: asg(_at_)severn(_dot_)wash(_dot_)inmet(_dot_)com (Al Gilman)
Subject: mailserver: vs. expanded mailto: URL
To: uri(_at_)bunyip(_dot_)com
cc: asg(_at_)severn(_dot_)wash(_dot_)inmet(_dot_)com (Al Gilman)
SUMMARY:
I would like to try to explain why the mailto: URL scheme as it
is now limited and the current draft mailserver: URL scheme
between them still leave many make-mail-from-HTML opportunities
under-served; and recommend that a systematic approach to map
between URL and RFC 822 header syntax be adopted instead.
THE SHORTFALL:
The referring URL would often do well to be able to nominate a
draft message body and subject in mailto: <individual> situations
as well as mailto: <mailbot> situations. It is also unfortunate
that the mailto: URL scheme cannot nominate a cc: header as well
as the To: header. This is particularly true in mailto: URLs
inserted in HTML documents to collect comments. I have
frequently been confronted with the necessity to chose between
the button for technical feedback and content feedback, each of
which went to only one place. Usually the gripe or attaboy has
to do with visitor usability and does not allocate nicely into
just content or just technical. In most cases the feedback mail
should fan out to both technical and content owners. While this
can be done with a little extra mail-logical programming
somewhere else, the most direct way to accomplish this is at the
point of the URL.
In the Hypermail-generated archive that we use for the lynx-dev
email list, it would be an improvement in the group process
support if each page had a mailto: URL embedded that would send
mail to the list with a cc:<poster>. I am sure others can think
of other cases where one or another headers would be a natural
part of the message-template embedded in the URL. Not a lot,
just a lot of different headers in a lot of different URLs. This
is not a major burden on the mail composing tool. They all go
through the same transformation and the security problems are a
known short list.
THE ALTERNATIVE:
Use the general URI syntax feature of "parameters" to pass
arbitrary headers to the draft message. Only the headers with
known security problems have to be known to the tools
constructing the draft message. The headers and draft body of
the message should be carefully presented to the user for review
as is well explained in the present RFC draft.
That is to say, after the
mailto: mailbox
part of the mailto: URL, there would be
*( ; header-name=header-value)
optional set of header presets before the
*( / body-line )
tail giving the draft message body.
Each ( ; header-name=header-value ) instance gets transformed into
Header-name: header-value CRLF
in the header part of the draft RFC 822 message to be sent by
electronic mail to mailbox.
MAILSERVER: UNNECESSARY
Once the mailto: URL has been restored to health, i.e. to cover
the cases one wants in genuine mailto: scenarios, the necessary
mailbot commands are all handled within its capabilities and a
separate scheme is not needed.
The URL specification should get out of the game of trying to
pick winners as to what RFC 822 headers to interface to and which
not to. The URL syntax should be bound systematically to the
message syntax to pass headers through from URL to message draft,
and let the tool writers and HTML content writers determine which
headers are worth supporting.
Al Gilman
gilman(_at_)wash(_dot_)inmet(_dot_)com http://www.inmet.com/~asg/