W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

Notes from DAV meeting

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

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

- 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
(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,

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

(a) Servers SHOULD put trailing slash after collection names when producing
(b) Servers SHOULD allow requests to collections even if trailing slash is
(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 -

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

Received on Tuesday, 14 August 2001 16:21:27 UTC

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