Subject: RE: bind draft issues

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 3 Mar 2003 15:47:32 -0500

I do not understand what you mean by a URL having a
property.  A URL is just a string.  It has no properties,
no state, nothing other than a sequence of characters.
A URL is mapped by a server to a resource, and that 
resource has state.

A lock can "protect" a URL mapping, but that does not
give a URL a WebDAV property.

So at least as far as bindings are concerned, I feel
that 2518 does fully specify the behavior of the
properties defined by 2518.

Cheers,
Geoff

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Monday, March 03, 2003 2:12 PM
To: WebDAV
Subject: Re: bind draft issues

On Saturday, March 1, 2003, at 06:27  AM, Clemm, Geoff wrote:
>
>    From: Brian Korver [mailto:[email-masked]]
>
>    URL Properties
>
>    The behavior of other URL properties (in addition to
>    locks) should be fully specified, for instance the
>    display-name property.
>
> I'm not aware of the binding protocol causing any change
> to the behavior of the properties defined by 2518.  Also
> note that a resource has properties, not a URL.

Geoff,

URLs have properties to.  Think about how DAV:lockdiscovery
works in the face of COPY/MOVE, or DAV:displayname for that
matter.

Regarding this issue, I was not suggesting that the problem
is that the binding protocol changed the behavior of properties,
just that the behavior needs to be fully specified.  Do
you feel that 2518 does fully specify the behavior of
URL properties?

-brian
[email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 4 Mar 2003 16:56:05 -0500

In case there remains any question about whether HTTP supports
multiple URIs being mapped to the same resource, the following quote
appears in section 9.6 of RFC-2616:

"A single resource MAY be identified by many different URIs. For
 example, an article might have a URI for identifying "the current
 version" which is separate from the URI identifying each
 particular version. In this case, a PUT request on a general URI
 might result in several other URIs being defined by the origin
 server."

The binding protocol does two things: 

- it provides terminology for us to unambiguously discuss concepts
that already exist in HTTP (and therefore are inherited by WebDAV).

- it provides a new method to allow a client to explicitly
creating multiple mappings to a resource.

It is important to distinguish the new terminology for existing
concepts (e.g. "bindings") from new functionality (e.g. BIND).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 4:36 PM
To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
Subject: RE: bind draft issues

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 9:33 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: bind draft issues
>
> > I thought we had agreement that GULP is the currently best
> > approach of explaining the WebDAV locking model. GULP also covers
> > binds (implicitly!)  and therefore either should be added to
> > RFC2518bis, or be the basis for a rewrite:

> GULP should not cover bindings.  That's the problem.  It causes a

I don't understand this statement. How is the fact that GULP indeed
handles the effects of multiple bindings (internal member URIs) to the
same resource affecting it's usability for servers that do not need to
consider this case??? Maybe it's really time to re-read it:

-----------
Grand Unified Lock Proposal (V5.2)

- A lock either directly or indirectly locks a resource.

- A LOCK request creates a new lock, and the resource identified
  by the request-URL is directly locked by that lock.  The
  "lock-root" of the new lock is the request-URL. If at the time of
  the request, the request-URL is not mapped to a resource, a new
  resource with no content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
  members of that collection (other than the collection itself) are
  indirectly locked by that lock.  In particular, if a binding to a
  resource is added to a collection that is locked by a depth:infinity
  lock, and if the resource is not locked by that lock, then the
  resource becomes indirectly locked by that lock.  Conversely, if a
  resource is indirectly locked with a depth:infinity lock, and if the
  result of removing a binding to the resource is that the resource is
  no longer a member of the collection that is directly locked by that
  lock, then the resource is no longer locked by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock.

- If a request would modify the content for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or a binding of a locked collection,
  the request MUST fail unless the lock-token for that lock is
  submitted in the request.

- If a request causes a directly locked resource to no longer be
  mapped to the lock-root of that lock, then the request MUST
  fail unless the lock-token for that lock is submitted in the
  request.  If the request succeeds, then that lock MUST have been
  deleted by that request.

- If a request would cause a resource to be locked by two different
  exclusive locks, the request MUST fail.
-----------

I really doubt that you make the description significantly simpler by
removing this case.

> problem because some RFC2518 servers just don't work that way.  There's

Could you explain? Are you saying that there are RFC2518-compliant
servers that do not comply to the GULP lock model? In which case
there's simply a problem in the model that needs to be
fixed. Actually, Geoff and I have been asking for this kind of
feedback for several months now.

> no need to say whether operations apply always to URLs, bindings or
> resources in RFC2518, because when you have 1:1 mappings between
> URLs

No. You don't. Just because RFC2518 doesn't have a BIND method doesn't
mean that multiple bindings do not exist.

In fact, RFC2518bis talks about redirect resources, although it
doesn't define a method to create them. This is a very similar issue.

> and resources it just doesn't matter 95% of the time, and lets
> implementations expose their existing repository.

So how precisely have these implementations problems with GULP? Please
explain!

> Otherwise, I think there is a lot of useful specification language in
> GULP.

OK.

So *please* specify in which way GULP is inconsistent with
RFC2518. Things I don't like to hear are:

- it contains the term "binding"

- RFC2518 defines a 1:1 mapping between URL and resource (this is
clearly wrong, because RFC2518 extends HTTP, and there's no such
restriction in HTTP).

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Mar 2003 09:08:59 -0500

Geoff, as RFC3253 relies on the concept of bindings, could you
   please attempt to fill in what *you* think an identical
   DAV:resource-id needs to indicate?

For RFC3253, two version-controlled resources are the "same" when
they have the same version history.  So the obvious implementation
of the DAV:resource-id property for a version-controlled resources
is the DAV:version-history property.

Version and Version-History resources cannot be moved, so the
URL at which the were created can act as their DAV:resource-id.

So this allows RFC3253 to remain neutral on the question of 
what does "resource identity" mean about the results of various
other HTTP and WebDAV methods.

Note: the question of resource identity for an activity resource
is not addressed by RFC3253, so that remains an open question.
Since most versioning repositories store activity resources in some
kind of database, resource identity for activities ends up not
being much of a problem in practice though, since there usually will
be some obvious implementation property that could be used as
the DAV:resource-id property.

Cheers,
Geoff

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Mar 2003 09:24:15 -0500

Actually, my suggestion below that RFC3253 is neutral wrt to
the meaning of "resource identity" is probably somewhat misleading.
In particular, there is the underlying assumption that you can
make any version of a version-controlled resource appear at the
location of that version-controlled resource (e.g. with an UPDATE
request).  This assumption is not very compatible with an attempt
to have a URL define the "variant" of a resource (e.g. the Swedish
variant), since any version checked-in at the Swedish variant URL
would go into the version history and then be accessible at any
other version-controlled resource for that version history.
In addition, wrt to PROPFIND semantics, many important use cases
would be broken if PROPFIND of a live versioning property could
return different values at different URL locations.

So there is a basic leaning towards "content and properties are the
same at all URL locations of a given resource" semantics for a
versioning server (at least, for version-controlled resources).

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Monday, March 10, 2003 9:09 AM
To: WebDAV; Roy T. Fielding
Subject: RE: bind draft issues

Cheers,
Geoff