The Atom Syndication Format

atom:id comparison is deliberately lexical rather than by dereferencing because IRI normalization is complex and dereferencing would create unacceptable network dependencies. The specification recommends a set of normalization strategies (lowercase scheme/host, minimal percent-encoding, no dot-segments, NFC character normalization) when generating atom:id values to reduce spurious mismatches.

Exclusive XML canonicalization is required instead of standard Canonical XML because signed Atom Documents enclosed in other XML documents have their signatures broken by standard canonicalization; exclusive canonicalization avoids this by limiting the canonicalized namespace context.

security, crypto

When both signing and encrypting, the document SHOULD be signed first and then encrypted. This provides integrity to the base document while hiding the signer's identity. If MACs are used, this ordering is REQUIRED.

security, crypto

Atom Documents MUST be well-formed XML as defined by XML 1.0. The specification does not define a DTD and does not require validity in the XML sense.

atom:entry elements that contain no atom:content MUST contain at least one atom:link with rel='alternate'. atom:entry MUST contain an atom:summary when atom:content has a 'src' attribute or when the content type is Base64-encoded binary (non-text, non-XML MIME type).

atom:feed MUST contain one or more atom:author elements unless every child atom:entry contains at least one atom:author element. It MUST contain exactly one atom:id, one atom:title, and one atom:updated element.

atom:feed SHOULD contain one atom:link with rel='self' pointing to the preferred URI for the feed. It MUST NOT contain more than one atom:link with rel='alternate' having the same combination of type and hreflang values.

Atom Processors MUST compare atom:id values character-by-character in a case-sensitive fashion. Comparison MUST NOT rely on dereferencing the IRI. Two IRIs that resolve to the same resource but differ in any character (including case or percent-encoding) are considered distinct identifiers.

Atom Processors MUST NOT reject an Atom Document solely because it contains an XML-Signature element they cannot verify; they MUST continue processing and MAY inform the user of the validation failure.

security, crypto

Atom Processors that decrypt Atom Documents MUST support AES-128 in CBC mode. XML Encryption alone does not ensure integrity; processors SHOULD verify a hash (from an embedded signature or explicit hash) after decryption to guard against bit-manipulation attacks.

security, crypto

Atom Processors that encounter foreign markup (from non-Atom vocabularies or future Atom extensions) in a legal location MUST NOT stop processing or signal an error. When unknown foreign markup appears as a child of atom:entry, atom:feed, or a Person construct, processors MUST NOT change their behavior as a result.

Atom Processors that verify signed Atom Documents MUST support exclusive XML canonicalization (URI: http://www.w3.org/2001/10/xml-exc-c14n#) and MUST be able to verify RSA signatures. DSA signature verification is not required. MACs SHOULD NOT be used for signatures due to key-management risks.

security, crypto

If the 'type' attribute on a Text construct or atom:content is absent, Atom Processors MUST behave as though it were present with a value of 'text'.

When an IRI that is not also a URI is dereferenced, it MUST be mapped to a URI using the steps in RFC 3987 Section 3.1. However, when an IRI serves as an atom:id value, it MUST NOT be so mapped, so that identity comparison works on raw IRI strings.

A Person construct contains a mandatory atom:name element (exactly one), an optional atom:uri element (IRI reference, at most one), and an optional atom:email element conforming to the addr-spec production of RFC 2822 (at most one). Used by atom:author and atom:contributor.

Atom defines two document types: Atom Feed Documents (root element atom:feed) containing feed metadata and zero or more entries, and Atom Entry Documents (root element atom:entry) representing a single entry outside any feed context. Both are identified by the media type application/atom+xml.

http, json

Text constructs carry human-readable text with an optional 'type' attribute whose value must be 'text', 'html', or 'xhtml'. MIME media types MUST NOT be used as type values on Text constructs; that restriction applies only to atom:content.

The atom:content element either contains inline content or references external content via a 'src' attribute (IRI). When 'src' is present, atom:content MUST be empty and the 'type' attribute SHOULD be a MIME media type. Inline content supports text, html, xhtml, XML media types, text/* types, and Base64-encoded binary.

The atom:id element conveys a permanent, universally unique IRI identifier for an entry or feed. The IRI MUST NOT be assumed dereferenceable; it is a persistent opaque identifier that MUST NOT change when the document is relocated, migrated, syndicated, or republished.

The atom:link element references a Web resource via a mandatory href attribute (IRI reference). The optional rel attribute defaults to 'alternate' if absent. This document defines five initial relation values: alternate, related, self, enclosure, and via.

The atom:source element preserves metadata from the source feed when an entry is copied across feeds. Aggregators performing such copying SHOULD include at least atom:id, atom:title, and atom:updated from the source feed in the atom:source element.

The application/atom+xml media type is registered. Optional 'charset' parameter follows application/xml semantics (RFC 3023). File extension is .atom. The media type uses the +xml convention and inherits XML media type security considerations.

registry, http

The IANA Registry of Link Relations is established by this document with five initial values: 'alternate', 'related', 'self', 'enclosure', and 'via'. New assignments require IESG Approval per RFC 2434. Registrations must supply the attribute value, description, expected display characteristics, and security considerations.

registry

Atom Processors are vulnerable to spoofing attacks where an attacker publishes an atom:entry using the atom:id of an entry from a different feed, potentially with a falsified atom:source element. Processors that de-duplicate by atom:id should also verify publisher origin before treating entries as duplicates.

security

Text constructs and atom:content may deliver HTML and XHTML containing unsafe elements (IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, LINK). Implementations must carefully sanitize or sandbox such content, as it can directly contain or reference executable content.

security

Date constructs encode a date-time value conforming to the RFC 3339 'date-time' production. An uppercase 'T' MUST separate date and time, and an uppercase 'Z' MUST be present when no numeric time zone offset is provided.

For atom:content with a non-text, non-XML MIME type, the content MUST be valid Base64 encoding (RFC 3548 section 3). Lines are separated by a single newline (U+000A); leading/trailing whitespace within the element is permitted.