Subject: Notes from DAV meeting

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 14 Aug 2001 13:20:40 -0700

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

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 15 Aug 2001 13:36:32 +0200

Lisa,

thanks for the summary.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, August 14, 2001 10:21 PM
> To: Webdav WG
> Cc: [email-masked]
> Subject: Notes from DAV meeting
>
>
>

A few notes regarding the slides:

- Lock Null Resources: LOCK -> PUT is used by MS Office when doing a "save
as..."

- XML escaping: servers and clients need to process response bodies using a
conforming, namespace aware XML parser. CDATA can appear everywhere where
text content is expected (not only in properties)

- xml:lang: should stick to the definitions in Canonical XML
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DocSubsets): attributes in
the xml namespace are inherited from parents. I'd rather not have WebDAV
invent different rules

- allprop: recommend adopting the proposal using a <include> element as
child of <propfind>.

> DAV WG charter discussion

Yes. We have implemented ordered collections and redirect references. I
think I remember of having redirect references and BINDs added to the core
protocol, is this still under consideration?

> identifying releationships between resources, like bindings.  Resolution -

We are currently supporting the Translate header, as our back end system
doesn't have a concept of different URLs for processed/unprocessed content.
Furthermore, I think the current wording on <source> is hard to understand,
in particular

- src/dst seem be the wrong way round,
- why does <source><link>.. need a <src> element? Isn't it always identical
to the resource on which the property is defined?
- the documentation on src/dst in <link> talks about a href XML element
(http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_link) which
doesn't exist

If the intention is to have <source> to be able to replace the Translate
header, this needs more work...

> Consensus to put the lang attribute only on the 'prop' element.

Strongly disagree. This contradicts both the current wording in RFC2518, the
definitions in the XML spec itself
<http://www.w3.org/TR/2000/REC-xml-20001006#sec-lang-tag> and specs defining
XML fragment exchange (Canonical XML:
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DocSubsets>).