Re: mailserver: vs. expanded mailto: URL

Al Gilman (asg@severn.wash.inmet.com)
Wed, 22 Nov 1995 00:13:21 -0500 (EST)


From: asg@severn.wash.inmet.com (Al Gilman)
Message-Id: <9511220513.AA08946@severn.wash.inmet.com>
Subject: Re: mailserver: vs. expanded mailto: URL
To: Harald.T.Alvestrand@uninett.no
Date: Wed, 22 Nov 1995 00:13:21 -0500 (EST)
Cc: asg@severn.wash.inmet.com, uri@bunyip.com, macrides@sci.wfbr.edu
In-Reply-To: <9511211226.AA02499@severn.wash.inmet.com> from "Harald.T.Alvestrand@uninett.no" at Nov 21, 95 01:25:55 pm

Harald raised the question of how mailservers might play in the context
of a form POST or GET action.

Mostly, I think that that is an independent question from what the URI
should be.  A mailto: URI can be acted on by any client with a mail 
connection.  Forms mode requires HTTP.  Mail clients will be getting
URIs in text/HTML independently from of access to HTTP.  

Foteos Macrides was kind enough to give me the following capsule 
description of how Harald's question has been handled in Mosaic
and Lynx.

-------------------------------------------------------------------------
Date: Tue, 21 Nov 1995 22:28:32 -0500 (EST)
From: Foteos Macrides <MACRIDES@SCI.WFBR.EDU>
Subject: Re: mailserver: vs. expanded mailto: URL (fwd)

asg@severn.wash.inmet.com (Al Gilman) wrote:
>[stuff about mailto and mailserv URLs]

	The proposed mailserv format is:
	
	mailserver:<rfc822-addr-spec>/<subject>/<body>
	
so you can do things like:

  <A HREF="mailserv:listproc@listproc.cc.ukans.edu//UNSUBSCRIBE%20lynx-dev"
  >UnSubscribe from the lynx-dev list</A>

	In theory, at least, one could use it in a form to set the
subject, and treat the form content as the body field:

  <FORM METHOD="POST" ACTION="mailserv:user@host/Form%20submission">

	For mailto as an anchor HREF, Mosaic added the ability to
treat the TITLE attribute as the subject, and I added that to Lynx as
well.	For forms with a mailto ACTION, I use the document's TITLE
as the subject, for want of anything better.  It is inappropriate
for the client to look for an INPUT with some name, such as "subject",
and use that itself.  A CGI script invoked as the form's ACTION could
analyze the content and then do whatever it's author likes with that,
and mail it somewhere, but the client should NOT analyze the content
itself.  It should mail it equivalently to if it were going to an http
server, with any newlines in TEXTAREAs hex escaped, and raw newlines
used to break up the content into lines none of which exceed 78
characters (so you won't have problems with mailing software or
gateways).

	The recipient of the mail should extract it, concatenate
the maximum-78-character lines to recreate a normal form content,
and then analyze it equivalently to a CGI script.

	I don't know if specifying a GET versus POST method should
make a difference, but if so, I suppose the content should begin
with a '?' if it's GET, and not if it's POST.  In Lynx, I ignore
the METHOD attribute and mail the content without a lead '?'.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================