RE: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 22, 2003 7:26 PM
> To: Jason Crawford; Webdav WG
> Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE,
> CONSISTENCY
> 
> 
> 
> 
> 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."

Agreed. We should close this after the next draft is submitted and everybody had a chance to look at it (unless it didn't change since -03 in case we can do that right now).

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

Agreed.

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

Agreed (note that the Terminology section indeed defines "null resource").

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

I think 5.1 is sufficiently clear, so mark this one as closed.



--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 22 June 2003 14:33:35 UTC