Subject: WG Last Call: Bindings Protocol

From: Jim Whitehead <[email-masked]>
Date: Mon, 27 Dec 1999 16:56:04 -0800

*** WORKING GROUP LAST CALL FOR COMMENTS ***

WEBDAV BINDINGS PROTOCOL SPECIFICATION

<draft-ietf-webdav-binding-protocol-02>
http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding-
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 resolves
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). 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 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 on
January 25, 2000.  While the documents are being brought up for last call in
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 Protocol
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

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 27 Dec 1999 22:28:13 -0800

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
references.

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.

--Eric