[13:48:30] --- kei has joined
[14:37:24] --- kei has left: Replaced by new connection
[14:38:34] --- kei has joined
[14:42:09] --- kei has left
[14:43:14] --- keitaro has joined
[17:17:32] --- SAH has joined
[17:18:32] --- lisaD has joined
[17:18:52] --- psa has joined
[17:20:19] <lisaD> We're getting started
[17:20:24] <psa> meeting is about to begin
[17:21:19] <psa> introducing Joe Hildebrand
[17:21:23] <psa> co-chair
[17:21:41] <psa> agenda bashing
[17:21:54] <psa> Ted: milestone and charter check?
[17:21:58] <psa> JH: will do at end
[17:22:05] <psa> review of outstanding drafts
[17:22:24] <psa> rfc2518bis...
[17:22:33] <psa> we do have list of issues
[17:22:48] <psa> http://www.webdav.org/wg/rfcdev/issues.htm
[17:23:10] --- hardie has joined
[17:23:12] <psa> last updated July 04 (version -06)
[17:23:23] <psa> recent changes mostly clarify lock behavior
[17:24:42] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html
[17:26:10] <psa> consistency
[17:27:02] <psa> JH: we will discuss each of these on the list
[17:27:18] <psa> but close each of them as quickly as possible
[17:27:37] <psa> compliance resource: Add a brief description to the text describing why we discuss compliance on a per-resource basis.  Try to remove references to server compliance.
[17:27:58] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0231.html
[17:28:03] <psa> this affects as bind as well
[17:28:09] <psa> need to think about that some more
[17:28:13] --- sakai has joined
[17:28:52] <psa> 14 DEFINE_PRINCIPAL: The term “principal” is never defined in the WebDAV specification, or the HTTP or Digest specifications.  It should be defined.
[17:29:03] <psa> this is defined in the ACL RFC
[17:29:14] <psa> copy and paste to RFC 2518
[17:29:43] <psa> 29 MKCOL_AND_302: The HTTP 302 response also returns the Location header, which a client uses to determine where to redirect itself.  The multistatus response does not have any mechanism for returning the Location header information.  This is a problem for redirect references in the Advanced Collections specification.
[17:30:24] <psa> Lisa says: they should all return 302?
[17:30:48] <psa> Larry M: if you move something, you leave behind a stub that 302s everything
[17:31:27] <psa> Lisa saith: some implementations ignore things in HTTP that are not specifically mentioned in RFC 2518
[17:32:20] <psa> bis explicitly mentions that any dav request may be redirected via 301 or 302
[17:32:56] <psa> oops, bad paste a little while ago
[17:33:11] <psa> issue 29 = The specification is ambiguous on the handling of 302 by MKCOL.  It should explicitly state that MKCOL is redirected by a 302.
[17:33:58] --- Cam has joined
[17:34:45] <psa> Larry M: perhaps say that dav does not redefine HTTP
[17:35:05] <psa> but mention that 301 and 302 in particular could be returned
[17:35:26] <psa> 30 IMPLIED_LWS: The specification should explicitly note that the HTTP implied linear whitespace rule also applies to productions in the WebDAV specification.
[17:35:27] <psa> in bis
[17:35:48] <psa> the list has not been updated yet, will be updated to reflect most recent bis status
[17:35:56] --- keitaro has left: Disconnected
[17:36:14] <psa> 31 PUT_AND_INTERMEDIATE_COLLECTIONS: HTTP/1.1 allows PUT to create intermediate collections during PUT operation. WebDAV explicitly forbids this. This may cause problems with non-DAV-aware HTTP/1.1 authoring clients which depend on this behavior, even though the behavior is not guaranteed by HTTP/1.1 PUT.
[17:36:27] <psa> JH: won't you just get an error?
[17:36:30] --- keitaro has joined
[17:36:37] <psa> Lisa: I think this is just a theoretical error
[17:36:42] <psa> JH: what code?
[17:36:45] <psa> Lisa: 409
[17:37:03] --- ray_atarashi has joined
[17:37:08] <lisaD> We've never seen HTTP clients try to PUT files on WebDAV servers, really.
[17:37:14] <psa> 32 INTEROP_DELETE_AND_MULTISTATUS: An HTTP/1.1 authoring tool which issues a DELETE to a WebDAV server might receive a 207 MultiStatus response, which it would not understand.  Following rules in the HTTP specification, it would then treat the 207 as a 200 (OK), and incorrectly assume the operation succeeded.
[17:37:27] --- hardie has left: Disconnected
[17:37:46] <psa> Lisa: we don't tend to see PUT and DELETE with HTTP 1.1 clients
[17:39:14] <psa> LM: proposed resolution?
[17:39:48] <psa> Lisa: it's not correct, but it works and has not caused interoperability problems
[17:41:17] <psa> Lisa: mere HTTP clients are screwed if they communicate with DAV servers anyway -- same would be the case if we used an 800 series error
[17:41:41] <psa> JH: close and move along
[17:42:03] <psa> JH: all "closed" issues will be checked with the list before being finally closed
[17:42:21] <psa> 33 OVERWRITE_DELETE_ALL_TOO_STRONG: A COPY or a MOVE with Overwrite set to True will perform a DELETE with Depth infinity at the destination of the operation. However, in the same situation, most OS’s will perform a merge, rather than a DELETE. It is feared the DELETE is counter to user’s expectations.
[17:42:38] <psa> JH: many OSes will warn before delete
[17:43:01] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0053.html
[17:43:28] <psa> Lisa: this is not implemented as specified in some implementations
[17:44:00] <psa> need to find out if the implementation community is split
[17:44:28] <psa> TH: not deterministic if ignore
[17:44:35] <psa> Lisa: windows file systems don't work that way
[17:46:00] <psa> ?? a resource could be something other than a file or directory
[17:46:18] <psa> always use overwrite_false?
[17:46:37] <lisaD> That's Roy Fielding speaking
[17:46:48] <psa> ok
[17:47:42] <psa> TH: if file system doesn't implement it, then don't implement it
[17:47:50] <psa> Lisa: as author I prefer something deterministic
[17:48:19] <psa> JH: overwrite could have 3 states? true, false, merge?
[17:50:09] <psa> Ryan Korver: if you can't figure out how to do it, then return instructions as to how you do things
[17:50:22] <SAH> s/Ryan/Brian/
[17:50:25] <psa> Lisa: this will give us warm fuzzies, but won't make clients more compatible
[17:50:25] <psa> sorry
[17:50:36] <psa> the scribe is undergoing hearing loss
[17:53:01] <psa> we could make this more specific without redesigning delta v
[17:53:36] <psa> Larry M: sounds like delta v is inconsistent with webdav
[17:54:22] <psa> non-versioned client could cause a versioned file to go away
[17:54:59] <psa> Larry M: client would see different behavior depending on whether server is delta v
[17:56:34] <psa> JH: do we have to change any text in this spec because of this?
[17:57:37] <psa> LD: we could change the text to put fewer constraints on futuure specs
[17:58:01] <psa> TH: we could send this to the delta v list
[17:58:26] --- sakai has left: Replaced by new connection
[17:58:47] <psa> LD: I can send proposed text
[17:59:03] <psa> TH: difficult for dav client to know if server has been extended or not
[17:59:19] <psa> LD: I believe this is backwards compatible
[17:59:22] --- keitaro has left
[18:01:16] --- hardie has joined
[18:01:34] <psa> 34 WHEN_TO_MULTISTATUS_FOR_DELETE_1: If a DELETE is issued to a collection, and it fails on all resources contained by the collection, and on the collection itself, a server should report just a single 4xx status code. But, instead the definition of DELETE indicates it should return a multistatus since an error occurred on a resource other than the Request-URI.  The language needs to be tweaked so a multistatus is not required in this case.
[18:01:43] <psa> JH: this seems OK?
[18:02:46] <psa> 35 WHEN_TO_MULTISTATUS_FOR_DELETE_2: If a DELETE is issued to a collection, and it succeeds on all resources except the Request-URI, then it is OK for the server to report a single failure code. A multistatus response should be returned instead, and the language of DELETE should be tweaked so this is the case.
[18:03:31] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0118.html
[18:03:38] <psa> LD: I don't think this issue makes sense
[18:04:07] <psa> 36 DATE_FORMAT_GETLASTMODIFIED: RFC 2518 specifies that the DAV:getlastmodified property must have the format specified by the HTTP-date production in RFC 2068.  However, HTTP-date allows three date formats, rfc1123-date, rfc850-date, and asctime-date.  Since RFC 2068 requires clients to accept all three time formats, this creates some ambiguity for whether WebDAV clients should also accept all three.  The WebDAV specification should be updated to clarify that only the rfc1123-date  production should be used in DAV:getlastmodified.
[18:04:37] <psa> LD: I doubt that any impls do all three
[18:04:54] <psa> LD: and no servers impl anything but rfc1123
[18:05:02] <psa> update spec accordingly to reflect usage
[18:05:22] <psa> 37 DEEP_LOCK_ERROR_STATUS: Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued.  Yet, the example in section 8.10.10 which demonstrates this uses a 207.
[18:05:33] <psa> JH: just a clarifying comment needed?
[18:06:11] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html
[18:06:15] <psa> LD checking to see if fixed
[18:06:23] <psa> so already in bis
[18:06:56] <psa> 38 OVERWRITE_DELETE_ERROR_STATUS: If a COPY or MOVE is submitted on a collection with Overwrite=T, if an error occurs during the delete processing associated with the Overwrite header, causing the entire operation to fail, what status should be returned?
[18:07:42] <psa> JH: just do roll-up error as we did with previous issue(s)?
[18:08:26] <psa> TH: this is not partial success, but complete failure
[18:08:37] <psa> so why return 207?
[18:09:04] <psa> LD: I think Kevin was looking for a shortcut
[18:12:10] <psa> TH: we're really trying to tell the client was *would* work, not what failed
[18:12:53] <psa> LD: right way to do it would be 424 special failed dependency
[18:13:04] <psa> LD: I think the whole big body is better, but verbose
[18:13:34] <psa> LD: 403 forbidden is ok, as is 207 listing each thing that failed
[18:13:53] <psa> 424 is always inside a 207
[18:15:00] <psa> LD: answer is to say what errors you can use and why you might want to do one or the other (403 vs. 207+424)
[18:15:15] <psa> 40 LOCK_ISSUES: skipping for now
[18:16:09] <psa> 42 MULTISTATUS_FROM_MKCOL: If MKCOL is submitted with an entity body, as permitted by RFC 2518, to create a collection and populate it, then it would make sense to return a 207 Multistatus for errors.  This possibility should be made more clear in the specification.
[18:16:27] <psa> JH: just a clarification, seems reasonable
[18:16:43] <psa> 44 REPORT_OTHER_RESOURCE_LOCKED: In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message.
[18:17:11] <psa> LD: list consensus is to add bodies to error codes to provide more information to the client
[18:17:49] <psa> 47 COPY_INTO_YOURSELF_CLARIFY: RFC 2518 doesn’t explicitly specify how to handle the case where a COPY with Depth infinity has a destination that is within the source hierarchy. For example, a COPY of Depth infinity of /A/ into /A/B/. One resolution is to state that the copy must behave as if the resources are first copied to a temporary location, then moved from the temporary location into the destination.
[18:18:17] <psa> JH: seems that we could simply return an error here
[18:19:44] <psa> 49 EXTEND_UNDEFINED: The definition of the DAV header in section 9.1 uses a production called “extend”, which is undefined in either this, or the HTTP/1.1 spec.
[18:20:31] <psa> JH: we should run the *BNF checker before submitting
[18:21:32] <psa> checkers use 2234, so we might want to use that
[18:22:47] <psa> TH: check RFC Editor errata
[18:22:51] <psa> 50 PUT_ON_COLLECTION: Currently, the language in section 8.7.2 does not state that a PUT is permitted on a collection. On the flip side, it doesn’t state that this is forbidden either. It’s just silent. The spec. should explicitly state that PUT is (or is not) permitted on a collection.
[18:23:10] <psa> JH: is PUT permitted on a collection?
[18:23:43] <psa> any problem with continuing to leave this blank?
[18:24:40] <psa> none expressed
[18:24:43] <psa> 51 LEVEL_OR_CLASS: When describing compliance, the terms “level” and “class” are both used in the specification. Section 9.1 uses the term “level”, while Section 15 uses the term “class”. The specification should pick one and be consistent.
[18:24:47] <psa> LD to double-check
[18:25:20] <psa> 52 LOCK_BODY_SHOULD_BE_MUST: Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST.
[18:25:24] <psa> 51 is fixed already
[18:25:47] <psa> 52 is fixed as well based on recent list discussion
[18:27:07] <psa> the quote is not accurate when referring to bis
[18:27:17] <psa> 53: LD will check
[18:27:32] <psa> LD think this has been clarfified
[18:27:35] <psa> thinks
[18:27:46] <lisaD> Somebody should read my language to see if they agree...
[18:27:53] <psa> 54 IF_AND_AUTH: The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document.
[18:27:57] <lisaD> sometimes as author it's hard to know if you've succeeded in "clarifying" something
[18:28:21] <psa> JH: we shall ask for verification that the clarification clarified the matter
[18:29:12] <psa> anonymous locking is allowed, so 54 is moot
[18:29:14] <psa> 55 DISPLAYNAME: There is confusion over the definition and use of the displayname property that has led to varying implementations. The default value of displayname should be specified. The behavior of displayname when there are multiple URLs for the resource needs to be clarified.
[18:30:16] <psa> 56 DEPTH_LOCK_AND_IF: The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection.  Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed.
[18:30:27] <psa> 55 to be brought up on the list
[18:31:01] <psa> can anyone explain 56?
[18:31:10] <psa> LD: underspecified in 2518
[18:32:02] <psa> LD: if lock token appears anywhere in If header, then included (plus additional explanation)
[18:32:10] <psa> 57 LOCK_SEMANTICS: At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an “authorized” principal, but “authorized” is never explicitly defined.
[18:32:16] <psa> Roy: essentially the same issue
[18:32:51] <psa> 59 PROPFIND_INFINITY: If a client quickly submits multiple PROPFIND, Depth: infinity requests to the top of a collection tree containing many resources, it effectively forms a denial of service (DoS) attack. Though this is noted at a high level in Section 17.2 in Security Considerations, the specific risks of a large PROPFIND should be noted there. Additionally, the specification should note whether a server is allowed to have a configuration option to disable Depth: inifinity PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a server does not support Depth: infinity PROPFIND. Integer values other than 0 and 1 in PROPFIND requests were also proposed.
[18:32:56] <psa> JH: seems like implementation advice
[18:33:27] <psa> TH: could return server busy error, no?
[18:36:02] <psa> TH: could return server busy error if too many requests in a row, for example
[18:37:08] <psa> 60 LOCK_REFRESH_BODY: just discussed
[18:37:42] <psa> 61 RESOURCETYPE_EXTENSION: Both versioning and access control have a need to have multiple values within the DAV:resourcetype property. The specification needs to explicitly state that these multiple values are allowable, and that clients should expect this. At least one example should demonstrate that.
[18:37:52] <psa> already discussed
[18:38:11] <psa> 63 LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY: Is the complexity of the IF header appropriate for the simple task of verifying that a client knowingly owns a lock?  The IF header seems to serve a different purpose.  One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?).  Another is for the client to check some preconditions before doing an action.  Another seems to be to specify what lock to refresh in a lock refresh request.  This seems to create ambiguity in our definition of the semantics of the IF: header.
[18:38:15] <psa> yes, it's too complex
[18:38:21] <psa> that's the way the protocol is
[18:38:28] <psa> sorry
[18:38:43] <psa> 64 OPTIONS_RESPONSE_VARIES_FOR_RESOURCES: Should the response for an OPTIONS request be expected to vary from resource to resource?  What should we proscribe?  What about an example for file, directories and null resources?
[18:38:57] <psa> yes, options vary from resource to resource
[18:39:13] <psa> LD: this is clear now that extensions exist
[18:39:33] <psa> 65 UNLOCK_WHAT_URL: What do you return if the unlock request specifies a URL on which the lock does not reside?  What if it’s on a URL that is locked by the lock, but it’s not the resource where the lock is rooted?
[18:39:48] <psa> JH: do we have preconditions for this now?
[18:39:49] --- ray_atarashi has left
[18:40:03] <psa> LD thinks so but will double-check
[18:40:20] <psa> 66 MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL: Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation.  Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL  in the IF: header.
[18:40:37] <psa> LD: I think this is clarified
[18:40:57] <psa> 67 UNLOCK_NEEDS_IF_HEADER: Shouldn’t we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it?  (This might be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)
[18:41:04] <psa> too late to change at this stage
[18:41:26] <psa> 68 UNLOCK_WITHOUT_GOOD_TOKEN -- should have preconditions for these, LD to check
[18:41:48] <psa> 69 URL_ENCODING_ISSUES: We have to resolve some issues involving encoding methods for URI’s.  The discussion is very involved.
[18:42:14] <psa> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0081.html
[18:42:20] <psa> HTTP URI issue
[18:43:14] <psa> 70 LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER: The LOCK renewal request should not us an IF header to specify what lock is being renewed.  This limits the use of the IF header.
[18:43:20] <psa> now well specified
[18:43:38] <psa> 71 IF_HEADER_CHECKS_AFTER_OTHER_CHECKS: Should we document if the IF header is evaluated before methods specific checks of afterwards.  The IF header is said to be modeled after the IF-MATCH header and the documentation for that says that method specific checks should come first.  It’s not clear if it’s feasible to make all method specific checks before checking the IF header.  It’s also probably easier to implement IF header checks at a common layer of code that is called before the method specific code in many implementations.
[18:45:00] <psa> moving along to other issues
[18:45:01] <psa> bindings
[18:45:09] <psa> s/issues/documents/
[18:45:23] --- ray_atarashi has joined
[18:45:24] <psa> does bindings need to include locks?
[18:46:12] <psa> http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html
[18:48:02] <psa> options...
[18:48:07] <psa> 1. last call as-is
[18:48:16] <psa> 2. add more explicit text as requested
[18:48:34] <psa> 3. delay until rfc2518bis is completed, then refer to bis for interactions
[18:48:53] <psa> 4. extract locking out of rfc2518bis, refer to new locking draft for interactions
[18:51:46] <psa> Roy: I think we should address only the real interoperability problems
[18:52:55] <psa> TH: I think the draft needs clarification on some possible scenarios
[18:55:48] <psa> is this interoperability w.r.t bindings or locks?
[18:56:57] <psa> do we want to split out locking into a separate document?
[18:57:10] <psa> there is precedent for HTTP: 2616 and 2617
[18:58:02] <psa> splitting out locking seems ok
[18:59:38] <psa> TH: an explicit call to the mailing list seems necessary regarding whether we need clarifying text on the point mentioned (text already provided by LD on list)
[19:00:06] <psa> Larry M: I don't see how breaking the locking content into another draft will help
[19:01:33] <psa> JH: if people think the bis draft is unclear, they should express those
[19:03:20] --- hardie has left: Disconnected
[19:07:33] <psa> redirect...
[19:08:07] <psa> Last updated to version -08 April 04
[19:08:11] <psa> open issues still exist
[19:08:25] <psa> julian proposes to defer work on this until after bindings is done
[19:08:39] <psa> do we really need both redirect and bindings?
[19:08:48] <psa> yes, we do need both
[19:08:55] <psa> patch (non WG doc)
[19:09:02] <psa> ready for last call
[19:09:11] <psa> significant review by HTTP WG
[19:09:27] <psa> do we want to endorce this as reviewed by WEBDAV WG?
[19:09:38] <psa> or leave them be as individual drafts?
[19:10:08] <psa> LD: implementors are out there waiting
[19:10:20] <psa> Roy: put out question to list: do you plan to support this?
[19:12:12] <psa> application/gdif applied for
[19:12:24] <psa> pass it by the ietf-types list
[19:13:34] <psa> quota draft is not currently on the charter
[19:13:39] <psa> should this be a WG item?
[19:14:22] <psa> draft-ietf-webdav-quota-03
[19:14:26] <psa> so it is a WG item
[19:15:20] <psa> WGLC call on this
[19:15:22] <psa> to be issued shortly
[19:15:49] <psa> milestones and charter check
[19:16:20] --- SAH has left
[19:18:09] <psa> WGLC call for quota next week
[19:18:17] --- ray_atarashi has left
[19:18:19] <psa> JH: will discuss updated dates with authors
[19:18:30] <psa> may need volunteer for bindings
[19:19:12] <psa> </end>
[19:20:27] <psa> log: http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-08-05.html
[19:20:43] --- psa has left
[19:20:47] --- lisaD has left: Disconnected
[19:21:47] --- Cam has left
[21:24:50] --- lisaD has joined
[21:28:03] --- lisaD has left