Bindings and Redirect Ref. teleconf. Mar. 1, 2000

Advanced Collections Teleconference
March 1, 2000

Present: Chuck Fay, Geoff Clemm, Judy Slein, Jim Whitehead, Jason Crawford
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, and Redirect References
protocol  produced as a result of this conference call will also
be subject to review by the mailing list. ***

Bindings protocol issues:

Geoff Clemm read some language for delete on bindings.  Discussed
introducing an UNBIND method.  Some concern over the "mixed mode" case,
where say collections are not bindable, but non-collection resources are.
Geoff will send some proposed language out on this.

Issue 7 (Yaron5.3Huh?): Agreed that Geoff's new language, in
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0392.html, will
be proposed as a substitute for the current language.  Major change is to
bulletize existing text, spelling out the existing text more clearly.  No
change to issue 8, since we feel this will be clear after the change to 5.3.

Discussion on feedback from Roy on the nature of resources.  Then discussed
the dav:resourceid, whch seems to be his last major concern.  Discussed
having a check for equivalence method, and having an identifier for the set
of URLs mapped to a particular resource.  Also discussed having a URN
instead of the dav:resourceid.  Discussed whether the property should be
required.  Agreed to have a URN instead of a dav:resourceid, this will be
accessible in a property, which is a SHOULD implement, not a MUST (due to
filesystem implementation such as WebRFM), as well as a separate method that
returns a boolean, yes/no, for two URLs mapping/not mapping to the same
resource.

Discussion on whether the bindings property should be called the mappings
property. Concern that the "bindings" name on the bound-to resource might
suggest that the individual resource holds the state of the bindings, rather
than the collection.  Thus, some name like "binder", or "bindings-to" might
be more appropriate. Geoff will submit some name ideas for this.

Redirect References protocol:

Issue #1:  Discussion over whether redirect resources should or should not
have bodies.  There don't appear to be compelling reasons for having this
capability.  It does add complexity to the protocol, and to implementations.
So, agreement that a redirect reference MUST NOT have a body.

Agreement to Yaron's proposal that Redirect Resources should be authorable
on non-WebDAV servers, by non-WebDAV clients.

Issue #1A: Issue goes away, since MKRESOURCE will be replaced by MKREF.

Issue #2: Use policy from Binding protocol for listing status codes.

Issue #3: Yes, change caching to MUST NOT cache response from
MKREF/MKRESOURCE.

Issue #4, 5: Not relevant once we switch to MKREF.

Issue #6: Need to add rationale for why we use relative URLs.  Server is
required to store it as a relative URL.  Server MUST NOT change the relative
URL during a MOVE.

Raises the issue of needing separate methods for getting the value of a
reference, and modifying the value of a reference.  Tentatively agreed on
REFGET, REFSET (but noone likes these too much).

Issue #7, 8, 9: Agreed that we will remove cross references between specs.
Also will remove any mention of other specifications, since this is now
intended to be a standalone specification.  Will expand discussion of
redirect references.  Agreed to move notational conventions after the
introduction.

Issue #10: Will use "revealing private locations" instead.

Issue #11: Will continue to follow IETF rules, but will try to produce a
nicely formatted specification as well for review.

Issue #12: Agreed, although these paragraphs will end up being changed due
to the move to make this a standalone specification.

Issue #13: Accepted change.

Issue #14: Agreement that we won't discuss bindings at all in the redirect
references specification.

Issue #15: Agreement that we won't mention Direct Reference Resources in the
specification.  Probably also means that the definition of Reference goes
away as well.

Some discussion of whether to allow authoring of other than 302 redirects.
303, 304, and 305 don't seem to make sense for remote authoring.  303 is
intended for POST output. 304 is for conditional GET requests.  305 says to
use a proxy to access a resource (though perhaps this would be useful to
author).  300 would involve sending the multiple choices when the resource
was created, and would complicate MKREF.

Next week's teleconference: Tuesday at 11-1 Pacific.

*** End of teleconference ***

Received on Wednesday, 1 March 2000 16:08:21 UTC