Home >> FAQs/Tutorials >> RSS Tutorials >> Index

RSS Tutorials - The Atom Syndication Format - Part 3

By: M. Nottingham, Ed. & R. Sayre, Ed.

(Continued from previous topic...)

The Atom Syndication Format - Part 3

   The atom:source element is designed to allow the aggregation of
   entries from different feeds while retaining information about an
   entry's source feed.  For this reason, Atom Processors that are
   performing such aggregation SHOULD include at least the required
   feed-level Metadata elements (atom:id, atom:title, and atom:updated)
   in the atom:source element.

4.2.12.  The "atom:subtitle" Element

   The "atom:subtitle" element is a Text construct that conveys a human-
   readable description or subtitle for a feed.

   atomSubtitle = element atom:subtitle { atomTextConstruct }

4.2.13.  The "atom:summary" Element

   The "atom:summary" element is a Text construct that conveys a short
   summary, abstract, or excerpt of an entry.

   atomSummary = element atom:summary { atomTextConstruct }

   It is not advisable for the atom:summary element to duplicate
   atom:title or atom:content because Atom Processors might assume there
   is a useful summary when there is none.

4.2.14.  The "atom:title" Element

   The "atom:title" element is a Text construct that conveys a human-
   readable title for an entry or feed.

   atomTitle = element atom:title { atomTextConstruct }

4.2.15.  The "atom:updated" Element

   The "atom:updated" element is a Date construct indicating the most
   recent instant in time when an entry or feed was modified in a way
   the publisher considers significant.  Therefore, not all
   modifications necessarily result in a changed atom:updated value.

   atomUpdated = element atom:updated { atomDateConstruct }

   Publishers MAY change the value of this element over time.

[Page 25]

5.  Securing Atom Documents

   Because Atom is an XML-based format, existing XML security mechanisms
   can be used to secure its content.

   Producers of feeds and/or entries, and intermediaries who aggregate
   feeds and/or entries, may have sound reasons for signing and/or
   encrypting otherwise-unprotected content.  For example, a merchant
   might digitally sign a message that contains a discount coupon for
   its products.  A bank that uses Atom to deliver customer statements
   is very likely to want to sign and encrypt those messages to protect
   their customers' financial information and to assure the customer of
   their authenticity.  Intermediaries may want to encrypt aggregated
   feeds so that a passive observer cannot tell what topics the
   recipient is interested in.  Of course, many other examples exist as

   The algorithm requirements in this section pertain to the Atom
   Processor.  They require that a recipient, at a minimum, be able to
   handle messages that use the specified cryptographic algorithms.
   These requirements do not limit the algorithms that the sender can

5.1.  Digital Signatures

   The root of an Atom Document (i.e., atom:feed in an Atom Feed
   Document, atom:entry in an Atom Entry Document) or any atom:entry
   element MAY have an Enveloped Signature, as described by XML-
   Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212].

   Atom Processors MUST NOT reject an Atom Document containing such a
   signature because they are not capable of verifying it; they MUST
   continue processing and MAY inform the user of their failure to
   validate the signature.

   In other words, the presence of an element with the namespace URI
   "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature"
   as a child of the document element MUST NOT cause an Atom Processor
   to fail merely because of its presence.

   Other elements in an Atom Document MUST NOT be signed unless their
   definitions explicitly specify such a capability.

   Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for
   Canonical XML [W3C.REC-xml-c14n-20010315].  However, many
   implementers do not use it because signed XML documents enclosed in
   other XML documents have their signatures broken.  Thus, Atom
   Processors that verify signed Atom Documents MUST be able to

[Page 26]

   canonicalize with the exclusive XML canonicalization method
   identified by the URI "http://www.w3.org/2001/10/xml-exc-c14n#", as
   specified in Exclusive XML Canonicalization

   Intermediaries such as aggregators may need to add an atom:source
   element to an entry that does not contain its own atom:source
   element.  If such an entry is signed, the addition will break the
   signature.  Thus, a publisher of individually-signed entries should
   strongly consider adding an atom:source element to those entries
   before signing them.  Implementers should also be aware of the issues
   concerning the use of markup in the "xml:" namespace as it interacts
   with canonicalization.

   Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for
   DSA signatures and recommends support for RSA signatures.  However,
   because of the much greater popularity in the market of RSA versus
   DSA, Atom Processors that verify signed Atom Documents MUST be able
   to verify RSA signatures, but do not need be able to verify DSA
   signatures.  Due to security issues that can arise if the keying
   material for message authentication code (MAC) authentication is not
   handled properly, Atom Documents SHOULD NOT use MACs for signatures.

