webdav wg meeting 54 th ietf, yokohama. agenda 10 min agenda bashing 20 min interop plans 20 min...
TRANSCRIPT
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: [email protected] 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.