WebDAV WG meeting

54th IETF, Yokohama

Agenda

10 min agenda bashing

20 min Interop plans

20 min ACL progress (last call)

60 min RFC2518bis issues

Interop Plans

Interop in September at UCSC September 11-13 Interim DAV WG meeting also Focus on testing client server pairs RFC2518 bis issues will be discussed as they

crop up

Online, ongoing interop info Jim Luther coordinating, send info 4 servers and 3 clients listed

Mailing list Same one as last year: interop@webdav.org Note discussion continues year-round

Interop topics

Specific RFC2518bis discussion topics e.g. trailing slashes

ACL implementations Servers known to exist

DASL implementations? Servers known to exist

ACL progress

WG Last call for draft 08 “ended” June 9 Discussion continues draft 09 coming soon, very similar

Recent discussion: Set of privileges now includes “unlock” How to search for users and groups has now

changed slightly How groups “contain” users has changed

slightly List of locations where principals can be found

– moved to live property (from OPTIONS)

ACL status

Implementations already exist Will attempt interop testing in September

Next Steps Publish 09 draft Another WG last call? Submit to IESG

RFC2518 bis Process

Draft-ietf-webdav-rfc2518bis-01.txt

Significant progress

Some open issues still may involve significant work (particularly source issue)

Complete list of open issueshttp://www.webdav.org/wg/rfcdev/issues.htm

RFC2518bis Issues:

Open issues If header – use of multiple tokens, NOT syntax Source property, dynamic resources URI vs URL terminology Extending “DAV:” header in OPTIONS response MOVE, COPY and live properties Trailing slash for collections

Recently closed issues Discovery of Root of Lock UNLOCK any locked URL, not just root Shared locks are interoperable

If header complications

If header allows boolean logic to combine tokens

Servers must evaluate function to decide to do request

AND, OR, NOT allowed, however boolean logic not quite complete

Clients do not use full complexity. Interoperability issues?

Discussion on list has been weak on this topic

Source property

No interoperability proven

Still no firm agreement on requirements

URI/URL/URN terminology

Example 1…Collection - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in section 5 of this specification.

Member URI - A URI which is a member of the set of URIs contained by a collection.

Example 2… A lock token is a type of state token, represented as a URI, which identifies a particular lock

Surprising amount of disagreement

Disintegrated into discussion of whether two different resources can have the same URL

Extending DAV: header

Used to indicate support for DAV level 1 or DAV level 2 (including locks)

Also used to indicate support for other standardsDAV: 1, 2, orderedcoll

Current proposal to discourage use of this header except as already used.

Move, Copy and live properties

Recall that allowing the client to specify what properties are kept live has been cut from the specification

COPY creates a new resource Should initialize live properties to appropriate

values for a new resource, just like PUT? Dead properties should be copied

MOVE relocates or renames a resource Should keep live properties same values to

the extent possible and appropriate Dead properties must be kept

Trailing Slash

Is a URL to a collection the same whether or not it has a trailing slash?http://foo.com/~lisahttp://foo.com/~lisa/ (canonical)

RFC2518 suggests responding to the first successfully, but with Content-Location header so that client can start using correct URL

Interoperability problems discovered with this approach IE 5 and NS 4.7 Relative URLs are appended to the Request-

URI, not the Content-Location URI.