Notes from IETF-60 WebDAV WG Meeting

Slides are here:
http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ietf60
.pdf
or
http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ietf60
.ppt

NOTES:

Introducing Joe Hildebrand as co-chair

Agenda bashing

Review of outstanding drafts

Reivew of RFC2518bis
Last updated July 04 (version -06), recent changes mostly clarify lock
behavior.
Pass through beginning of issue list: 
http://www.webdav.org/wg/rfcdev/issues.htm

  - 12 COMPLIANCE_RESOURCE: Agreed to add a brief description to the text
describing why we discuss compliance on a per-resource basis.  Try to remove
references to server compliance.This affects as bind as well and we may need
to think about that some more.

  - 14 DEFINE_PRINCIPAL: The term "principal" is never defined in the WebDAV
specification, or the HTTP or Digest specifications.  It should be defined.
It is defined in the ACL RFC -- copy and paste to RFC 2518.

  - 29 MKCOL_AND_302: The specification is ambiguous on the handling of
302 by MKCOL.  It should explicitly state that MKCOL is redirected by a 302.
We discussed whether all methods should be redirected by a 302, not just
MKCOL.  Lisa added a section to RFC2518bis that covers MKCOL as well as
other methods, so possibly this should be closed.

  - 30 IMPLIED_LWS: The specification should explicitly note that the HTTP
implied linear whitespace rule also applies to productions in the WebDAV
specification.  This is in 'bis' already.

  - 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.  Although we've never seen HTTP clients try to PUT files on
WebDAV servers, we agreed it could be useful to have a HTTP
backwards-compatibility section in WebDAV.

  - 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.  Same as previous issue.

  -  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. Note that many OSes will warn before delete.  We also realize
this is not implemented as specified in some implementations, and should
find out if the implementation community is split.  Roy pointed out that a
resource may be something other than a file or directory, that's why the
rules can't simply be the same as a file system -- there was no
disagreement.

There were a couple suggestions how to handle this:
  - could have 3 states: true, false, merge (Joe)
  - If the server can't figure out how to do it, then return instructions as
to how you do things (Brian Korver)
  - A client can always use "overwrite=false" and handle their own merging.
(possibly Roy) Lisa pointed out that none of these approaches would actually
make things more interoperable except possibly the last -- new mechanisms
might not be implemented for this corner case.

The other issue with this issue is that DeltaV explicitly prescribes
something different on COPY to a versioned resource.  Does this mean it's
inconsistent with webdav?  Lisa said maybe according to a strict definition,
but at least it works better (otherwise a non-versioned client could cause a
versioned file to go away).  Larry asks if a client will see different
behavior because a DeltaV server handles the COPY -- but we think that the
differences will not be detectable to a non-DeltaV client, because DeltaV
only redefines COPY to versioned resources, not to collections.

So, do we have to change any text in this spec because of this?  Lisa
suggests we could change the text to put fewer constraints on futuure specs
but otherwise explain to implementors that they should follow the spec
wording for normal WebDAV resources.

- 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.  Lisa thinks this is already the case in recent
versions of RFC2518bis.

- 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.  Lisa thought this issue was a little confused.

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

  - 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.  Already fixed in RFC2518bis.

  - 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?  In the discussion, it seemed that using the
207 response with individual response codes for each resource was the
correct approach, and Lisa needs to confirm that the spec is clear on this.

  - 40 LOCK_ISSUES: skipping for now

  - 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.  This was seen as just a
clarification, seems reasonable (Joe)

  - 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.  Lisa
reported that the list consensus is to add bodies to error codes to provide
more information to the client, and this is in -06.

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

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

Side discussion ensued on remembering to run the *BNF checker before
submitting.  The checkers use 2234, so we might want to use that. 
Definitely check RFC Editor errata.

  - 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.  The
intention of RFC2518 was to leave this silent, and there was no objection in
the room to continuing to be silent about PUT on collections.  This issue
should be resolved as closed (rejected) unless the mailing list overturns
this.

  - 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. -- which it already is.

  - 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.
It was explained that recent list discussion concluded that a LOCK request
that has a body is a request for a new lock, while a LOCK request without a
body is a request to refresh a lock.  Thus, this issue can be resolved as
overtake by events.

  - 54 IF_AND_AUTH: The fact that use of authentication credentials with
submission of lock tokens is required should be strengthened in the
document.  Lisa said that  sometimes as author it's hard to know if you've
succeeded in "clarifying" something Joe said we shall ask for verification
that the clarification clarified the matter.

  - 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.  this
definitely needs to be taken to the list.

  - 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.  Lisa responded that 2518bis does have some clearer text on
this so far, but more work might be needed.

  - 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.  Lisa believes as author that this is probably
clearer now.

  - 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.  Lisa suggested that we
could make it clear that 503 could be used (from
HTTP) in many situations.

  - 60 LOCK_REFRESH_BODY: duplicate of LOCK_BODY_SHOULD_BE_MUST

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

  - 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.  There was general agreement that it is too complex but
that's the way the protocol is, presumably because it's not bad enough to
want to break backward compatibility.

  - 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?  We agreed that options vary from resource to resource, but
believe that this is clear now that extensions to WebDAV exist and show how
to use OPTIONS better.

  - 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?  Agreed
that we seem to have preconditions for this now.

  - 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.  Lisa thinks this is clarified

  - 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).  Agreed that this was
probably too late to change at this stage.

  - 68 UNLOCK_WITHOUT_GOOD_TOKEN -- should have preconditions for these, LD
to check

  - 69 URL_ENCODING_ISSUES: We have to resolve some issues involving
encoding methods for URI's.  The discussion is very involved. --  HTTP URI
issue

  - 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.  Lisa thinks now well specified.

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


BINDINGS


Current issues list:  
http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html;
The issue of whether bindings needs to explain how locks and bindings work
together isn't listed there.

What do we do with bindings?  Options...
   1. last call as-is
   2. add more explicit text as requested
   3. delay until rfc2518bis is completed, then refer to bis for
interactions
   4. extract locking out of rfc2518bis, refer to new locking draft for
interactions

Roy suggested to address only the real interoperability problems.  Ted
thought  the draft needs clarification on some possible scenarios.  Ted
suggested that 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).

We noted there is precedent for splitting up a required feature out of a
specification to a separate document: URLs were defined in HTTP in 2068, but
out of HTTP in 2616 (2617 defined URLs).  Larry said he didn't see how
breaking the locking content into another draft will help.  Joe said that if
people think the bis draft us unclear, they should explain how.

REDIRECT

This was last updated to version -08 April 04.  Open issues still exist.
Julian proposes to defer work on this until after bindings is done.  Brief
discussion of whether we really need both redirect and bindings -- probably
yes.

PATCH

This is a non WG doc that's ready for submission as a standard -- it's
gotten significant review by HTTP WG, and significant support in WebDAV (
implementors are out there waiting).  Lisa applied for MIME registration for
application/gdiff.

We asked if we want to endorce this as reviewed by WEBDAV WG, or leave them
be as individual drafts? We do want to put the question to list: 
do you plan to support this?


QUOTA

draft-ietf-webdav-quota-03 -- is a WG item -- we will do WGLC call on 
this shortly


MILESTONES AND CHARTER CHECK:

Joe will discuss updated dates with authors.  We may need volunteer 
authors if dates aren't met.

-- 
Joe Hildebrand

Received on Monday, 16 August 2004 20:44:37 UTC