- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 14 Aug 2001 13:20:40 -0700
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
- Cc: <minutes@ietf.org>
I haven't received the actual notes yet from the notetaker (hint, nudge) but here's what I wrote down from the WebDAV meeting last week in London. Note these are incomplete. Lots of progress made; various threads to pick up and continue on the list. Reported By Lisa Dusseault The slides I threw up on RFC2518 issues are available at http://www.sharemation.com/~milele/public/dav/WebDAVWG-London.ppt. (WebDAV-compatible repository) DASL revival discussion ----------------------- Issue raised by Jim Amsden whether robust SQL-like language specified in the draft was too complex. Implementors seemed to think this wasn't a problem. Mention of XML Query - whether it may be mature enough to use. Issue with that -- doesn't solve the same problems (e.g. filtered collection content listings) Should schema discovery be cut or fixed? e.g. just limited to one resource at a time? Have a way to specify allowed searches on all dead properties? Is it required to be able to do body/content searches -- not required -- filtered collection listings primary importance Larry Masinter noted DASL is not in the DAV charter -- thus DASL can't be revived in the DAV WG. Either restart DASL WG or handle outside the scope of a WG. DAV WG charter discussion ------------------------- Some items remain in DAV WG charter, not currently dealt with: advanced collection, bindings, registry. Is there any interest in actually working on these issues? RFC 2518 Issues list -------------------- The rest of the WG discussed various RFC2518 issues, brought up by the interop or previously. Consensus was reached on a number of issues -- if the mailing list does not raise new objections, we should record these for 2518. - Finding Root of Repository - Consensus around: Client should not rely on finding DAV: support in response to OPTIONS / request Clients may attempt to find the root of the repository but they must not fail if the root is not at '/' Client implementors need to speak up on the list if they need a new way to find the root of the repository. - Source property not implemented - The source property is better than the Translate header (used by Microsoft) because (a) it can name a separate resource that can be separately addressed by ACLs, (b) it can include several HREFs when a dynamic page is generated by more than one source file. Suggestion from Peter (?) source property is part of the general problem of identifying releationships between resources, like bindings. Resolution - bring up on the list. - Lock null resources - The WG had consensus on simplifying the way LOCK is used to create resources: (a) LOCK on unmapped URL will create a zero-length regular resource (MIME type needs to be decided) (b) MKCOL will not work on a resource created this way (c) A resource created this way will not disappear when unlocked (d) A resource created this way is a normal zero-length resource, thus no special behaviour for GET Suggestions for MIME-type included new mime-type, application/octet-stream, text/plain. - Lock Permissions - Consensus around: Users other than lock creators MAY be able to UNLOCK a resource by discovering and using the correct lock token. Servers should never allow users other than lock creaters to update a locked resource, even if they use the correct lock token. Servers should always require the correct lock token to ensure intentionality. - If Header - Jim Amsden promised to post If header grammar - XML 'lang' attribute placement - Consensus to put the lang attribute only on the 'prop' element. - Reliance on MIME type vs file extension - Consensus that clients should use MIME type in preference to file extension - Trailing slash - Consensus: (a) Servers SHOULD put trailing slash after collection names when producing them. (b) Servers SHOULD allow requests to collections even if trailing slash is missing (c) Servers can use the Content-Location header to clarify the proper URL for a collection, in the response to any request that did not include the proper trailing slash. (d) The trailing slash convention is good. Possibly strengthen language so that it's more than just a convention. - Date Formats - Consensus: Spec is not broke; implementations should take more care in handling the TWO date formats required for DAV property values. - Lock Owner - Consensus: (a) WHen client provides value for lock owner, server should preserve this value and not modify or overwrite it. When client does not provide a value, Server MAY provide a helpful value. Idea: RFC2518 maybe should add "lock creator" value to lock information, in order to reduce confusion, and specify that lock creator is server-calculated (protected) Lisa
Received on Tuesday, 14 August 2001 16:21:27 UTC