RE: Comments on bind-08

> 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."

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.
> 
> The last sentence of the first paragraph already mentions the 
> 506 status.

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.
> 
> That's in section 3.1 (definition of DAV:resource-id 
> property), isn't it?

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,"
> 
> 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.

Maybe the language needs to be SHOULD?


> > * 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.
> 
> But then it wouldn't be atomic, right?

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

> > * Section 5. I think we need a condition for a cross-server 
> UNBIND failure.
> 
> 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 (==
> GUIDs) -- "urn:uuid" seems to be dead.

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

- Jim

Received on Tuesday, 30 November 2004 01:30:56 UTC