RE: Interop issue: Proposal for fixing lock token provision

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:nn683849@smallcue.com]

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