Re: Notes from IETF-60 WebDAV WG Meeting

Joe Hildebrand wrote:

thanks for the summary. Some comments in-line.

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

I agree with the first part, but I'm not sure what the last sentence 
intends to say. Could you please clarify?

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

I'm not sure what the issue actually is. Any HTTP method can be 
redirected by a 3xx server response.

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

I don't think I agree here. RFC3253 doesn't make any distinction here.

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

I think we should find out what servers do implement; and then update 
the spec accordingly. That may mean re-aligning it with RFC3253.

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

I think what this is asking for is not to return a 4xx status unless the 
whole request was rejected (and not partly successful). That seems to 
make sense, but it may not be what's implemented.

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

I don't think we should say anything about that unless we're prepared to 
define that request body format.

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

It doesn't need to say anything about it.

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

Correct. There already was a proposal to deprecate displayname because 
of the existing broken implementations and to define something new.

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

What does the definition of 503 has to do with that case? I think we 
should simply state that servers may reject the request and define a 
precondition name.

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

Unless we find out that existing implementations happen to do this the 
same way, I don't think we can do anything about it today.

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

So what *is* that issue? The authors of BIND feel that RFC2518 (+ 
possibly GULP as generic clarification of WebDAV locking) clearly say 
how locks and binds interact.

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

I haven't seen any new mails regarding this topic in the last few weeks.

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

Agreed. Basically, we do have a *very* short summary of locking 
semantics 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>) 
which seems to reflect the consensus of the working group, and is 
compatible with both RFC2518 and BIND. We "just" need to make sure that 
what it says can be found in RFC2518bis (or whatever will be the future 
place for WebDAV locking).

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

Yes. It's different from BIND, and it adresses authoring of a popular 
HTTP construct.

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

(see comments on the ietf HTTP mailing list).

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

I'm reluctant putting new things (as previously QUOTA, btw) on our 
agenda unless there are signs that we do make progress with what has 
been on our agenda for years now.

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

There was a controversy on the mailing list back when -02 was posted. As 
in draft -03 there wasn't any list of changes, it's hard to say what has 
changed since.

> MILESTONES AND CHARTER CHECK:
> 
> Joe will discuss updated dates with authors.  We may need volunteer 
> authors if dates aren't met.

To make progress we need also:

- proper issue tracking

- good visibility of progress (what changed and why?)

- the willingness to actually stick to our agenda

The agenda states that we should have last-called BIND a few months ago. 
We should either do that *or* find out what's left to do so we can.

Best regards, Julian





Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 20 August 2004 14:14:28 UTC