WebDAV Advanced Collections Minutes July 6, 1999 ATTENDING: Judy Slein, Geoff Clemm, Chuck Fay, Jim Whitehead ACTION ITEMS Judy: arrange phone conference for July 20 REQUIREMENTS Jim and Geoff do not have time to take authoring responsibilities for the requirements document, but are willing to see it pushed as an informational rfc if someone else will be author. Judy is willing to be author, but needs input and comments from others. Jim will move it forward as an informational rfc provided that Judy takes authorship responsibilities. Judy also circulated a draft rationale document and needs comments and help filling in holes. LOGISTICS Geoff will work on Oslo slides on the plane, expects to give overview of the spec and invite discussion. Jim has slides available from his upcoming presentations, and will give them to Geoff. Judy and Chuck will be away on 7/20, but there should be a phone conference anyhow to review the Oslo meeting. We will aim to have a new draft of the spec available August 6, based on comments of the authors and comments received in Oslo. This draft will be the basis of working group last call. Vacation plans: Jim will be out 7/29 - 8/2, and at Delta-V 8/17 - 8/18 Judy will be out 7/10 - 7/28 Chuck will be out 7/15 - 7/23 Judy will work on the spec till Friday 7/9, then turn it over to Jim till she gets back from vacation. SPEC REVIEW Chuck: Is it that it's impossible for bindings to get into an inconsistent state (as on p.6) or that servers MUST NOT let them get into an inconsistent state? He thinks the language on p.6 should be normative. Does para.5 on p.8 clarify this? It says that implementations MUST ensure the integrity of bindings. We don't want normative language in 2 places. What we're saying about the integrity of bindings may be inconsistent with the definition of referential integrity in the terminology section. Agreed: We'll keep normative language out of the overview. So on p.6 we'll just say the integrity of bindings is guaranteed. We'll move the statement about MOVE and DELETE right after "implementations MUST act to ensure the integrity of bindings" in 4.2. Chuck: The definitions of bindings and URI mappings and their relationship to the WebDAV spec are good. Geoff: No major comments. He'll send minor ones via e-mail. Jim: On headers -- For some headers, we use plain URIs as values, for others we uses coded-URIs or generic-coded-URIs. Let's make it simpler for implementers by being consistent. We'll just always use coded-URI or generic-coded-URI. Jim: Position header -- We capitalize First, Last, etc., but in the XML elements they are lower case. Let's make them lower case in the Position header, too. There may be formatting problems with white space in properties and XML elements. Also at some points in the table of contents. These appear in Wordpad, but not in notepad or IE. Jim: Check the prime character in figures to make sure Word has not been doing smart substitutions. Jim: Many figures are at the end of sections, so that next section header follows immediately and looks like a caption. We should fix this by labeling the figures underneath or providing a brief identification of the figure in prose. Jim: Reference issues -- In the normative references, change [HTTP] to refer to the new draft standard RFC 2616. Also check the text of the spec to make sure there are no references to RFC 2068. Jim: Delete from the informational references [DASL] and [CollReq], since these are just internet drafts. We don't want to risk being held up for IESG approval because of references to internet drafts. Jim: Doesn't like our changes to the DAV:response XML element. Doesn't like adding a prop block, and doesn't like DAV:location as a pseudo-property. He would rather introduce a new DAV:headers element and use it for headers that we don't want to treat as properties. Geoff: Would rather treat headers and properties the same. Agreed: We'll leave section 10 on changes to the DAV:response element as is. Geoff: In 4.2.3, in step 4 of the algorithm, should right-to-left really be left-to-right? Jim and Geoff will discuss this offline. Jim generally likes the spec. Judy: Do we really want to require servers to implement both bindings and redirect references, or should we have 2 separate compliance classes for these? They are very different from each other, and you can imagine a server wanting to implement only 1 of them. Jim: Favors keeping them together in a single compliance class to avoid an explosion of compliance classes. Also, redirect references are so minimal to implement that server implementers shouldn't object. One issue is how easy it would be to discover exactly what the server supports. If it's easy to discover, there's less objection to separating them. Judy: You would just have 2 separate compliance classes, and look to see which was in the DAV: header in response to OPTIONS. No decision. Judy: Why are we requiring servers guarantee the integrity of bindings? Geoff: Unless the protocol provides a way to have integrity guaranteed for bindings, his product will find an out-of-band way to do that. In versioning, there are many orthogonal ways of grouping information: by activity, by version tree, by configuration. Most of point of versioning is to be able to reproduce this information for clients. If it can be broken, it's no use to clients.Jim: Happy to keep this requirement. It's hard to imagine an implementation where you wouldn’t have strong integrity. Chuck: We could have another compliance class. Geoff needs mandatory integrity, but not everyone does. Geoff: Weak binding is of such limited value, that splitting that hair in compliance classes is not a good idea. Geoff: We should keep a clean distinction between bindings and direct references. Direct references differ from bindings in that strong integrity is not required for direct references. Judy: Why did DMA leave it up to servers whether to guarantee integrity of references? Chuck: Cross-server bindings optional, but a server might want to provide them. Requiring integrity makes this harder for servers to provide. Making integrity optional might get wider support for cross-server bindings. In DMA there might be light weight DMSs that wouldn’t want to enforce integrity. Bindings still are references, and it still takes work to enforce integrity for them. Geoff: Make a clear distinction between bindings and references. Bindings are relationships between a name and a resource; references are relationships between 2 names. Chuck: The value of allowing dangling references is that it makes possible light weight implementations. In DMA it was expected that most systems would enforce integrity, but DMA didn’t require it and clients are not supposed to assume it. They are supposed to avoid doing things that would result in dangling references. Geoff: Dangling references can be useful to clients, and should be allowed when we add in direct references. Clients may want to be able to create the references before their target exist, etc. But let's keep direct references separate from bindings. Chuck: Hypertext analogy -- Hypertext links are not guaranteed valid, though some web servers might provide this as added value. The prevailing strategy is to allow lack of integrity, and people get by. Chuck: There can be multiple bindings to same resource, so how heavy weight will implementations have to be to track them all? Someone who wants to implement a light weight server would not want to have to track them all. If we allowed only one binding it would be a lot easier to say that servers must maintain integrity. Geoff: There are still likely to be only limited numbers of bindings to a given resource. Creating a binding is no heavier weight than creating a new resource. Chuck: Are there systems that don’t maintain the integrity of containment relationships? We don't know. Agreed: We'll keep the requirement of strong integrity for bindings. Judy: COPY with Depth 0 -- How can we be consistent with our underlying model without unintuitive results? Jim: A binding is an association that really spans between Depth 0 and Depth 1. We have chosen to treat it as part of depth 1, as this gets fewest undesirable consequences. If we treated it as part of Depth 0, so that bindings got copied with the collection but their resources did not, then our COPY operation would leave us with a new set of bindings to existing resources, not with new copies of the resources. Jim: Has been thinking that we really need a separate set of objects that control the namespace, separate from all underlying resources. Then collections would contain resources. There would be a clean separation of namespaces from resources. But he doesn't propose that we make these changes now. Geoff: The purpose of collections is to affect namespace. They give us a clean way of controlling namespace. Agreed: No changes to spec. Judy: MKREF by default overwrites an existing resource. But what if the existing resource is a collection? Overwriting it could do a lot of damage if it's unintentional. Jim: But there’s a UI mediating between the client and an end user, so it's not so dangerous as it looks at first. If we require a delete before the MKREF, someone could sneak in between the delete and the mkref, so you would have to lock and unlock as well. Judy: It was really for efficiency that we decided to make overwrite the default behavior. Chuck: Would prefer the safer default. Agreed: We'll switch to the safer default. Judy: DAV:reftarget and DAV:location are inconsistent. One is #PCDATA and the other is an href. Agreed: Make both reftarget and location href’s. Judy: No one has really thought about the list of headers required to be returned for GET or HEAD on a redirect reference with Passthrough: F. Jim: The easy fix is to change "at a minimum" to "for example". Judy: There has been a discussion of the atomicity requirement for PROPPATCH on the mailing list. Do we want to reconsider our requirements that ORDERPATCH be atomic? Jim: It would be hard on clients to have to interpret partial success from ORDERPATCH, and the intermediate state might not be consistent with the ordering. Server implementers will do their best to achieve atomicity. Let's start with a strong requirement and see how implementers do.