Subject: RE: Interop issue: Proposal for fixing lock token provision

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 8 Oct 2002 17:18:12 -0400

Julian makes several good points.

One is that we need to address the If header length problem in 2518bis
in any case.  Even if we did provide a separate header that allowed
invalid lock tokens, we still need to use the If header when we want
to check for a list of valid lock tokens, or when we want to check for
a list of etags.

Another good point is that we don't have to argue about whether a
client should be allowed to submit invalid lock tokens, because once
the If header length problem is addressed (which we have to do
anyway), then the "If: <tag> (<token>)(Not <token>)" provides this
functionality without defining a header with new semantics.

In an earlier message in this thread, the following points were raised
as being problems with the "If:...Not..."  approach:

   PROBLEM #1: Servers may not support the OR, and the NOT, correctly,
   because most clients don't currently use this. This solution HAS NOT
   been proven, it is only theoretical. It might not work.

It will work against all existing servers that are correctly
implemented and that don't have an If header length problem, unlike
the "new header" approach, which is guaranteed to fail against all
existing servers.  If the servers are going to be updated,
updating them to correctly implement existing semantics seems
like a sensible approach to take, especially when the existing
semantics are a "logical or" and a "logical not", built-in operators
in most programming languages.

   PROBLEM #2: What if multiple locks are required (e.g. moving a
   collection that has multiple locked resources? What if the URLs are
   long? The IF header becomes very long and may be truncated by some
   proxies. E.g.

   If: <http://www.ics.uci.edu/users/f/fielding/index.html> 
   (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
   NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
   <http:// www.ics.uci.edu/users/f/fielding/anotherfile.html>
   (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>
   NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>)
   <http:// www.ics.uci.edu/users/f/fielding/thirdfile.html>
   (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>
   NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>)

This is the If header length problem.  Once we fix the If header
problem (which we have to do anyway), there no longer is a need
for a new header to get this functionality.

   PROBLEM #3: Uck, this is really complicated. While it's useful to know
   that a client can do this with some existing servers, provided they
   handle it correctly, surely we can do this in a simpler mechanism that
   is less prone to interoperability problems. A simple header that allows
   the client to supply lock tokens to use is semantically equivalent to
   the above example, but shorter, simpler, and easier to implement. Also
   it can be split across multiple lines.
   Use-Lock-Tokens:
   <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, 
   <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>
   Use-Lock-Tokens:
   <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>

Computer programs are really good at spitting out the same string
twice, surrounded by some constant characters.  Given the verbosity of
XML, and the fact that the Internet is used to stream video, cutting
down the number of characters required to identify lock tokens does
not strike me as a high priority task.  And since any client that
wants to interoperate with an existing server has to be able to
generate the If form of the request anyway, this is no simplification
for an interoperable client that has to be able to generate both forms
of the request.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]

Some 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>))

?

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 9 Oct 2002 01:50:23 +0200

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

I'd like to underline that I'm *really* interested to understand why a
client would *ever* want a request to succeed if a lock which is supposed to
be present unexpectedly disappeared.

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

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Clemm, Geoff
  Sent: Tuesday, October 08, 2002 11:18 PM
  To: 'Webdav WG'
  Subject: RE: Interop issue: Proposal for fixing lock token provision

  Cheers,
  Geoff

  -----Original Message-----

  Some thoughts:

  ?

---

From: "Seth Osher" <[email-masked]>
Date: Tue, 8 Oct 2002 23:53:42 -0400

RE: Interop issue: Proposal for fixing lock token provisionFor example a
long running folder copy, move or delete.

If the operation takes long enough that locks might expire
during the operation, then the semantic might not even be
really enforceable. Particularly, it servers is incapable of checking the
locks in advance, or to do so might be expensive from a time
perspective (say an operation on a optical-archive, where the full set
of resources is only known on the media).

In these cases you want the copy or move to perform "as much work
as possible" so you just want to provide a list of all your current tokens.

A second example is where a server provides multiple views of the same
data.  A client may not know for certain what resources it has locked
and are going to participate in a copy, move or delete operation.
Rather than fully enumerating the set of resources to be operated on,
presenting "all-my-tokens" would be useful, if not critical.

A third case is where a user wants the operation to succeed, even
if etags for the locked resources have changed (perhaps a shared-write
has updated the resource, changing its etag).  In this case, we want to
present the lock, and don't want to worry about the etag.  It might even
have be deleted by the shared-write lock so the token is no longer valid.

Perhaps it is possible to construct an If: header that handles these
cases, but a shorthand that avoids recursive introspection on the server
would be useful, particularly in low-bandwidth environments.

- Seth Osher

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Julian Reschke
  Sent: Tuesday, October 08, 2002 7:50 PM
  To: Clemm, Geoff; 'Webdav WG'
  Subject: RE: Interop issue: Proposal for fixing lock token provision

  Obviously I agree with Geoff.

  Julian

    -----Original Message-----
    From: [email-masked]
[mailto:[email-masked]]On Behalf Of Clemm, Geoff
    Sent: Tuesday, October 08, 2002 11:18 PM
    To: 'Webdav WG'
    Subject: RE: Interop issue: Proposal for fixing lock token provision

       PROBLEM #3: Uck, this is really complicated. While it's useful to
know
       that a client can do this with some existing servers, provided they
       handle it correctly, surely we can do this in a simpler mechanism
that
       is less prone to interoperability problems. A simple header that
allows
       the client to supply lock tokens to use is semantically equivalent to
       the above example, but shorter, simpler, and easier to implement.
Also
       it can be split across multiple lines.
       Use-Lock-Tokens:
       <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>,
       <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>
       Use-Lock-Tokens:
       <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>

    Cheers,
    Geoff

    -----Original Message-----

    Some thoughts:

    ?

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 9 Oct 2002 10:40:00 +0200

> Behalf Of Seth Osher
> Sent: Wednesday, October 09, 2002 5:54 AM
> To: Webdav WG
> For example a long running folder copy, move or delete.
>

...in which case I'd say that the locks should have had a longer timeout in
the first place. Why bother locking, if you're unsure that the timeout is
long enough to protect the subsequent request?

> as possible" so you just want to provide a list of all your

Really? Again -- if it's irrelevant whether the lock is still there, why was
it made in the first place?

> presenting "all-my-tokens" would be useful, if not critical.

I don't understand this scenario. Could you please define what a "view"
technically is on your system? Is it an additional binding to the same
resource?

Every lock that the client made has been made on a particular request URI --
and that's the URI that needs to be submitted alongside with the lock token
(in the If header).

> present the lock, and don't want to worry about the etag.  It might even

Why do you submit the etag if you don't want it to be enforced?

> have be deleted by the shared-write lock so the token is no longer valid.

Why would the resource be deleted if you still have a shared-lock on it?

> would be useful, particularly in low-bandwidth environments.

As shown in yesterday's mail, it is possible. It's just syntactically
different.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 9 Oct 2002 11:35:54 +0200

Hi,

a new version of our proposal for datatype handling for WebDAV properties is
available at [1] and [2].

In addition to the marshalling of type information, it now also covers

- marshalling of "protected" flag (signals the user client not to allow
editing of this property)
- marshalling of "hidden" flag  (signals the user client not to display this
property)
- displaynames for properties

At this point, it would be interesting to receive feedback from developers
of generic WebDAV clients (such as KCura or Xythos).

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-03
.html>
[2]
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-property-datatypes
-03.txt>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760