Subject: Comments on bind-08

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 29 Nov 2004 14:03:57 -0800

I gave the latest WebDAV Bindings Protocol specification a careful read
today, and was generally very impressed by the solidity of the
specification. I have a number of comments (below) which mostly seek to
clarify the intent of the specification. I'm fine with these being
considered last-call comments if the WG wants to proceed with a WG last call
on the -08 specification -- IMO, the specification is certainly ready for
such a review.

Also, I'm not sure whether current WG practice is for those submitting
comments to directly enter them into the issue tracking system. If so, let
me know, and I'll enter these in.

OK, the comments:

* Terminology section (1.1): There is a reference to
draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs
elsewhere in the specification as well). References in RFCs need to be to
documents of RFC level stability (or equivalent). If
draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should
just revert back to RFC 2396.

* Section 2, paragraph 3. The language here would preclude the future
definition of a DESTROY method which had the semantics of removing the state
of a resource from a server, irregardless of any containment relationships
that may hold it. Such a method could be quite useful for records management
functionality, in order to implement a records disposition policy that
specified deletion at a certain time. My recommended tweak to the language
of section 2 is minor: add the following sentence to the end of the
paragraph:

"It is permissible, however, for future method definitions (e.g., a DESTROY
method) to have semantics that remove all bindings and/or immediately
reclaim system resources."

* Section 2.1. I think it would be more clear to separate out the discussion
of loops and bindings, and make it a separate section (say, 2.2) This issue
comes up frequently enough that it would be good to make it easy to find
this issue in the TOC. Also, a mention of the Already Reported status code
would be good to have here, since it also mentions 506.

* Section 2.3. This section doesn't clearly address the semantics of COPY
with Depth infinity. My recommendation is to add, after paragraph 3, text
like this:

"As specified in [RFC2518], a COPY with Depth infinity causes the collection
resource to be duplicated, all of its bound children to be duplicated, and
their children's bound children, and so on, to the bottom of the containment
hierarchy. All of the segments of the bindings of the destination collection
are the same as for the destination collection. However, the destination
resource for all bindings in the destination collection are different from
those of the source collection, since all resources have been duplicated,
creating new resources with distinct DAV:resource-id properties."

* There should also be some text addressing COPY depth infinity and loops --
in some instances during a COPY with Depth infinity, the server really wants
to recreate the binding that causes the loop, rather than continuing to make
duplicate resources. This is somewhat addressed by the final paragraph in
Section 2.3, but not exactly.

* One gap in the current COPY semantics is the ability to copy a collection
and its bindings. COPY depth 0 says copy all non-binding state. COPY depth
infinity copies all bindings and makes duplicates of all bound resources.
But, there's no single atomic operation (call it BINDDUP) that duplicates
the collection and its bindings, but doesn't duplicate the bound resources.
That is, there is no operation that does a COPY Depth 0 plus BIND for all
members. So, two questions. Is there a compelling scenario for having a
BINDDUP method? I confess I'm having a hard time coming up with one. Second,
assuming there is a compelling scenario, can it be accomplished just using
COPY, LOCK, and BIND, rather than having a special purpose method. Also
unclear.

* It might make sense to create an example covering the situation described
in the final paragraph of Section 2.3. I'm not 100% sure I know what
scenario this paragraph addresses, other reading the spec. for the first
time would presumably have a tougher time.

* Section 2.4, second paragraph. "MUST NOT" is used in the text of an
example -- seems like it should be lower case here instead.

* Section 2.6 -- there needs to be some discussion on the interactions of
DAV:resource-id and versioning. As near as I can tell, the intent is that
every revision will have a unique DAV:resource-id value.

* Section 2.6 -- I think it would help clarify the text to say that one
possible implementation technique is to use a GUID for the unique
identifier, and then reference the same GUID document as is referenced in
RFC 2518.

