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

RSS FAQs - Atom Syndiation Format RFC4287 Reference Document

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

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14   15  16  17  18  19  20  21  22  23 

(Continued from previous part...)

   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
   well.

   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
   choose.

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]

(Continued on next part...)

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14   15  16  17  18  19  20  21  22  23