Add a new element to an 'entry' to declare the state of the entry.




When editing an entry via the Atom Publishing Protocol the 'disposition' of the entry needs to be made explicit.


Add a new section, before 3.5, that lists all the new additions to the format:

   3.X Atom Element Definitions
   This specification adds the following elements to an "atom:entry". 
   Unless stated otherwise these elements SHOULD only be used in the context
   of the Atom Publishing Protocol.

   3.X.1 "atom:state"

   The "atom:state" element represents the state of an individual entry. 
   This element appears as a child of the atom:entry element. The content
   of the element is a string that identifies the state of an entry.
   If the "atom:state" element is not present then the state of the entry
   must be interpreted as if the "atom:state" element was present and
   had a value of "published".

   The value of "atom:state" MUST be either a name that is non-empty and does
   not contain any colon (":") characters, or a IRI [RFC3987].  Note
   that use of a relative reference is not allowed.  If a name is given,
   implementations MUST consider the state to be equivalent
   to the same name registered within the IANA Registry of Entry 
   States Section 5, and thus the IRI that would be obtained by
   appending the value of the "atom:state" element to the string
   "".  The value of "atom:state"
   describes the state of an entry, but does not impose any behavioral
   requirements on implementations.

   This document defines 2 initial values for the Registry of Link

   The value "published" signifies that the entry should be published
   when it appears in a POST or PUT request body. When appearing in 
   a GET response it indicates that the entry has been published.

   The value "draft" signifies that the entry should not be published
   when it appears in a POST or PUT request body. When appearing in 
   a GET response it indicates that the entry has not been published.

   5.1 Registry of Entry States

   This registry is maintained by IANA and initially contains two 
   values: "published" and "draft".  New assignments are subject to IESG Approval, 
   as outlined in [RFC2434]. Requests should be made by email to IANA, which 
   will then forward the request to the IESG requesting approval. 
   The request should contain discussion of at least the following five topics:

    * A value for the "atom:state" attribute that conforms to the syntax rule 
        given in Section 3.X.1
    * Common name for entry state.
    * Description of state semantics.
    * Expected display characteristics of an entry with the given state.
    * Security considerations.



[JoeGregorio] I really don't care if new elements are allowed or not allowed in a full Atom document, but I do believe we need to explicitly state a policy one way or the other.

I'm also not tied emotionally to the name 'state', it could be 'disposition', 'condition', 'druthers', etc.

How much do we want to pack into this element? For example, do we add 'allow-comments', 'accept-trackbacks', 'sent-notification-email', etc.

See Also: PaceOtherVocabularies