W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

WG Last Call: Access Control Specification

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Tue, 7 May 2002 12:33:27 -0700
To: "WebDAV" <w3c-dist-auth@w3.org>
Cc: <acl@webdav.org>
Message-ID: <AMEPKEBLDJJCCDEJHAMIOEBBEMAA.ejw@cse.ucsc.edu>
** WORKING GROUP LAST CALL FOR COMMENTS ***

From November 11 to December 3, 2001, the WebDAV Working Group held a last
call for comments period on the -07 version of the WebDAV Access Control
Protocol. During the last call period, several working group members
performed detailed reviews of the  document. Their feedback has now been
incorporated into the -08 version of the Access Control Protocol.

Additionally, since the submission of the -07 version of the protocol
specification, additional early implementation experience indicated the need
for multiple improvements to the specification, including the addition of
several privileges (DAV:write-properties, DAV:write-content, DAV:unlock),
and the addition of many error conditions for the ACL method.

From the abstract of the -08 specification:

   This document specifies a set of methods, headers, and
   message bodies that define Access Control extensions to
   the WebDAV Distributed Authoring Protocol. This protocol
   permits a client to read and modify access control lists
   that instruct a server whether to allow or deny operations
   upon a resource (such as HTTP method invocations) by a
   given principal.

I am very hopeful that this is the absolutely final call for comments from
the WebDAV Working Group on the WebDAV Access Control Protocol,
draft-ietf-webdav-acl-08, prior to sending it along to the IESG for
approval.  This last call for comments period begins immediately, and ends
Sunday, June 9, 2001, at midnight, US Pacific time.  This allows over four
weeks for review of the specification.

The latest revision of the WebDAV Access Control Protocol was submitted as
an Internet-Draft yesterday, and should appear in the Internet-Drafts
directory
in the next few days. In the meanwhile, it can be accessed at:

Text (this is the normative version)
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.txt

HTML:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.htm

PDF:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.pdf

Word:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.doc

The -07 revision can be found in:
http://www.webdav.org/acl/protocol/old/draft-ietf-webdav-acl-07.txt


At the end of the last call review period, a new draft may be issued.
Depending on the scope of changes introduced between the -08 and -09
versions, there will either be an immediate call for rough consensus (very
few changes), or a second last call review period (significant changes).
Once the document represents the rough consensus of the working group, I
will submit this document to the Internet Engineering Steering Group (IESG)
for their approval.  IESG review involves a (minimum) two week public last
call for comments period.  This IESG-initiated last call period is in
addition to the working group last call period.

This document is intended to be a "Proposed Standard".  Quoting from RFC
2026, "The Internet Standards Process -- Revision 3":

   The entry-level maturity for the standards track is
   "Proposed Standard". A specific action by the IESG
   is required to move a specification onto the standards
   track at the "Proposed Standard" level.

   A Proposed Standard specification is generally stable,
   has resolved known design choices, is believed to be
   well-understood, has received significant community
   review, and appears to enjoy enough community interest
   to be considered valuable.  However, further experience
   might result in a change or even retraction of the
   specification before it advances.

   Usually, neither implementation nor operational experience
   is required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and
   will usually represent a strong argument in favor of a
   Proposed Standard designation.

Many details on the procedures used to develop an IETF standard can be found
in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt

If there are any procedural questions or concerns, please do not hesitate to
contact me, or raise an issue on the list.

Notes:

1) Issues raised during the last call period will be resolved individually,
rather than lumped together and dealt with as a whole.

2) If you've been waiting for a "stable" version of the specification before
performing a review, wait no longer.  This is it.  Several parties have
implemented this specification already. Please review the specification NOW
in order to ensure your input gets included.

- Jim Whitehead
Received on Tuesday, 7 May 2002 15:34:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT