Notes from DAV meeting

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