Re: E-mail access

Dylan Barrell <dbarrell@opentext.ch> wrote:

> I don't see any reason to support both forms of access (Why have two ways
> of doing something when there is no advantage of the second method over the 
> first) 

E-mail actually has some advantages over HTTP in some circumstances:
  1) Email penetrates firewalls, virtually everywhere, allowing kinds and
	types of collaboration that would be difficult without it.

  2) Email is a "batch mode" type of interaction much better suited to laptops
	and situations without permanent IP connectivity.  It is also better
	suited to certain types of automated updates done by tools, which
	then don't rely on the server being up to do (certain parts of) their
	work.

The interesting question is not whether there are advantages, but how big they
are, and how difficult it is to support both types of interactions.  It is also
possible that the e-mail interface could be defined in terms of an email=>HTTP
gateway scenario, such that mail messages could then become HTTP operations.

Such a transformation could be defined in terms of a MIME type, and be an
e-mail attachment:

	From:	"Alan Robertson" <alanr@bell-labs.com>
	Mime-Version:	1.0
	To:	"WEBDAV server" <webdav-server@mail.w3.org>
	Content-Type: application/webdav-request
	Content-Length:	2794

	WebDav-Version:	1.0
	HTTP-Operation:	PUT
	Return-Mail:	alanr@bell-labs.com
	Return-Subject:	Desired Subject
	Operation-ID:	12345 			{or suitable
suitable string}
	HTTP-URL:	http://webdav.w3.org/gawdawfulurl...
	HTTP-Operand:	(some method of indicating which attachment to use
			as an operand).

With such a request, you also need a response type:
	To:		"Alan Robertson" <alanr@bell-labs.com>
	Mime-Version:	1.0
	From:		"WEBDAV server" <webdav-server@mail.w3.org>
	Subject:	Desired Subject
	Content-Type:	application/webdav-response
	Content-Length:	356

	WebDav-Version:	1.0
	HTTP-Operation:	PUT
	Operation-ID:	12345
	HTTP-URL:	http://webdav.w3.org/gawdawfulurl...
	HTTP-Operand:	(some method of indicating which attachment to use
			as an operand).
	HTTP-Result:	200

Such a gateway could be defined easily strictly in terms of such HTTP semantics
as we are defining elsewhere.  Again, the issue for the spec is:
	Is it worthwhile?
		Will anyone implement it?
		Would anyone use it?
		What is it "just the right approach" for?

If it's worthwhile, then the questions about how it might be used come up.
Things like: What kind of management entity is going to be looking at these
results?  What do they need to do their job?, etc.


	-- Alan Robertson
	   alanr@bell-labs.com

Received on Tuesday, 27 May 1997 10:35:23 UTC