Six Apart has an objective to enable the ability to migrate our customers seamlessly from one product to another. In other words, if a customer wants to move from TypePad to MovableType or vice versa then we would like Atom to be the protocol to facilitate that process. When we move them we want each and every property of each and every entry retained in the target system.
That's cool. Do you expect to use the same endpoint for day to day publishing and import/export?
When creating an entry, the entry/id element is optional.
Usually, yeah, but probably not for a strict import/export facility or a republisher.
If the element is omitted, empty, or null, then the server MUST create a unique id and assign it to that entry.
Or reject it. I'll probably accept it.
If an entry/id element is provided then the server MUST create an entry with that id.
My client doesn't care if entry id is replaced. That would be bad for import/export, though. I'll probably recommend not pointing Cosimo at an import/export facility.
If the id provided is not a unique id on the target system, then the server MUST produce an error.
If it's a good system, it will do this.
I am curious why we have not explored the use of error messages to communicate to the client the problem at hand. IMHO it is not an either/or proposition, it is about finding a logical way to support both use cases: a client or server generated id/correlation mechanism.
We have. hError client and server.