* Section 2.6, final paragraph, last two sentences. Change "must not" to
"MUST NOT" (and eliminate the "For example" at the start of the sentence --
perhaps change to "Specifically,"

* Section 2.6. Need to add a note indicating that REBIND does not affect the
value of DAV:resource-id.

* Section 3.2, final sentence -- delete the word "either", add a comma after
"or".

* Section 3.2. I think it would be helpful to have an example of this
property. I'd be happy to help develop such an example.

* Section 4. The intent of the BIND method is for its behavior to be atomic.
However, this is never actually stated explicitly in the specification.
Seems like it should be.

* Section 4. Need a new condition to cover the case where the BIND
half-succeeded, and then needed to be rewound. This condition would address
the case where Overwrite is true, the destination binding has been removed,
but the new binding couldn't be created.

* Section 4.1, final sentence. Remove comma after the URI.

* Section 5. Same comment as for BIND. The intent of UNBIND is that it's
supposed to be atomic, but that's never explicitly stated.

* Section 5. I think we need a condition for a cross-server UNBIND failure.

* Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be
atomic, but this is not explicitly stated.

* Section 6. Should precondition DAV:rebind-into-collection be named
DAV:rebind-from-collection, to mirror the similar precondition for UNBIND?

* Section 6. Precondition DAV:rebind-source-exists is incorrect. The
DAV:href element identifies the destination binding to be created, not the
source. Seems like this precondition, and the previous one, reflect an older
marshalling of the arguments.

* Section 6.2. I think it would be helpful to have an example including
REBIND and locks, showing submission of one or more lock tokens in the If
header.

* Section 7.1.1. Might just be a personal preference, but I'd rather see
plain GUIDs rather than opaqulocktoken URI GUIDs in the example.

That's it.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Nov 2004 23:58:51 +0100

> on the -08 specification -- IMO, the specification is certainly ready for

Thanks.

> me know, and I'll enter these in.

I don't have any preference. At the end of the day, discussion needs to 
take place on the mailing list anyway.

> just revert back to RFC 2396.

It has been approved in September and is on in the RFC Editor's 
publication queue. If it get's published before we are done we'll update 
the draft ourselves, otherwise it'll be part of the publication process 
anyway.

> reclaim system resources."

I'm fine with stating that it's possible to define a method that 
*explicitly* has that semantics (affecting other bindings). How about...:

"It is permissible, however, for future method definitions (e.g., a 
DESTROY method) to have semantics that explicitly remove all bindings 
and/or immediately reclaim system resources."

> would be good to have here, since it also mentions 506.

The last sentence of the first paragraph already mentions the 506 status.

Would adding a new subsection ("Bind Loops") and moving the first 
paragraph of 2.1 into that subsection be what you have in mind?

> creating new resources with distinct DAV:resource-id properties."

As far as I understand, the depth:infinity semantics for COPY follow 
from what's being said about depth:0 and the RFC2518 infinity semantics 
(just checking...). Thus, I'm not convinced that we need to say this, 
but it probably wouldn't hurt either. Feedback appreciated.

> Section 2.3, but not exactly.

I thought it was. Could you be more specific. Maybe expand that 
statement so that it becomes clear that this applies to loop situations 
as well?

> COPY, LOCK, and BIND, rather than having a special purpose method. Also

I do agree we don't have that. I have no idea whether anybody needs it. 
If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND 
and UNLOCK.

> time would presumably have a tougher time.

Agreed. I'll give it a try.

> example -- seems like it should be lower case here instead.

Agreed.

> every revision will have a unique DAV:resource-id value.

That's correct. I'm not sure why we would need to state this -- a 
version resource clearly is not the same resource as it's VCR, so it 
seems clear they'll never have the same DAV:resource-id.

> identifier, and then reference the same GUID document as is referenced in

That's in section 3.1 (definition of DAV:resource-id property), isn't it?

> perhaps change to "Specifically,"

I agree for PUT/COPY, but things get unclear when we talk about MOVE (as 
RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, 
on the other hand, has that property. Feedback appreciated.

> value of DAV:resource-id.

See :-)

> * Section 3.2, final sentence -- delete the word "either", add a comma after

OK.

> property. I'd be happy to help develop such an example.

Agreed.

> However, this is never actually stated explicitly in the specification.

Yes. Probably the same for UNBIND (REBIND already mentions it). Text 
suggestion welcome.

> but the new binding couldn't be created.

But then it wouldn't be atomic, right?

> * Section 4.1, final sentence. Remove comma after the URI.

OK.

> supposed to be atomic, but that's never explicitly stated.

200.

> * Section 5. I think we need a condition for a cross-server UNBIND failure.

Could you please describe that situation in more detail?

