Transcript WebDAV WG meeting

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 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.