Advanced Collections Minutes 4/20/99 Attending: Judy Slein, Tyson Chihaya, Geoff Clemm, Chuck Fay, Jim Whitehead, Jim Davis ACTION ITEMS Geoff: Send email to the webdav mailing list describing his MKRESOURCE proposal. Jim W: Try again to spur discussion of server-maintained orderings. Judy: Revise spec based on today's decisions by COB Thursday. Then turn it over to Jim W for revisions. Jim W: Revise spec after Judy is done. All: Review spec revision 03.2 for next week. COPY FOR COLLECTIONS We don't want to modify the WebDAV spec or conflict with it. It says that a COPY on a collection with Depth: 0 creates an empty collection. Geoff wants some way to copy the bindings as well as the properties, and proposes defining semantics for Depth: 1 to do this. We would like the Depth header to mean the same thing in the context of DELETE, COPY, PROPFIND. In PROPFIND it makes sense for Depth: 0 to get just the properties of the collection, and Depth: 1 to get the properties of the collection and of the resources identified by its immediate members. But Geoff wants COPY Depth: 1 to copy the properties and bindings, but not the resources. He wants the bindings in the new collection still to connect to the original resources. So if you did a PUT to an existing member of the new collection, it would affect the member of the old collection. This is like a BIND operation with a Depth header. Geoff: For versioning, there needs to be some COPY semantics that leaves the URIs at the destination still bound to old resources. Jim W: As defined in WebDAV, COPY with Depth: infinity does create new copies of the resources identified by the collection members. Judy: Using the Depth header to get Geoff's semantics departs too far from the meaning of Depth. It may be useful to have rebind semantics for COPY on collections, but don't do it using Depth 1 semantics. Use a new header. Jim W: We could use a new method or new header. Jim would want a new method unless we use the Mandatory header. Without Mandatory, an HTTP server would ignore a new header that it didn't understand. Jim W: What if we said to the versioning folks, if you need a new kind of COPY, you must propose the new method? Geoff: OK. Decisions: We will not define semantics for COPY with Depth: 1. COPY with Depth 0 is just as it was defined in Webdav: The collection's properties get copied, but not its bindings. We could say either 1. Bindings are not part of a collection's state for purposes of COPY or 2. Bindings are part of the collection's state, but they don't get copied. We prefer 2. Chuck: Confirm that a binding is not part of the state of the target resource? That's what we intend. SEMANTICS OF MOVE Yaron is ok with Geoff's proposal that MOVE be BIND+DELETE. It's what he meant in the first place. So MOVE is fundamentally a rename. Decision: Define MOVE as bind + delete, with an implementer's note that for cross- server cases you can do COPY followed by fixup followed by DELETE. Judy: They're not really equivalent unless you think that fixup of property values is included in the fixup step. RFC 2518 didn't talk about creationdate, etc., on a MOVE. We might cause debate if we raise this issue. But clients would appreciate the clarification. Any volunteers to draft something describing the affected properties and how they need to be fixed up? No. Chuck: Clarify how MOVE means bind + delete. You create a new binding to the resource, then delete the old binding. Delete is defined to be remove the binding in the request-URI. MOVE is a modification to 2 collections, not a change to the resource being moved. Think about what you have to have checked out to do this in a configuration management system -- it's the collections, not the resource that's being moved. SEMANTICS OF DELETE If we define DELETE to mean remove one binding, we need some way to delete the resource. We need either a destroy method or a header on DELETE specifying which semantics to use. Geoff: We need unbind and destroy. One of them must be mapped to delete. For versioning, we have to map unbind to delete or else there would be serious consequences: versioning servers would have to fail all DELETE requests and define new unbind and destroy methods. This is undesirable. Bindings are different from direct references, but they have the same DELETE semantics we had agreed to for direct references. PUT to an existing binding affects its target resource, so again this is the behavior we had agreed to for direct references. Bindings force our choices on some cases that were difficult to decide for direct references. If a DELETE causes the last binding to be removed, the server can garbage collect if it wants to. Chuck: Won't this be unexpected behavior for down-level clients? HTTP is unclear about what happens on a DELETE. (They were careful not to commit either way.) Look at Unix hard links for an example of choosing to remove the link rather than destroy the file. There needs to be some way to destroy the resource. Should we use a header or a new method? If we define a header, the server may not understand it. At least it's not too damaging if the server does the wrong thing. But if the server only does an unbind when the client wanted a destroy, the resource is still visible in other locations. This is a security hole. The file may have been a sensitive file that it was really important to destroy. DELETE is advice to server. HTTP 1.1 doesn't require the server to destroy the resource. A DESTROY method would avoid the problem about the server ignoring a destroy header. What if there are other flavors of destroy/delete needed in the future, say by versioning? Will we want yet another method? We can give clear semantics for DELETE and DESTROY. Can we find a better name than destroy? "liberate"? Take the name question offline. Can we just use Depth: infinity on a DELETE? Then people will wonder what does Depth 5 mean. We need a binary switch. It's also bad separation of concerns, since Depth header is currently for use with collections, to specify how deep in the collection hierarchy to go. Jim W: Just use the name DESTROY. It's intuitive, and has been discussed before. Should we define it in advanced collections or versioning? Better in collections. Since we define DELETE, people will feel that we need an answer to the question, how do you do a *real* delete? Geoff: Semantics of destroy will be remove all bindings, and then servers are free to destroy the resource whenever they choose. Will versioning need yet additional semantics? For example, there are aggregate resources such that when you destroy them, it destroys more than one thing. Defining DESTROY in advanced collections actually might help settle some discussions in versioning. Define how the depth header works with DESTROY. DESTROY Depth: infinity should work. Chuck: Are bindings different from internal members? No. Every URI for a resource is a binding. PUT creates a resource and a binding. DELETE is no longer ambiguous. It removes the binding. Before there was usually only one binding to a resource. Chuck: People would have expected resource to go away. If any server today implemented DELETE to destroy the resource, it would not be in compliance. Jim W: Can we define DELETE to be you must do unbind and may also destroy? Geoff: No, the client can't know what will happen then. Jim W: This is like the PUT issue on the mailing list now. The concern is that users depend on the old definition, or one interpretation of it. Now you make that illegal and cause interoperability problems. Chuck: HTTP 1.1 appears to require that the server delete the resource. Jim W talked to Roy about what the intention of HTTP 1.1 was. The assumption was that URI and resource were synonymous, so there was no difference between a binding and a resource. Really they meant to delete the binding, but didn't have the language to express this. Jim W: Believes that people more often think delete should mean unbind. HTTP 1.1 doesn't say that you have to destroy bits. The client needs to know what will happen before it makes the call. DESTROY: Definition should say that it removes all bindings, and stay weasly on destroying bits -- the server should intend to free the space. Chuck is ok with this decision. SERVER-MAINTAINED ORDERINGS Last week we said we would stick with just client-maintained and see whether the list wants server-maintained. There was no further discussion on the list this past week. Jim W will try again to engage the list in a discussion. Geoff: is neutral on this issue, but would like to keep the spec simple. Judy: Server-maintained orderings are in the spec now. It didn't seem like a big deal. We already had a property that says which ordering is on a given collection. We just needed to add something to OPTIONS for servers to advertise what orderings they can offer. Review the current spec to see whether it does what the people on the list were asking for. MKRESOURCE Geoff didn't send his proposal to the mailing list, so that action item is still open. It will stay MKREF in the spec for now. Jim W supports MKRESOURCE. Judy: There are several separable parts to the proposal -- whether we want a generic creation method, whether it should have a PROPPATCH-like body, and whether the resource type for the new resource is part of the body or in a header. Geoff: And whether it should overwrite an existing resource. Goeff: The XML body is a critical part of the proposal. He's not interested in seeing a MKRESOURCE method without it.