Presentation on theme: "WebDAV WG meeting 54 th IETF, Yokohama. Agenda 10 min agenda bashing 20 min Interop plans 20 min ACL progress (last call) 60 min RFC2518bis issues."— Presentation transcript:
WebDAV WG meeting 54 th 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: firstname.lastname@example.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 issues http://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 standards DAV: 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/~lisa http://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.