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