RE: Using If and not failing

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, February 01, 2003 8:27 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> To be clear, I did not object to the proposal per se.  I've been echoing
> the recommendation that it's at least a good interim solution, and I
> only tweaked the solution you call the "final form" in my recent emails.
>
> However, I felt the proposal wasn't sufficient to completely solve the
> interoperability problems.  I still worry on that point, and I'm *not*
> the only one.
>
>  - Jim W has expressed concern that any proposal that allows the If
> header to succeed regardless of server state is weakening the ability of
> the If header to correct the client's incorrect state. That objection
> applied both to a "here are all my locktokens" approach and to the
> proposals showing how to work around the current syntax.

Technically speaking, they *don't* workaround the server state. The client
says "let the request succeed if my locktoken is still valid, or if it's
gone", and this is what happens. This works *by design*. Not that I think
that it's ever a good idea to send this kind of request.

>  - Dan Brotsky saw these proposals and still felt strongly that a much
> more simple approach was necessary for long-term interoperability.

I'd like to hear that directly from him, not as hear-say. In particular, it
would be nice if the group of client programmers that thinks that there *is*
an issue would actually sit down and try how the proposed usage of the
existing If header turns out to work.

> In other words, we're not done yet.  We are still refining our
> understanding of various issues and proposals surrounding the If header.
> The If header still has other problems:
>
>  - the "ignored clauses" that the list decided shouldn't be ignored
>  - Uncertainty or at least implementation differences in what locks are
> required to do various operations

-> GULP.

>  - Confusion on whether multiple lists are ANDed together (tagged list)
> or ORed together (no-tag)

Could you please explain the nature of the problem?

>  - You(geoff) suggested dropping the no-tag-list production (Oct 7 2002)
>  - Jason suggested that no-tag-list production always apply to
> Request-URI only (Oct 12 2002)

That was my impression as well.

> We still need more input from more WG members.

On the other hand, we've been working on this issue for almost 6 months
wiith little progress. So my *concrete* proposal about how to proceed is:

1) allow comma separated notation for tagged lists (to workaround proxy
limitations)

2) use GULP as a basis to clearly explain which resources are affected

3) add a set of the tests I wrote to Litmus

4) write a separate document (?) that gives guidelines on "safe" authoring.

Note that if we left out 2), this would be no change for RFC2518 at all, and
all servers compliant to RFC2518 should already behave as desired.


Julian


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

Received on Saturday, 1 February 2003 15:10:58 UTC