Advanced Collections Minutes 4/27/99 Attending: Judy Slein, Jim Whitehead, Geoff Clemm, Chuck Fay ACTION ITEMS Judy: Write an UNBIND definition for the spec Jim: Revise spec All: Read 3.2 spec (and DASL spec) DELETE / UNBIND / DESTROY Geoff: Thinks Roy is trying to encourage us to think of every URL as a separate resource -- Jim W: no Jim W: No, he thinks there is a many-to-one relationsihp between URL and resource, and a many-to-one relationship between resourcen and representation. to state Geoff: We don't care about state. Jim W: right. Roy doesn't define representation, but it's something like the entity that gets included in a GET response. In the weather example, there are supposed to be two resources associated with the same representation. Geoff: We want clients to be able to control sharing. A change in the state should be visible through all the bindings. Judy: Jason proposed collapsing resource and state. Won't that get us what we need? Jim W: No, it won't handle dynamic content. There we need to distinguish between state and resource. The resource is the output of the cgi script. [Judy: why isn't that the representation? What actually is the resource in this case?] Geoff: We want PUT at URL 1 to be reflected at URL 2. For static resources, the state and representation are both the contents of some file, say, and PUT changes the content of the file. For dynamic resources, PUT changes the state (the cgi script), and so changes the representations it generates. BIND may fail in some situations (cgi script) or into tar file. Not everything is sharable. We wouldn't need DELETE if we could get a list of all the bindings to a given resource and UNBIND each. Geoff: The HTTP spec is loose in its definitions of delete and resource. As long as we are careful to understand DELETE to have the least harmful results (delete less rather than more) we should be all right. Judy: We could just define UNBIND, and let versioning define DELETE to make it precise in whatever way it needs for versioning servers. Since HTTP's definition is so vague, probably specifying more precisely what versioning servers will do in response to DELETE will be ok. Versioning servers want to interoperate with DELETE requests from Office 2000 applications. So they do want to go back and clean up DELETE. Chuck: Is there any practice (as opposed to the HTTP spec) that we can appeal to in choosing a semantics for DELETE? We might end up fighting about which platform is more important, and actual practice might not be good semantic basis anyhow. Experience so far: mod_put deletes individual resources, responds with an error for collections; netscape and aol allow delete on collections. Jim W: Don't put existing practice into the spec. Chuck: If things were ill-defined in the past, and we define something clear, we won't get interoperability with down-level clients. Geoff: Define DELETE to be the least damaging possible: delete the least possible thing (a single binding). Chuck: Intuitively, delete means that stuff is gone. That is, it's not accessible any more. Geoff: Separate intuitiveness from the principle of least harm. Least harm is more important. Jim W: Redefine DELETE so that 200 response means that GET wont work in the future. Make it optional whether to destroy state or not. Geoff: When an Office 2000 client issues delete, we don't want the server to fail. Chuck: The issue he wanted to raise is not about whether the server has to destroy the state or not, but about whether only one binding is removed while others remain. Jim W: Let's leave DELETE vague. At a minimum, it just removes one binding, but it may do anything up to destroying the state. We'll define UNBIND and DESTROY precisely, and if you (the client) care about a precise result, you will use UNBIND or DESTROY. Judy: good Geoff: good Chuck: What is the versioning scenario that needs DELETE to do only an unbind? Geoff: If you bind URL to versioned resource or to a revision, if you interpret DELETE as removing all bindings to the revision or versioned resource would have bad consequences on the history and on any other client in a different view seeing the revision. Delete just means I don't want to see it in my workspace any more. Once people are used to living with others working with the same resources, they will get used to thinking of DELETE as just "remove from my view". Geoff: A workspace maps URLs to specific revisions of things. You commit when you are finished working. If you do a delete in that context, it means in your workspace only. Others accept your changes when they are ready. And aside from issues of sharing, you want the revision to continue to exist for the history anyway. Is it important for down-level clients to be able to manipulate workspaces? Geoff thinks yes. Chuck: If we keep fuzzy delete semantics, the user may not get what he wants. Chuck: Thought Geoff would not want to leave delete ill-defined. Geoff is unsure right now, but thinks it's ok. The versioning server can do what it likes, and down-level clients know they can't count on any particular DELETE behavior. Jim W: A successful DELETE means future GET requests will get 404 responses. That's all that is needed. Jim W: Thinks the consistency maintenance language in rfc 2518 (where it says that all bindings for a resource get removed on DELETE) may need to be removed, and is willing to promote this change. This change would be ok because it's on the edge and clients are not being written to it. Geoff: good. Judy: good. Judy: That language in 2518 was making it difficult to claim that the two definitions of MOVE are logically equivalent. (BIND / DELETE = COPY / fixup / DELETE) Jim W: Would like to define PUT and DELETE better, as Larry suggested. Don't let PUT create attributed collections. In a separate proposal. Chuck: Relate what we are proposing to DMA in the areas of containment and deletion. DMA is more explicit, and has fewer side effects. In DMA, there is an explicit binding object. A container has links to binding objects, and objects contained in containers have links to binding objects. So you can easily delete exactly what you want. There is also a distinction between direct vs referential containment. An object is directly contained in exactly one container, and that is where it "really" lives. Geoff: Our redirect referece is more that style. We got rid of it for direct references because it was causing us difficulties in figuring out appropriate semantics for COPY and LOCK. Chuck: There is no object model here. An object model does make things simpler. Making the bindings into objects does make things simpler. Roy's message does propose an object model with 3 levels. Chuck: A more explicit object model, with fewer side effects, would be better. He is concerned about leaving ambiguities in DELETE. To the extent that client can't predict what the server will do, we lose interoperability. Geoff: That's true for down-level servers anyway. But we will introduce something we'll define more precisely: UNBIND and DESTROY. Chuck: We can't fix what's been done, but we can make new capabilities precisely defined. Be careful to be precise when defining UNBIND and DESTROY. An object model may be needed to get it right. SERVER-MAINTAINED ORDERINGS Max seemed content with what is in the spec at 3.2. He did suggest adding a human-readable description for each advertised server-maintained ordering. Jim W: Let's not do that. It would raise internationalization issues, and possibly also require content-negotiation. Where would a developer go for a canonical list of orderings? IANA? Add something to IANA considerations -- a form for registration, specifying what information to include when registering an ordering: English-language description or reference to an informational rfc, canonical identifier, contact, security considerations. Judy and Jim: ok. Since Max will use this feature in his server, let's leave it in and see how it goes. COMMENTS ON SPECIFICATION 03.2 No one is ready to comment. Be ready for next week. Jim W now has the spec and will revise it this week. Judy will work on a new UNBIND section while Jim edits.