W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: WG Last Call: Bindings Protocol

From: Eric Sedlar <esedlar@us.oracle.com>
Date: Mon, 27 Dec 1999 22:28:13 -0800
Message-ID: <024501bf50fc$b7fa5440$9a114498@us.oracle.com>
To: "Jim Whitehead" <ejw@ics.uci.edu>, "WebDAV WG" <w3c-dist-auth@w3.org>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
This looks pretty good, as it addresses the circular reference issue.  I'd
still like to see an optional weak binding that is guaranteed not to dangle
but that also does not affect the reference count, as I think that is needed
when the implementor chooses not to allow circular BINDings affecting

A couple of other comments:

* on the security issue of revealing the set of bindings with the
dav:bindings property:  I recommend some comment to the effect that BINDings
from unreadable collections should not be readable.  So, the list of
bindings in this property would only show READABLE bindings (and thus would
be different depending on who was examining the property)
* some comment to the effect that if the URL is a versioned resource, and
the currently selected revision is changed, the resourceid will not change.
(I'm assuming that is what you want.)  So even though two people might see
different data from a GET request from the same URL (because they would get
a different revision selected), they would still have the same resourceid.
Therefore, people should NOT use resourceid to invalidate caches or any
other application that assumes a one to one correspondence between
resourceid and data.


----- Original Message -----
From: "Jim Whitehead" <ejw@ics.uci.edu>
To: "WebDAV WG" <w3c-dist-auth@w3.org>
Sent: Monday, December 27, 1999 4:56 PM
Subject: WG Last Call: Bindings Protocol

> <draft-ietf-webdav-binding-protocol-02>
> protocol-02
> This is the final call for comments from the working group on the WebDAV
> Bindings Protocol specification, draft-ietf-webdav-binding-protocol-02.
> This last call period begins immediately, and ends January 24, 2000, at
> midnight, US Pacific time.  This allows 4 weeks for review of this
> specification.
> At the end of the last call period, a new draft will be issued that
> comments raised during the last call period.  Depending on the scope of
> changes, there will follow either an immediate call for rough consensus
> (very few changes), or a second last call period (significant changes).
> 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 review 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:
> ftp://ftp.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) This specification is one of three that have been developed in tandem,
> the
> other two being the Redirect References Protocol,
> draft-ietf-webdav-redirectref-protocol-02
> and the Ordered Collections Protocol,
> draft-ietf-webdav-ordering-protocol-02.
> It is my intention to bring these documents up for last call in sequence,
> with the Redirect References Protocol going next, starting its last call
> January 25, 2000.  While the documents are being brought up for last call
> sequence, you may, if you wish, review all three at once, and submit
> comments on all three during the last call period for the Bindings
> Specification.
> 2) If you've been waiting for a "stable" version of the specification
> before performing a review, wait no longer.  This is it.  Review the
> specification NOW.
> - Jim Whitehead
> Chair, IETF WEBDAV Working Group
Received on Tuesday, 28 December 1999 01:28:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC