Subject: Issues remaining with Bind draft

From: Lisa Dusseault <[email-masked]>
Date: Wed, 17 Mar 2004 15:08:26 -0800

I've re-reviewed the bind draft.  Many of these issues have come up 
before but I feel they haven't been resolved in the draft.

General
-----------

The spec must stand alone, not be dependent on changes to RFC2518 in 
'bis'.  Otherwise, bind can't be approved until RFC2518bis is approved. 
  That means no dependencies for things like 'lockroot'.

In general, the spec needs more info to specify how existing things 
work.  All the following questions must be answered in the spec, NOT 
just in email.  The spec must be explicit, because different people 
reading a model description always end up with different ideas how the 
model works in practice.

A - Issues relating to 2518 features
   1.  Can you UNLOCK a URI that binds to a locked resource, when that 
URI wasn't directly locked?  If not, what's the error?
   2. Can you LOCK a URI that binds to a locked resource, when that URI 
wasn't directly locked? If not, what's the error?
   3.  In If header evaluation, does a URI "match" a lock token, when 
that URI wasn't directly locked but the underlying resource was locked 
with that token?
   4.  What exactly does lockdiscovery show on a locked binding? On a 
locked resource accessed through an unlocked binding?  Does 
'lockdiscovery' look exactly the same on every binding to a locked 
resource?
   5.  What does creationdate refer to, I assume it's the creationdate 
of the underlying resource (not the creation date of the binding)?  If 
the underlying resource, is there any way to tell when a binding was 
created?  and vice versa?

B - Issues related to versioning features (massively incomplete), or 
how does a server supporting bindings and versioning work
   1. If a resource is checked out, do all bindings appear checked out?  
(In general, are all the live properties defined in versioning the same 
on all bindings?)
   2. Clarify that a VCR isn't just another binding (because different 
VCRs pointing to the same VHR have different live properties, not the 
same ones)
   etc...

Questions on specific text
-----------------------------------

What does this mean (section 2.3, second-last paragraph): "If because 
of multiple bindings to a resource, more than one source resource  
updates a single destination resource, the order of the updates is 
server  defined."

I don't understand the case when more than one source resource updates 
a single destination resource.

I also don't see how this could arise:  " If a COPY request would cause 
a new resource to be created as a copy of an  existing resource, and 
that COPY request has already created a copy of that existing resource, 
the COPY request instead creates another binding to the  previous copy, 
instead of creating a new resource."

Section 2.4

" When DELETE is applied to a collection, it MUST NOT modify the 
membership  of any other collection that is not itself a member of the 
collection being deleted. For example, if both "/a/.../x" and 
"/b/.../y" identify the same  collection, C, then applying DELETE to 
"/a" MUST NOT delete an internal  member from C or from any other 
collection that is a member of C, because  that would modify the 
membership of "/b"."

I don't understand why there's a conditional on the first sentence of 
"that is not itself a member of the collection being deleted".  When 
would the membership of any other collection be modified?  In 
particular, C is a descendant (not a direct member) of /a, but even if 
it were a direct member, it seems the rule should apply.

Section 6 -- REBIND method

One precondition is " (DAV:binding-allowed): The resource identified by 
the DAV:href  supports multiple bindings to it."   How can this error 
possibly occur?

Does REBIND destroy locks, as MOVE does?  It shouldn't, unless there's 
a compelling reason for backward compatibility.

Does REBIND change the ETag of a resource?  Does it change the 
getlastmodified value of the resource?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Mar 2004 12:36:58 +0100

> before but I feel they haven't been resolved in the draft.

There isn't any.

> work. All the following questions must be answered in the spec, NOT just 
> in email. The spec must be explicit, because different people reading a 
> model description always end up with different ideas how the model works 
> in practice.

Here I disagree.

First of all, there are several ways to resolve questions raised:

1) If there is a simple answer based on existing specs and the current 
draft, just answer it here on the mailing list.

2) If the issue is likely to be re-raised (because the answer is not 
obvious), record it (and the answer) on the issues list.

3) If the issue is indeed valid, add it to the issues list and attempt 
to resolve it.

In general, there are areas where the spec *can't* specify how existing 
things work, because they depend on specific implementations. I 
absolutely agree that those situations should be avoided, but sometime 
there's nothing we can do about that.

I'll post answers to the specific issues in a separate mail.

Regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Mar 2004 14:29:03 +0100

Lisa Dusseault wrote:

> 1. Can you UNLOCK a URI that binds to a locked resource, when that URI 

I can't see any language in RFC2518 and/or BIND saying that you can't, 
so you can. UNLOCK removes the lock identified by the lock token header 
from the resource identified by the request URI, so the actual URI being 
used for UNLOCK is irrelevant.

> wasn't directly locked? If not, what's the error?

You can, as long both locks are compatible (that is, none of them is 
exclusive). So the situation here is exactly as if you use the same 
request URI.

> 3. In If header evaluation, does a URI "match" a lock token, when that 
> URI wasn't directly locked but the underlying resource was locked with 
> that token?

The If header matching description 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>) 
talks about resources, not URIs, thus it's not relevant which URI you 
provide as long as it identifies the right resource.

> 4. What exactly does lockdiscovery show on a locked binding? On a locked 
> resource accessed through an unlocked binding? Does 'lockdiscovery' look 
> exactly the same on every binding to a locked resource?

Yes. The lock belongs to the state of the resource, so PROPFIND returns 
the same operation no matter which binding you use.

> 5. What does creationdate refer to, I assume it's the creationdate of 
> the underlying resource (not the creation date of the binding)? If the 

Yes.

> underlying resource, is there any way to tell when a binding was 

No.

> B - Issues related to versioning features (massively incomplete), or how 
> does a server supporting bindings and versioning work
> 1. If a resource is checked out, do all bindings appear checked out? (In 
> general, are all the live properties defined in versioning the same on 
> all bindings?)

Yes, again; that's the nature of bindings.

> 2. Clarify that a VCR isn't just another binding (because different VCRs 
> pointing to the same VHR have different live properties, not the same ones)
> etc...

As DeltaV doesn't say that, I'm not sure why we would need to clarify that.

> What does this mean (section 2.3, second-last paragraph): "If because of 
> multiple bindings to a resource, more than one source resource updates a 
> single destination resource, the order of the updates is server defined."
>
> I don't understand the case when more than one source resource updates a 
> single destination resource.

This can happen when, for instance, you copy /a with members /a/b and 
/a/c (bindings to different resources) to a destination /d with members 
/d/a and /d/b (bindings to the same resource). The end result will be 
that /d/a and /d/b are still bindings to the same resource, but the spec 
doesn't guarantee whether it'll be the content of /a/b or /a/c. It's an 
edge case.

> I also don't see how this could arise: " If a COPY request would cause a 
> new resource to be created as a copy of an existing resource, and that 
> COPY request has already created a copy of that existing resource, the 
> COPY request instead creates another binding to the previous copy, 

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-03.html#rfc.issue.2.3_COPY_SHARED_BINDINGS>.

> collection being deleted. For example, if both "/a/.../x" and "/b/.../y" 
> identify the same collection, C, then applying DELETE to "/a" MUST NOT 
> delete an internal member from C or from any other collection that is a 
> member of C, because that would modify the membership of "/b"."
> 
> would the membership of any other collection be modified? In particular, 

It shouldn't. That's the point of the statement.

> C is a descendant (not a direct member) of /a, but even if it were a 
> direct member, it seems the rule should apply.
> 

If a part of your namespace doesn't allow multiple bindings.

> Does REBIND destroy locks, as MOVE does? It shouldn't, unless there's a 
> compelling reason for backward compatibility.

No, it should. REBIND is a "strong" MOVE (that will never attempt a 
"weak" resource move using COPY/DELETE). That's the only semantical 
difference to MOVE, and thus locks behave just like they do with MOVE.

> getlastmodified value of the resource?

Same as MOVE (which means: usually not).

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 18 Mar 2004 09:01:35 -0500

> General

I wouldn't describe this as "standing alone" (since it clearly must
depend on RFC2616, RFC2518, etc.), but I agree that it cannot depend
on material in specs that have not yet been finished/approved.

>   That means no dependencies for things like 'lockroot'.

As Julian indicated, we are not aware of any such dependencies.

> work. 

The spec needs to describe how the new things it is
defining work, and it needs to describe any modifications to the
behavior of existing things.  But if it is layered above some other
specs (as the binding spec is layered above 2616, 2518, etc), it
should not repeat or reword behavior it is just inheriting unmodified
from those other spec.  Doing so would only introduce confusion
when the spec that does define the behavior of those existing things is 
revised.

> All the following questions must be answered in the spec, NOT 
> just in email.

If every question that ever arises about a spec on the
mailing list resulted in a paragraph or even just a
sentence being added to the spec, the spec would rapidly
become too bulky and verbose to be useful as a spec.

> The spec must be explicit, because different people 

As Julian indicated, there are a variety of sources of information
that are used to help implementors.  The spec is of course a critical
piece, but the issues list and the mailing list are two other essential
pieces.

So every question gets answered in the mailing list.
Some questions get added to the issues list.
Some issues result in changes to the specification.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 Mar 2004 10:16:29 -0800

On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:

> so you can. UNLOCK removes the lock identified by the lock token  
> header from the resource identified by the request URI, so the actual  
> URI being used for UNLOCK is irrelevant.

It's not good enough to say that if it's not forbidden, it's allowed.   
Servers need to either allow this consistently, or disallow it  
consistently.  Clients need dependable behavior.  The spec needs to say  
something like "Servers MUST allow UNLOCK to succeed on a binding to a  
locked resource (provided other conditions are met like lock token),  
even if the locked resource was originally locked through another  
binding.

> exclusive). So the situation here is exactly as if you use the same  

Again, this needs to be clear in the spec.  Add language to the spec  
saying "A lock created on any binding to a resource prevents exclusive  
locks from being created on any other binding to the same resource."

>> that URI wasn't directly locked but the underlying resource was  
>> locked with that token?
>

So say that in the spec.

> Yes. The lock belongs to the state of the resource, so PROPFIND  
> returns the same operation no matter which binding you use.

So say that in the spec.  This clearly needs to be said, because  
several people have read the spec and come to different conclusions  
about whether other bindings also appear as locked.

etc...

>> (In general, are all the live properties defined in versioning the  
>> same on all bindings?)
>
I had to do a fair bit of thinking and logical deductions to figure  
that out, and I'm fairly experienced in this area.  Let's save  
implementors that work and the risk of making an incorrect assumption.   
A bindings section on the relationship of binding to the  
resources/properties defined in DeltaV isn't too hard to write.

>> I don't understand the case when more than one source resource  
>> updates a single destination resource.
>
> /a/c (bindings to different resources) to a destination /d with  
> members /d/a and /d/b (bindings to the same resource). The end result  
> will be that /d/a and /d/b are still bindings to the same resource,  
> but the spec doesn't guarantee whether it'll be the content of /a/b or  
> /a/c. It's an edge case.
>
Do you mean you're copying /a so that it becomes a child of the  
destination /d or so that it overwrites the destination /d?

>> I also don't see how this could arise: " If a COPY request would  
>> cause a new resource to be created as a copy of an existing resource,  
>> and that COPY request has already created a copy of that existing  
>> resource, the COPY request instead creates another binding to the  
>> previous copy, instead of creating a new resource."
>
> See  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -03.html#rfc.issue.2.3_COPY_SHARED_BINDINGS>.
>
>> Section 2.4
>> particular,

If you agree with me, then the text should simply read:

"When DELETE is applied to a collection, it MUST NOT modify the  
membership of any other collection.  For example, if both [continue  
text unchanged...]"

>> One precondition is " (DAV:binding-allowed): The resource identified  
>> by the DAV:href supports multiple bindings to it." How can this error  
>> possibly occur?
>

This is in a case where the resource already allowed multiple bindings,  
one of the bindings is simply being rebound.  So "DAV:binding-allowed"  
means either that the resource doesn't support multiple bindings, OR  
that the URI namespace area doesn't support multiple bindings?

> difference to MOVE, and thus locks behave just like they do with MOVE.

I disagree, but in either case, the spec needs to say this one way or  
another.

> Same as MOVE (which means: usually not).

Can't we be more specific about this?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Mar 2004 19:50:55 +0100

Lisa Dusseault wrote:

>> I can't see any language in RFC2518 and/or BIND saying that you 
>> can't,  so you can. UNLOCK removes the lock identified by the lock 
>> token  header from the resource identified by the request URI, so the 
>> actual  URI being used for UNLOCK is irrelevant.
> 
> 
> even if the locked resource was originally locked through another  binding.

The behaviour follows directly from what RFC2518 and the BIND spec say. 
The essential fact here is that live properties and locks belong to the 
state of the resource, so *unless stated explicitly otherwise*, the 
request URI does not matter. I think the BIND draft is very clear on 
that generic principle, and this is all we need.

> locks from being created on any other binding to the same resource."

But that follows from RFC2518's locking semantics. The request URI does 
not matter -- you are accessing the same resource, and thus it behaves 
as if you'd attempt the two locks on the same request URI.

>> provide as long as it identifies the right resource.

Sorry? Are you suggesting that anytime RFC2518 applies, we say that 
explicitly?

> about whether other bindings also appear as locked.

In which case I'd like to hear *how* they came to that conclusion.

> ...

>>> VCRs pointing to the same VHR have different live properties, not 
>>> the  same ones)
>>> etc...
>>
>>

I'm still not sure which part of DeltaV is supposed to be unclear here. 
But if there is one, this should be fixed as an RFC3253 erratum.

>>> What does this mean (section 2.3, second-last paragraph): "If 
>>> because  of multiple bindings to a resource, more than one source 
>>> resource  updates a single destination resource, the order of the 
>>> updates is  server defined."
>>>
>> but the spec doesn't guarantee whether it'll be the content of /a/b 
>> or  /a/c. It's an edge case.
>>

The latter.

> ...

>>> membership of any other collection that is not itself a member of 
>>> the  collection being deleted. For example, if both "/a/.../x" and  
>>> I don't understand why there's a conditional on the first sentence 
>>> of  "that is not itself a member of the collection being deleted". 
>>> When  would the membership of any other collection be modified? In  
>>> particular,
>>
>>

Well, it *may* change the membership of member collections.

>>> by the DAV:href supports multiple bindings to it." How can this 
>>> error  possibly occur?
>>
>>

OK, now I see. This precondition also exists on BIND (where it makes a 
lot of sense), however I'm not sure why we would need it for REBIND. 
Geoff, do you remember why it appears here?

>>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
>>> there's  a compelling reason for backward compatibility.
>>
>>