5.2.  Encryption

   The root of an Atom Document (i.e., atom:feed in an Atom Feed
   Document, atom:entry in an Atom Entry Document) MAY be encrypted,
   using the mechanisms described by XML Encryption Syntax and
   Processing [W3C.REC-xmlenc-core-20021210].

   Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
   TripleDES, AES-128, and AES-256.  Atom Processors that decrypt Atom
   Documents MUST be able to decrypt with AES-128 in Cipher Block
   Chaining (CBC) mode.

   Encryption based on [W3C.REC-xmlenc-core-20021210] does not ensure
   integrity of the original document.  There are known cryptographic
   attacks where someone who cannot decrypt a message can still change
   bits in a way where part or all the decrypted message makes sense but
   has a different meaning.  Thus, Atom Processors that decrypt Atom
   Documents SHOULD check the integrity of the decrypted document by
   verifying the hash in the signature (if any) in the document, or by
   verifying a hash of the document within the document (if any).

[Page 27]

5.3.  Signing and Encrypting

   When an Atom Document is to be both signed and encrypted, it is
   generally a good idea to first sign the document, then encrypt the
   signed document.  This provides integrity to the base document while
   encrypting all the information, including the identity of the entity
   that signed the document.  Note that, if MACs are used for
   authentication, the order MUST be that the document is signed and
   then encrypted, and not the other way around.

6.  Extending Atom

6.1.  Extensions from Non-Atom Vocabularies

   This specification describes Atom's XML markup vocabulary.  Markup
   from other vocabularies ("foreign markup") can be used in an Atom
   Document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2.  Extensions to the Atom Vocabulary

   The Atom namespace is reserved for future forward-compatible
   revisions of Atom.  Future versions of this specification could add
   new elements and attributes to the Atom markup vocabulary.  Software
   written to conform to this version of the specification will not be
   able to process such markup correctly and, in fact, will not be able
   to distinguish it from markup error.  For the purposes of this
   discussion, unrecognized markup from the Atom vocabulary will be
   considered "foreign markup".

6.3.  Processing Foreign Markup

   Atom Processors that encounter foreign markup in a location that is
   legal according to this specification MUST NOT stop processing or
   signal an error.  It might be the case that the Atom Processor is
   able to process the foreign markup correctly and does so.  Otherwise,
   such markup is termed "unknown foreign markup".

   When unknown foreign markup is encountered as a child of atom:entry,
   atom:feed, or a Person construct, Atom Processors MAY bypass the
   markup and any textual content and MUST NOT change their behavior as
   a result of the markup's presence.

   When unknown foreign markup is encountered in a Text Construct or
   atom:content element, software SHOULD ignore the markup and process
   any text content of foreign elements as though the surrounding markup
   were not present.

[Page 28]

6.4.  Extension Elements

   Atom allows foreign markup anywhere in an Atom document, except where
   it is explicitly forbidden.  Child elements of atom:entry, atom:feed,
   atom:source, and Person constructs are considered Metadata elements
   and are described below.  Child elements of Person constructs are
   considered to apply to the construct.  The role of other foreign
   markup is undefined by this specification.

6.4.1.  Simple Extension Elements

   A Simple Extension element MUST NOT have any attributes or child
   elements.  The element MAY contain character data or be empty.
   Simple Extension elements are not Language-Sensitive.

   simpleExtensionElement =
      element * - atom:* {

   The element can be interpreted as a simple property (or name/value
   pair) of the parent element that encloses it.  The pair consisting of
   the namespace-URI of the element and the local name of the element
   can be interpreted as the name of the property.  The character data
   content of the element can be interpreted as the value of the
   property.  If the element is empty, then the property value can be
   interpreted as an empty string.

6.4.2.  Structured Extension Elements

   The root element of a Structured Extension element MUST have at least
   one attribute or child element.  It MAY have attributes, it MAY
   contain well-formed XML content (including character data), or it MAY
   be empty.  Structured Extension elements are Language-Sensitive.

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))

   The structure of a Structured Extension element, including the order
   of its child elements, could be significant.

