> Is this why the update is multipart? so that several URLs can be > updated in a single operation? This seems one way to get > transactions. Yes, that's right. I think adding transactions to the web using some explicit COMMIT operation is probably wrong. Rather, just have a POST be the transaction. POST commit data if you must. I'm interested in pushing the complexity of version management into GET and POST partly because most of the issues are orthogonal to the deployment of caching, proxies, updates, transactions, etc. that have dominated the design of GET and POST. If we can create a world where there are three operations: GET, PUT (for simple replace) and POST (for anything else) and all of the rest of the complexity is in the data that's sent back and forth, I think it will be a model that will survive the transition of HTTP to HTTP-NG, the use of this kind of update mechanism using email as well as using direct web transactions, etc. I'm re-reading the VTML document, but I don't think what I intended for "multipart/update" matches what VTML does. What I *intended* was basically just a replacement for (one or more) PUT operations, which contained a set of headers that were appropriate for an update. VTML seems like it's much more a representation -- in a single file -- of a versioned resource. I'm sorry for waving about a name ("multipart/update") without giving a binding for it, since it leaves too much to the imagination. On a completely separate subject: is there a meeting July 8 then? Larry