OK, we may have to add this piece of information, because it's not obvious.

> Can't we be more specific about this?

No, we can't. It *will* be the same as for MOVE, and for MOVE there's no 
guarantee whatsoever.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 18 Mar 2004 15:47:35 -0500

> >> As DeltaV doesn't say that, I'm not sure why we would need to clarify 
 
> >> that.
 
> But if there is one, this should be fixed as an RFC3253 erratum.

This is deliberately left as an implementation choices.  For example, on 
one
of our servers, we do use multiple bindings to a shared resource for 
checked-in VCR's, and then automatically create a new resource on
checkout.  As long as we satisfy the versioning pre and post conditions,
we are free to make that choice.  If the spec made the kind of statement
Lisa is asking for, it would be limiting the implementation choices of
a provider for no good reason.

In general, an implementor will have to do a fair bit of thinking and
logical deductions, because the spec is the basis for interoperation of
a wide range of implementations, not an implementation guide.

> Geoff, do you remember why it appears here?

I think it is just an error (resulting from copying all of the BIND
preconditions to the REBIND method).

So I think deleting the precondition would be the right thing to do.

> OK, we may have to add this piece of information, because it's not 
obvious.

I agree with Julian that locking semantics require this behavior, and I
agree that it would be reasonable to add this as an explicit 
post-condition
of the REBIND method.  We would then need to add a similar post-condition 
to
the UNBIND method.

> guarantee whatsoever.

That is correct.  If the etags on the rebound (or moved) resources
satisfy etag semantics, the etags can stay the same.  But they might have
to be changed (in case there previously was a resource at the destination
of the REBIND MOVE with that etag but with different content), so you 
can't
infer whether or not the etag changes as the result of a MOVE.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 Mar 2004 13:44:11 -0800

> a provider for no good reason.
We don't necessarily have to restrict implementations when we add 
clarifying text.  For example, we could say that "A VCR is more than 
just a binding to a VHR -- it has different properties and state.  
Likewise, two VCRs pointing to the same VHR don't always behave as two 
bindings to the same underlying VCR resource, again because of 
different properties and state in certain circumstances, such as when 
one VCR is checked out."

> infer whether or not the etag changes as the result of a MOVE.

Why couldn't the source ETag be preserved in a REBIND, even if the 
destination resource is being overwritten?  At the least, the spec 
should say that the source ETag MAY be preserved, so that clients know 
they have to handle both cases.

The getlastmodified is a little more contentious.  Does it mean that 
the underlying resource body changed?  If so, then the spec should say 
that this property SHOULD NOT (or MUST NOT) change only because of a 
REBIND operation.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Mar 2004 22:58:26 +0100

> they have to handle both cases.

A "MAY" doesn't really help. The issue here is that servers that do have 
ETags that are unique across *all* resources in the namespace will be 
able to preserve them. However, those that use weaker RFC2616 semantics 
(unique per entity body and URL) will have to ensure that namespace 
operations such as COPY or MOVE (or REBIND) will not cause duplicate 
ETags for different entities to appear.

Both types of implementations exist (actually, we have both types within 
the same server).

Now it may make sense to discuss this issue, but it's not related to 
BIND. As I said, REBIND and MOVE share the same considerations here.

> The getlastmodified is a little more contentious.  Does it mean that the 
> underlying resource body changed?  If so, then the spec should say that 
> this property SHOULD NOT (or MUST NOT) change only because of a REBIND 
> operation.

Nope. If anything, the spec should say that REBIND should behave like 
MOVE in this regard.

In particular, I'd lean to SHOULD change, because in general there's no 
other reliable way to maintain RFC2616's semantics for the 
"Last-Modified" header.

Anyway, this issue applies to all WebDAV namespace operations, and we 
have lived with the current under-specification since 1999. Thus having 
it clarified in RFC2518bis should suffice.

Regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Mar 2004 15:11:47 +0100

Geoffrey M Clemm wrote:

> ..

Done. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_precondition_binding_allowed>

>>>>difference to MOVE, and thus locks behave just like they do with 
> 
> MOVE.
> 
>>OK, we may have to add this piece of information, because it's not 
> 
> obvious.
> 
 > ..

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_lock_behaviour>.

Can you suggest a specific text?

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Mar 2004 14:24:55 -0500

How about for REBIND:

(DAV:lock-deleted): If the URL specified in the DAV:href element in the 
request body was protected by a write-lock at the time of the request, 
that write-lock must have been deleted by the request.

And something similar for UNBIND.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 20 Mar 2004 11:14:04 +0100

> And something similar for UNBIND.

OK, here's the change:

UNBIND postcondition:

       (DAV:lock-deleted): If the internal member URI of the binding
       specified by the Request-URI and the DAV:segment element in the
       request body was protected by a write-lock at the time of the
       request, that write-lock must have been deleted by the request.

REBIND postcondition:

       (DAV:lock-deleted): If the URL specified in the DAV:href element
       in the request body was protected by a write-lock at the time of
       the request, that write-lock must have been deleted by the
       request.

