Adv. Col. Teleconference 22 Mar 2000

Advanced Collections Teleconference
March 22, 2000

Present: Jason Crawford, Judy Slein, Jim Whitehead (notetaker), Geoff Clemm

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

Began by discussing Geoff's proposed language for resolving issue
Yaron.MrIntegrity, at
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0444.html
Tentatively liked this new langauge, but it was sent out just prior to the
teleconference. We need to see if there will be any discussion of this topic
on the mailing list.

Next started considering issues #43-45 of the bindings spec.

Issue #43: Revisited name for the bindings property. Judy suggested the name
"parents", and this was adopted.

Issue #44: Discussed resolutions to the loop detected issue identified by
Tim Ellison on the mailing list. Two approaches were examined.  Approach #1:
Pass back URNs for all the resources in the multistatus, and then the client
would be able to piece together which URLs were associated with which URNs,
and thus pick out where the loop occurred.  Approach #2: Just only pass back
the URL of the resource being pointed to, and only pass this back for the
resource for which the 506 Loop Detected is reported.  This will identify
the URL of the looped-back-to resource, and this can be reported by the
client to the user.

Also discussed whether there should be a "duplicate detected" status code,
and whether that is the same as "loop detected".  Also, discussed whether
loop detected should be a 2xx status code, since the existence of a loop is
not an error.  The duplicate detected status code would allow propfind
requests to be smaller in the case where there were multiple bindings to the
same resource in the propfind output.  But, receiving this response back
might break downlevel clients that are not expecting this response. But, the
necessary loop detected code might also break downlevel clients. Agreed to
change loop detected to a 2xx. Tentatively agreed to have a duplicate
detected status code, it will be a 2xx, and the properties for the resource
that issues the duplicate detected status code will be in the propfind, and
will also return the href of the resource being pointed to (tentatively
called "dup-href") as a psuedo-property, but no further children will be
included in the listing (have the same URL stem).

Issue #45: Not listing all the children every time does address the denial
of service. But, in the general case, the only reliable DAV prevention of
denial of service guarantee is to limit the number of threads that can be
used for DAV requests.

Redirect References:

Issue #60: (revisited this) Agreed to return both the location (in a
pseudo-property), and the redirectref value (as a real property) for 302
responses in a multistatus.

Issue #73: Agreed to accept Juergen's suggested ascii art for Section 10.

Issue #74: Agreed that we will use the same term consistently for
plain/ordinary HTTP/1.1 redirects.

Issue #75: Agreed to delete the sentence.

Issue #76: Disagree. DAV:location cannot be a live property, since it needs
to be the absolute location, and this is why we need a separate target
property.

Issue #77: Agreed to this change.

Issue #78: Agreed to this change. Agree that this is not new to this
protocol, but this is explicitly noted in the document.

Issue #79: Agreed, there is nothing you can do about someone making a
redirect reference to another resource, since they are weak links.  We will
delete the sentence noted in this comment.

Issue #80: Will modify the i18n section to account for this draft being
standalone now.

Issue #81: We will make this change.

Issue #82:  Will modify the IANA section to account for this draft being
standalone now. We will also be listing new methods, headers, properties,
etc.

Issue #83: Agreed, we will remove references to the bindings specification.

Issue #84: Will change the name of the section to be "Changes to the ..."
instead of "Extensions to the..."

Issue #85: Looked at RFC 2616 3xx status codes. Looks like we may also want
to allow authoring of 303 and 307, in addition to 301 and 302.

*** End of teleconference ***

Received on Wednesday, 22 March 2000 15:57:54 UTC