W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: Comments on bind-08

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 30 Nov 2004 20:23:49 +0100
Message-ID: <41ACC8C5.6040001@gmx.de>
To: ejw@cs.ucsc.edu
CC: "'WebDAV (WebDAV WG)'" <w3c-dist-auth@w3.org>

Jim Whitehead wrote:
>>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.

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

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

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

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

(see above)

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

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

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

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?

> ...

>>>* 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?

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

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.

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

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?

>>>* 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?

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


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 30 November 2004 19:24:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC