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).
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.
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:* {
text
}
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 }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
The structure of a Structured Extension element, including the order
of its child elements, could be significant.
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
[RFC3023].
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
issues.
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
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 4.2.7.2)
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
the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and
LINK elements, but other elements might also have negative security
properties.
(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
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
confidentiality.
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,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[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.
[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.
[W3C.REC-xml-20040204]
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,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-
c14n-20010315, March 2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[W3C.REC-xml-exc-c14n-20020718]
Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML
Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-
20020718, July 2002,
<http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.
[W3C.REC-xml-infoset-20040204]
Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", W3C REC REC-xml-infoset-20040204,
February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", W3C REC REC-xml-names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[W3C.REC-xmlbase-20010627]
Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627,
June 2001,
<http://www.w3.org/TR/2001/REC-xmlbase-20010627>.
[W3C.REC-xmldsig-core-20020212]
Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
Syntax and Processing", W3C REC REC-xmldsig-core-20020212,
February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-xmlenc-core-20021210]
Reagle, J. and D. Eastlake, "XML Encryption Syntax and
Processing", W3C REC REC-xmlenc-core-20021210,
December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[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/
REC-xhtml-modularization-20010410>.
9.2. Informative References
[ISO.8601.1988]
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,
<http://www.oasis-open.org/committees/relax-ng/
compact-20021121.html>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[W3C.NOTE-datetime-19980827]
Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C
NOTE NOTE-datetime-19980827, August 1998,
<http://www.w3.org/TR/1998/NOTE-datetime-19980827>.
[W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", W3C REC REC-xmlschema-2-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
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 }?,
undefinedAttribute*
# Text Constructs
atomPlainTextConstruct =
atomCommonAttributes,
attribute type { "text" | "html" }?,
text
atomXHTMLTextConstruct =
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct
# Person Construct
atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)
# Date Construct
atomDateConstruct =
atomCommonAttributes,
xsd:dateTime
# 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 {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
# atom:entry
atomEntry =
[
s:rule [
context = "atom:entry"
s:assert [
test = "atom:link[@rel=’alternate’] "
~ "or atom:link[not(@rel)] "
~ "or atom:content"
"An atom:entry must have at least one atom:link element "
~ "with a rel attribute of ’alternate’ "
~ "or an atom:content."
]
]
s:rule [
context = "atom:entry"
s:assert [
test = "atom:author or "
~ "../atom:author or atom:source/atom:author"
"An atom:entry must have an atom:author "
~ "if its feed does not."
]
]
]
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent?
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& extensionElement*)
}
# atom:content
atomInlineTextContent =
element atom:content {
atomCommonAttributes,
attribute type { "text" | "html" }?,
(text)*
}
atomInlineXHTMLContent =
element atom:content {
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
}
atomInlineOtherContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
(text|anyElement)*
}
atomOutOfLineContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
attribute src { atomUri },
empty
}
atomContent = atomInlineTextContent
| atomInlineXHTMLContent
| atomInlineOtherContent
| atomOutOfLineContent
# atom:author
atomAuthor = element atom:author { atomPersonConstruct }
# atom:category
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomUri }?,
attribute label { text }?,
undefinedContent
}
# atom:contributor
atomContributor = element atom:contributor { atomPersonConstruct }
# atom:generator
atomGenerator = element atom:generator {
atomCommonAttributes,
attribute uri { atomUri }?,
attribute version { text }?,
text
}
# atom:icon
atomIcon = element atom:icon {
atomCommonAttributes,
(atomUri)
}
# atom:id
atomId = element atom:id {
atomCommonAttributes,
(atomUri)
}
# atom:logo
atomLogo = element atom:logo {
atomCommonAttributes,
(atomUri)
}
# atom:link
atomLink =
element atom:link {
atomCommonAttributes,
attribute href { atomUri },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { atomLanguageTag }?,
attribute title { text }?,
attribute length { text }?,
undefinedContent
}
# atom:published
atomPublished = element atom:published { atomDateConstruct }
# atom:rights
atomRights = element atom:rights { atomTextConstruct }
# atom:source
atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId?
& atomLink*
& atomLogo?
& atomRights?