(note that for UNBIND the actual URI is composed from request-URI and 
DAV:segment in the request body).

 From Geoff's and my point of view, we have now resolved those issues 
raised by Lisa which indeed warranted a document change. As these 
changes are minor, we *could* proceed with draft 04 as base for the 
working group last call, but of course I can also produce a -05 draft 
early next week and submit that (Opinions?).

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 21 Mar 2004 10:21:39 -0500

Either way is OK with me.  If it would take you more than a few minutes
to generate a new revision, I'd just last call the 04 version.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sun, 21 Mar 2004 16:30:59 +0100

> to generate a new revision, I'd just last call the 04 version.

In fact, it'll only take a few minutes.  I'll await the feedback of our 
working group chairs...

Regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 22 Mar 2004 12:10:04 -0800

This is definitely an improvement.  However, I still  have some issues 
-- the interaction between bindings and locks is still unclear.  The 
spec needs to clearly say that
  - if one binding is locked, then every binding is locked (with the 
same lock token)
  - All bindings to the same resource MUST support the same features 
(e.g. locking)
  - All bindings to the same resource MUST show the same values for live 
properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.

Unless my understanding of the intent is wrong...?  In which case, it 
needs to clarify some other way.

Lisa

On Mar 20, 2004, at 2:14 AM, Julian Reschke wrote:

>
> Geoffrey M Clemm wrote:
>
>> How about for REBIND:
>> (DAV:lock-deleted): If the URL specified in the DAV:href element in 
>> the request body was protected by a write-lock at the time of the

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Mar 2004 21:25:57 +0100

Lisa Dusseault wrote:

>  - if one binding is locked, then every binding is locked (with the same 
> lock token)

No, the bindings aren't locked, the *resource* is (RFC2518).

>  - All bindings to the same resource MUST support the same features 

The bindings themselves do not support anything; the resource they are 
mapped to do. As they are mapped to the same resource, the same features 
are available.

> properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.

Same. You're communicating with the resource, not particular bindings.

> needs to clarify some other way.

I'd say all of this follows from section 1, paragraphs 4 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#rfc.section.1.p.4>) 
to 6:

"The BIND method defined here provides a mechanism for allowing clients 
to create alternative access paths to existing WebDAV resources. HTTP 
[RFC2616] and WebDAV [RFC2518]  methods are able to work because there 
are mappings between URIs and resources. A method is addressed to a URI, 
and the server follows the mapping from that URI to a resource, applying 
the method to that resource. Multiple URIs may be mapped to the same 
resource, but until now there has been no way for clients to create 
additional URIs mapped to existing resources.

BIND lets clients associate a new URI with an existing WebDAV resource, 
and this URI can then be used to submit requests to the resource. Since 
URIs of WebDAV resources are hierarchical, and correspond to a hierarchy 
of collections in resource space, the BIND method also has the effect of 
adding the resource to a collection. As new URIs are associated with the 
resource, it appears in additional collections.

A BIND request does not create a new resource, but simply makes 
available a new URI for submitting requests to an existing resource. The 
new URI is indistinguishable from any other URI when submitting a 
request to a resource. Only one round trip is needed to submit a request 
to the intended target. Servers are required to enforce the integrity of 
the relationships between the new URIs and the resources associated with 
them. Consequently, it may be very costly for servers to support BIND 
requests that cross server boundaries."

At this point I really don't know how to improve that description 
(except by adding "we mean it -- it's really just another name mapped to 
the same resource" :-). If you think that this introduction needs to be 
improved, please make a concrete proposal.

Does anybody else feel that this is unclear?

Regards. Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 24 Mar 2004 08:48:39 -0800

I suggest adding the following text to the Bind draft:

"Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY,  
PUT when the destination is unbound) each create only one binding and  
one resource.  Methods that create a new binding (BIND) leave other  
bindings unaffected.

"The following methods MUST have an identical result on every binding  
to a resource, regardless of which binding is addressed:
  - GET, PUT (to an existing binding), OPTIONS, HEAD.
  - PROPPATCH, LOCK, UNLOCK
  - all the methods defined in RFC3253 (except the ones that create a  
new resource)
  - ORDERPATCH
  - ACL

"The following methods have a result that only affects the binding that  
is addressed, and don't affect other bindings to the same resource:  
REBIND, UNBIND.  MOVE, COPY and DELETE have special behavior described  
in detail in sections 2.3 to 2.5.

"The REPORT and PROPFIND methods could conceivably provide different  
information depending on which binding to a resource is addressed but  
by default they return the same information regardless of binding.  The  
definition of each property or report ought to make clear if this  
property or report diverges from the default.  All reports defined in  
RFC3253 and the ACL RFC return the same result for any binding to the  
same resource.  All (live) properties defined in RFC2518, RFC3253,  
RFC3648 and the ACL RFC MUST have the same value appearing on all  
bindings to the same resource. All dead properties MUST appear the same  
on all bindings to the same resource. An implementation MAY define  
custom live properties which have different values on different  
bindings to the same resource."

