Visual RFC.
ALL RFCs / RFC 9116
Read the RFC ↗
RFC 9116 / SECURITY.TXT DISCLOSURE CONTACTS

Check expiry before using contacts

04

Contact details can go out of date. Expires gives an RFC 3339 date and time after which the file’s information is stale and should not be used. It is not a guarantee that an address was safe or current before that time.

RFC 9116 · § 2.5.5EXAMPLE
3 / 3
Check expiry before using contactsThe fixed expiry2026-11-01 at midnight UTC is compared with two explicit check times. At2026-10-20 midnight, twelve days remain; freshness alone is not authenticity. At2026-11-02 midnight, the old file is stale and a report connector stops before the stale mailbox. The final scene separately illustrates a reviewed replacement with expiry2026-12-01; renewing the date is not proof that contact ownership was checked. These are fixed teaching dates, not the current browser clock.Stale contacts can misdirect a reportOrganizationRevised filereview and republishExpires: 2026-12-01T00:00:00ZContacts reviewed · illustrative maintenanceLess than a year ahead: RECOMMENDEDChanging a date alone proves no review
03
Publish current information with a new expiry.

In this illustrative maintenance step, the organization reviews its contacts and publishes a revised file expiring 2026-12-01. Editing only a date would not prove the contacts were checked.

Source for this drawing: RFC 9116 · Read RFC section 2.5.5 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Expiry
The date and time after which the file data is considered stale.
RFC 3339
The Internet timestamp syntax used by the Expires field.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Expires MUST always be present and MUST NOT appear more than once. It is RECOMMENDED that its value be less than a year in the future, to reduce staleness.

  • Expires MUST always be present and MUST NOT appear more than once. It is RECOMMENDED that its value be less than a year in the future, to reduce staleness.
  • The worked fixture expires at 2026-11-01T00:00:00Z. At the illustrative check time 2026-10-20T00:00:00Z it has 12 days remaining. Z denotes UTC.
  • At the illustrative later time 2026-11-02T00:00:00Z, the same file is stale. Do not send a sensitive report using its contacts merely because the file is still downloadable.
  • An expiry timestamp is a file-content freshness boundary, not a TLS certificate validity date, HTTP cache lifetime or automatic renewal instruction.
  • Organizations should keep contact information and referenced resources current, accessible, secure and under their control. A stale file can route sensitive reports to the wrong recipient; not publishing may be preferable to stale information.
DETAILS

All times are fixed teaching fixtures, not this browser’s current time. The guide does not calculate freshness from a previous run or assert that a real contact remains valid. Expires is an exactly-once requirement; the less-than-one-year horizon is a recommendation. A file that is not stale still needs syntax, scope, destination and trust checks.

Read the RFC section ↗

All chapters in RFC 9116

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