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 lagnauge, but it was sent out just prior to the teleconference. But, 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 ***