Atom Threading Extensions
Extracted elements (23)
Changes to thr:count, thr:updated, and total should be treated as 'insignificant' updates per RFC 4287, meaning the containing feed/entry atom:updated value SHOULD NOT be changed when only these extension values change, to avoid cache invalidation churn.
There is no implied relationship between the value of thr:total and any thr:count attribute on replies links; the two extensions measure different things and publishers should not assume they must be kept in sync.
Atom does not mandate that feed consumers support extensions beyond ignoring unknown ones; as a result, some implementations may not be capable of fully utilizing thr:count, thr:updated, or thr:total.
Atom processors that do not understand the in-reply-to extension will not recognize the threading relationship. Publishers are advised to also include a 'related' link to the parent resource so that a meaningful semantic relationship is visible to non-extension-aware processors.
If an entry is a response to multiple resources, additional 'in-reply-to' elements MAY be used; no significance is assigned to their order.
If the resource being responded to lacks a persistent unique identifier, the publisher MUST assign one meeting the atom:id requirements for use as the 'ref' value. If a dereferenceable IRI valid as atom:id exists, it SHOULD be used as both 'ref' and 'href'.
Processors MUST NOT assume that multiple replies links within an entry reference different representations of the same resource; each replies link MUST be processed independently.
The 'href' attribute specifies an IRI for retrieving the resource being responded to; once mapped to a URI, it MUST be dereferenceable.
The 'in-reply-to' element MUST contain a 'ref' attribute identifying the resource being responded to.
The 'source' attribute, if present, specifies the IRI of an Atom Feed or Entry Document containing the referenced entry; once mapped to a URI, that URI MUST be dereferenceable.
The thr:total element's content MUST be an unsigned non-negative integer conforming to the canonical XML Schema nonNegativeInteger representation, and an entry MUST NOT contain more than one such element.
The value of the 'ref' attribute MUST conform to the same construction and comparison rules as the atom:id element defined in RFC 4287 Section 4.2.6. Processors MUST NOT assume the IRI can be dereferenced.
thr:count, thr:updated, and total MUST NOT be assumed to provide completely accurate information about the thread. Feed publishers SHOULD make an effort to keep values accurate.
When an IRI that is not also a URI must be dereferenced, it MUST be mapped to a URI using the steps in RFC 3987 Section 3.1. When an IRI serves as an identifier (e.g., ref attribute), it MUST NOT be so mapped.
A 'replies' link MAY carry a 'thr:count' attribute (unsigned nonNegativeInteger XML Schema type) hinting at the total number of replies in the linked resource; the value is advisory and may not be accurate.
A 'replies' link MAY carry a 'thr:updated' attribute (RFC 3339 date-time, same construction rules as Atom Date Construct) hinting at the most recently updated reply; the value is advisory.
The 'in-reply-to' extension element (thr:in-reply-to) indicates that an Atom entry is a response to another resource. It carries a mandatory 'ref' attribute plus optional 'href', 'source', and 'type' attributes.
The 'replies' link relation (rel="replies" on atom:link) references a resource where responses to an entry may be found. If the type attribute is omitted, it defaults to 'application/atom+xml'.
The 'total' extension element (thr:total) indicates the total number of unique responses to an entry known to the publisher. Its content MUST be an unsigned nonNegativeInteger. An entry MUST NOT contain more than one thr:total element.
This specification registers one new Atom link relation type in the IANA Registry of Link Relations (as defined by RFC 4287): attribute value 'replies', pointing to a resource containing responses to an entry.
Distributed threading across multiple domains allows an attacker to attach inappropriate or unwanted content to a discussion by marking an entry as a response to an entry on another domain. Mitigations include user-configurable allowed sources and heuristic legitimacy checks.
Feeds using threaded extensions could be crafted to cause consumers to initiate excessive or unending sequences of network requests, resulting in denial of service to the consumer, target server, or intervening networks. Consumers should require user intervention after a threshold or apply hard/heuristic request limits.
Malicious publishers can edit previously published thr:in-reply-to entries after the fact, creating attribution and repudiation concerns that are harder to detect in distributed comment systems than in centralized ones. XML Digital Signatures (RFC 4287 Section 5.1) partially mitigate this but are not a complete defense.