> atomic, but this is not explicitly stated.

Last sentence of first paragraph, but I do agree it could be improved. 
As you said, same as for BIND and UNBIND.

> DAV:rebind-from-collection, to mirror the similar precondition for UNBIND?

Agreed. Not sure why it was inconsistent.

> marshalling of the arguments.

Agreed. I think we should keep the precondition, but it needs to say:

"The Request-URI plus the DAV:segment in the request body element MUST 
identify a non-null resource."

> REBIND and locks, showing submission of one or more lock tokens in the If

Such as one involving locked source and destination collections? That 
may be useful. What do others think?

> plain GUIDs rather than opaqulocktoken URI GUIDs in the example.

A plain GUID isn't a legal URI. And unfortunately, there's still (!) no 
registered URI scheme except "opaquelocktoken" that's based on UUIDs (== 
GUIDs) -- "urn:uuid" seems to be dead.

> That's it.

Thank you very much for the review. I'll do the editorial changes right 
away and add the other points to the issues list on a case-by-case once 
we agree that we should change the current text.

Best regards, Julian

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

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 29 Nov 2004 17:30:11 -0800

> "It is permissible, however, for future method definitions 
> (e.g., a DESTROY method) to have semantics that explicitly 
> remove all bindings and/or immediately reclaim system resources."

Fine with me.

> 
> > * Section 2.1. I think it would be more clear to separate out the 
> > discussion of loops and bindings, and make it a separate 
> section (say, 
> > 2.2) This issue comes up frequently enough that it would be good to 
> > make it easy to find this issue in the TOC. Also, a mention of the 
> > Already Reported status code would be good to have here, 
> since it also mentions 506.
> 

Right -- it should mention 208 Already Reported as well.

> Would adding a new subsection ("Bind Loops") and moving the 
> first paragraph of 2.1 into that subsection be what you have in mind?

Yes.

> > * There should also be some text addressing COPY depth infinity and 
> > loops -- in some instances during a COPY with Depth infinity, the 
> > server really wants to recreate the binding that causes the loop, 
> > rather than continuing to make duplicate resources. This is 
> somewhat 
> > addressed by the final paragraph in Section 2.3, but not exactly.
> 
> I thought it was. Could you be more specific. Maybe expand 
> that statement so that it becomes clear that this applies to 
> loop situations as well?

Maybe that would do it. I think the current language may actually address
loops, but since loops aren't explicitly discussed, it's not
straightforward.

> > * Section 2.6 -- there needs to be some discussion on the 
> interactions 
> > of DAV:resource-id and versioning. As near as I can tell, 
> the intent 
> > is that every revision will have a unique DAV:resource-id value.
> 
> That's correct. I'm not sure why we would need to state this 
> -- a version resource clearly is not the same resource as 
> it's VCR, so it seems clear they'll never have the same 
> DAV:resource-id.

I think it's worth explicitly mentioning this.

> > * Section 2.6 -- I think it would help clarify the text to say that 
> > one possible implementation technique is to use a GUID for 
> the unique 
> > identifier, and then reference the same GUID document as is 
> referenced 
> > in RFC 2518.
> 

Ah, yes, I see it there now.

> > * Section 2.6, final paragraph, last two sentences. Change 
> "must not" 
> > to "MUST NOT" (and eliminate the "For example" at the start of the 
> > sentence -- perhaps change to "Specifically,"
> 
> RFC2518 allows this to be implemented in terms of 
> COPY/DELETE). REBIND, on the other hand, has that property. 
> Feedback appreciated.

Maybe the language needs to be SHOULD?

> > half-succeeded, and then needed to be rewound. This condition would 
> > address the case where Overwrite is true, the destination 
> binding has 
> > been removed, but the new binding couldn't be created.
> 

Well, what status element would you return in the case where the method
half-succeeded, and then needed to re rewound?

> Could you please describe that situation in more detail?

Well, what I had in mind was this; Resource R has two bindings C1(B1->R) and
C2(B2->R). C1 and C2 are on different servers. The servers were both up and
communicating when binding C2 was created. The server with C2 is temporarily
down when the UNBIND comes in to server with C1. However, in this case, the
server with C1 can still do the UNBIND without any problems, though it
wouldn't be able to communicate about the UNBIND to the other server. Is
this a problem the client wants to know about? Unsure.

