Creates a new option for the document element, <archive>, which can contain multiple feeds or instances of the same feed, in order to archive the states of a feed or feeds and the states of the entries published while the feed was in each of those states. Specifies that multiple instances of a resource with the same atom:id is illegal in Feed Documents, Entry Documents, and if PaceAggregationDocument2 as adopted, Aggregation Documents, but is legal in Archive Documents.


New Proposal.


  1. Our charter speaks of creating an archive format.

  2. If we wish to be able to archive multiple revisions of an entry or the contents of a feed's head in a single document, we must either specify that the atom:id of a resource be repeatable within a document intended as an archive, or that we invent some other method of identifying multiple instances of the same entry or feed metadata. Multiple instances within an archive type document would be simpler.

  3. Multiple versions of an entry or feed in a non-archive document is unprecedented in syndication formats. In spite of the fact that changing feed metadata after an entry is published breaks the connection between the state of the feed metadata at the time of publishing the entry and the entry, this is how feeds have always worked, so no exception to the one-feed-instance-per-document rule need be made for Aggregation Documents--that is a special case reserved only for archiving.


In section 2:

2.  Atom Documents

   This specification describes three kinds of Atom Documents: Atom Feed
   Documents, Atom Entry Documents, and Atom Archive Documents.

   An Atom Archive Document contains an archive or an Atom feed or feeds,
   or one portion thereof.  Its document element is atom:archive.

   ...and further down...

   start = atomFeed | atomEntry | atomArchive

   All three kinds of Atom documents are specified in terms of ...

Replace the first sentence of section 3.5 of draft-ietf-atompub-format-05.txt with the following (with the choice of alternate terms left to comments made during discussion and the discretion of the editors):

An Identity construct is an element whose content conveys a permanent,
universally unique identifier for the resource (instantiated|described)
by the construct's parent element.  The content of an Identity construct
MUST be unique within an Atom Feed Document or an Atom Entry Document;
therefore, only one version of any resource MAY appear within those
document types.  Multiple versions of the same resource MAY appear
within an Atom Archive Document, in which case, the contents of their
Identity constructs would be identical.

In section 4:

4.X  The "atom:archive" Element

   The "atom:archive" element is the document element (i.e., top-level)
   element of an Atom Archive Document, and acts as a container
   for archives of one or more feeds or portions of feeds and metadata
   associated with the archive. The first element child  of atom:archive
   MUST be atom:head, which MAY be followed zero or more atom:feed child

   atomArchive =
      element atom:archive {
          & atomFeed*)

   Multiple instances of the same atom:feed MAY appear as children of
   atom:archive in order to reflect changes in the feed metadata.
   Likewise, multiple instances of atom:entry elements MAY appears as
   children of atom:feed children of atom:archive in order to reflect
   changes in the content or metadata of the entry.

4.X.1  The "version" Attribute

   atom:archive elements MUST have a "version" attribute whose content
   indicates the version of the Atom specification that the feed
   conforms to.  The content of this attribute is unstructured text.

   The version identifier for this specification is
   "draft-ietf-atompub-format-05: do not deploy".

   atomVersionAttribute =
    attribute version {"draft-ietf-atompub-format-05 : do not deploy"}

Discussion of the atom:version attribute and atom:head element may be repeated or relocated under atom:archive and atom:feed as deemed best by the editors.

4.X  The "atom:head" Element

   The atom:head element acts as a container for metadata about the
   containing feed or archive.


Consumers that wish to be able to access archives would need to be able to handle one more type of Atom Document, which would add one level of hierarchy above <feed>.


The proposed text does not mention Atom Aggregation Documents, although they are discussed in the abstract and rationale. If PaceAggregationDocument2 is adopted, language consistent with the contents of the abstract and rationale will need to be added to the proposed text from that proposal.