WebDAV Advanced Collections Conference Call - 1/14/99 Attending: Judy Slein, Chuck Fay, Jim Whitehead ACTION ITEMS Judy: Get external reviewers once the next ID is available. All: Think about locking references. E-mail discussion before next meeting. Jim W: Add to the WebDAV issues list the need for a location element to be used with 302's inside multistatus responses. Judy: Spec changes. Add location element to multistatus response syntax in the Advanced Collections spec. Change spec to let MKCOL be redirected rather than having it fail. Change spec to allow replacing a reference with an ordinary resource using PUT. Change spec to say that No-Passthrough defaults to false. Add to definition of No-Passthrough that it can be used with PROPFIND on a collection with Depth=infinity, and describe semantics. Change the definition of referential resource to say that it has no body, but does have properties. Change the values of Ref-Integrity to DAV:none and something that means "don't care". If Jim Davis agrees, get rid of the DAV:refintegrity property. Change the definition of "weak reference" to "server does not enforce referential integrity". Change the definition of "strong reference" to "server enforces referential integrity". All: Review 3.5, 3.6, and 3.8 in detail after Judy makes updates. Jim W: Set up web site where we'll keep working documents of the design team; annouonce to WebDAV when it's ready. Judy: Confirm that Tuesdays 1:00 - 3:00 eastern / 10:00 - noon pacific works for everyone. GENERAL Jim has had some discussions with Keith Moore about the need to refocus WebDAV, in line with the general IETF policy of doing so about every 18 months. Jim notes that only a small fraction of the mailing list actively participates, which indicates a need to refocus. He is proposing separate working groups for versioning and access control, but keeping advanced collections because it is near completion. He told Keith he thought it would be complete May / June of this year. Goals of this series of conference calls: Have a polished spec in time for the March IETF (approximately 6 weeks from now). Last call after IETF. Finish this spec in the May / June time frame. Regular participants in this conference call will be the design team (authors) of the Advanced Collections specification. We need to get external reviewers as soon as the draft is available for the IETF. They will be able to help with details like status codes. ISSUES LIST REVIEW Reviewed current issues list. Anyone can e-mail additions or bring them to the phone calls. Issue 5: Status codes - In general, the approach is to appeal to the HTTP spec, and only explicitly discuss status codes that go beyond what is there. Be sure that the discussion of 302 is adequate. ISSUE 1: NO-PASSTHROUGH Yaron, at the December 1998 IETF, stated that he believed that no-passthrough was the equivalent of URL munging. Why would he think this? There were similar discussions about source links: We could have decided to use a request header that would cause a method to operate on the source rather than on the output. But there might need to be different access control on the output than on the source, so there really are 2 resources, and there need to be 2 URLs. Would we want separate access control for the reference as itself than for the reference as mediator? No. Are there any HTTP headers that are like No-Passthrough? The Accept headers are analogous. No-Passthrough is like URL-munging because it could be expressed as ;nopassthrough. Why is url-munging considered to be bad? There are 2 reasons. When it is used to append an operation to a URL (;op=checkout), it is unclear what order to perform operations if request method is anything other than GET. In addition, there is the possibility of collisions in the url-munging space (not a problem here because it's part of a spec). No-passthrough has consistent semantics no matter what method it gets applied to, and there's no problem like the order-of-operations problem. Two URLs would mean that 2 entries in the namespace would be used up for every reference. Conclusion: Keep No-Passthrough. We can revisit this if there are insuperable difficulties with operations on collections (especially LOCK). Ed. note: see also list discussion at: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0051.html SEMANTICS OF LOCK ON REFERENCES Another issue: Does LOCK get redirected? Does the reference itself always get locked? What if lock depth is infinity? The server might have to lock objects in many trees? What if the references cross web servers (probably 502)? Add LOCK to the list of operations that never get passed through? For lock, return 302, but if depth infinity, no-passthrough is true by default What does the user expect - what is it to lock a reference? Just the target gets locked, or both the reference and its target? It may be that both the reference and the target should get locked. This is the only way to insure that, for example, no one changes DAV:reftarget while the user is editing the target resource. Consider separately the case where we are locking an individual reference and the case where we are locking a collection with Depth=infinity. When locking a collection with Depth=infinity, for redirect references, lock the reference and return 302. But LOCK is atomic, and how will UNLOCK work? We need a location element in the multistatus response of WebDAV for 302's What about lock tokens? If the response has a 302 for each redirect reference, there will need to be separate tokens for each 302. What if the reference is to something lower in the tree? The whole LOCK will fail because the target is already locked (for direct references only)? If Depth=infinity, the intent will be to lock both the reference and its target. This will have to be done in 2 stages for redirects. The client might not bother to lock the targets of a redirect till the user clicks on it. If the client locks redirect reference, would the response be a 302 with a lock body because reference itself got locked? Ick. Maybe we should not worry about down-level clients. Behavior gets too bizarre if we try to take them into account. So if a LOCK is sent to a redirect reference, the reference does not get locked if No-Passthrough is false. Chuck proposes that we think about referencing-aware clients and develop a proposal that would work for them, then test it for down-level clients. Conclusion: We will think about this more and have an e-mail discussion on locking before the next meeting. ISSUE 2: 302 RESPONSES PROPFIND should be like GET, so each redirect reference should get a 302 response with a location element. But this doesn't help down-level clients, who will not understand a location element. Judy will added the location element to the Advanced Collections spec. Jim will add it to the WebDAV issues list to get it into the WebDAV spec when it is next revised. Creation methods. The spec currently says that MKCOL fails for a redirect reference, as it would for any other non-null resource. Jim thinks it would make more sense to let MKCOL get redirected, then fail it if there is a target. Judy will change this in the spec. It also makes behavior for dangling references make more sense. Can you PUT on top of a reference? Yes - PUT with No-Passthrough=true replaces the reference. Judy will fix this in the spec. No-Passthrough defaults to false. Judy will make this explicit in the spec. No-Passthrough can be used with PROPFIND on a collection with Depth=infinity. Judy will state this in the spec and describe the semantics. After Judy makes these changes, everyone will review 3.5, 3.6, and 3.8 in detail. TERMINOLOGY Terminology: The definition of "Referential resource" says that it has no content. This might be taken to imply that it has no properties. Change it to say that it has no body, but does have properties. Change the definition of "weak reference" to "server does not enforce referential integrity". Change the definnition of "strong reference" to "server enforces referential integrity". ISSUE 3: WEAK REFERENCES Roy presented reasonable scenarios to back up his request that there be a way to ask a server not to enforce referential integrity for a specific reference. But do servers really give clients this option? Would the various DMSs give clients this choice? DMA found that some repositories require every object to be contained in some collection. They couldn't devise a creation sequence that would maintain referential integrity through the whole sequence, so they allowed a larger atomic operation, and referential integrity could be enforced at end of it but not during it. Conclusion: Keep the option, and try and get some feedback from DMS vendors. The values of the Ref-Integrity header will be DAV:none (do not enforce referential integrity for this reference) and DAV:don't care (well, something that means that). The Ref- Integrity header defaults to don't care. The server could respond with error if it forces referential integrity and the client requests none. The DAV:refintegrity property doesn't seem to be very useful. What scenarios are there for a client wanting to use this to discover anything about referential integrity for the reference? The only values we could provide are "integrity not being enforced" and "integrity being enforced" with no detail about what the policy is. See what Jim Davis thinks about this. LOGISTICS Meet Tuesdays (Judy to confirm with the rest of the design team). Jim W will create a web site for spec, reqts, issues list, minutes and hook it into WebDAV site. When it's ready, we'll announce it to WebDAV. Judy keeps ownership of the documents and issues list.