atom:updated is an objective machine readable date which can be used by an author to signal that the changes they've made to an entry are significant.
this is a suggested revision of PaceDateUpdated: stripped distraction of sorting, punted format rules back to section 3.3 Date Constructs, doesn't replace atom:modified, atom:issued, atom:created, stronger Rationale and rewritten Abstract. I'm mostly happy with this, except for the second sentence of the second paragraph of the spec text... cleaner text could be written, surely.
users want to be notified of significant updates to entries they have previously read
users don't want to be bothered with every minor change that crosses the wire
a simple modified date is too noisy, what with spelling errors and such.
while there are objections to duplicating dates from dcterms in the Atom core, dcterms does not have anything that matches the semantics of atom:updated.
Add a new sub-section to draft-ietf-atompub-format-01 in section 5 (atom:entry), near any other 'date' sections.
=== 5.x "atom:updated" Element === The "atom:updated" element is a Date Construct indicating the most recent date and time when a change was made to the entry which the publisher wishes to bring to the attention of subscribers. Such changes will typically not include minor adjustments like spelling and grammatical corrections, content reformatting, etc. The content of this element MUST conform to the specifications of the Date Construct defined in section 3.3. atom:entry elements MAY contain exactly one atom:updated element. If an Atom entry is published with an atom:updated element, all future instances should also, carrying forward the last value. The value of this element SHOULD be the actual date of the update, and not some date subjectively chosen by the publisher.
atom:updated is for the benefit of end users, while atom:modified is for the benefit of the software in between (and users in absence of atom:updated).
it's optional, and it's absence is the same as if the publishing author doesn't bother marking significant updates, and lack of support in aggregator software is similarly non-fatal. It can be safely ignored, although with loss of value/utility to the end-user.
atom:updated is OPTIONAL, with the understanding that subsequent minor modifications SHOULD carry forward the last atom:updated. That is SHOULD, not MUST, because it's not a world-ending error and we need to allow for situations where someone migrates from one CMS which supports atom:updated to another CMS which doesn't. Also, rather difficult to test any given feed instance for conformance to a MUST requirement.
Feed-reading software can use this date field to detect "significant" changes and signal this to the end user (via flags, marked as unread, a sort option, etc)
Format rules have been punted, leaving it to section 3.3 Date Constructs to define. For simplicity's sake it is preferable that each specific date element NOT have differing format rules.