WebDAV Advanced Collections Minutes December 1, 1999 ATTENDING: Judy Slein, Chuck Fay, Jason Crawford, Jim Whitehead, Kevin Wiggen DISCLAIMER: All decisions made by the design team are subject to review by the WebDAV mailing list. ACTION ITEMS Judy: Draft alternative text for bindings vs. URI mappings, send to design team Jason: Contact Henry Sanders about Microsoft's difficulties with atomic DELETE. Jason: Send a summary of discussions of atomic DELETE to the WebDAV list to get further discussion there. Judy: Investigate requirements for URNs to be sure a UUID URI can be used as a URN. Judy: Check with Geoff. Is there anyplace in the versioning spec where XML is defined for responses to OPTIONS? Judy: Send mail to WebDAV announcing that we are removing support for server- maintained orderings. LOGISTICS Next meeting Wednesday December 8 THE BINDING SPEC NEW ABSTRACT Agreed: Judy will shorten the abstract to one or 2 paragraphs. Critical information will all be in the first paragraph. Jim: Too long, too detailed. Only the 1st paragraph will appear in announcements. Chuck: If you keep the example -- where you talk about the path segment, use S to identify it, so that in the formal notation that follows, it will be clear what S means. It's hard to parse the sentence with the example. Break it out into bullets to make parsing easier. NEW INTRODUCTION Agreed: The changes are OK. Judy: Tried to make it less about letting resources be shared by multiple collections and instead about creating additional URIS that can be used to access them. Chuck: But it really is about letting multiple collections share a resource. Jim: Likes the changes. It starts out by talking about creating additional URIs, but goes on to talk about resources being shared between collections as an effect of that. Chuck: Agrees. NOTE IN SECTION 4: CAN'T CREATE A NEW URI UNRELATED TO A COLLECTION Action: Judy will send out some alternative wordings to the design team. Jason: This text was difficult to understand. The example was critical to making it comprehensible at all. Jim: It's confusing. We might consider taking this out of the spec and putting it into the rationale document. It might be easier to follow if it were moved back into the terminology section where the distinction between bindings and URI mappings is being made. It's really about yet another way that bindings are different from URI mappings. DIFFICULTIES OF IMPLEMENTING BINDINGS (KEVIN) Agreed: No changes needed based on this discussion. Kevin: His developers think it will be too difficult to implement cross-server bindings to collections. They have an environment where they have millions of users and terabytes of data on multiple servers. Cross-server bindings are important to them, and eventually they will implement them for individual resources, but not for collections. Since the spec does not provide any server-to-server protocol elements, it's not helpful for these cases. For both individual resources and collections, you have to do 2-phase commits. Bindings to collections are just potentially much more dangerous. A DELETE would potentially destroy enormous quantities of data if a coordination mistake between servers happened. Maybe we should consider having 2 compliance classes, one for bindings to individual resources and one for bindings to collections. Jim: You could just always refuse bind requests to collections. The issues concern cross-server cases only, and only when the binding is to a collection. Kevin: Also thinks it would be hard for a file system implement bindings. Jason: On Linux, the file system doesn't allow hard links to collections, only to individual resources, even if you are the superuser. You can have symbolic links to collections, but not hard links. ATOMICITY OF DELETE Judy: Rather not invent a new Atomic header if we can get away with just requiring atomicity. Jason never got a direct response to the question whether NT can do atomic DELETE. Jim: Ask Henry Sanders. He knows the most about the implementation details of IIS. How likely is it that Microsoft will ever implement bindings in any case? Maybe we shouldn't worry too much about whether they like atomic DELETE. But if we want to merge bindings back into RFC 2518, we want to have something they can live with. We need more discussion on the WebDAV mailing list. If there is no consensus in favor of atomic DELETE, we'll add the Atomic header. UUID VS. davresourceid URL SCHEME Yaron wants a generic UUID URL scheme that can be reused. There is none currently registered with IANA. There are 2 expired internet drafts from Microsoft. Jim: UUID stuff from RFC 2518 is ok for our purposes. Just change the name to UUID URI Scheme. Judy: What was the issue about whether they need to be URNs? Jim: Since they are not really locators, someone might want to be able to use them as names. So make sure that they can be used as URNs. Check the URN spec to be sure we don't say anything that would prevent that. Judy will investigate. OPTIONS Agreed: We'll return compliance classes in the DAV header. Judy: RFC 2518 defines the DAV header as the place to return compliance classes. Delta-V has defined a separate header that they will use to return their compliance classes. What should we do? Jim: Just use the DAV header. He'll try to persuade Delta-V to do the same. Jim thinks Delta-V may have defined some XML for use in OPTIONS responses. Judy looked at the versioning spec and couldn't find any. We do define some (which will not be needed if we get rid of server-maintained orderings). MKRESOURCE Judy: We have to coordinate our decisions about MKRESOURCE with DeltaV. Jim: There has been no further discussion of MKRESOURCE in DeltaV since we last met. SERVER-MAINTAINED ORDERINGS Agreed: We will remove support for server-maintained orderings. Judy: The support we currently provide has no cost for a server that doesn't support any server-maintained orderings, and no cost to clients who don't care. The only cost is in added text in the spec. Kevin: It does have the small cost that the server has to respond if someone asks what server-maintained orderings it can provide. Kevin: We should not provide the marginal support for server-maintained orderings that we do now. Doing half the job now will just make it harder for anyone who wants to specify real support for server-maintained orderings in the future. We should do nothing, so that whoever writes the real specification for server-maintained orderings in the future will have a clean slate to work from. Judy: What about the proposal that a server be able to inform clients of its default ordering (if any)? Don't forbid a server to put an arbitrary value in DAV:orderingtype, but don't say anything about this in the spec. MUST DAV:orderingtype BE RETURNED IN PROPFIND RESPONSES? Agreed: DAV:orderingtype should not be returned in PROPFIND responses unless the client asked for it. In addition to the 2 options Kevin described on the mailing list, he has another option to suggest: Really minimize the work for the server by not asking it to order the hrefs in PROPFIND responses. Instead, have a seqno live property that it maintains (based on the client's instructions as already specified). If a client cares about the ordering, it asks to have seqno returned with the PROPFIND, and sorts the collection members itself. Objection: Very simple clients that do no sorting would display collection members in the right order given the current spec, but would lose that if we let servers respond to PROPFIND with an arbitrary ordering. Most clients probably do their own sort unless they know that the server has some ordering that matters. Objection: You don't want to have to wait for the entire result set before starting to display. Kevin would like DASL and PROPFIND to work the same way. (Some implementations are already using DASL to implement PROPFIND.) Add an order-by clause to PROPFIND. Jim: No, that's too complicated for PROPFIND. Jim: We might want results from a DASL query to come back in the order specified for the collection if no order-by is specified. Kevin: Would like to be able to get a subset of a collection's members, but ordered according to the collection ordering. This would happen if DASL and PROPFIND worked the same way. Kevin really wanted it to be that a server doesn't have to return the collection members in any particular order unless the client asks for them to be returned ordered. That was not the intent of the ordering spec. If a collection has an ordering, the server is required to respond to PROPFIND with the hrefs in that order. It may turn out that ordered collections won't be very useful, because clients will ignore the ordering that comes back and re-sort the results some other way. The discussion we started out with was only about whether the server should include DAV:orderingtype in PROPFIND responses even if the client does not explicitly request it. Consensus is that it should not. MISC COMMENTS ON BINDING SPEC Chuck: Remove the statement that support for cross-server bindings is unlikely. Don't try to predict the future. That might discourage clients from designing for cross-server bindings. Just say that support for cross-server bindings is potentially costly. (Kevin does expect to support cross-server bindings on individual resources eventually.) Jason: In the new text about checking lock / acl state of descendents, change it to say "Although deleting a binding to a resource affects only that one binding, if the resource is a collection the server must examine the lock state and access control restrictions on all descendents of the collection to determine whether to allow the DELETE." (Same for MOVE.) Chuck: We don't want to commit ourselves to any particular lock semantics in the binding spec. Does this statement do that?