IETF-51 WebDAV WG meeting minutes

WebDAV Working Group Meeting (1:30pm Monday August 6th, 2001)
IETF'51 London, England

Lisa Dusseault standing in for Jim Whitehead as Chair.
- Lisa D. presented the agenda and it was approved by the group.
- Discussion started with DASL.  Lisa D. is taking over the role of editor,
and has tried to contact previous authors without much success.  Lisa D.
made a call for participants on the DASL spec.
- Larry M. asked if the XML query language from W3C is sufficient for DASL.
Lisa thinks it is solving a different problem and that an SQL-like syntax
is more appropriate for DASL.
- Should include discovery so that the server can answer which properties
it supports searches over.  Nobody stood up for schema discovery.
- How about search over content?  Should be in scope of the working group,
but should it be a requirement of DASL?
- IETF process ? should DASL be part of the WebDAV WG or be in a separate
WG or be an independent submission?  People agreed that it should not be
part of the WebDAV WG.  ACLs were in the WebDAV WG charter, DASL isn't.
- Question: What remains to do in the WebDAV WG charter?  Advanced
collections, redirect references, properties registry doc., ordered
collections, and raising DAV to a draft standard.
- This remaining work is probably just lacking an editor/champion.  The WG
should push them forward or drop them if there is no interest in the work
being done.
- Larry M. presented the WebDAV Inter-op report. 58 people, 20
organizations, 35 implementations, (17 clients, 18 servers of which 5 open
source).
- Participants had agreed not to publish the results for individual tests.
- Not many implementations inter-operated completely without any issues.
- The event made good progress towards inter-op., some teams made fixes in
real time either on-site or in collaboration with development teams 'back
home'.
- Proposed a virtual inter-op meeting in late-September, say a four hour
test window and a telephone conference call.
- Mailing list for inter-op discussions is interop@webdav.org, which is by
invitation.
- Found common inter-op problems, maybe these can be distilled into an
implementers' guide.
- Little, if any, DeltaV testing took place.
- Typical problems include security, URI encoding problems, etc.
misunderstandings in the spec.
- Inter-op testing uncovered some required features were missing.  Many
servers did not implement LOCK, and many clients required it.
- Some inter-op problems were HTTP issues, such as authentication, multiple
authentication headers.
- Missing, unused, untested features included DAV:source property (nobody
used or implemented it), content-language being reflected in the
DAV:getcontentlanguage property.  It was noted that the source property
should be removed unless there are min. two independent interoperable
client and server implementations of it.  Jim A. pointed out that the
DAV:source property is simply a dead property containing an HREF, there
should be nothing difficult to implement it.  Translate header was used in
place of the source property by some implementations.  It is a Boolean
switch to tell the server whether to interpret the resource or not.
- John S. asked if people had considered using simple URL mangling to
indicate the source, such as in PHP's .phps
- Poor support for the lang attribute on properties.  Maybe it is not used
because there is some ambiguity over it in the specification?
- The "property behavior" element in MOVE/COPY may not have been tested.
- Discovering the root of the repository.  Some clients relied upon
"OPTIONS /" to respond with DAV information, although servlet
implementations would require at least a URL segment.  So should clients
not rely on "/" being in DAV-space?  Clients may use other means of
determining the root of the repository.  One suggestion [from the floor]
was to use the authentication realm.
- Security issues included those who use authorization headers from one
request with subsequent requests on the same connection.
- Cookies in WebDAV.  Some servers require that client support cookies,
i.e. for session look-up rather than re-authentication.  Clients should not
be expected to support cookies, but in these circumstances clients should
support cookies if they expect performant servers.  This is material for
the implementer's guide.
- Lock-null resources.  LOCK followed by PUT, and LOCK followed by MKCOL
are both required to be supported according to the spec., but no clients
required the LOCK followed by MKCOL behavior.  Consider dropping this from
the spec.
- LOCK followed by UNLOCK should cause the lock-null resource to disappear.
Varying implementations were seen.
- Support for "If-None-Match: ?" is unknown.
- Discussion of status code when creating a lock-null resource, should it
be 200 or 201?
- Maybe lock-null resources should have a discrete MIME-type to distinguish
it as a special resource.  However, some server platforms don't remember
the MIME-types but rely on the file extensions.
- Lock permissions.  Lock operations by non-lock creator.  Should there be
a principal in ACLs that allows 'lock stealing'?  Servers should only allow
privileged UNLOCK.
- If: header confusion.  Issues surrounding the size of the header value
when dealing with deep collections, and combination problems.  When
combining values does it mean logical AND or OR?  Jim A. to post grammar
for the If: header onto the list.
- URL escaping ? how to deal with href illegal characters eg., "?/New
Folder", are they XML escaped or URL escaped or both, and in what order,
e.g. UTF-8 encoding and HEX encoding.  Recommended to take a look at
Donald's refs to DSIG document on canonicalization.
- (At this point the curtain falls and nearly crushes Lisa)!
- Where does the xml:lang attribute go?  Does anyone care?  Maybe should
state that implementations should support it anywhere as XML generators may
move it up to the root.  No objections to putting the lang attribute on the
DAV:prop element.
- Servers should return URLs with a trailing slash when referring to
collections, however, clients should not rely on it.  Consider making the
standing convention stronger?
- Note that URLs returned in a multi-status may be relative to the
content-location returned in the response ? should be in the implementer's
guide.
- Date format: page 27 of the RFC2518 stands.  Implementations should
follow the spec in this regard.
- Lock owner information.  Should servers take the information passed by
the client, or use information they know based on the client's
authenticated principal?  Agreed that the server should take the
information passed by the client, and maybe augment the lock token
information with "creator" as well.
- Should clarify which properties are live and which are protected.
- Meeting closed at 5:30pm.

Received on Wednesday, 15 August 2001 06:29:00 UTC