W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

RE: Email access to DAV functionality

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 26 Feb 1997 20:54:26 -0800
Message-ID: <11352BDEEB92CF119F3F00805F14F485023BD0B4@RED-44-MSG>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
I think the proper response is 4,
4) Do nothing

If no one is interested enough in the e-mail scenario to champion it
then I see no reason why we should spend any time on it. If a champion
does appear then let them shadow the group and point out relevant
issues, but let us leave this out of the requirements document.

> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Wednesday, February 26, 1997 12:21 PM
> To:	w3c-dist-auth@w3.org
> Subject:	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
> 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 23:54:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:14 UTC