Subject: RE: Using If and not failing

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 1 Feb 2003 10:14:34 -0500

Yes, this proposal appears in the thread 
"Submitting tokens without a validity check"
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0284.html
based on a suggestion from Stefan:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0390.html 
The final form of this proposal (with constant
tokens) appears in a message from Julian:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0286.html

Since at the time, Lisa was the only one who
objected to this proposal, it sounds like we
now all agree that this is the right approach?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Saturday, February 01, 2003 4:58 AM
To: Lisa Dusseault; 'Webdav WG'
Subject: RE: Using If and not failing

Lisa,

you are aware that this exactly the proposal that Geoff and myself have been
making for some months now?

Julian

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, February 01, 2003 7:15 AM
> To: 'Lisa Dusseault'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> I've been looking into this some more. This trick should also work with
> tagged lists.  However, since multiple tagged lists are ANDed together
> (" If the state of the resource to which the header is applied does not
> match any of the specified state lists then the request MUST fail") it
> has to be done a little differently.
>
> <no-lock> here represents a lock token that the client made up, which is
> intended to Fail.
> If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not
> <no-lock>)
>
> This evaluates as
> 	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
> 	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))
>
> I tested this against Xythos WFS, and clients can use this syntax to
> make sure that the request does not fail even if locktoken1 or
> locktoken2 are no longer there.  Of course this should always be used
> with ETag checks.
>
> lisa
>
>
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:[email-masked]]
> > Sent: Thursday, January 23, 2003 12:20 PM
> > To: Webdav WG
> > Subject: Using If and not failing
> >
> >
> >
> >
> > Did anybody point out that there's an interesting way for the
> > client to
> > ensure that the If header never fails the request, by always
> > providing a
> > "true" statement?
> >
> > -          One or more tokens can be put in parentheses to
> > form a group
> > or list
> > -          Multiple lists can be included and they are ORed together
> >
> > So if the client wants to put a bunch of locktokens in the If
> > header it
> > can put any number of them in there, all separated by virtual "OR"s:
> >
> > DOSTUFF /resourceurl.html HTTP/1.1
> > If: (<locktoken1>) (<locktoken2>) (<locktoken3)
> >
> > This request will succeed if the any of the clauses match.
> >
> >
> >
> >
>
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 1 Feb 2003 11:27:17 -0800

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.

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

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
 - Confusion on whether multiple lists are ANDed together (tagged list)
or ORed together (no-tag)
 - 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)

We still need more input from more WG members. 

Lisa

> [mailto:[email-masked]] On Behalf Of Clemm, Geoff
> To: 'Webdav WG'

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 1 Feb 2003 21:10:17 +0100

> Sent: Saturday, February 01, 2003 8:27 PM
> To: 'Clemm, Geoff'; 'Webdav WG'

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.

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

> required to do various operations

-> GULP.

> or ORed together (no-tag)

Could you please explain the nature of the problem?

> 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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 1 Feb 2003 17:05:22 -0800

> existing If header turns out to work.

Please see:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0118.html

> Could you please explain the nature of the problem?

Section 9.4.1, No-tag-list production:

"If multiple No-tag-list productions are used then one only needs to
match the state of the resource for the method to be allowed to
continue." 

Conclusion: multiple untagged lists only one needs to match --> OR

Section 9.4.2, Tagged-list Production:

"When the If header is applied to a particular resource, the Tagged-
list productions MUST be searched to determine if any of the listed
resources match the operand resource(s) for the current method. If none
of the resource productions match the current resource then the header
MUST be ignored. If one of the resource productions does match the name
of the resource under consideration then the list productions following
the resource production MUST be applied to the resource in the manner
specified in the previous section. "

Conclusion: multiple tagged lists each needs to match --> AND

Note that in the previous quoted paragraphs, the part about ignoring
clauses will be removed if we continue by our previous consensus.

> 1) allow comma separated notation for tagged lists (to 

This completely breaks the syntax of the header for clients sending
requests to servers that don't immediately support 2518bis.  Clients
wouldn't actually be able to use commas for years because there is
currently no way to see if a server supports 2518bis.  I'm pointing this
out because if we decide to do this, we have to be clear on
understanding it's not going to be very useful for a long time.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 2 Feb 2003 11:59:58 +0100

> Sent: Sunday, February 02, 2003 2:05 AM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> ...

Yes.

> all servers compliant to RFC2518 should already behave as desired.

but I *meant* to write:

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

What you say is true and applies to *any* "new" feature in RFC2518bis --
therefore it makes sense to avoid them wherever possible (thus the proposal
to use the If header instead of inventing a new header).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 2 Feb 2003 12:08:16 +0100

> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0118.html

I'm aware of the original mail.

Fact is, there has been extensive dicussion about this mail (with Dan *not*
returning to the list). We have tried to analyze the problem, and we have
made proposals how to achieve the desired semantics. I even posted a test
suite.

We are now waiting for feedback, in particular a discussion whether our
proposal works for the clients or not (in which case they need to explain
*why*). It seems to be impossible to get this kind of feedback. Until we get
it, I'd propose to consider this particular issue (how to let a request
succeed when the lock token is known, but the lock has gone away) as closed.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 2 Feb 2003 06:38:14 -0800

> to use the If header instead of inventing a new header).

I don't think my logic supports your conclusion.

Adding commas to the If header is *exactly* as disruptive as inventing a
new header.  
 - At first, clients will not support this, knowing that very few
servers support the new syntax or header, and having no easy way to
distinguish
 - Later, some clients may include logic to do both/either once many
servers support the new syntax or header
 - Finally, in a few years, most clients will move to the new paradigm,
*if* it adds value, once all servers are known to support the new syntax
or header.
 - If the change does not add sufficient value, clients will never
switch over.

Given that changing the syntax and adding a header are identical in
interoperability cost, if we rule out one solely because of the cost we
logically rule out the other.  

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 2 Feb 2003 21:54:16 +0100

Yes.

However, we *already* have the desired behaviour (for the conditional
operation). So this is something that is already supported by RFC2518, and
we should use it. Clients can use it *now*.

The *only* thing that's missing (and it's only a problem when there are
misbehaving proxies in the communication path) is the change to allow comma
separated lists. Whether we do *that* change is a completely separate issue.

Julian