RE: WG Last Call: Bindings Protocol

Thanks for your comments on the bindings spec.

> -----Original Message-----
> From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> Sent: Tuesday, December 28, 1999 1:28 AM
> To: Jim Whitehead; WebDAV WG
> Cc: Geoffrey M. Clemm
> Subject: Re: WG Last Call: Bindings Protocol
> 
> 
> This looks pretty good, as it addresses the circular 
> reference issue.  I'd
> still like to see an optional weak binding that is guaranteed 
> not to dangle
> but that also does not affect the reference count, as I think 
> that is needed
> when the implementor chooses not to allow circular BINDings affecting
> references.

When we first started talking about developing an advanced collections spec
two years ago, there was a lot of discussion about different flavors of
references/links/bindings that different servers might want to support.  The
upshot was so much confusion that we resolved not to touch issues of
weak/strong and their variants.

We have had to retreat from that resolve, in order to make sure clients will
understand exactly what they are getting when they create a binding or a
reference.  But we don't want to define semantics for all the possible
variants.  Instead we've chosen one flavor of binding and one flavor of
reference to specify, which we believe will be widely useful and which
complement each other.

It's quite possible that other flavors of bindings and references will be
specified in the future, and of course you are welcome to write a draft
specifying the sort of weak binding you are looking for.

> 
> A couple of other comments:
> 
> * on the security issue of revealing the set of bindings with the
> dav:bindings property:  I recommend some comment to the 
> effect that BINDings
> from unreadable collections should not be readable.  So, the list of
> bindings in this property would only show READABLE bindings 
> (and thus would
> be different depending on who was examining the property)

We do say in Section 11:

"A PROPFIND requesting DAV:bindings MUST return only those bindings that the
client is authorized to see."

So your suggestion is that in addition we say that if the client is not
authorized to read the collection C in which a binding C:(S->R) appears, the
client is also not authorized to see that value of the DAV:bindings property
on the resource R.  Then we could get rid of the security concern described
in 16.4.  Is that right?

> * some comment to the effect that if the URL is a versioned 
> resource, and
> the currently selected revision is changed, the resourceid 
> will not change.
> (I'm assuming that is what you want.)  So even though two 
> people might see
> different data from a GET request from the same URL (because 
> they would get
> a different revision selected), they would still have the 
> same resourceid.
> Therefore, people should NOT use resourceid to invalidate 
> caches or any
> other application that assumes a one to one correspondence between
> resourceid and data.

I think that your conclusions are all exactly correct, but I agree with
Jason that it would be better to discuss ramifications for versioning in the
DeltaV spec.

Thanks again for your comments.

--Judy

Received on Wednesday, 5 January 2000 10:05:27 UTC