[Page 29]

   This specification does not provide an interpretation of a Structured
   Extension element.  The syntax of the XML contained in the element
   (and an interpretation of how the element relates to its containing
   element) is defined by the specification of the Atom extension.

7.  IANA Considerations

   An Atom Document, when serialized as XML 1.0, can be identified with
   the following media type:

   MIME media type name:  application
   MIME subtype name:  atom+xml
   Mandatory parameters:  None.
   Optional parameters:
      "charset":  This parameter has semantics identical to the charset
         parameter of the "application/xml" media type as specified in
   Encoding considerations:  Identical to those of "application/xml" as
      described in [RFC3023], Section 3.2.
   Security considerations:  As defined in this specification.
      In addition, as this media type uses the "+xml" convention, it
      shares the same security considerations as described in [RFC3023],
      Section 10.
   Interoperability considerations:  There are no known interoperability
   Published specification:  This specification.
   Applications that use this media type:  No known applications
      currently use this media type.

   Additional information:

   Magic number(s):  As specified for "application/xml" in [RFC3023],
      Section 3.2.
   File extension:  .atom
   Fragment identifiers:  As specified for "application/xml" in
      [RFC3023], Section 5.
   Base URI:  As specified in [RFC3023], Section 6.
   Macintosh File Type code:  TEXT
   Person and email address to contact for further information:  Mark
      Nottingham <mnot@pobox.com>
   Intended usage:  COMMON
   Author/Change controller:  IESG

[Page 30]

7.1.  Registry of Link Relations

   This registry is maintained by IANA and initially contains five
   values: "alternate", "related", "self", "enclosure", and "via".  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 use the
   following template:

   o  Attribute Value: (A value for the "rel" attribute that conforms to
      the syntax rule given in Section
   o  Description:
   o  Expected display characteristics:
   o  Security considerations:

8.  Security Considerations

8.1.  HTML and XHTML Content

   Text constructs and atom:content allow the delivery of HTML and
   XHTML.  Many elements in these languages are considered 'unsafe' in
   that they open clients to one or more types of attack.  Implementers
   of software that processes Atom should carefully consider their
   handling of every type of element when processing incoming (X)HTML in
   Atom Documents.  See the security sections of [RFC2854] and [HTML]
   for guidance.

   Atom Processors should pay particular attention to the security of
   LINK elements, but other elements might also have negative security

   (X)HTML can either directly contain or indirectly reference
   executable content.

8.2.  URIs

   Atom Processors handle URIs.  See Section 7 of [RFC3986].

8.3.  IRIs

   Atom Processors handle IRIs.  See Section 8 of [RFC3987].

8.4.  Spoofing

   Atom Processors should be aware of the potential for spoofing attacks
   where the attacker publishes an atom:entry with the atom:id value of
   an entry from another feed, perhaps with a falsified atom:source

[Page 31]

   element duplicating the atom:id of the other feed.  For example, an
   Atom Processor could suppress display of duplicate entries by
   displaying only one entry from a set of entries with identical
   atom:id values.  In that situation, the Atom Processor might also
   take steps to determine whether the entries originated from the same
   publisher before considering them duplicates.

8.5.  Encryption and Signing

   Atom Documents can be encrypted and signed using
   [W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212],
   respectively, and are subject to the security considerations implied
   by their use.

   Digital signatures provide authentication, message integrity, and
   non-repudiation with proof of origin.  Encryption provides data

9.  References

9.1.  Normative References

   [HTML]     Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
              Specification", W3C REC REC-html401-19991224,
              December 1999,

   [MIMEREG]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC2854]  Connolly, D. and L. Masinter, "The 'text/html' Media
              Type", RFC 2854, June 2000.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3066]  Alvestrand, H., "Tags for the Identification of
              Languages", BCP 47, RFC 3066, January 2001.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, July 2002.

