RE: Interop issue: Proposal for fixing lock token provision

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: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
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

 

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