- From: Al Gilman <asg@severn.wash.inmet.com>
- Date: Sun, 19 Nov 1995 21:30:32 -0500 (EST)
- To: uri@bunyip.com
- Cc: asg@severn.wash.inmet.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@wash.inmet.com http://www.inmet.com/~asg/
Received on Sunday, 19 November 1995 21:30:52 UTC