[Page 32]

   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", W3C REC REC-xml-20040204, February 2004,

              Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-
              c14n-20010315, March 2001,

              Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML
              Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-
              20020718, July 2002,

              Cowan, J. and R. Tobin, "XML Information Set (Second
              Edition)", W3C REC REC-xml-infoset-20040204,
              February 2004,

              Hollander, D., Bray, T., and A. Layman, "Namespaces in
              XML", W3C REC REC-xml-names-19990114, January 1999,

              Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627,
              June 2001,

              Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
              Syntax and Processing", W3C REC REC-xmldsig-core-20020212,
              February 2002,

[Page 33]

              Reagle, J. and D. Eastlake, "XML Encryption Syntax and
              Processing", W3C REC REC-xmlenc-core-20021210,
              December 2002,

   [XHTML]    Altheim, M., Boumphrey, F., McCarron, S., Dooley, S.,
              Schnitzenbaumer, S., and T. Wugofski, "Modularization of
              XHTML[TM]", W3C REC REC-xhtml-modularization-20010410,
              April 2001, <http://www.w3.org/TR/2001/

9.2.  Informative References

              International Organization for Standardization, "Data
              elements and interchange formats - Information interchange
              - Representation of dates and times", ISO Standard 8601,
              June 1988.

   [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", December 2001,

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

              Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C
              NOTE NOTE-datetime-19980827, August 1998,

              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004,

[Page 34]

Appendix A.  Contributors

   The following people contributed to preliminary versions of this
   document: Tim Bray, Mark Pilgrim, and Sam Ruby.  Norman Walsh
   provided the Relax NG schema.  The content and concepts within are a
   product of the Atom community and the Atompub Working Group.

   The Atompub Working Group has dozens of very active contributors who
   proposed ideas and wording for this document, including:

   Danny Ayers, James Aylett, Roger Benningfield, Arve Bersvendsen, Tim
   Bray, Dan Brickley, Thomas Broyer, Robin Cover, Bill de hOra, Martin
   Duerst, Roy Fielding, Joe Gregorio, Bjoern Hoehrmann, Paul Hoffman,
   Anne van Kesteren, Brett Lindsley, Dare Obasanjo, David Orchard,
   Aristotle Pagaltzis, John Panzer, Graham Parks, Dave Pawson, Mark
   Pilgrim, David Powell, Julian Reschke, Phil Ringnalda, Antone Roundy,
   Sam Ruby, Eric Scheid, Brent Simmons, Henri Sivonen, Ray Slakinski,
   James Snell, Henry Story, Asbjorn Ulsberg, Walter Underwood, Norman
   Walsh, Dave Winer, and Bob Wyman.

Appendix B.  RELAX NG Compact Schema

   This appendix is informative.

   The Relax NG schema explicitly excludes elements in the Atom
   namespace that are not defined in this revision of the specification.
   Requirements for Atom Processors encountering such markup are given
   in Sections 6.2 and 6.3.

   # -*- rnc -*-
   # RELAX NG Compact Syntax Grammar for the
   # Atom Format Specification Version 11

   namespace atom = "http://www.w3.org/2005/Atom"
   namespace xhtml = "http://www.w3.org/1999/xhtml"
   namespace s = "http://www.ascc.net/xml/schematron"
   namespace local = ""

   start = atomFeed | atomEntry

   # Common attributes

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,

   # Text Constructs

[Page 35]

   atomPlainTextConstruct =
      attribute type { "text" | "html" }?,

   atomXHTMLTextConstruct =
      attribute type { "xhtml" },

   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

   # Person Construct

   atomPersonConstruct =
      (element atom:name { text }
       & element atom:uri { atomUri }?
       & element atom:email { atomEmailAddress }?
       & extensionElement*)

   # Date Construct

   atomDateConstruct =

   # atom:feed

   atomFeed =
         s:rule [
            context = "atom:feed"
            s:assert [
               test = "atom:author or not(atom:entry[not(atom:author)])"
               "An atom:feed must have an atom:author unless all "
               ~ "of its atom:entry children have an atom:author."
      element atom:feed {
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId

[Page 36]

(Continued on next topic...)

  1. The Atom Syndication Format - Reference Document
  2. The Atom Syndication Format - Part 2
  3. The Atom Syndication Format - Part 3
  4. The Atom Syndication Format - Part 4

Selected Developer Jobs: