PaceCompoundEntries was designed for multipart/related to be put into the core protocol. To be able to use multipart/related as an extension to the protocol, we must ensure interop with clients/servers which won't implement it. Here are some thought I came about (I lost my notes somewhere between home and work, or maybe just under other sheets or paper on my desk, I do my best to recall everything correctly… ;-)
Server-side: to be able to talk with clients not supporting multipart/related, a server MUST be able to serve a Compound Entry (I'll use this term to refer to the resource composed of an Atom Entry plus attached resources) at least as an application/atom+xml representation, and optionally as a set of distinct resources. I don't remember how I modeled the levels of conformance, but here's (approximately) what is expected of a "complete" server implementation: - multipart/related;type="application/atom+xml" in a PUT creates an entry and related resources. In the "collection feed", the entry's atom:[EMAIL PROTECTED]"edit"] link to the application/atom+xml representation. - to give access to the multipart/related representation, the server can use transparent content negotiation or provide an additional atom:[EMAIL PROTECTED]"edit"] linking to the multipart representation. - when sending a multipart representation (could be called the "complete representation" of the Compound Entry), subsidiary body parts can be provided as message/external-body;access-type=URL [RFC2017] - multipart/related;type="application/atom+xml" in a POST _replaces_ the Compound Entry. The multipart entity can use message/external-body;access-type=URL to just re-use a subsidiary part without sending it back to the server. To link back subsidiary parts to the server-side resources, an Atom-ID header can be used (the server sent it to the client in the previous step, the client sends it to the server), in this case, the resources can be "updated", otherwise, the previous subsidiary resource is deleted and a new subsidiary resource is created (without Atom-ID, there no way to know the intent of the client; except in the case of an external subsidiary part, which can be linked back to the server resource using the resource URL) - issuing a DELETE to (one of) the entry URL(s) removes the Compound Entry (that is, the Atom Entry and all the subsidiary parts) [@@TBD@@ should we allow servers to keep a subsidiary resource because it knows –by a mean not defined here– that it is referenced from another resource?] - subsidiary resources MAY be individually editable, and are then exposed in a media collection. Such resources cannot be DELETEd. - when sending an Atom Entry Document to a client (outside a multipart/related structure) - if a client POSTs an Atom Entry Document to update the root entry, the server MAY figure out which subsidiary resources are no longer referenced and delete them accordingly. The "spec" won't reference MHTML, so won't talk about Content-Location. Use of cid: URIs is as defined in PaceCompoundEntries (suggested "algorithm": use text replacement before processing/parsing; for every text or XML part) Thoughts? -- Thomas Broyer
