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

Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY

From: Lisa Dusseault <lisa@xythos.com>
Date: Sun, 22 Jun 2003 10:25:33 -0700
To: "Jason Crawford" <ccjason@us.ibm.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <006901c338e3$498f0ff0$fdcb90c6@lisalap>


WRITE_DAV_PROP:  This issue is at least addressed in RFC2518bis, if not completely closed.  It was addressed separately for each property in the definition for that property.  E.g. the definition for 'displayname' says "This property is live and MAY be protected."

BACKGROUND "It would be helpful to note which specifications are considered to be necessary background reading for reading the WebDAV spec."  Unless somebody comes up with specific suggestions what references to add, let's CLOSE this issue.

NULL_RESOURCE: "Add a forward reference ... in the definition of Null Resource in the Terminology section."  This definition is now gone, so the issue should be resolved REJECTED.

CONSISTENCY:  The issue is described as "Disagreement over whether a DAV URI namespace needs to be consistent."  Roy suggested <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html> removing the following definition from RFC2518:
   "An HTTP URL namespace is said to be consistent if it meets the
   following conditions: for every URL in the HTTP hierarchy there
   exists a collection that contains that URL as an internal member."
However, consistency is not a requirement.  RFC2518 goes on:
   "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL 
   namespace be consistent.  However, certain WebDAV methods are 
   prohibited from producing results that cause namespace 
   inconsistencies."
To proceed on this issue, somebody who agrees that there is a problem here needs to suggest new wording, since we can't simply remove the definition without rewriting or removing the next few paragraphs and the definitions of some methods.  If nobody suggests new wording or explains why we need to remove a definition that isn't even a requirement, I suggest we keep it the way it is and resolve the issue CLOSED.  (We can always reopen an issue if somebody later decides to propose something concrete.)

Lisa
Received on Sunday, 22 June 2003 13:25:28 GMT

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