RE: Interop issue: Proposal for fixing lock token provision

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   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.

I'd be happy to extend the syntax of the If header to allow a ","
to separate the productions.

RFC2518 authors: was it just a blunder (:-) that "," is not
the separator, or was there some good reason why it wasn't used?

Server writers: what would your server do today if it received
multiple If headers in a single request?

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

As indicated in my previous message, I need to see some explanation
for why clients that don't care about merge prevention are using locks
in the first place?  Why aren't they just using etags?

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

I don't see any connection between this issue and whether or
not to use a separate header.  If they don't have the right
list of tokens in the new header, they will still get a failure
and the same extra round-trip is 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.

If the untagged syntax becomes useless, I'm happy to deprecate it.
I'm always happy to delete/deprecate things from the spec if they
turned out to not be useful ... that simplifies the spec, rather than
making it more complex.

   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.

Why is it complicated to create a tagged list?  And I'm not sure what
you mean by "in practice".  If you mean "against existing servers",
then you certainly aren't going to fix things by adding a new header
that those servers are not expecting.

My impression from what is being reported is that clients aren't
aware they should be sending a tagged list, and some servers aren't
aware that tagged lists need to be implemented.  This is simplest
to fix by making clients aware that they should be sending tagged
lists, and making servers aware that they should be implementing
tagged lists.

   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.

For there to be demonstrable solid consistent opinions from client
implementers, we need to see it documented in the mailing list, since
that is where working group consensus is formed.  If client implementers
feel this is an important issue, it is imperative that they participate
in this discussion.  It's like democracy ... you don't get to complain
if you don't vote.

Cheers,
Geoff


   From: Clemm, Geoff

   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.