---

This text is intended to supplement the model description by making  
requirements on implementations to encourage them to behave  
consistently, and to clear up confusion in applying the model in  
specific cases.

Lisa

On Mar 22, 2004, at 12:25 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> This is definitely an improvement.  However, I still  have some  
>> issues -- the interaction between bindings and locks is still  
>> unclear.  The spec needs to clearly say that
> mapped to do. As they are mapped to the same resource, the same  
> features are available.
>
>>  - All bindings to the same resource MUST show the same values for  
>> live properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.
>
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -04.html#rfc.section.1.p.4>) to 6:
>
> "The BIND method defined here provides a mechanism for allowing  
> clients to create alternative access paths to existing WebDAV  
> resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to  
> work because there are mappings between URIs and resources. A method  
> is addressed to a URI, and the server follows the mapping from that  
> URI to a resource, applying the method to that resource. Multiple URIs  
> may be mapped to the same resource, but until now there has been no  
> way for clients to create additional URIs mapped to existing  
> resources.
>
> BIND lets clients associate a new URI with an existing WebDAV  
> resource, and this URI can then be used to submit requests to the  
> resource. Since URIs of WebDAV resources are hierarchical, and  
> correspond to a hierarchy of collections in resource space, the BIND  
> method also has the effect of adding the resource to a collection. As  
> new URIs are associated with the resource, it appears in additional  
> collections.
>
> available a new URI for submitting requests to an existing resource.  
> The new URI is indistinguishable from any other URI when submitting a  
> request to a resource. Only one round trip is needed to submit a  
> request to the intended target. Servers are required to enforce the  
> integrity of the relationships between the new URIs and the resources  
> associated with them. Consequently, it may be very costly for servers  
> to support BIND requests that cross server boundaries."
>
> (except by adding "we mean it -- it's really just another name mapped  
> to the same resource" :-). If you think that this introduction needs  
> to be improved, please make a concrete proposal.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Mar 2004 09:32:33 -0800

At 8:48 AM -0800 03/24/2004, Lisa Dusseault wrote:
>PUT when the destination is unbound) each create only one binding 
>and one resource.  Methods that create a new binding (BIND) leave 
>other bindings unaffected.
>
>"The following methods MUST have an identical result on every 
>binding to a resource, regardless of which binding is addressed:

It strikes me that just listing them out from RFC 3253 would be useful here,
even if redundant, as it would eliminate any confusion on exactly which ones
are meant.

>  - ORDERPATCH
>  - ACL
>
>"The following methods have a result that only affects the binding 
>that is addressed, and don't affect other bindings to the same 
>resource: REBIND, UNBIND.

For the custom live properties, could PROPPATCH have an effect that 
affects only
the binding address (as noted below, implementations MAY define custom live
properties which have different values on different bindings)?

>MOVE, COPY and DELETE have special behavior described in detail in 
>sections 2.3 to 2.5.
>
>information depending on which binding to a resource is addressed 
>but by default they return the same information regardless of 
>binding.  The definition of each property or report ought to make 
>clear if this property or report diverges from the default.

I'm trying to work through the implications of this, and having a bit 
of trouble.
Does this imply that a method generating this must be applied both to the
binding against which it was targeted and against some other binding to test
this?  or does it imply some mechanism of indicating that a property is
capable fo divergence?  In the second case, how is that discovered/stored?

>  All reports defined in RFC3253 and the ACL RFC return the same 
>result for any binding to the same resource.  All (live) properties 
>defined in RFC2518, RFC3253, RFC3648 and the ACL RFC MUST have the 
>same value appearing on all bindings to the same resource. All dead 
>properties MUST appear the same on all bindings to the same 
>resource. An implementation MAY define custom live properties which 
>have different values on different bindings to the same resource."
>
>---
>
>>>  - if one binding is locked, then every binding is locked (with 
>>>the same lock token)
>>
>>>  - All bindings to the same resource MUST support the same 
>>>features (e.g. locking)
>>
>>The bindings themselves do not support anything; the resource they 
>>are mapped to do. As they are mapped to the same resource, the same 
>>features are available.
>>
>>>Unless my understanding of the intent is wrong...?  In which case, 
>>>it needs to clarify some other way.
>>
>>work because there are mappings between URIs and resources. A 
>>method is addressed to a URI, and the server follows the mapping 
>>from that URI to a resource, applying the method to that resource. 
>>Multiple URIs may be mapped to the same resource, but until now 
>>there has been no way for clients to create additional URIs mapped 
>>to existing resources.
>>
>>correspond to a hierarchy of collections in resource space, the 
>>BIND method also has the effect of adding the resource to a 
>>collection. As new URIs are associated with the resource, it 
>>appears in additional collections.
>>
>>available a new URI for submitting requests to an existing 
>>resource. The new URI is indistinguishable from any other URI when 
>>submitting a request to a resource. Only one round trip is needed 
>>to submit a request to the intended target. Servers are required to 
>>enforce the integrity of the relationships between the new URIs and 
>>the resources associated with them. Consequently, it may be very 
>>costly for servers to support BIND requests that cross server 
>>boundaries."
>>
>>(except by adding "we mean it -- it's really just another name 
>>mapped to the same resource" :-). If you think that this 
>>introduction needs to be improved, please make a concrete proposal.
>>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Mar 2004 18:55:59 +0100

> properties which have different values on different bindings)?

