RE: Interop issue: Proposal for fixing lock token provision

RE: Interop issue: Proposal for fixing lock token provisionI agree with
Geoff.

If there's an interoperability problem, I'd like to see a precise
description, preferrably from the client implementors.

The scenario of a client having a lock token and the etag trying to PUT, and
the server rejecting the request because the lock was lost doesn't really
seem to be a case that needs special treatment. If this is happening
frequently, it's a client (wrong timeout) or server bug that needs to be
fixed. If it doesn't happen frequently, there's no reason to add special
optimzations in RFC2518bis.

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

  -----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 9:18 PM
  To: 'Webdav WG'
  Subject: 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.