Subject: RE: Interop issue: Proposal for fixing lock token provision

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 7 Oct 2002 14:14:23 -0400

Alternatively, we could just say:

"A client MUST submit a tagged-list If header, using the
DAV:lock-root of the lock as the tag for that lock token."

A simple rule for new clients, that will interoperate with
all correctly implemented old and new servers.

If any of the tagged-list productions fail, the resource
that is no longer locked will be indicated with a 412 in
the multistatus return, telling the client to either remove
that lock from its table, or request a new lock for that
resource.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]

for compatibility reasons, if the client didn't provide the new submit
header, the server prudently can be expected to check the If: header
using whatever semantics that it thinks 2518 specifies regarding
token submission.

Similarly, for compatibility reasons (in addition to any correctness
reasons)
we might expect the client to continue to submit If headers.  For
compatibility
reasons a production client wouldn't depend on the server checking
conditions on
resources other than ones the server thinks are pertinent, but we can begin
to
test interoperability of that.   Eventually though clients would only
submit
the If: header for correctness reasons and will feel free to do checks on
any resource it feels is appropriate.

> d) all state productions in a If header are checked, not only those that
>    apply to "affected" resources by the operation.
Yes,  Initially clients that are spamming the If: header will pay a price
for that.  But as they eventually move to the new header or stop
spamming the If: header, that price will no longer be paid.

The tact that can be taken in production systems is...

New clients can submit the new header and only the If: clauses that it
feels
it wants tested.  If the LOCKED error code is returned, they can resubmit
to check if the error is just a problem with an old server.   This means
there
will be a price for using an old server, but things will still work and it
will be
an incentive to upgrade.

New clients can submit If: clauses for extra resources, but they will not
be
written to be dependent on submitting extra If: clauses to achieve
correctness.  Not unless they have a way to verify that the server
supports this.  I don't see this as a problem since we aren't emphasizing
this feature yet.  But eventually it becomes a possibility.

New servers will know that if a client submits a new header, that it should
process that new header.   In that case it will also process *all* of the
If: header
clauses and we can test servers to verify that they support this even if
production clients don't exercise this feature.

If new servers receive a request that does not have the new header, they
will fall back on whatever code they currently use for If: headers
submitting
lock tokens.

That's what productions systems could do.  Testing systems and tightly
integrated systems could actually fully exercise the new features.

J.

------------------------------------------
Phone: 914-784-7569

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 7 Oct 2002 11:44:21 -0700

The proposal to require tagged-lists would not fix everything:

-          The IF header, particularly with URL tagging, is very long
and can't be split up over several lines.

-          If a lock disappears, the request will fail, even if the
client wants it to succeed anyway. Round-trip required.

-          The client doesn't always know which locks are required (e.g.
DELETE a resource in collection with depth-0 lock). Round-trip required.

Note that if we went with the proposal simply to require tagged lists,
then the untagged list production should be "deprecated", probably by
telling clients they MUST NOT use untagged list productions.  The
untagged syntax becomes useless and should eventually be removed, though
servers must continue to support the syntax as long as they want to
interoperate with pre-existing clients.

I know the proposal to required tagged lists has been considered by
client developers, and it was considered inferior to the proposal for a
new header.  In practice, it's the situation they currently experience -
although the specification doesn't say the client MUST use tagged-lists,
clients eventually come to that realization.  And still, after
programming the client to work that way, they find it's complicated and
sometimes doesn't work in practice.

Client implementers aren't the largest active constituency on this
mailing list, and I'm not sure why, because I would guess they are the
largest constituency of WebDAV implementers. When we do hear a solid
consistent opinion from the client implementers, I believe it should be
taken very seriously.

Lisa 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Clemm, Geoff
Sent: Monday, October 07, 2002 11:14 AM
To: 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock token provision

Cheers, 
Geoff 

-----Original Message----- 

Similarly, for compatibility reasons (in addition to any correctness 
reasons) 
we might expect the client to continue to submit If headers.  For 
compatibility 
reasons a production client wouldn't depend on the server checking 
conditions on 
resources other than ones the server thinks are pertinent, but we can
begin 
to 
test interoperability of that.   Eventually though clients would only 
submit 
the If: header for correctness reasons and will feel free to do checks
on 
any resource it feels is appropriate. 

>    apply to "affected" resources by the operation. 
Yes,  Initially clients that are spamming the If: header will pay a
price 
for that.  But as they eventually move to the new header or stop 
spamming the If: header, that price will no longer be paid. 

New clients can submit the new header and only the If: clauses that it 
feels 
it wants tested.  If the LOCKED error code is returned, they can
resubmit 
to check if the error is just a problem with an old server.   This means

there 
will be a price for using an old server, but things will still work and
it 
will be 
an incentive to upgrade. 

New clients can submit If: clauses for extra resources, but they will
not 
be 
written to be dependent on submitting extra If: clauses to achieve 
correctness.  Not unless they have a way to verify that the server 
supports this.  I don't see this as a problem since we aren't
emphasizing 
this feature yet.  But eventually it becomes a possibility. 

New servers will know that if a client submits a new header, that it
should 
process that new header.   In that case it will also process *all* of
the 
If: header 
clauses and we can test servers to verify that they support this even if

J.