Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


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:

1 WebDAV WG meeting 54 th IETF, Yokohama

2 Agenda  10 min agenda bashing  20 min Interop plans  20 min ACL progress (last call)  60 min RFC2518bis issues

3 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

4 Interop topics  Specific RFC2518bis discussion topics  e.g. trailing slashes  ACL implementations  Servers known to exist  DASL implementations?  Servers known to exist

5 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)

6 ACL status  Implementations already exist  Will attempt interop testing in September  Next Steps  Publish 09 draft  Another WG last call?  Submit to IESG

7 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

8 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

9 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

10 Source property  No interoperability proven  Still no firm agreement on requirements

11 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

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

13 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

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


Download ppt "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."

Similar presentations


Ads by Google