Email access to DAV functionality

On Tuesday, February 25, 1997, Einar Steffarud wrote:

>I am extremely concernd to find that EMail is totally excluded from
>consideration as a useful transport tool for WEBDAV technologies, or
>as a related technology that needs to be considered.

This is a very timely post, since last Thursday, February 20, 1997, Keith
Moore sent me revisions to the charter, including this issue:

>1. This charter declares "email access" in scope but "disconnected
>operation" out-of-scope.  This IMHO is an oxymoron; providing email
>access to web authoring/versioning servers requires support for
>disconnected operation.  I believe the charter should either
>
>(a) explain why this is not the case,
>(b) include disconnected operation in-scope,
>(c) move email access out-of-scope, or
>(d) add another item to the list of deliverables:
>
>    * determine requirements to support disconnected operation and
>      access by email
>
>   to be required BEFORE the group submits any drafts for
>   standards-track.

Addressing Einar's issue of email access not being mentioned in the DAV
requirements document, a new principle was added to the requirements
document:

4.7. Alternate Transport Mechanisms

It may be desirable to transport WebDAV requests and responses by other
mechanisms, particularly EMail, in addition to HTTP.  The design of the
WebDAV extensions should take alternative transports into account.

However, I would say that this issue still needs some discussion.

Mirroring Keith's list of options, I would say that we have several ways of
approaching this issue:

1) We can consider email access to be out of scope (and explain why).

2) We can consider email access in the design of the DAV extensions to
HTTP, but not produce any deliverables on how to do this.

Quoting Larry Masinter, this might take the form of:

>change the charter to say that "support for email interactions
>is not a requirement, but the ability to interact over email
>and disconnected operations are considerations which may
>be taken into account when considering design alternatives"

3) Have email and disconnected operation be in-scope for limited contexts:

Quoting Larry Masinter (from the same mail message), this might take the
form of:

>define a kind of "limited disconnected operation",
>i.e., where the editor of resource-content is disconnected
>from the resource location while editing is taking place,
>but must be connected in order to actually update or
>interact with the resource.

4) Do this email and disconnected operation fully, and have a requirements
document and a protocol document for accessing DAV functionality via email
with full disconnected operation.

I see the largest constraint on performing activity #3 and #4 to be lack of
resources.  I currently do not know of anyone who wishes to become the
champion for email access and disconnected operation, and is willing to
become the document editor for either the requirements or protocol
specification document for email access and disconnected operation.  If you
would like to volunteer for this, please contact me (soon) via email.

In the absence of someone becoming the champion for this activity, I think
the best course of action is to adopt course #2, which would ensure the DAV
design doesn't preclude email access to DAV functionality.  This way a
future working group could consider email access and disconnected operation
fully, as a primary concern.

Opinions?

- Jim

Received on Wednesday, 26 February 1997 16:01:42 UTC