WebDAV Advanced Collections Minutes August 31, 1999 ATTENDING: Judy Slein, Geoff Clemm, Jim Whitehead, Chuck Fay, Jason Crawford ACTION ITEMS All: Check the paragraphs on POST and PUT in Bindings, Section 10. Judy: Take locking decisions to the mailing list. LOGISTICS No meeting next week. We'll try to progress by e-mail. Next meeting (even though Jim Whitehead will be away) September 14. Proposed general WebDAV meeting at IBM / Chapel Hill in October. 1 day WebDAV, 1/2 day DASL, 1 day versioning. ISSUES ISSUE 2: YOU CAN'T PREVENT PEOPLE FROM DELETING COLLECTIONS ALONG THE PATH OF THE REQUEST-URI, BECAUSE WRITE LOCKS WON'T BE THE ONLY KIND OF LOCK IN THE WORLD. IMAGINE A TYPE OF LOCK THAT PREVENTS AN UPDATE BUT NOT A DELETE OR MOVE. AGREED: We'll change the language related to protecting the Request-URI to SHOULD. We intend this to protect the entire path, including the final segment. This does impact the definition of write locks in RFC 2518, which will have to change. It's no longer that a write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent them. Jim: It's not necessary to worry about all the kinds of locks people might invent. Geoff: Would prefer just lock resource, and not to protect the path of the Request-URI. He thought that in the past Yaron wanted to guarantee that the lock owner could still use Request-URI. So that's why we put in this extra constraint. Jason: In some situations you need to "lock" the namespace, especially when crossing servers. Geoff: It's awkward that the namespace "lock" is on a number of individual bindings in different places. And the way each segment of the Request- URI is affected depends on the lock type. As people define different kinds of locks, we have to revisit how protecting the Request-URI interacts with those new kinds of locks. Geoff: What is the overhead of protecting the Request-URL? You have to store the Request-URL with the lock token. Jim: Even if there is some inconvenience to preserving the Request-URI, we should do so to meet the user expectation of being able to use request-URI. Jim: If we had a different id for the resource, this wouldn't be an issue. "the one true name" Geoff: This is too hard to tackle. The semantics would be hard to figure out. For example, suppose one client uses "TodaysDoc" and another uses "July23Doc". Does the true name change over time? It depends on implementation choices, not on a dependable semantic. Jim: Sometimes you want to be able to figure out whether 2 urls point to the same resource. It doesn't matter if the answer changes over time. You only care about now. Why do people want this? For a static resource, want to be able to make links or RDF assertions about them. You want to know that the 2 urls point to the same thing, so that you know that an assertion about url a is an assertion about url b. Judy: We could constrain the stuff about protecting the Request-URI to write locks, and leave behavior for other kinds of locks undefined. Jason: We will probably end up with more kinds of locks, and will need to revisit this when they come along. Geoff: Locks can disappear anyway through administrator action, so it's not so important to protect the namespace. It's highly unlikely that anyone will remove a binding somewhere above the locked resource in the Request-URI anyhow. Jim: Since it's not a common case for a name to disappear, it's better to simplify. Take out the requirement that the Request-URI be protected. Geoff: In versioning, a resource is unwritable unless it is checked out, so it decreases even further the chance of something getting changed on the Request-URI path. Geoff: Doesn't like the definition of write lock in RFC 2518 preventing MOVE and DELETE, since those operations affect the parent collection, not the locked resource. Jim: A binding is a relation, so it really affects both ends of the relation, the parent collection and the locked resource, when you do a MOVE or a DELETE. Geoff: Wants it to affect only the collection. Otherwise, you have to change the state of the target resource and create a new version of it when you do a MOVE. Chuck: No, a write lock needs to prevent MOVE and DELETE. Geoff: Making one URL segment special is bad, from conceptual point of view and implementation. If we say we are not going to protect the Request-URI -- we allow non-lock-holders to MOVE or DELETE bindings higher in the path -- then we need to allow MOVE and DELETE on the final segment of the Request-URI. There's value in being able to protect the path, but complexity is too much. Jim: It's ok to not protect parent paths, but we violate user expectations if we don't protect the name of the resource itself. Implementation complexity for that is not great. Don't let anyone move or delete the locked resource out from under the lock holder. Jason: Agrees that we should be consistent and protect either the whole path or none of it. Jim: We are not defining a pure system, but one used by people with expectations that are not necessarily pure. Chuck: We could say that an optimal implementation would lock whole path, but make it a SHOULD. Geoff: The server could choose complexity vs user expectation. Jim: Really we would want MAY for the path above the locked resource, and SHOULD for the complete Request-URI (identifier of the locked resource itself). Geoff: Let's make it SHOULD all the way up. Jason: What makes it hard to implement protecting the Request-URI? Geoff: In versioning, you control what appears in a workspace by version selection rules that pick out which revision of each collection is to be included. If then you have to protect a name of a locked resource, it becomes hard to evaluate the VSRs. You have to check both lock state and the VSR. ISSUE 1: INCOMPATIBILITY BETWEEN RFC 2518 LOCK/MOVE BEHAVIOR AND MOVE SEMANTICS DEFINED FOR BINDINGS. AGREED: For MOVE, if the source resource is locked (the lock is not inherited from a parent collection), the lock moves with it to the destination. If the destination resource is locked (the lock is not inherited from a parent collection), its lock is lost. For MOVE, if it's the parent collections that are locked, the resource being moved inherits the lock of the destination collection. If a collection is MOVEd, and there are some locked resources in that collection, the locks on those resources get moved. We don't require support for cross-server MOVEs where the source resource is locked, but we will define an optional lock header for use in responses, so that the destination server can change the lock token and return the new token with its response. If the server allows a cross- server MOVE but elects not to return a lock token value, the client can do lock discovery to find it out. If a cross-server MOVE is allowed in a case where there are multiple bindings to the source resource, and the source resource is locked, the result will be that the resource is locked on both servers with the same lock token in both places. (If the same lock token cannot be used, the MOVE must fail. For COPY, any locks at the destination are deleted, and no new locks are created at the destination. After the COPY, there will be no locks at the destination except what is inherited from above. This is a reversal of the position taken in RFC 2518. RFC 2518 Section 7.7 is clear for cases where a resource is moved into a locked collection: the resource inherits the lock on the parent collection at the destination. There is controversy about whether it also is intended to apply to cases where a resource is moved to a location where the individual resource is locked. Jim: Section 7.7 was intended to apply to individual locks: if the destination is locked, the resource would be locked after the move. This is inconsistent with statements elsewhere in RFC 2518 that locks do not survive a DELETE and that MOVE is equivalent to COPY + DELETE with some fixup. The intent was that 7.7 would override these statements for the particular case where a resource is being moved to a locked location. Geoff favors getting rid of Depth locks, so that we would only have to be concerned about singleton locks. Jason: We should at least allow lock to move with the resource, maybe by providing a header. Geoff: Why was the decision made to remove locks on move? Cross-server cases -- the destination server might change the lock token. Servers are allowed to use whatever algorithm they like for generating lock tokens, as long as they are guaranteed unique for all space and time. Geoff: Depth locks across servers are problematic. Think about moving a tree that spans multiple servers. Jim: It's much simpler to have the lock disappear after a move. Does a lock follow along with the move? everyone thinks so except Jim and Yaron. ClearCase does bring lock along. Binding semantics maks it harder to say that the lock disappears. Jason: If we say that we are going to protect the Request-URL and the lock owner performs a move, do we then protect the destination URL? Chuck: On a cross-server move, is the destination server required to recognize the same lock token after the move? RFC 2518 lets servers decide how they want to structure lock tokens, as long as the token is guaranteed unique. So the destination server might not want to use the original token. There are choices about how we might deal with this: have the server refuse to MOVE the resource if it can't use the same token, or let servers change the token and provide a way for clients to discover the new token. What if there are locks on several resources in a tree that is being moved across servers (but the tree itself is not locked)? Move /foo/a/ to a different server, when /foo/a/x.html is locked, /foo/a/w.html is locked. The destination collection would not be locked, but the individual resources would still be locked. If the tokens changes, you would not report the changed tokens in a header. The client would just have to do a PROPFIND to discover the new lock tokens. What if there is a second binding to a resource being moved across servers? After the move, it would be locked at both source and destination (on different servers). Most likely the server would not allow the move in that case. You can probably only move a resource across servers if there is only one binding or if the resource is not locked. Geoff: As long as we support depth locks, we can get around the problems of cross-server MOVEs by having clients lock the parent at the destination, then lock the child after it is moved. If client wants to maintain lock on copy / move but not have null resource at the destination, it can lock parent at destination, lock child after it is moved, then unlock parent. Judy: I don't think you can lock the child while its parent is locked with a depth lock. You can only have one lock on a resource at a time. Until we started discussing cross-server cases, we had consensus that source locks are preserved over a MOVE. Judy: There may be some disagreement on list. When we looked at scenarios, Kevin thought the lock at the destination should always be the one that survives a move. Jim Amsden felt that no lock should be present after a move. Others: That's because the question was not posed in the right way. We should take our proposal to the list for discussion. ISSUE 3: CYCLES AGREED: We will allow cycles to be created. AGREED: We will provide an error code that can be used if a loop is encountered while processing a request, but we won't require servers to fail requests if they encounter loops. There are 2 questions: Should we allow cycles to be created in the first place? If so, should we require failure when a cycle is encountered in Depth: infinity processing? Geoff: We should allow cycles to be created. This is cheaper than requiring servers to check. You pay now or later. If you don't pay at creation time, you pay later when doing Depth: infinity processing. But if you wait till later, you are in a situation where you are doing the traversal anyway, so the incremental cost is small. Geoff: At Oslo, by the end of the discussion people agreed that it is reasonable to allow cycles to be created. Geoff: There are also cases where cycles are required. In versioning, activities may contain versions and may contain other activities. You may want cyclic relationships in some cases. Versioning proposes to use bindings for this. Should we require failure if a cycle is encountered during depth infinity processing? It's not always a problem. It's not a problem for MOVE except maybe in cross-server cases. Jason: We should not require failure, but some loops may be a problem, depending on the operation and on whether the Request-URI is involved in the loop. If you are trying to perform a depth lock and you encounter a loop, the lock would fail. Jim: The operation would eventually terminate, but the behavior would be unexpected behavior. Sometimes the server won't be able to perform the operation because of a cycle, and sometimes the server might decide it's too much trouble to perform the operation because of a cycle. We need to define some error code "can't do because of cycle" and provide a way to identify the path that's the problem. Should we just make the error code available, but not specify when it must be used? We should probably specify what to do in a PROPFIND. Use the error code for the URL that caused the problem, but complete the PROPFIND. Should we distinguish between "can't do" and "detected and moving on"? What family of error code to use? It may not be a client error, but it's not really a server error. There's no category that really fits. Sometimes the loop may be created intentionally, sometimes accidentally, sometimes maliciously. So we'll just use a server error code, recognizing that the category is not an ideal fit. If the error code is at the top level, it was fatal and the server didn't perform the operation. If it's inside a Multi- Status response, it's only terminating that loop and does not indicate failure of the operation as a whole. ISSUE 4: WHETHER TO REPLACE DAV:bindings WITH A METHOD. AGREED: We'll keep the DAV:bindings property. Geoff: This is probably part of Yaron's general aversion to live properties. We should not do anything about this property alone. If we ever do get rid of live properties altogether, that will be the time to get rid of DAV:bindings. ISSUE 5: WHETHER TO REPLACE THE Position HEADER WITH A METHOD. AGREED: We'll keep the Position header. No, setting a member's position really is part of the operation of adding it to the collection. If you separate setting the position from adding the member, someone could sneak in and lock the collection between the time you add the member and the time you attempt to set its position in the ordering. ISSUE 6: WHETHER TO GET RID OF THE "BINDINGS AND OTHER METHODS" SECTION. AGREED: We keep this section. Nothing is ever obvious when it comes to bindings. MISCELLANEOUS Jim: Do mailing list members understand why we think this functionality is important? Geoff: At Oslo, people assumed it is valuable. No one raised the question. Jim: We are running out of time. Keith wants us to finish. We'll have to make the case toKeith that there is wide desire for these specs. Geoff did not think Keith wanted to prevent them from being approved, just wants us to finish up. Jim: On the next draft, each of us should find at least one other person who commits to reviewing it on mailing list. This will be evidence of wider interest than just the authoring team. Jim: Proposes a general WebDAV meeting at the end of October. Jim Amsden would host it in North Carolina. The proposal is for 1 day DAV, 1/2 day DASL, 1 day versioning. Issues that Jim sees needing attention: Need continuing DAV support organization: interoperability, press, demos Plan for move from proposed to draft standard Decide what to do about remaining topics: acl, variants -- new working groups? Jim won't be able to contribute significantly after beginning of the year, so we need transition plans.