> > * Section 6.2. I think it would be helpful to have an example 
> > including REBIND and locks, showing submission of one or more lock 
> > tokens in the If header.
> 
> Such as one involving locked source and destination 
> collections? That may be useful. What do others think?

Yes, that's what I had in mind.

> 
> > * Section 7.1.1. Might just be a personal preference, but 
> I'd rather 
> > see plain GUIDs rather than opaqulocktoken URI GUIDs in the example.
> 
> A plain GUID isn't a legal URI. And unfortunately, there's 
> still (!) no registered URI scheme except "opaquelocktoken" 
> that's based on UUIDs (==

Ah, hadn't caught that the value had to be an HREF. What are the benefits of
the HREF formatting?

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 29 Nov 2004 22:57:46 -0500

> but it probably wouldn't hurt either. Feedback appreciated.

Jim: I'm OK with adding the paragraph, but what was the possible 
misunderstanding
that this additional text was intended to clear up?  How else could a 
Depth=infinity
COPY work?

> and UNLOCK.

I do not thing we need to special case this particular scenario, so I 
would vote
not to add anything to handle it.

> seems clear they'll never have the same DAV:resource-id.

I agree with Julian.  A version is a new resource created by the CHECKIN 
method.
According to section 2.6, a new resource must be assigned a new 
resource-id,
so each new version needs to be assigned a new, distinct resource-id.

> on the other hand, has that property. Feedback appreciated.

I'd vote to take Jim's suggested changes here.  A UUID that is not 
preserved
by the MOVE implementation for a repository should not be a candidate for 
a
DAV:resource-id implementation.

> > * Section 6.2. I think it would be helpful to have an example 
including
> may be useful. What do others think?

I continue to believe that the right place for locking examples is in a
locking spec, and that the binding spec just needs to make clear which 
resources
and which URL mappings are being modified by an operation, since this is 
all
you need to know which locks are required.  I believe this information is
well-defined in the pre-conditions of the methods introduced by the 
binding
spec.  So I'd vote not to add such an example, but I could live with it,
if a majority is for it.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 14:10:02 +0100

> that this additional text was intended to clear up?  How else could a 

Yes, I'd like to understand that as well before adding additional text.

> ...
> by the MOVE implementation for a repository should not be a candidate for a

I disagree here. We spent a lot of time discussing whether we can change 
the semantics for MOVE, and in the end we agreed to leave MOVE alone and 
to add REBIND. Section 2.5 specifies that a server MAY implement MOVE as 
REBIND (atomic), but that it doesn't have to. We should leave it at that.

> well-defined in the pre-conditions of the methods introduced by the binding

I agree (preferring not to add an example). On the other hand, adding 
just an example is way better than adding new normative text (which 
really belonsg into the base spec or a specific locking spec).

If we want to add an example, it would be good to if we could agree 
exactly what the example should show.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 30 Nov 2004 09:58:55 -0500

> REBIND (atomic), but that it doesn't have to. We should leave it at 
that.

I wasn't suggesting that we change the semantics for MOVE (and I agree 
that
we cannot do so).  What we can do is define the semantics for 
DAV:resource-id,
since that is a new property that is being introduced by this spec.  So
what I was suggesting was that we state that a server cannot implement
DAV:resource-id in a way that it is modified during a MOVE operation. This
just means that a server cannot use some existing custom property to 
implement
DAV:resource-id if that custom property is not preserved during a MOVE.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 17:47:46 +0100

Geoffrey M Clemm wrote:

> I wasn't suggesting that we change the semantics for MOVE (and I agree that

Understood. However, that makes it impossible to implement a server that 
indeed does support DAV:resource-id and REBIND while keeping MOVE's old 
semantics (and, as a matter of fact, this is what we want to do).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 30 Nov 2004 09:32:58 -0800

Weighing in...

> that this additional text was intended to clear up?  How else could a

I agree with Jim that we should add clearer wording here.  The 
ingenuity of
implementors is great, and that includes a surprising ability to come to
different conclusions than the writers of a specification.

>>> interactions of
> I agree with Julian.  A version is a new resource created by the 
> CHECKIN method.

Great -- so we agree on what should happen.  As Jim suggests,
let's put it in the spec.

> and which URL mappings are being modified by an operation, since this 
> is all

An example with locks and REBIND would be great.  Other examples with 
locks
and bound resources (and requirements about what URL must be 
used/supported
in the requests) would also be great.

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 30 Nov 2004 12:54:26 -0500

OK, since I don't feel strongly about this, I'm happy to defer to
Julian's preference.

Cheers,
Geoff

that

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 19:17:15 +0100

Lisa Dusseault wrote:
> I agree with Jim that we should add clearer wording here.  The ingenuity of

I'd still like to know how it is clearer...

> let's put it in the spec.

Again, before we put additional spec into the spec, it should be clear 
what problem it solves. I understand that you lean to "more is better", 
but please acknowledge that many people writing specs disagree.

> An example with locks and REBIND would be great.  Other examples with locks
> and bound resources (and requirements about what URL must be used/supported

I'm not sure how locking examples for REBIND are going to help much. 
REBIND is just like MOVE, except for slightly different marshalling. I'm 
not against adding an example per se, but if we do it it should really 
contain something that's not available elsewhere.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 30 Nov 2004 13:35:04 -0500

I agree with Julian.  A new section of text or example can do more
harm than good (a classic being the "MOVE is logically a COPY/DELETE"
section from 2518).

So I think it is a reasonable criteria to require that any proposed
addition be motivated by at least one example of a misunderstanding
that may arise with the current text.

Cheers,
Geoff

ingenuity of
including

locks
used/supported

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 30 Nov 2004 11:15:58 -0800

I would say that the absence of text more often causes problems than 
additional text.  We shouldn't let one example scare us.  In fact one 
could argue that we needed *more* text to explain what MOVE was about 
so that people understood what the authors had in mind.

lisa

On Nov 30, 2004, at 10:35 AM, Geoffrey M Clemm wrote:

>>>> I continue to believe that the right place for locking examples is 
>>>> in
> a

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 20:23:49 +0100

>>remove all bindings and/or immediately reclaim system resources."

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2_allow_destroy>

> Right -- it should mention 208 Already Reported as well.

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

>>first paragraph of 2.1 into that subsection be what you have in mind?

(see above)

> loops, but since loops aren't explicitly discussed, it's not

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_vs_loops> 
(to be discussed)

> I think it's worth explicitly mentioning this.

I'm still not convinced. Can you explain how a reader of both RFC3253 
and BIND would come to the conclusion that a version can be the "same" 
resource as the VCR?

> half-succeeded, and then needed to re rewound?

That depends on why the new binding couldn't be created....?

>>>* Section 5. I think we need a condition for a cross-server 
>>
>>UNBIND failure.
>>

I'm not seeing a problem (yet). C1 would be removed, while C2 wouldn't. 
It's the server's job to ensure that resource R isn't negatively affected.

> Yes, that's what I had in mind.

Could you be more specific about which case you think would need to be 
clarified? Is this about the specific marshalling of REBIND, or about 
locking semantics in face of multiple bindings?

> Ah, hadn't caught that the value had to be an HREF. What are the benefits of

It's way "everybody" does it (WebDAV lock tokens, WebDAV ordering, Atom 
IDs, XML namespaces). Also, UUIDs may not always be the best identifier 
available. For instance, for lock tokens a server may be using a single 
UUID + a counter (as allowed in the opaquelockoken syntax) -- why 
shouldn't it do the same for resource IDs?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 20:38:36 +0100

> OK, since I don't feel strongly about this, I'm happy to defer to

OK,

partial fix that takes care of most of Jim's problems -- 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_when_do_ids_change>):

    On the other hand, any method that affects an existing resource must
    not change the value of its DAV:resource-id property.  Specifically,
    a PUT or a COPY that updates an existing resource must not change the
    value of its DAV:resource-id property.  A REBIND, since it does not
    create a new resource, but only changes the location of an existing
    resource, must not change the value of the DAV:resource-id property.

I'm not sure whether we need to change more (such as say something about 
MOVE for which it's hard to make any prediction because of RFC2518's 
semantics). Feedback appreciated.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 21:14:35 +0100

OK,

I'm going back to Jim's original issues list to ensure that we are on 
the page re: answers, fixes, issues and open questions (that are not yet 
on the issues list).

> just revert back to RFC 2396.

I think this answered.

> reclaim system resources."

