RE: Interop issue: Proposal for fixing lock token provision

RE: Interop issue: Proposal for fixing lock token provisionSome thoughts:

- it doesn't make sense to raise the header length problem as argument in
favor of adding a new header. If the If header length is a problem, it needs
to be fixed anyway -- no matter how the other issues are treated

- As far as I now understand the client issue (BTW: why aren't the
developers of this or these clients not participating in this dicussion??),
they want to avoid to re-issue a request that specified a lock token just
because the lock went away in the meantime. I *still* don't see why this is
a problem -- if the lock was theirs, it's not supposed to go away without
reason (such as bad timeout value). If the lock *wasn't* theirs, this is a
case of "lock stealing", which certainly doesn't require to be optimized,
right?

- if a client really really wants the request to succeed either case (lock
being present or not), can't he simply submit an If header production such
as:

If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>)(Not
<locktoken:a-write-lock-token>))

?

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 Lisa Dusseault
  Sent: Tuesday, October 08, 2002 8:41 PM
  To: 'Clemm, Geoff'; 'Webdav WG'
  Subject: RE: Interop issue: Proposal for fixing lock token provision


  The client should be able to choose either of the headers you use as
examples, depending on whether they want the request to succeed even if lock
tokens are invalid.



  When the client submits "New-If-Header: token-1, token-2" (note the comma)
the client wants the request to succeed, as can be seen by the fact that it
is not issuing a conditional request.  So:

  1.       If token-1 is not needed, or doesn't correspond to a live lock,
the request doesn't fail.

  2.       Same for token-1.



  When the client submits "If:<lockroot-1> (<token1>) <lockroot-2>
(<token-2>)", the client is forcing the request to fail if the conditions
aren't met.  If that's what the client wants, then fine.  But if the client
wants the request to succeed, I would hope the client could use something
else, because:

  1.       If token1 is invalid, or doesn't match lockroot-1, the request
fails.

  2.       Same for token2



  Syntactic "swill" is important in this case because when moving a
directory with a bunch of locked files, the syntactic "swill" of the
existing if header can result in a request that is impossible to
successfully convey to the server because of bad support (in proxies,
firewalls or servers) for very long header values.



  Client effort may or may not be reduced.  Client effort is definitely
reduced in these cases:

  1.       The client has been able to put all their lock tokens in the
"New-If-Header" value without having to sort which ones apply to which URLs
and which ones are "required" for this operation.

  2.       If a lock has gone away, the client is not forced to (a) parse
the error and (b) reformat request without offending tokens and (c) reissue
the request, which they want to work, just in order for it to work.



  I fail to understand how these are "separate issues".  The proposal has
several advantages described. It can be interoperable with the existing
client/server deployed base because nobody has to change how they
send/handle the existing IF header.  Perhaps you want to compare this to
another proposal that would solve some of the same problems, but if that's
the case, then I cannot answer because I do not understand what the
alternate proposal is.



  Lisa



  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
On Behalf Of Clemm, Geoff
  Sent: Tuesday, October 08, 2002 10:44 AM
  To: 'Webdav WG'
  Subject: RE: Interop issue: Proposal for fixing lock token provision



  Perhaps you could explain this with an example?

  In particular, whenever you would have a client submit:

  New-If-Header: token-1 token-2

  I would have that client submit:

  If: <lockroot-1> (<token1>) <lockroot-2> (<token-2>)

  Other than the minor syntactic swill, and the addition of the
  lockroot tag, what is the difference in terms of client effort?
  (Semantically of course there is a difference, in that
  you cannot submit invalid lock tokens in If, but
  that is a separate issue).

  Cheers,
  Geoff



  -----Original Message-----
  From: Lisa Dusseault [mailto:lisa@xythos.com]
  Sent: Tuesday, October 08, 2002 12:44 PM
  To: 'Clemm, Geoff'; 'Webdav WG'
  Subject: RE: Interop issue: Proposal for fixing lock token provision



  > Using a different header to submit tokens doesn't make it any easier
  > for a client to decide what tokens to submit in the header.

  Yes it does, which is one of the major reasons client developers have
  asked for this to be fixed: it makes it possible for clients to submit a
  bunch of lock tokens for the same "area" of the namespace, even if the
  client is not sure whether the server would require each lock token.

  Since servers are different in how they require lock tokens for various
  operations, this allows clients to submit as many lock tokens as they
  believe they need, without failing on some servers.

  lisa