Control is a dog and we should drop it. Let us examine what it offers us.
1. The control element itself is intended to be a handy box to dump control metadata into. The primary benefit is that it makes it easy to strip such metadata. As evidenced by the requirements of six apart, not all of this metadata will need to be striped. 2. The draft element is intended to provide semantics to communicate publication status. This is a DRY violation. atom:published is optional. If an entry does not have published, it is... not published. We should not recreate semantics already available in atom syntax. 3. The significant element is intended to communicate a clients desire to update updated. This is another blatant DRY violation. A client can indicate its desire to change updated by... changing updated. If an implementation wishes to accept such a change or keep updated the same or change it on its own or just reject the post based on its own rules it can do so. Control metadata and its treatment will be widely varied across implementations. Control clearly does not belong in the core protocol. This is fertile territory for extensions and we ought to stay out of their way. Drop control. We should leave this out of the protocol and move on to other issues. As far as when to expose control information, let us say only this: "The complete entry SHOULD be returned when performing a GET on an entry's edit URI" - Luke
