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

RE: WebDAV resources must be in collections? (CONSISTENCY)

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Wed, 8 Oct 2003 09:06:15 -0700
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>

I'm OK with this. Implementors tend to do the "right" thing wrt consistency when it matters, and the current language has caused confusion far beyond its worth.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, October 07, 2003 5:46 PM
> To: 'Webdav WG'
> Subject: WebDAV resources must be in collections? (CONSISTENCY)
> This is the CONSISTENCY issue in 
> http://www.webdav.org/wg/rfcdev/issues.htm.
> RFC2518 says:
> "  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.
>    The root, or top-level collection of the namespace under
>    consideration is exempt from the previous rule."
> Roy Fielding - 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html:
> "There is no need for that requirement and it
> is the root of many terminology issues.  Any individual resource is
> capable of being or not being DAVable, as determined by either the
> capabilities described by an OPTIONS response"
> I've been thinking of a use case for WebDAV resources that may not 
> be in WebDAV-capable collections.  The SIMPLE WG has discussed 
> making Buddy lists be (in one model) a WebDAV resource.  This would 
> mean that the buddy list could be locked, unlocked, could support
> PROPFIND and PROPPATCH, could support the basic WebDAV properties 
> to know when the content changed and what the ETag is.  It could 
> have an owner and support the ACL method and the acl property.
> Should we remove this consistency requirement from RFC2518bis?
> Lisa
Received on Wednesday, 8 October 2003 12:06:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC