WebDAV Advanced Collections Conference Call - 2/16/99 Attending: Judy Slein, Jim Davis, Geoff Clemm, Jim W, Tyson ACTION ITEMS Judy: Spec changes Judy: Update issues list Judy: Submit revised spec to Internet-Drafts on Friday 2/19 Judy: Send mail to the list soliciting comments on the spec - say it's nearing completion Judy: Solicit a few reviewers to do thorough review of the spec Judy, Geoff, Jim D: Work on language for references in the middle of URLs (by e-mail) LOGISTICS No more design team meetings till after IETF www.apps.ietf.org has what information is available on Application Area agenda for IETF Jim has requested a BOF for versioning. If he gets it, the 2 hour WebDAV slot can be devoted to general WebDAV, collections, and access control. Otherwise, a mini-BOF for versioning will be part of the WebDAV meeting. Count on at least 30 minutes for collections. Maybe an hour. LOCK Nothing came up in the versioning workshop to affect us. COPY Judy: Could we consider (for both COPY and LOCK) having the semantics for an individual references stay consistent with the general rules for direct and redirect references (apply to the target for direct references, get a 302 response for redirect). Just make exceptions for operations on collections. This would give intuitive results that work for down-level clients for individual references. Jim W and Geoff: No, we need to keep the semantics the same between operations on individual references and operations on collections that contain references. It gets too complicated for people to understand otherwise. It would also force us to have an additional header. (It would be useful to record in the rationale that there is this option. It would be a backup position in case we get push-back on our decision.) Judy would like to put the summary table from her e-mail on COPY of 2/10 in an appendix to the spec. It may be useful for people to see in one place the semantic patterns and exceptions. Jim W: Note that whenever you duplicate information in this way, there is an opportunity for inconsistency in the spec. For now, Judy will try to keep design rationale in the spec. We can always separate it out later if the spec seems to be getting too long. In any case, we want to have all of our rationale available together in one document. Keep the semantics of PROPFIND as it is, the same for individual references and for collections that contain references: in both cases, redirect references get a 302 response. How do we reconcile our semantics of COPY / MOVE with the WebDAV spec? We say that MOVE is logically equivalent to COPY with No-Passthrough + DELETE. It's ok to say this because the No-Passthrough header is new with referencing. REVIEW OPEN ISSUES Issue 14: How to include reftype, reftarget, and location in Multi-Status responses The options are: Just include those elements directly inside the response element Define a new header element and put them in it Put them in a prop element Jim W prefers putting them in either a header block or a prop block. This would provide a framework for future extensions. It also helps a human trying to parse the response. Geoff prefers not to force people to make an ontological choice here (header vs property). Proposal: Use a prop block. Judy: a header block makes more sense given that we are trying to simulate the response to an operation on an individual reference within a Multi-Status response. Agreed: We'll follow a general policy of modeling both headers and properties as prop elements except in the case of transient headers, which will be treated as headers. So all of reftype, reftarget, and location will occur inside a prop element when returned in a Multi-Status response. New Issue: Can reftarget be a relative URL? Can reftarget be a relative url? If so, relative to what? (relative to base URL of the collection that contains the reference, but there is no canonical URL that is the one. relative to the URL that was used to get at the collection resource.) Why do we need reftarget to be relative? It saves the server from having to fix up the value of reftarget in case it points inside the same subtree where the reference is located, and you move the subtree. Alternatively, we use absolute url's and have the server fix them up. The server might not always be able to do the fixup. It might not always be easy to tell whether an absolute URL points to something that is being moved, for example in a chain of references that might go off server and then come back. Then let the server just make a best effort to fix them up. There may be interoperability problems with using relative URLs? How common is it for a reference to point within the same tree? Quite common, even for a reference to point within the same collection. We have the scenario where an article is included twice within the same set of course readings, once early in the course and once later on. If reftarget is relative, the client has the burden of figuring out the value of the absolute URL. Geoff believes that people will insist on having relative references. Disagreement about whether real servers will be willing to fix up reftarget if we require its value to be absolute. Jim W still has reservations about allowing reftarget to be relative. Agreed: DAV:reftarget property MAY be relative Ref-Target header MAY be relative Location header MUST be absolute (The HTTP spec gives us this.) Open Issue: How to determine the base for a relative URL in reftarget. We need to check the URL spec and make sure we get this right. HIERARCHY Is left-to-right parsing equivalent to right-to-left? Geoff thinks not. The examples he cites are tar files and gzips, where he believes left-to-right parsing will not work. We need a way of writing this up that is *not* in terms of parsing a URL. Judy, Geoff, and Jim D will try to sort this out via e-mail. John Stracke just sent mail about non-collection resources in the middle of URLs. Look at it off-line. It cites the example of a cgi script that lets you put slash-separated segments after the script name.