Re: Interop issue: Proposal for fixing lock token provision

On Monday, 10/07/2002 at 11:01 ZE2, Stefan Eissing
<nnstefan.eissing___at___greenbytes.de@smallcue.com> wrote:
> Am Samstag, 05.10.02, um 01:06 Uhr (Europe/Berlin) schrieb Jason
> Crawford:
>
> > We need to hear more from folks.  Things have been unusually quiet on
> > this
> > subject.
> >
> > Jason and Lisa have spoken up in favor of splitting the functionality.
> >
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html
> > (and
> > previous postings)
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html
> >
> > Stefan has spoken against it before that time, but it is unclear if he
> > understood the proposal.  Hopefully the proposal is clearer now.
>
> I try to summarize the proposal in my own wording. Let's see if we
> have a common understanding of the proposal:
>
> a) the If header is used for checking state of resource(s) as in 2518.
>     ETags and lock tokens can be used for state checking.
Yes.

> b) on modifications of resources, the server is required (as stated in
>      2518) to check if the client "submitted" the necessary tokens.
>    A new header is introduced which keeps untagged lock tokens. Those
>    lock tokens are regarded as "submitted by the client".
Yes.  I'd prefer that it be untagged, but that's negotiable.

> c) lock tokens in If headers are not considered as "submitted by the
> client"
Yes, but
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

Received on Monday, 7 October 2002 11:48:14 UTC