WebDAV Advanced Collections Conference Call - 2/2/99 Attending: Judy Slein, Geoff Clemm, Jim Davis, Jim Whitehead, Chuck Fay ACTION ITEMS Judy: Spec changes All: Send comments to Judy via e-mail this week on the treatment of redirect references in sections 4.5 - 4.7 and 4.9. Judy: Quick and dirty rationale for the decision on locking. Geoff: Polished rationale for the decision on locking (won't be available till after Friday). Jim: Check with others about the importance of the performance issue for resolving /W/X/Y/Z.html. Jim: Write up the concern about the ontology behind /W/X/Y/Z.html. Judy: Add ontology of hierarchies of references to the issues list. Judy: Get instructions for joining the call in the future. NEXT WEEK: COPY, security considerations, ontology LOGISTICS Internet Drafts deadline for the next IETF meeting will probably be about March 5, so we should plan to submit a draft at least by Feb 26 2/19 - 3/6 Jim Whitehead will be out of the country and not easily accessible LOCKING 3.6 Geoff is OK with this much: By default, a LOCK on a direct reference gets passed through to its target. (This includes the case of a LOCK on a collection, Depth = infinity, where the collection contains direct references.) A No-Passthrough header for a LOCK on a collection where Depth=infinity causes the LOCK not to be passed through. How do you interpret a URL /W/X/Y/Z.html, where every level of the URL identifies a reference? (See ONTOLOGY below.) Assume for this discussion that we can make sense of such a URL. Do we want to have /W/X/Y/, /W/X/, and /W/ locked automatically when someone locks /W/X/Y/Z.html? If not, it will be possible for someone to delete /W/, then create a new /W/ that points to a different target resource while /W/X/Y/X.html is locked. This is undesirable. But it's worse to do the automatic lock of all the levels of the hierarchy. That would be inconsistent with the lock behavior defined in WebDAV. So we're willing to live with the fact that someone could change /W/ while /W/X/Y/Z.html is locked. Manage this sort of problem out of band. Once we've decided this much, for consistency's sake, don't lock the lowest-level reference either. So the behavior will be, lock the target, not the direct reference. Jim W: We've taken two positions on lock semantics already, and now we are proposing to change our position again. Why is this so hard? The question we are agonizing over is, What should be the *default* behavior of locking for direct references? We are looking for efficiency and non-surprising behavior. Geoff proposes: If No-Passthrough is *not* used, LOCK operates only on target. Use No-Passthrough if you want to lock the reference. Do 2 operations if you want both the reference and its target to be locked. Jim W: Geoff's proposal yields surprising results if /X/ and /Y/ are normal collections, and /X/Y/Z.html is a direct reference, and you do a Depth=infinity LOCK on /Y/. You expect Z.html to be locked, but it won't be. Jim D: The client won't be surprised. To the client, it looks as if the target of Z.html is the collection member, and the target will be locked. Jim W: But another principal could delete Z.html in the locked collection. This would surprise the lock holder. Geoff: Some surprise is inherent in references. We can't avoid surprising down-level clients. The best we can do is default to something close to the intuitive case. Geoff: It's only operations on the namespace that produce surprising results. Let's make it our policy not to let there be any surprises related to GET or PROPFIND or other in general any operations that don't change the namespace. Jim D: Only a referencing client can use the No-Passthrough header. A referencing client who is a good citizen will check whether the target resource is locked before modifying a direct reference. So it is possible to avoid the kind of surprises Jim W is worried about by being good citizens. Jim W: It's a rule in WebDAV that if you LOCK a collection with Depth=infinity, you can't modify the state of the collection. Geoff's proposal violates that rule. We should stick with last week's decision that LOCK affects references, not their targets. Jim W: Ignoring the case of locking collections that contain direct references, the semantics of lock on a direct reference is that the target gets locked. Make the case of locking a collection with Depth = infinity consistent with this. This is to reverse our decision from last week. Judy: The reason we have such difficulty making a decision is that no matter what we do, there are undesirable / unintutitive / surprising results. We have to make a decision about what behavior is the least objectionable. Agreed: A LOCK on a direct reference by default locks the target, not the reference. The same is true when a LOCK is applied to a collection with Depth=infinity and the collection contains direct references. Judy will take a quick cut at writing a rationale for this decision. Geoff will produce something more polished when he gets back from Sweden. ONTOLOGY Jim W: The LOCK model depends on what we think the objects are that populate the namespace. The problem case described in the mail this week used the URL /W/X/Y/Z.html, where each of /W/, /W/X/, /W/X/Y/, and /W/X/Y/Z.html identifies a reference. Is it even possible to make sense of this case? There are several possible interpretations. /W/ is a reference with the target /A/. /W/X/ is a referential member of /A/. /W/X/ has as its target collection /A/B/. /W/X/Y/ is a member of collection /A/B/, and has as its target collection /A/B/C/. /W/X/Y/Z.html is a referential member of /A/B/C/, and has as its target the ordinary resource /A/B/C/D.html. If /W/ points to /A/, then X is a member of /A/, not of /W/. But this is not consistent with the namespace requirements of WebDAV. WebDAV says that for any URL /W/X, X must be a member of the collection /W/. Alternatively, we can say the /W/X/Y/Z.html is free-floating in the namespace. We can say that references, introduced after WebDAV, behave differently with respect to namespace consistency. Geoff needs to be able to make sense of /W/X/Y/Z.html for versioning, for creating a workspace in versioning. Jim D: We need to fix the WebDAV namespace consistency requirements if they prevent us from doing this. Jim W: The performance of GET processing needs to be efficient. To resolve a URL, it is not acceptable to have to traverse the URL tree to find out where the references are. High performance servers would not implement this. Geoff: Caching can solve this, and is a common implementation in file systems Jim D: If performance is a concern, don't use references. You have to make a trade-off between the flexibility you get from references and speed. Down-level WebDAV clients won't be able to tell that /W/ is not a collection. It will look to them as if we still obey the namespace consistency constraints. /W/ is sort-of a reference, and sort-of a collection. What is really the ontology here? Would it help if we had the notion of a "real name" (a GUID)? Many servers do. Jim W: We need to have an answer to the question: What collection has as part of its state /W/X? Collection A? The WebDAV spec says it's /W/. We could say that /W/X does not have to be part of the state of any collection (relax the rules of webDAV). Jim W doesn't like this. According to WebDAV, if you are a DAV resource and your parent is, too, then your parent must contain your url as part of its state. In our example, there is no parent collection. (Or /A/ is the parent collection. Or /W/ is sort-of the parent collection.) Jim will write up the alternative interpretations and his concerns. Judy will add this to the issues list. BACKPOINTERS Backpointers are currently in the spec, but the discussion on the mailing list has reached a deadlock. One person strongly objects to backpointers. Yaron also opposes optional features in general. Xerox participants strongly favor backpointers, others have voiced support -- Geoff, Bruce. Other DMS vendors have not expressed opinions. Chuck: DMA does have backpointers. They are useful for navigating up a hierarchy. He would like to see them in the spec. Jim W is concerned mainly to be sure that this issue is settled, and that it will not be raised again. (Review of the arguments from the mailing list.) Agreed: Leave backpointers in. PROPERTIES IN GENERAL Consider standardizing other optional properties -- make sure the work on Dublin Core in WebDAV continues. Jim W favors property registry. OPTIONS Three new compliance classes are defined in this spec: DAV:basicref, DAV:directref, and DAV:orderedcoll. What sorts of resources would respond with these values to an OPTIONS request? DAV:orderedcoll -- Only a collection responds this way, and it claims only that its own immediate children may be ordered. It says nothing about collections under it in the hierarchy. Servers to reply to options on null resources with 200 (OK) and an options list. For DAV:orderedcoll, this would mean that you could create a collection at that URI that is ordered. (The spec will not talk about what should be included in the Public header and what should be included in the Allow header. Interestingly, most servers do not implement Public. Microsoft does. In theory, Public lists all methods supported by the server, and Allow lists only those methods that you could perform on that particular resource now given its current state. In general, you expect the list in Public to be the same throughout a server's namespace. So rather than check every resource, you might check just one and assume that whatever is in the Public list will work anywhere -- you will be wrong occasionally, but right for the most part.) DAV:basicref DAV:directref -- Any URL can return these, because you could create a reference at any URL (you might have to delete the resource currently at the URL first). In general, if the tokens in the value of a header are not in a DAV: property, don't use the "DAV:" prefix on the token. REDIRECT Issue 2: Redirect will be closed next week if no one sends comments in the mail before then. VERSIONING Does there need to be syntax in the Ref-Target header and the DAV:reftarget property to allow for a revision id, in addition to a URL? Jim W: Don't change anything yet -- wait till after next week's versioning workshop.