Re: Comments on bind-08

Geoffrey M Clemm wrote:

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

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

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

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.

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

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


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

Received on Tuesday, 30 November 2004 13:10:35 UTC