To: Harald.T.Alvestrand@uninett.no Cc: email@example.com, firstname.lastname@example.org In-Reply-To: Harald.T.Alvestrand@uninett.no's message of Tue, 21 Nov 1995 04:25:55 -0800 <9511211226.AA27645@mocha.bunyip.com> Subject: Re: mailserver: vs. expanded mailto: URL From: Larry Masinter <email@example.com> Message-Id: <95Nov21.firstname.lastname@example.org> Date: Tue, 21 Nov 1995 21:55:14 PST 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:email@example.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'.