Re: mailserver: vs. expanded mailto: URL

These should be clarified in the HTML WG, I think:

> For instance, what is the implication of saying that if you put up a
> form with a METHOD=POST ACTION="mailto:garbagecollector@nowhere.com"?

It was the intent of RFC 1767 to specify this: the form data, encoded
by the ENCTYPE, gets sent to the email address encoded by the email
address.

> If this form has a field called "subject" or "mail-subject", should that
> field be systematically bound to the Subject: field?
> (as an editable default for the user interaction when the user confirms
> that he wishes to send mail, of course)

No.

HTML Form data is stylized enough that special processing for fields
like that doesn't make a lot of sense; the body of the message is
either application/x-www-form-urlencoded or multipart/form-data.

> If the METHOD=GET, what then?

I believe this is an error; the semantics for processing of METHOD=GET
on forms is to append ? and the (oddly) encoded form-data at the end
of the URL before actually doing a GET. This makes sense for HTTP and
not for other URL types.

> If instead, the URL is inside an <a href=>, what then?

? <A HREF="..."> determines a hypertext link that when selected is
connected to using GET semantics.

> Also, once you have solved the "any header" problem, you may go off and
> solve the "sign this message" problem or the "fill in the blanks" problem.
> No dearth of problems here....the "fileupload" RFC must be considered too.

The discussion on the mailserver: URL tries to deal with the common
header requirements. The "sign this message" problem seems to be
orthogonal, as it applies as much to HTTP as to MAILTO. "fill in the
blanks" is interesting, but seems to be too much processing to put
into a 'URL'. And, having considered 'fileupload', I don't see that it
has much to say about 'mailserver', since there doesn't seem to be a
useful semantics to apply to putting 'mailserver' URLs in HTML Forms.

> On the other hand, I am sympathetic to the idea that we only need
> one of these beasts, but I'm not certain we can redefine something
> that has wide (and inconsistent) usage so easily.

I think that the support issues for dealing with extending 'mailto'
are not much different from those for dealing with 'mailserver'. The
main thing is that GET on a 'mailto' seems to imply interactive
processing, while GET on a 'mailserver' implies 'send mail
automatically, and wait for a reply'.

Received on Wednesday, 22 November 1995 00:55:52 UTC