Bindings Protocol Teleconference
February 16, 2000

Present: Judy Slein, Jason Crawford, Jim Whitehead, Chuck Fay, Geoff Clemm
Minutes recorded by Jim Whitehead.

*** Note that decisions made during the teleconference are always
subject to review on the mailing list.  The mailing list is the final
arbiter of consensus on any issue.  Note also, that the revised
Bindings Protocol specification produced as a result of this
conference call will also be subject to review by the mailing
list. ***


Issue #20: [Bindings Property] The situation described in this issue
is somewhat pathological.  To accommodate this, properties would need
to be defined on URLs, not on resources.  However, this would violate
RFC 2518.  If such a situation as described in this issue were to
arise, conceptually the resource would hold the property, and the
non-DAV server would be exercising its right to not respond to a given
HTTP method, in this case, PROPFIND.  No changes needed to the spec.

Issues #21: [Integrity] Two separate issues here, one of integrity,
another for lazy vs. strong evaluation of operations. Provide pushback
to Roy asking to identify areas of the spec. that require non-lazy
evaluation.  Review the spec. for anything that would require this.

Also, there is the issue of Apache-style aliases -- are they the same
as bindings?  Aliases allow URL mappings to be created, but these
mappings do not appear in collections.  Bindings also create URL
mappings, and do show up in collections.  In their most general form,
aliases can be created using regular expressions, making it difficult,
or impossible to list all possible mappings within a collection -- it
would only make sense to list one distinguished member, or the regular
expression itself.  It appears that aliases and bindings are separate
abstractions.  But, bindings should not prevent aliases from being
applied.  In particular, we need to review this spec., and RFC 2518 to
ensure that aliases are not prevented from being defined, and interact
OK with DAV consistent namespaces.

Issue #22: [Delete on a non-empty collection]: Agreed to add a new
status code to be used to report the error condition that a collection
cannot be deleted until it is emptied.

Issue #23 (already closed)

Issue #24 [Don't mention redirect spec in abstract]: Agreed to this
change, will review suggested language.

Issue #25 [Move notational conventions section after introduction]:
Agreed to do this.

Issue #26 [Mentioning and cross-referencing redirect references spec]:
Agreed to remove explicit cross-references to other documents for
redirect references.  Will also ensure bindings spec. does not
explicitly define what a redirect reference is, to ensure redirect
reference spec. is the sole place for this.  Will mention that another
spec will define redirect references, to let people know to look there
for the details, but this spec. will not be explicitly referenced by
name.

Issue #27 [Resources are not storage objects]: Agreed.  Will change
third paragraph of introduction so that it does not mention storage,
and motivates resource sharing simply from a namespace
perspective. Example of having two people sharing a resource on one of
the Web storage sites, and wanting the same resource show up in both
people's home workspaces would motivate this.

Issue #28 [Bindings to any HTTP resource, not just DAV resources]:
Disagree.  We actually do mean bindings work just on WebDAV resources,
due to the problems of having a non-WebDAV resource as a member of a
WebDAV collection.  In particular, Depth operations would be
problematic in this case, and this would violate the namespace
consistency requirement of RFC 2518. The heart of this disagreement
seems to be that bindings really aren't the same as aliases. Need to
be careful when we state that PUT creates an implicit binding, since
this is really, when a PUT creates a binding in a *collection*.

Issue #29 -- are currently discussing this on the list, is related to
different definitions of what a resource is, and what a URL mapping
is.

Issue #30 -- This is really the same issue as Yaron's Mr. Integrity.

Issue #31 [BIND fail if there is an existing resource]: Agreed to keep
Overwrite header in the spec., but change the default to be non-delete
behavior.

Issue #32 [Section 5.2 language] The authors strongly feel the example
should stay in, that people might not understand first paragraph
without the aid of the example in the 2nd and 3rd paragraphs.

Issue #33 [Impression of redefining response codes] We will add
language to make it obvious that we are not redefining the status
codes, and are merely listing the exact conditions that lead to this
status code being issued.  Will double-check to ensure that status
codes are, in fact, not being redefined.

Issue #34 [DELETE and WebDAV] Agreed, will also move this discussion
to the appendix where Internal Member Resources are discussed, and we
will call this appendix something like "Reconciliation with the WebDAV
Spec."

Issue #35 [DAV:resourceid property] Discussed having a method to
compare two URLs and say whether they map to the same resource.
Decided against this, since there are two needs here, (1) comparing
two URLs at the same time, (2) comparing the same URL at two points in
time to verify that it is still the same resource.  The compare method
only handles case #1.  Will take this to the list to discuss further
with Roy.

*** End of teleconference ***