RE: Comments on bind-08

Geoff Clemm wrote:

	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? 

There are two possible confusions.

1) An implementer could implement the BINDDUP semantics (i.e., duplicate
bindings, but not resources), rather than the desired semantics of
duplicating resources and bindings. I agree that someone who reads and
understands the current specification and RFC 2518 should not come to this
misunderstanding. However, since the bind specification doesn't explicitly
address Depth infinity copies, there is no explicit information that would
clearly and definitively cause someone to stop thinking that BINDDUP
semantics are the intent.

2) It's not clear how to handle bindings that cause containment loops, since
in this case you do just want to only duplicate the binding, and not the
bound resource. This is enough different from the mainline COPY semantics
(duplicate binding and bound resource) that it's worth explicitly mentioning
it. For example, a reasonable interpretation of the current specification,
when copying loopback bindings, is to create a new binding to a new
collection, where the new collection's bindings point to the resources bound
by the collection originally pointed to by the loopback binding. This
preserves the "copy binding and duplicate destination resource" semantics
described for COPY.
	
Note that people, in general, do not go out of their way to seek
disconfirming evidence of positions they hold (see Reason's book on human
error), and hence the burden really is on the spec. writer to provide text
that clearly refutes alternate interpretations. 


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

Glad we're in agreement. It should be trivial to add a sentence to this
effect in the bind specification.
	

	> > * 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 just wanted to clarify the use of the If header to pass lock tokens for
already locked resources, since there have been client implementation issues
concerning If implementation in this past. I agree that we should, for now,
avoid discussion of the interactions of LOCK and bindings.

- Jim

Received on Wednesday, 1 December 2004 18:47:07 UTC