Fixed: 

> would be good to have here, since it also mentions 506.

Fixed:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.1_separate_loop_discussion>

> creating new resources with distinct DAV:resource-id properties."

Issue opened 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_depth_infinity>, 
but unclear whether we really need additional text. Feedback to Geoff's 
and my question appreciated.

> Section 2.3, but not exactly.

Issue opened: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_example>.

> COPY, LOCK, and BIND, rather than having a special purpose method. Also

I think we have consensus that we don't need to consider this case as 
important enough to require special discussion or even a new method.

> time would presumably have a tougher time.

Issue opened (see above): 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_example>. 
Q: would an example involving a COPY of a BIND loop resolve both issues?

> example -- seems like it should be lower case here instead.

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4>.

> every revision will have a unique DAV:resource-id value.

IMHO still unclear. Awaiting feedback explaining why a reader of both 
specs would come to the conclusion that a version is the "same resource" 
as the VCR.

> identifier, and then reference the same GUID document as is referenced in

Answered (it's a URI).

> perhaps change to "Specifically,"

Issue tracked as: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_when_do_ids_change>. 
Do we need additional changes?

> value of DAV:resource-id.

See above.

> * Section 3.2, final sentence -- delete the word "either", add a comma after

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.3.2>

> property. I'd be happy to help develop such an example.

Issue opened: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.3.2_example>.

> However, this is never actually stated explicitly in the specification.

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

> but the new binding couldn't be created.

Still under discussion.

> * Section 4.1, final sentence. Remove comma after the URI.

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.4.1>

> supposed to be atomic, but that's never explicitly stated.

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

> * Section 5. I think we need a condition for a cross-server UNBIND failure.

Still under discussion.

> atomic, but this is not explicitly stated.

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

> DAV:rebind-from-collection, to mirror the similar precondition for UNBIND?

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.6>

> marshalling of the arguments.

Rewritten as:

       (DAV:rebind-source-exists): The Request-URI plus the DAV:segment
       in the request body element MUST identify a resource.

> REBIND and locks, showing submission of one or more lock tokens in the If

Still discussing this...

> plain GUIDs rather than opaqulocktoken URI GUIDs in the example.

Still discussing this.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2004 21:59:06 +0100

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.3.2_example>. 

OK, resolved (for now) by rewriting the sections as:

3.2  DAV:parent-set Property

    The DAV:parent-set property is an OPTIONAL property that enables
    clients to discover what collections contain a binding to this
    resource (i.e.  what collections have that resource as an internal
    member).  It contains an of href/segment pair for each collection
    that has a binding to the resource.  The href identifies the
    collection, and the segment identifies the binding name of that
    resource in that collection.

    A given collection MUST appear only once in the DAV:parent-set for
    any given binding, even if there are multiple URI mappings to that
    collection.

    <!ELEMENT parent-set (parent)*>
    <!ELEMENT parent (href, segment)>
    <!ELEMENT segment (#PCDATA)>
    <!-- PCDATA value: segment, as defined in section 3.3 of
         [draft-fielding-rfc2396bis] -->

3.2.1  Example for DAV:parent-set property

    For example, if collection C1 is mapped to both /CollX and /CollY,
    and C1 contains a binding named "x.gif" to a resource R1, then either
    [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set
    of R1, but not both.  But if C1 also had a binding named "y.gif" to
    R1, then there would be two entries for C1 in the DAV:binding-set of
    R1 (i.e.  both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively,
    both [/CollY, x.gif] and [/CollY, y.gif]).

    +-------------------------+
    | Root Collection         |
    |  bindings:              |
    |  CollX          CollY   |
    +-------------------------+
        |            /
        |           /
        |          /
    +-----------------+
    | Collection C1   |
    | bindings:       |
    | x.gif    y.gif  |
    +-----------------+
         |      |
         |      |
         |      |
     +--------------+
     | Resource  R1 |
     +--------------+

    In this case, one possible value for DAV:parent-set property on
    "/CollX/x.gif" would be:

      <parent-set xmlns="DAV:">
        <parent>
          <href>/CollX</href>
          <segment>x.gif</segment>
        </parent>
        <parent>
          <href>/CollX</href>
          <segment>y.gif</segment>
        </parent>
      </parent-set>

...Feedback appreciated.

Julian