[Bug 227] Collection state definition in conflict between BIND and RFC2518bis

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227





------- Additional Comments From julian.reschke@greenbytes.de  2006-01-31 12:15 -------
OK, I have looked at the latest BIND draft, RFC2518 and the latest draft for
RFC2518bis.

The good news is that they use identical terminology, such as "internal member
URI" and "URI mapping", so there's no underlying conflict.

I find the reasoning in the BIND spec completely reasonable: saying that the set
of internal member URIs is part of the state of a collection indicates that the
state varies depending on which URL you use to access it, or alternatively that
collections may not have multiple http URLs after all. It seems to me that both
interpretations are unacceptable.

Now is this really a problem? Or can we get away with the current text in BIND
indicating that RFC2518bis uses a broken definition, while we even haven't
submitted RFC2518bis yet? My feeling is what we should fix it.

As far as I can tell, there seem to be at least two different approaches for
that, affecting Section 5.2 of BIS (and nothing more), see
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.5.2>.

1) Instead of saying "A collection is a resource whose state consists of at
least a list of internal member URLs..." (*) we'd replace that with something
like "...consists at least of the set of relations between the last path
segments of its internal member URLs and the resources they map to...", avoiding
the introduction of new terminology.

2) We adopt BIND terminology, copying the definition of a binding over here.

Although we've succeeded to get around without the term "binding" in RFC2518bis
so far, option 2) seems to be a bit more appealing to me.

I'd also like to note that getting the definition of the collection's state
right will make it simpler to talk about the impacts of depth-0 locking a
collection later.

Opinions?


(*) We've got a grammar error here, right?



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Tuesday, 31 January 2006 20:15:34 UTC