Nope, and I absolutely disagree that live properties may vary depending 
on access path.

> I'm trying to work through the implications of this, and having a bit of 
> trouble.

There must not be any divergence.

Regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Mar 2004 20:49:59 +0100

Lisa Dusseault wrote:
>> Nope, and I absolutely disagree that live properties may vary 
>> depending on access path.
> 
> 
> I believe servers have already been implemented and deployed where the 
> live property can vary depending on access path.  For example, in order 
> to continue to maintain backward compatibility for a custom property 
> called "parent-path", the server would have to implement bindings in 
> such a way that "parent-path" was calculated from the request address.

...or it could make the decision not to maintain support for something 
that doesn't fit into the BIND model.

What's the use case for that property?

> I should have been more clear in my original text.  What I meant was 
> that when a new live property is specified (e.g. in an Internet-Draft / 
> RFC), the specification should indicate if the live property may have 
> different values on different bindings.  Otherwise, the assumption is 

No, it must not have different values based on the access path.

> that the live property must have the same value on all bindings.

Precisely.

> Similarly, when a new report is specified, readers may assume that it 
> behaves the same on all bindings, unless the specification says otherwise.

Yes, they should assume it behaves the same on all bindings. The REPORT 
method is defined to return information for the resource referenced by 
the request URI. The request URI really is just the access path and has 
no influence on the result.

> I never envisioned a need or utility in having clients apply methods to 
> multiple bindings to test this.  I did envision a mechanism to indicate 
> that a property may diverge on different bindings, but I propose this 
> should be in the specification where the property is defined.  So there 
> are no issues for discovery/storage.

Again, I think the concept of properties that vary on access path is 
incompatible with what we are doing here. In the model we're working in, 
  state only exists in WebDAV resources (where bindings belong to the 
state of the containing collection).

So if you have a property that is supposed to vary, it *per definition* 
can't belong to the resource itself, thus it'll be part of the parent 
collection's state (an example would be a "hidden" flag that's attached 
to each of the bindings contained in the collection).

I agree that in many cases the strong model used in BIND doesn't work 
well in all practical use cases (there's a reason why Unix symbolic 
links seem to be more popular then hard links). That's why the Advanced 
Collection activity of this working group has resulted in *several* 
specs. For instance, REDIRECTREF resources 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>) 
*are* separate resources that can have their own metadata attached to 
it.  There was yet another planned thingy called "direct reference" (as 
far as I understand similar to redirectrefs minus the redirection step) 
that seems to more closely map to what you feel bindings should be 
doing. Maybe you want to pursue that project?

Regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 24 Mar 2004 10:39:20 -0800

behaves the same on all bindings, unless the specification says 
otherwise.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Mar 2004 18:52:54 +0100

> I suggest adding the following text to the Bind draft:

Lisa, I appreciate the effort to provide additional wording. However, in 
each of the cases I think it's either unnecessary (because the behaviour 
follows from the very nature of bindings), or actually incorrect.

> one resource.  Methods that create a new binding (BIND) leave other  

*Usually* that's true. However, servers can do what they want. There's 
nothing preventing a server to create *two* resources and bindings upon 
each PUT (for instance, that may be the case for a server that has 
"source" and "transformed" content in different namespaces).

> bindings unaffected.

 From 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_BIND>:

"The BIND method modifies the collection identified by the Request-URI, 
by adding a new binding from the segment specified in the BIND body to 
the resource identified in the BIND body."

This is the purpose of the BIND method, and I really don't want to get 
into the business of enumerating what a method *doesn't* do.

>  - all the methods defined in RFC3253 (except the ones that create a  

Which of course provokes the question if there are any methods that do 
*not* have that property. Which of RFC3253's methods do you think have 
that property? And why do you feel that for instance BIND and REBIND 
don't have that property?

The only difference I'm aware of is that sometimes some bindings are 
protected by a lock, while other's aren't. In those cases only namespace 
operations that will affect these URIs behave differently.

> in detail in sections 2.3 to 2.5.

That doesn't offer any additional information, right? It's just a 
forward pointer to information that follows later.

> by default they return the same information regardless of binding.  The

Let's see...

<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_PROPFIND>:

"The PROPFIND method retrieves properties defined on the resource 
identified by the Request-URI...."

<http://greenbytes.de/tech/webdav/rfc3253.html#METHOD_REPORT>:

"A REPORT request is an extensible mechanism for obtaining information 
about a resource."

So no, they should provide identical information.  We're getting 
information from resources, and as long as the resource is the same, the 
information is the same. The access path doesn't matter.

> bindings to the same resource."

I strongly disagree -- a live property that varies based on the request 
URI IMHO is a violation of the binding semantics defined in this spec.

Regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 25 Mar 2004 14:46:59 -0800

I found a reference to the "parentname" property, defined for Exchange  
2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there  
though it's unfortunate):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
wss/_cdo_schema_dav.asp

The "hidden" flag you suggest would also be interesting as a binding  
property, as was suggested in this Internet-Draft (also implemented in  
Microsoft servers):

http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-collection- 
props-00.txt

As you say, it could also be implemented on the parent collection as a  
list of hidden bindings within the collection, but the cat's out of the  
bag there for at least some implementations.  I don't see the harm in  
allowing some custom live properties to vary on bindings. Any  
implementation that didn't have the ability to calculate a live  
property based on a binding wouldn't have to do so.

Lisa

On Mar 24, 2004, at 11:49 AM, Julian Reschke wrote:

>> I believe servers have already been implemented and deployed where  
>> the live property can vary depending on access path.  For example, in  
>> order to continue to maintain backward compatibility for a custom  
>> property called "parent-path", the server would have to implement  
>> bindings in such a way that "parent-path" was calculated from the  
>> request address.
>
>>>> I'm trying to work through the implications of this, and having a  
>>>> bit of trouble.
>> that when a new live property is specified (e.g. in an Internet-Draft  
>> / RFC), the specification should indicate if the live property may  
>> have different values on different bindings.  Otherwise, the  
>> assumption is
>
> Yes, they should assume it behaves the same on all bindings. The  
> REPORT method is defined to return information for the resource  
> referenced by the request URI. The request URI really is just the  
> access path and has no influence on the result.
>
>> I never envisioned a need or utility in having clients apply methods  
>> to multiple bindings to test this.  I did envision a mechanism to  
>> indicate that a property may diverge on different bindings, but I  
>> propose this should be in the specification where the property is  
>> defined.  So there are no issues for discovery/storage.
>
> incompatible with what we are doing here. In the model we're working  
> in,  state only exists in WebDAV resources (where bindings belong to  
> the state of the containing collection).
>
> So if you have a property that is supposed to vary, it *per  
> definition* can't belong to the resource itself, thus it'll be part of  
> the parent collection's state (an example would be a "hidden" flag  
> that's attached to each of the bindings contained in the collection).
>
> links seem to be more popular then hard links). That's why the  
> Advanced Collection activity of this working group has resulted in  
> *several* specs. For instance, REDIRECTREF resources  
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref- 
> protocol-latest.html>) *are* separate resources that can have their  
> own metadata attached to it.  There was yet another planned thingy  
> called "direct reference" (as far as I understand similar to  
> redirectrefs minus the redirection step) that seems to more closely  
> map to what you feel bindings should be doing. Maybe you want to  
> pursue that project?
>
> Regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Mar 2004 00:04:36 +0100

> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 

I fail to see the issue. It only means that when Microsoft decides to 
support the BIND draft, they'll have to re-think that design decision. 
Just because somebody in the past did a poor system design that is 
inherently incompatible with having multiple URIs for the same resource 
shouldn't prevent *us* from doing things right.

> property based on a binding wouldn't have to do so.

The harm is that it's incompatible with the stated purpose of the spec 
-- specifying additional URIs to the *same* resource. Of course we can't 
prevent anybody from doing that, but it's against the stated purpose of 
the spec, and thus the spec shouldn't do anything which would encourage 
this kind of design.

BTW: the "hidden" flag in NTFS in fact is kept as part of the file 
resource, not of the binding. Thus, IIS in fact does the right thing in 
presenting this as property on the resource (well, they shouldn't have 
uses the DAV: namespace...).

To test that: create a file, create a second binding to that file 
(cygwin ln), show properties in Explorer for first binding, set 
"hidden", refresh window multiple times. See?

Regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 25 Mar 2004 16:44:01 -0800

> resource, not of the binding. Thus, IIS in fact does the right thing 
> in presenting this as property on the resource (well, they shouldn't 
> have uses the DAV: namespace...).
>
That's an interesting test, but that doesn't tell us what Exchange 2000 
does with the "ishidden" flag, which is not stored as the "hidden" flag 
in NTFS.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Mar 2004 09:17:48 +0100

> does with the "ishidden" flag, which is not stored as the "hidden" flag 

Well, either it works as with IIS (in which case it works consistently 
across Microsoft products), or it doesn't. *Does* Exchange support hard 
links / bindings? If it doesn't, how is the question relevant?

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 26 Mar 2004 06:56:50 -0500

I agree with Julian's response.  Systems that only allow one parent
for a resource are free to define/implement properties that only make
sense if there is exactly one parent.  If they decide to support 
multiple parents, then they will have to redefine that property.
One trivial way to do so is to just say that this property describes
one of the paths to the resource, e.g. in the case of "parentname",
you would say "this property describes the binding name of this resource
in one of its parents".

Cheers,
Geoff