RFC 7089

HTTP Framework for Time-Based Access to Resource States -- Memento ✨🎀

Title block tea 🍵: This is RFC 7089, an Independent Submission in the Informational category (ISSN 2070-1721), written by H. Van de Sompel (Los Alamos National Laboratory), M. Nelson (Old Dominion University), and R. Sanderson (Los Alamos National Laboratory). It's dated December 2013. Its header doesn't list it as obsoleting or updating any other RFC, so it's a standalone doc 💅.

Abstract

okay so the HTTP-based Memento framework is basically a bridge between the present web and the past web 🌸🦋 It helps you get representations of earlier states of a given resource. It does this by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that uses the given resource's URI plus a user agent's preferred datetime 🕰️. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also helps you recognize a resource that encapsulates a frozen prior state of another resource 🧊✨

Status of This Memo

this doc is not an Internet Standards Track spec, it's published purely for informational purposes 📚

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741 💅

For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7089 🔍

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these docs carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents

1. Introduction ....................................................4
   1.1. Terminology ................................................4
   1.2. Notational Conventions .....................................4
   1.3. Purpose ....................................................5
2. HTTP Headers, Link Relation Types ...............................7
   2.1. HTTP Headers ...............................................7
        2.1.1. Accept-Datetime and Memento-Datetime ................7
        2.1.2. Vary ................................................8
        2.1.3. Link ................................................8
   2.2. Link Relation Types ........................................9
        2.2.1. Link Relation Type "original" .......................9
        2.2.2. Link Relation Type "timegate" .......................9
        2.2.3. Link Relation Type "timemap" ........................9
        2.2.4. Link Relation Type "memento" .......................10
3. Overview of the Memento Framework ..............................11
   3.1. Datetime Negotiation ......................................11
   3.2. TimeMaps ..................................................13
4. Datetime Negotiation: HTTP Interactions ........................14
   4.1. Pattern 1 - The Original Resource Acts as Its Own
        TimeGate ..................................................15
        4.1.1. Pattern 1.1 - URI-R=URI-G; 302-Style
               Negotiation; Distinct URI-M  for Mementos ..........16
        4.1.2. Pattern 1.2 - URI-R=URI-G; 200-Style
               Negotiation; Distinct URI-M for Mementos ...........18
        4.1.3. Pattern 1.3 - URI-R=URI-G; 200-Style
               Negotiation; No Distinct URI-M for Mementos ........19
   4.2. Pattern 2 - A Remote Resource Acts as a TimeGate
        for the Original Resource .................................20
        4.2.1. Pattern 2.1 - URI-R<>URI-G; 302-Style
               Negotiation; Distinct URI-M for Mementos ...........22
        4.2.2. Pattern 2.2 - URI-R<>URI-G; 200-Style
               Negotiation; Distinct URI-M for Mementos ...........24
        4.2.3. Pattern 2.3 - URI-R<>URI-G; 200-Style
               Negotiation; No Distinct URI-M for Mementos ........25

   4.3. Pattern 3 - The Original Resource is a Fixed Resource .....26
   4.4. Pattern 4 - Mementos without a TimeGate ...................27
   4.5. Special Cases .............................................29
        4.5.1. Original Resource Provides No "timegate" Link ......29
        4.5.2. Server Exists but Original Resource No
               Longer Does ........................................29
        4.5.3. Issues with Accept-Datetime ........................30
        4.5.4. Memento of a 3XX Response ..........................30
        4.5.5. Memento of Responses with 4XX or 5XX HTTP
               Status Codes .......................................32
        4.5.6. Sticky "Memento-Datetime" and "original"
               Link for Mementos ..................................33
        4.5.7. Intermediate Resources .............................34
        4.5.8. Resources Excluded from Datetime Negotiation .......35
5. TimeMaps: Content and Serialization ............................36
   5.1. Special Cases .............................................38
        5.1.1. Index and Paging TimeMaps ..........................38
        5.1.2. Mementos for TimeMaps ..............................39
6. IANA Considerations ............................................40
   6.1. HTTP Headers ..............................................40
   6.2. Link Relation Types .......................................40
7. Security Considerations ........................................41
8. Acknowledgements ...............................................42
9. References .....................................................42
   9.1. Normative References ......................................42
   9.2. Informative References ....................................42
Appendix A. Use of Headers and Relation Types per Pattern .........43

---

1. Introduction ✨

1.1. Terminology

This spec uses the terms "resource", "request", "response", "entity-body", "content negotiation", "user agent", and "server" as described in [RFC2616]. It uses the terms "representation" and "resource state" as described in [W3C.REC-aww-20041215] 📖

On top of that, the following Memento-specific terms get introduced:

• Original Resource: An Original Resource is a resource that exists or used to exist, and for which access to one of its prior states may be required. 🕰️
• Memento: A Memento for an Original Resource is a resource that encapsulates a prior state of the Original Resource. A Memento for an Original Resource as it existed at time T is a resource that encapsulates the state the Original Resource had at time T. 🧊
• TimeGate: A TimeGate for an Original Resource is a resource that is capable of datetime negotiation to support access to prior states of the Original Resource. 🚪
• TimeMap: A TimeMap for an Original Resource is a resource from which a list of URIs of Mementos of the Original Resource is available. 🗺️

1.2. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🫶

When extra clarity is needed, these shorthands are used:

• URI-R denotes the URI of an Original Resource. 💜
• URI-G denotes the URI of a TimeGate. 💜
• URI-M denotes the URI of a Memento. 💜
• URI-T denotes the URI of a TimeMap. 💜

1.3. Purpose

okay so the state of an Original Resource can change over time 🦋 and if you dereference its URI at any specific moment, you get a response that matches the resource's state right then. that could be a representation of the resource (e.g., 200 OK HTTP status code) 🎀, a "nope, nothing here" (e.g., 404 Not Found HTTP status code) 💀, or a relation to another resource (e.g., 302 Found HTTP status code) 🧚. BUT, and this is the iconic part ✨, responses can also exist that reflect prior states of an Original Resource: a representation of a past state, an indication that the Original Resource didn't exist at some point in the past, a relation it had to another resource way back when, etc. 🕰️ Mementos that give you these responses live in Web archives, content management systems, or revision control systems, among others 🌸. For any given Original Resource, several Mementos can exist, and each one is a frozen prior state of that resource 🧊💜

Examples are:

Mementos for Original Resource http://www.ietf.org/ are as follows:

• http://web.archive.org/web/19970107171109/http://www.ietf.org/
• http://webarchive.nationalarchives.gov.uk/20080906200044/http://www.ietf.org/

Mementos for Original Resource http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol are as follows:

• http://en.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
• http://en.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=33912
• http://web.archive.org/web/20071011153017/http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Mementos for Original Resource http://www.w3.org/TR/webarch/ are as follows:

• http://www.w3.org/TR/2004/PR-webarch-20041105/
• http://www.w3.org/TR/2002/WD-webarch-20020830/
• http://archive.is/20120527002537/http://www.w3.org/TR/webarch/

In the abstract, the Memento framework introduces a mechanism to access versions of Web resources that:

• Is fully distributed 🌐 in the sense that resource versions may reside on multiple servers, and that any such server is likely only aware of the versions it holds 🫶
• Uses the global notion of datetime as a resource version indicator and access key ⏰
• Leverages the following primitives of [W3C.REC-aww-20041215]: resource, resource state, representation, content negotiation, and link 💅

The core components of Memento's mechanism to access resource versions are:

1. The abstract notion of the state of an Original Resource (URI-R) as it existed at datetime T. Note the relationship with the ability to identify the state of a resource at datetime T by means of a URI as intended by the proposed Dated URI scheme [DATED-URI] 🔥
2. A "bridge" from the present to the past 🌉, consisting of:
   • The existence of a TimeGate (URI-G), which is aware of (at least part of the) version history of the Original Resource (URI-R) 👑
   • The ability to negotiate in the datetime dimension with that TimeGate (URI-G), as a means to access the state that the Original Resource (URI-R) had at datetime T ⏳
3. A "bridge" from the past to the present 🌉, consisting of an appropriately typed link from a Memento (URI-M), which encapsulates the state the Original Resource (URI-R) had at datetime T, to the Original Resource (URI-R) 🔗
4. The existence of a TimeMap (URI-T) from which a list of all Mementos that encapsulate a prior state of the Original Resource (URI-R) can be obtained 📜

This document is concerned with specifying an instantiation of these abstractions for resources that are identified by HTTP(S) URIs 🎀

---

2. HTTP Headers, Link Relation Types

The Memento framework is concerned with HEAD and GET interactions with Original Resources, TimeGates, Mementos, and TimeMaps that are identified by HTTP or HTTPS URIs 🧚 Details are only provided for resources identified by HTTP URIs, but they apply similarly to those with HTTPS URIs 💖

2.1. HTTP Headers

The Memento framework operates at the level of HTTP request and response headers 🧠 It introduces two new headers ("Accept-Datetime" and "Memento-Datetime") and introduces new values for two existing headers ("Vary" and "Link") ✨ Other HTTP headers are present or absent in Memento response/request cycles as specified by [RFC2616] 🌈

2.1.1. Accept-Datetime and Memento-Datetime

okay this is the time travel part 🕰️💅 The "Accept-Datetime" request header is sent by a user agent when it wants to access a past state of an Original Resource. It rides along in an HTTP request issued against a TimeGate for an Original Resource, and its value tells you the datetime of the past state you're after 🦋

Example of an "Accept-Datetime" request header:

Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT

The "Memento-Datetime" response header is how a server says "hey, this response reflects a prior state of an Original Resource" 🫶 Its value expresses the datetime of that state. The URI of the Original Resource is given as the Target IRI of a link in the HTTP "Link" header that has a Relation Type of "original" (see Section 2.2) 🔗

The presence of a "Memento-Datetime" header and its associated value for a given response is a promise 🤞 that the resource state reflected in the response will no longer change (see Section 4.5.6) 💜

Example of a "Memento-Datetime" response header:

Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT

Values for the "Accept-Datetime" and "Memento-Datetime" headers consist of a MUST-be-there datetime, I mean a mandatory datetime 🙈 expressed according to the [RFC1123] format, which is formalized by the rfc1123-date construction rule of the BNF in Figure 1. This BNF is derived from the HTTP-date construction of the BNF for Full Dates provided in [RFC2616] 🧾 The datetime is case sensitive, with names for days and months exactly as shown in the wkday and month construction rules of the BNF, respectively 🔠 The datetime MUST be represented in Greenwich Mean Time (GMT) 🌍

accept-dt-value = rfc1123-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1        = 2DIGIT SP month SP 4DIGIT
                 ; day month year (e.g., 20 Mar 1957)
time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
wkday        = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
              "Sun"
month        = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
              "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

               Figure 1: BNF for the Datetime Format

2.1.2. Vary

Generally, the "Vary" header is used in HTTP responses to show the dimensions in which content negotiation is possible 🎨 In the Memento framework, a TimeGate uses the "Vary" header with a value that includes "accept-datetime" to say that datetime negotiation is possible ⏰

For example, this use of the "Vary" header tells you datetime is the only dimension where negotiation works:

Vary: accept-datetime

And this one shows that both datetime negotiation and media type content negotiation are possible 👑

Vary: accept-datetime, accept

2.1.3. Link

The Memento framework defines the "original", "timegate", "timemap", and "memento" Relation Types to convey typed links among Original Resources, TimeGates, Mementos, and TimeMaps 🔗 They're defined in Section 2.2, below. Existing Relation Types may also be used, for example, to help you navigate between Mementos 🧭 Examples are "first", "last", "prev", "next", "predecessor-version", and "successor-version" as detailed in [RFC5988] and [RFC5829] 💅

2.2. Link Relation Types

This section introduces the Relation Types used in the Memento framework 🌸 They're defined in a general way, and their use in HTTP "Link" headers [RFC5988] is described in detail 📖 The use of these Relation Types in TimeMaps is described in Section 5 🫶

2.2.1. Link Relation Type "original"

"original" -- a link with an "original" Relation Type is used to point from a TimeGate or a Memento to its associated Original Resource 👈

Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests issued against a TimeGate or a Memento MUST include exactly one link with an "original" Relation Type in their HTTP "Link" header 🔥

2.2.2. Link Relation Type "timegate"

"timegate" -- a link with a "timegate" Relation Type is used to point from the Original Resource, as well as from a Memento associated with the Original Resource, to a TimeGate for the Original Resource 🌉

Use in HTTP "Link" headers: If there is a TimeGate associated with an Original Resource or Memento that is preferred for use, then responses to HTTP HEAD/GET requests issued against these latter resources MUST include a link with a "timegate" Relation Type in their HTTP "Link" header 🎀 Since multiple TimeGates can exist for any Original Resource, multiple "timegate" links MAY occur, each with a distinct Target IRI 🦋

2.2.3. Link Relation Type "timemap"

"timemap" -- a link with a "timemap" Relation Type is used to point from a TimeGate or a Memento associated with an Original Resource, as well as from the Original Resource itself, to a TimeMap for the Original Resource 📜

Attributes: A link with a "timemap" Relation Type SHOULD use the "type" attribute to convey the MIME type of the TimeMap serialization 🧾 The "from" and "until" attributes may be used to express the start and end of the temporal interval covered by Mementos listed in the TimeMap ⏳ That is, the linked TimeMap will not contain Mementos with archival datetimes outside of the expressed temporal interval 🙅‍♀️ Attempts SHOULD be made to convey this interval as accurately as possible 🎯 The value for these attributes MUST be a datetime expressed according to the rfc1123-date construction rule of the BNF in Figure 1, and it MUST be represented in Greenwich Mean Time (GMT) 🌍

Use in HTTP "Link" headers: If there is a TimeMap associated with an Original Resource, a TimeGate, or a Memento that is preferred for use, then responses to HTTP HEAD/GET requests issued against these latter resources MUST include a link with a "timemap" Relation Type in their HTTP "Link" header 🫶 Multiple such links, each with a distinct Target IRI, MAY be expressed as a means to point to different TimeMaps or to different serializations of the same TimeMap ✨ In all cases, use of the "from" and "until" attributes is OPTIONAL 🥰

2.2.4. Link Relation Type "memento" 🎀

okay bestie, "memento" is the relation type for pointing at a Memento for an Original Resource 🦋 It can be used by a TimeGate, by a Memento, or by the Original Resource itself, all pointing at a Memento. Main character energy for the links 💅

Attributes: A link with a "memento" Relation Type MUST include a "datetime" attribute whose value matches the "Memento-Datetime" of the Memento the link points at. So it's the value of the Memento-Datetime header you get back when you dereference that Memento's URI ✨ The value for the "datetime" attribute MUST be a datetime written according to the rfc1123-date rule in the BNF of Figure 1, and it MUST be in Greenwich Mean Time (GMT) 🌸 A link like this MAY also include a "license" attribute to attach a license to the Memento, and if it does, the value for "license" MUST be a URI 🫶

Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests against an Original Resource, a TimeGate, or a Memento MAY include links with a "memento" Relation Type in their HTTP Link headers 💜 When a Memento gets selected, giving navigational links to the other Mementos can be really helpful for the user agent 🧚 Highkey the most important ones are the links to the temporally first and last Memento the responding server knows about, plus the links to Mementos that sit temporally next to the selected one 🔥

---

3. Overview of the Memento Framework 🌈

okay so the Memento framework gives you two complementary ways to get representations of prior states of an Original Resource 🦋 It's giving teamwork:

• Datetime Negotiation: this is a twist on content negotiation where the user agent tells the server which datetime it wants, instead of, say, a media type preference 💖 The server looks at what it knows about the Original Resource's past and picks the Memento that best matches that datetime preference ✨ More in Section 3.1, and the full details are in Section 4 🎀
• TimeMaps: a TimeMap is a resource you can grab a list from, and that list gives you a complete overview of an Original Resource's past 🌸 The server makes a TimeMap that lists every Memento it knows about, along with each one's archival datetime 🍓 The user agent can get the TimeMap and pick Mementos from it 💅 Overview in Section 3.2, details in Section 5 💜

---

3.1. Datetime Negotiation 🧚

Okay here's the vibe. Figure 2 is a schematic of a successful request/response chain that uses datetime negotiation 🦋 The dashed lines show the HTTP transactions between the user agent and the server 🌈 In this scenario the Original Resource lives on one server, while its TimeGate and Mementos live on another server (Pattern 2.1 (Section 4.2.1) in Section 4) 🫶 Other setups exist too, like everything living on the same server (think content management systems), or everything being on different servers (like an aggregator of TimeGates) 💅

1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R
2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G
4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
         URI-R,URI-T ------------------------------------------> URI-G
5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M
6: UA <-- HTTP 200; Memento-Datetime: T; Link:
         URI-R,URI-T,URI-G ------------------------------------- URI-M

          Figure 2: A Datetime Negotiation Request/Response Chain

Step 1: The user agent that wants a prior state of the Original Resource sends an HTTP HEAD/GET to URI-R, with an Accept-Datetime header whose value is the datetime of the state it wants 🌸

Step 2: The response from URI-R has an HTTP Link header with a "timegate" Relation Type, pointing at a TimeGate (URI-G) for the Original Resource 💖

Step 3: The user agent kicks off datetime negotiation with the TimeGate by sending an HTTP GET to URI-G, with an Accept-Datetime header holding the datetime of the prior state it wants 🧚

Step 4: The response from URI-G has a Location header pointing at a Memento (URI-M) for the Original Resource ✨ It also has an HTTP Link header with an "original" Relation Type pointing at the Original Resource (URI-R), and another HTTP Link header with a "timemap" Relation Type pointing at a TimeMap (URI-T) 🎀

Step 5: The user agent sends an HTTP GET to URI-M 🦋

Step 6: The response from URI-M has a Memento-Datetime header with the archival datetime of the Memento 🌈 It also has an HTTP Link header with an "original" Relation Type pointing at the Original Resource (URI-R), a "timegate" Relation Type pointing at a TimeGate (URI-G) for the Original Resource, and a "timemap" Relation Type pointing at a TimeMap (URI-T) for the Original Resource 💜 The state the response shows is the state the Original Resource had at the archival datetime in the Memento-Datetime header 🫶

Okay so, to answer a datetime negotiation request, the server runs an internal algorithm to pick the Memento that best matches the user agent's datetime preference 💅 The exact selection algorithm is up to the server, but it's supposed to be consistent, like always picking the Memento nearest in time to the requested datetime, or always picking the nearest one in the past, and so on 🔥

Due to how sparse Mementos are in most systems, the Memento-Datetime value a server returns can be (significantly) different from the value the user agent put in Accept-Datetime 🙈

Even though a Memento captures a prior state of an Original Resource, the entity-body returned for an HTTP GET to a Memento might not be byte-for-byte the same as an entity-body that the Original Resource once returned 💀 There are lots of reasons why they'd probably be different but still carry basically the same information 🌸 Those include format migrations as part of a digital preservation strategy, URI-rewriting done by some Web archives, and adding banners to brand Web archives 🍓

When doing datetime negotiation, the regular content negotiation dimensions (media type, character encoding, language, and compression) are still available 🧚 It's up to the TimeGate server whether it honors that content negotiation, and while doing so it MUST always first select a Memento that meets the user agent's datetime preference, and only then consider honoring regular content negotiation for it 💖 Because of this order, the returned Memento won't necessarily match the user agent's regular content negotiation preferences 😭 So it is RECOMMENDED that the server provides "memento" links in the HTTP Link header pointing at Mementos that do match the user agent's regular content negotiation requests and that have a Memento-Datetime header value close in time to the user agent's preferred datetime 🫶

A user agent doing datetime negotiation with a resource usually starts with an HTTP HEAD, not GET, carrying an Accept-Datetime header, so it can figure out how to proceed 🦋 This approach ties into the different server implementation patterns, which will make sense in Section 4 ✨

Details about the HTTP interactions in datetime negotiation are in Section 4 🎀

---

3.2. TimeMaps 🌸

Figure 3 is a schematic of a successful request/response chain where a user agent gets a TimeMap 💅 It uses the same pictorial conventions as Figure 2, and the same scenario 🧚 Note that, besides a TimeGate, an Original Resource and a Memento can also link to a TimeMap 🌈

1: UA --- HTTP HEAD/GET ------------------------------------> URI-R
2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
3: UA --- HTTP HEAD/GET ------------------------------------> URI-G
4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
         URI-R,URI-T ------------------------------------------> URI-G
5: UA --- HTTP GET URI-T -----------------------------------> URI-T
6: UA <-- HTTP 200 ------------------------------------------ URI-T

          Figure 3: A Request/Response Chain to Obtain a TimeMap

Step 1: The user agent that wants a TimeMap for the Original Resource sends an HTTP HEAD/GET to URI-R 🦋 It can include an Accept-Datetime header or leave it off 💖

Step 2: No matter whether Step 1 used an Accept-Datetime header, the response from URI-R has an HTTP Link header with a "timegate" Relation Type pointing at a TimeGate (URI-G) for the Original Resource 🫶

Step 3: The user agent sends an HTTP GET to URI-G 🧚 It can include an Accept-Datetime header or leave it off 🌸

Step 4: No matter whether Step 1 used an Accept-Datetime header, the response has an HTTP Link header with a "timemap" Relation Type pointing at a TimeMap (URI-T) 💜

Step 5: The user agent sends an HTTP GET to URI-T 🔥

Step 6: The response from URI-T has an entity-body that lists all the Mementos for the Original Resource that the responding server knows about, along with their archival datetimes 👑

Details about what TimeMaps contain and how they're serialized are in Section 5 💅

4. Datetime Negotiation: HTTP Interactions ✨

okay so Figure 2 shows one specific pattern for setting up Memento 🎀 There are actually a few patterns, and they sort into four groups:

• Pattern 1 (Section 4.1) - The Original Resource acts as its own TimeGate
• Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for the Original Resource
• Pattern 3 (Section 4.3) - The Original Resource is a Fixed Resource
• Pattern 4 (Section 4.4) - Mementos without a TimeGate

The HTTP interactions for the common cases of each pattern are covered in Sections 4.1 through 4.4 💅 Appendix A is the cheat sheet for how the "Vary", "Memento-Datetime", and "Link" headers show up in responses from Original Resources, TimeGates, and Mementos across the patterns 🧚 Weird situations get their own section, which is Section 4.5. Also, in the sections below, the HTTP status code for responses with an entity-body is written as "200 OK", but a bunch of "206 Partial Content" responses could be used instead, so don't panic if you see those 🫶

Figure 4 is a user agent trying to datetime negotiate with the Original Resource http://a.example.org/ by adding an "Accept-Datetime" header to its HTTP HEAD request 🦋 This starting request is identical for Pattern 1 (Section 4.1) through Pattern 3 (Section 4.3), so it's giving consistency 💜

HEAD / HTTP/1.1
Host: a.example.org
Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
Connection: close

         Figure 4: User Agent Attempts Datetime Negotiation
                       with Original Resource

4.1. Pattern 1 - The Original Resource Acts as Its Own TimeGate 🌸

In this pattern, the Original Resource is its own TimeGate, so URI-R and URI-G are the same thing 👑 Content management systems and revision control systems can totally do datetime negotiation this way, since they already know the version history of their own resources. Iconic behaviour 🙈

The response depends on which negotiation style is used (200-style or 302-style), and on whether there's a URI-M for Mementos that's different from the URI-R of the Original Resource. All the cases are in the table below, and the server responses for each get their own tour in the rest of this section ✨

+-------------------+------------+----------+---------+-------------+
|      Pattern      |  Original  | TimeGate | Memento | Negotiation |
|                   |  Resource  |          |         |    Style    |
+-------------------+------------+----------+---------+-------------+
|    Pattern 1.1    |    URI-R   |   URI-R  |  URI-M  |     302     |
|  (Section 4.1.1)  |            |          |         |             |
|    Pattern 1.2    |    URI-R   |   URI-R  |  URI-M  |     200     |
|  (Section 4.1.2)  |            |          |         |             |
|    Pattern 1.3    |    URI-R   |   URI-R  |  URI-R  |     200     |
|  (Section 4.1.3)  |            |          |         |             |
+-------------------+------------+----------+---------+-------------+

                     Table 1: Pattern 1

4.1.1. Pattern 1.1 - URI-R=URI-G; 302-Style Negotiation; Distinct URI-M 🦋

In this case, the response to the user agent's Figure 4 request comes back as "302 Found", and the "Location" header carries the URI-M of the selected Memento 💖 Here's how Memento response headers and links look in the response from URI-R=URI-G:

• The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value.
• The response MUST NOT contain a "Memento-Datetime" header.
• The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged too, but they're subject to the considerations in Section 2.2.

The server's answer to the Figure 4 request is Figure 5 ✨ Notice the recommended link to the TimeGate, which in this case has a Target IRI that's the URI-R of the Original Resource.

HTTP/1.1 302 Found
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Vary: accept-datetime
Location:
 http://a.example.org/?version=20010320133610
Link: <http://a.example.org/>; rel="original timegate"
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

          Figure 5: Response from URI-R=URI-G for Pattern 1.1

Next, in Figure 6, the user agent gets the selected Memento by sending an HTTP GET request to the URI-M that came in the "Location" header 🧚 Including "Accept-Datetime" in this request isn't needed, but it'll usually show up anyway because the user agent is still in datetime negotiation mode, which is very relatable 😭

GET /?version=20010320133610 HTTP/1.1
Host: a.example.org
Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
Connection: close

            Figure 6: User Agent Requests Selected Memento

The response is "200 OK", and its entity-body is the representation of the selected Memento 🎀 Here's what the Memento response headers and links look like in the response from URI-M:

• A "Vary" header that includes an "accept-datetime" value MUST NOT be provided.
• The response MUST include a "Memento-Datetime" header. Its value gives the archival datetime of the Memento.
• The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged too, but they're subject to the considerations in Section 2.2.

Figure 7 is the server's answer to the Figure 6 request ✨ Look at the required "original" link and the recommended "timegate" and "timemap" links. The first two both point to the Original Resource, which is acting as its own TimeGate. The "timemap" link has "from" and "until" attributes that show the time span covered by the Mementos in the linked TimeMap 🌈

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:06:51 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
Link: <http://a.example.org/>; rel="original timegate",
 <http://a.example.org/?version=all&style=timemap>
   ; rel="timemap"; type="application/link-format"
   ; from="Tue, 15 Sep 2000 11:28:26 GMT"
   ; until="Wed, 20 Jan 2010 09:34:33 GMT"
Content-Length: 23364
Content-Type: text/html;charset=utf-8
Connection: close

            Figure 7: Response from URI-M for Pattern 1.1

4.1.2. Pattern 1.2 - URI-R=URI-G; 200-Style Negotiation; Distinct URI-M ⭐

This time the response to the Figure 4 request is "200 OK", and the "Content-Location" header carries the URI-M of the selected Memento 💅 Here's the Memento response header and link situation from URI-R=URI-G:

• The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value.
• The response MUST include a "Memento-Datetime" header. Its value gives the archival datetime of the selected Memento.
• The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged too, but they're subject to the considerations in Section 2.2.

Figure 8 is the server's answer to the Figure 4 request 🍓 Notice the optional "memento" links, which point at the oldest and most recent Mementos for the Original Resource that the responding server knows about.

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Vary: accept-datetime
Content-Location:
 http://a.example.org/?version=20010320133610
Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
Link: <http://a.example.org/>; rel="original timegate",
 <http://a.example.org/?version=20000915112826>
 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
 <http://a.example.org/?version=20100120093433>
 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT",
 <http://a.example.org/?version=all&style=timemap>
 ; rel="timemap"; type="application/link-format"
Content-Length: 23364
Content-Type: text/html;charset=utf-8
Connection: close

          Figure 8: Response from URI-R=URI-G for Pattern 1.2

For the next request, you send the same thing as Figure 4 but with HTTP GET instead of HEAD 🫶 The user agent then gets the representation of the selected Memento, returned as the entity-body of a response that has the same Memento headers as Figure 8.

4.1.3. Pattern 1.3 - URI-R=URI-G; 200-Style Negotiation; No Distinct URI-M 🌸

Here the response to the Figure 4 request is "200 OK", and there's no "Content-Location" or "Location" header, because there's no URI-M of the selected Memento to share 🙈 Memento response headers and links from URI-R=URI-G work like this:

• The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value.
• The response MUST include a "Memento-Datetime" header. Its value gives the archival datetime of the selected Memento.
• The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged too, but they're subject to the considerations in Section 2.2.

Figure 9 is the server's answer to the Figure 4 request ✨ The recommended "timemap" and "timegate" links show up alongside the mandatory "original" link.

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Vary: accept-datetime
Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
Link: <http://a.example.org/>; rel="original timegate",
 <http://a.example.org/?version=all&style=timemap>
   ; rel="timemap"; type="application/link-format"
Content-Length: 23364
Content-Type: text/html;charset=utf-8
Connection: close

            Figure 9: Response from URI-R=URI-G for Pattern 1.3

When you send the next request, which is the same as Figure 4 but with HTTP GET instead of HEAD, the user agent gets the representation of the selected Memento 💖 It comes back as the entity-body of a response with the same Memento headers as Figure 9.

4.2. Pattern 2 - A Remote Resource Acts as a TimeGate for the Original Resource ✨

okay bestie, pattern 2 is where things get spicy 🌶️ The Original Resource does NOT act as its own TimeGate, so URI-R and URI-G are different URIs 🦋 This setup is usually run by servers whose history lives in remote systems like Web archives and transactional archives [Fitch]. But servers that keep their own history, like content management systems and version control systems, can use it too. Think of it as spreading out the work of answering requests for current and older representations across different servers 💅

This pattern is summarized in the table below and detailed in the rest of this section. Three cases exist, and they differ in two ways: the negotiation style the remote TimeGate uses, and whether the Mementos get a URI-M that is distinct from the TimeGate's URI-G 🌈

+-------------------+------------+----------+---------+-------------+
|      Pattern      |  Original  | TimeGate | Memento | Negotiation |
|                   |  Resource  |          |         |    Style    |
+-------------------+------------+----------+---------+-------------+
|    Pattern 2.1    |    URI-R   |   URI-G  |  URI-M  |     302     |
|  (Section 4.2.1)  |            |          |         |             |
|    Pattern 2.2    |    URI-R   |   URI-G  |  URI-M  |     200     |
|  (Section 4.2.2)  |            |          |         |             |
|    Pattern 2.3    |    URI-R   |   URI-G  |  URI-G  |     200     |
|  (Section 4.2.3)  |            |          |         |             |
+-------------------+------------+----------+---------+-------------+

                            Table 2: Pattern 2

The Original Resource's response to the request in Figure 4 is the same for all three cases. Here's how headers and links work in the response from URI-R 🎀

• Don't send a Vary header that includes an accept-datetime value. It MUST NOT be provided 🙅‍♀️
• The response MUST NOT contain a Memento-Datetime header 🚫
• The Link header SHOULD be provided 💖 It MUST NOT include a link with an original Relation Type. If a preferred TimeGate is associated with the Original Resource, then it MUST include a link with a timegate Relation Type that has the URI-G of the TimeGate as Target IRI. If a preferred TimeMap is associated with the Original Resource, then it SHOULD include a link with a timemap Relation Type that has the URI-T of the TimeGate as Target IRI. Multiple timegate and timemap links can be provided for situations where the server knows about several TimeGates or TimeMaps for the Original Resource 🧚

Figure 10 shows what that looks like. Notice there's no original link, because the responding resource is neither a TimeGate nor a Memento 👀

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:02:12 GMT
Server: Apache
Link: <http://arxiv.example.net/timegate/http://a.example.org/>
   ; rel="timegate"
Content-Length: 255
Connection: close
Content-Type: text/html; charset=iso-8859-1

         Figure 10: Response from URI-R<>URI-G for Pattern 2

Once a user agent has the URI-G of a remote TimeGate for the Original Resource, it can start datetime negotiation with that TimeGate 🕰️ Figure 11 shows the request sent to the TimeGate, and Sections 4.2.1 through 4.2.3 walk through the responses for each TimeGate pattern 💜

HEAD /timegate/http://a.example.org/ HTTP/1.1
Host: arxiv.example.net
Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
Connection: close

        Figure 11: User Agent Engages in Datetime Negotiation
                        with Remote TimeGate

---

4.2.1. Pattern 2.1 - URI-R<>URI-G; 302-Style Negotiation; Distinct URI-M 🦋

okay so in case the TimeGate uses 302 negotiation, the response to the Figure 11 request comes back as a 302 Found HTTP status code, and the Location header carries the URI-M of the selected Memento 🏃‍♀️ Here's how the Memento headers and links work in the response from URI-G 💅

• The Vary header MUST be provided, and it MUST include the accept-datetime value 🌸
• The response MUST NOT contain a Memento-Datetime header 🙅‍♀️
• The Link header MUST be provided, and it MUST contain at least a link with the original Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged too, but they're subject to the considerations in Section 2.2 ✨

The server's response to Figure 11 is shown in Figure 12. It has the mandatory original link pointing back to the Original Resource for this TimeGate, plus the recommended timemap link with from and until attributes 🍓

HTTP/1.1 302 Found
Date: Thu, 21 Jan 2010 00:02:14 GMT
Server: Apache
Vary: accept-datetime
Location:
 http://arxiv.example.net/web/20010321203610/http://a.example.org/
Link: <http://a.example.org/>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org/>
   ; rel="timemap"; type="application/link-format"
   ; from="Tue, 15 Sep 2000 11:28:26 GMT"
   ; until="Wed, 20 Jan 2010 09:34:33 GMT"
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

        Figure 12: Response from URI-G<>URI-R for Pattern 2.1

Next, in the GET request shown in Figure 13, the user agent grabs the selected Memento by requesting the URI-M from the Location header 🎯 Including the Accept-Datetime header isn't needed here, but it'll usually show up because the user agent is still in datetime negotiation mode 🫶

GET /web/20010321203610/http://a.example.org/ HTTP/1.1
Host: arxiv.example.net/
Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
Connection: close

           Figure 13: User Agent Requests Selected Memento

The response has a 200 OK HTTP status code. Here's the deal with Memento headers and links in the response from URI-M 🌈

• A Vary header that includes an accept-datetime value MUST NOT be provided 🚫
• The response MUST include a Memento-Datetime header. Its value expresses the archival datetime of the Memento 🕰️
• The Link header MUST be provided, and it MUST contain at least a link with the original Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged and subject to Section 2.2 💖

The server's response to Figure 13 is shown in Figure 14. Look at that, the recommended timegate and timemap links are both here 🧚

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:02:15 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
Link: <http://a.example.org/>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org/>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org/>
   ; rel="timegate"
Content-Length: 25532
Content-Type: text/html;charset=utf-8
Connection: close

           Figure 14: Response from URI-M for Pattern 2.1

---

4.2.2. Pattern 2.2 - URI-R<>URI-G; 200-Style Negotiation; Distinct URI-M ✨

so in case the TimeGate uses 200 negotiation and each Memento has its own distinct URI-M, the Figure 11 response is a 200 OK HTTP status code, and the Content-Location header carries the URI-M of the selected Memento 🌸 Here's the Memento headers and links situation for the response from URI-G 💅

• The Vary header MUST be provided, and it MUST include the accept-datetime value 🎀
• The response MUST include a Memento-Datetime header. Its value expresses the archival datetime of the Memento 🕰️
• The Link header MUST be provided, and it MUST contain at least a link with the original Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged and subject to Section 2.2 🫶

The server's response to Figure 11 is shown in Figure 15 👑

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Vary: accept-datetime
Content-Location:
 http://arxiv.example.net/web/20010321203610/http://a.example.org/
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
Link: <http://a.example.org/>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org/>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org/>
   ; rel="timegate"
Content-Length: 25532
Content-Type: text/html;charset=utf-8
Connection: close

         Figure 15: Response from URI-G<>URI-R for Pattern 2.2

In a follow-up request, which is the same as Figure 11 but uses HTTP GET instead of HEAD, the user agent can grab the representation of the selected Memento 🧚 It comes back as the entity-body of a response with the same Memento headers as Figure 15 🌈

---

4.2.3. Pattern 2.3 - URI-R<>URI-G; 200-Style Negotiation; No Distinct URI-M 🍓

last one! 🎉 In case the TimeGate uses 200 negotiation but Mementos don't have distinct URIs, the Figure 11 response is a 200 OK HTTP status code. It doesn't have a Content-Location or Location header, because there's no URI-M for the selected Memento to hand over 🙈 Here's the Memento headers and links situation for the response from URI-G 💜

• The Vary header MUST be provided, and it MUST include the accept-datetime value 🌷
• The response MUST include a Memento-Datetime header. Its value expresses the archival datetime of the Memento 🕰️
• The Link header MUST be provided, and it MUST contain at least a link with the original Relation Type that has the URI-R of the Original Resource as Target IRI. Other links are encouraged and subject to Section 2.2 💖

The server's response to Figure 11 is shown in Figure 16 ⭐

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Vary: accept-datetime
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
Link: <http://a.example.org/>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org/>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org/>
   ; rel="timegate"
Content-Length: 25532
Content-Type: text/html;charset=utf-8
Connection: close

         Figure 16: Response from URI-G<>URI-R for Pattern 2.3

In a follow-up request, which is the same as Figure 11 but uses HTTP GET instead of HEAD, the user agent can grab the representation of the selected Memento 🦋 It comes back as the entity-body of a response with the same Memento headers as Figure 16 ✨

4.3. Pattern 3 - The Original Resource is a Fixed Resource ✨

Okay so this one is kinda the chill pattern 🌸 There's no datetime negotiation with a TimeGate happening here at all, bestie. It's for Original Resources that never change state, or that stop changing after some point in their existence, which means URI-R and URI-M are the same thing either from the very start or from some moment onward 🦋 Think tweets, or stable media files on news sites. Here's the table, it's giving simple 💅

   +----------+----------------+----------+---------+------------------+
   |  Pattern |    Original    | TimeGate | Memento |    Negotiation   |
   |          |    Resource    |          |         |       Style      |
   +----------+----------------+----------+---------+------------------+
   |  Pattern |      URI-R     |     -    |  URI-R  |         -        |
   |     3    |                |          |         |                  |
   +----------+----------------+----------+---------+------------------+

                            Table 3: Pattern 3

Servers hosting these resources can totally support the Memento framework by treating the stable resource (a FixedResource as defined in [W3C.gen-ont-20090420]) as a Memento 🎀 Here's how the Memento response headers and links work for a stable resource like that:

• A "Vary" header that includes an "accept-datetime" value MUST NOT be provided. 🙅‍♀️
• The response MUST include a "Memento-Datetime" header 💖 Its value expresses the datetime at which the resource became stable. Providing this value is a promise that the resource has not changed since that datetime and will not change anymore beyond it 🫶
• The "Link" header MUST be provided and MUST have a link with the "original" Relation Type that has the URI-R of the stable resource itself as Target IRI 🔥

Figure 17 shows a response to an HTTP HEAD request for the resource with URI-R http://a.example.org/ that has been stable since March 20, 2009 ✨

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
Link: <http://a.example.org/>; rel="original"
Content-Length: 875
Content-Type: text/html;charset=utf-8
Connection: close

            Figure 17: Response from URI-R=URI-M for Pattern 3

4.4. Pattern 4 - Mementos without a TimeGate 🧚

Okay this one is so real, because sometimes a server hosts Mementos but doesn't expose a TimeGate for them 💀 That can happen when the server's Mementos come from snapshotting a set of Original Resources from another server as it's being retired. So you only end up with a single Memento per Original Resource, which means a TimeGate just isn't necessary 😭 It can also happen with servers that host multiple Mementos for an Original Resource but think exposing TimeGates is too expensive 🙈 In this case URI-R and URI-M are distinct, but there's no TimeGate. Here's the table 🌈

   +----------+----------------+----------+---------+------------------+
   |  Pattern |    Original    | TimeGate | Memento |    Negotiation   |
   |          |    Resource    |          |         |       Style      |
   +----------+----------------+----------+---------+------------------+
   |  Pattern |      URI-R     |     -    |  URI-M  |         -        |
   |     4    |                |          |         |                  |
   +----------+----------------+----------+---------+------------------+

                            Table 4: Pattern 4

Servers that host Mementos without TimeGates can still support the Memento framework by providing the appropriate Memento headers and links 💜 Here's how it works for a response from URI-M:

• A "Vary" header that includes an "accept-datetime" value MUST NOT be provided. 🙅‍♀️
• The response MUST include a "Memento-Datetime" header. Its value expresses the archival datetime of the Memento 💖
• The "Link" header MUST be provided, and it MUST have a link with the "original" Relation Type that has the URI-R of the associated Original Resource as Target IRI. Providing other links is encouraged, and it's subject to the considerations in Section 2.2 👑

Figure 18 shows a response to an HTTP HEAD request for the Memento with URI-M http://arxiv.example.net/web/20010321203610/http://a.example.org/. Notice the links here, bestie 👀 Three links have the URI-M of the Memento as Target IRI, with Relation Types "memento", "first", and "last". That combo tells you this is the only Memento for the Original Resource (the Target IRI from the "original" link, http://a.example.org/) that the server knows about 🦋 Also, a response like this does NOT mean there's no server anywhere that exposes a TimeGate. It just means the responding server neither provides nor knows where a TimeGate lives 🌸

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
Link: <http://a.example.org/>; rel="original",
 <http://arxiv.example.net/web/20010321203610/http://a.example.org/>
   ; rel="first last memento"
   ; datetime="Wed, 21 Mar 2001 20:36:10 GMT"
Content-Length: 25532
Content-Type: text/html;charset=utf-8
Connection: close

            Figure 18: Response from URI-M<>URI-R for Pattern 4

4.5. Special Cases ⭐

4.5.1. Original Resource Provides No "timegate" Link 🙈

Sometimes the response from the Original Resource doesn't contain a "timegate" link. That can happen when:

• The Original Resource's server does not support the Memento framework 💀
• The Original Resource no longer exists, and the responding server isn't aware of its prior existence 😭
• The server that hosted the Original Resource no longer exists 🌈

In all of these cases, the user agent should attempt to determine an appropriate TimeGate for the Original Resource, either automatically or with the user helping out interactively 💅

4.5.2. Server Exists but Original Resource No Longer Does 🍓

Sometimes the server knows an Original Resource used to exist but doesn't provide a current representation anymore. If there's a preferred TimeGate for that discontinued Original Resource, then the server MUST include a "timegate" link in responses to requests for it 🫶 This may let you access Mementos for the Original Resource even though it's gone 🦋 Here's a server's response to a request for the discontinued resource http://a.example.org/pic 👇

HTTP/1.1 404 Not Found
Date: Thu, 21 Jan 2010 00:02:12 GMT
Server: Apache
Link:
 <http://arxiv.example.net/timegate/http://a.example.org/pic>
   ; rel="timegate"
Content-Length: 255
Content-Type: text/html; charset=iso-8909-1
Connection: close

  Figure 19: Response from an Original Resource That No Longer Exists

4.5.3. Issues with Accept-Datetime 🎀

These special cases can come up with the "Accept-Datetime" header when a user agent sends a request to a TimeGate:

• If the value of "Accept-Datetime" is earlier than the datetime of the first Memento, or later than the datetime of the most recent Memento the TimeGate knows about, the first or most recent Memento MUST be selected, respectively 🔥
• If the value of "Accept-Datetime" does not conform to the rfc1123-date construction rule of the BNF in Figure 1, the response MUST have a "400 Bad Request" HTTP status code 🙅‍♀️
• If a user agent sends a request to a TimeGate and doesn't include an "Accept-Datetime" request header, the most recent Memento SHOULD be selected 👑

In all cases, headers and links in responses are used as described for TimeGates in the respective scenarios ✨

4.5.4. Memento of a 3XX Response 🌸

Sometimes HTTP responses with 3XX status codes get archived. For example, crawl-based Web archives commonly archive responses with "301 Moved Permanently" and "302 Found", whereas Linked Data archives hold on to "303 See Other" responses 🧚

If the Memento requested by the user agent is an archived version of an HTTP response with a 3XX status code, the server's response MUST have the same 3XX HTTP status code. Other Memento headers are used as described for Mementos in the respective scenarios 💖

The user agent's handling of an HTTP response with a 3XX status code is NOT affected by the presence of a "Memento-Datetime" header. The user agent MUST behave the same way it does with HTTP responses with a 3XX status code that don't have a "Memento-Datetime" header 💅

However, the user agent MUST be aware that the URI selected from the "Location" header of an HTTP response with a 3XX status code might not be a Memento, but rather an Original Resource 🫶 In that latter case, it SHOULD proceed by looking for a Memento of the selected Original Resource 🔍

Here's an example, bestie 🎀 Figure 20 shows the response to an HTTP GET request for http://a.example.org issued on April 11, 2008. This response is archived as a Memento of http://a.example.org, with URI-M http://arxiv.example.net/web/20080411000650/http://a.example.org. The response to an HTTP GET on this URI-M is shown in Figure 21. It's a replay of the original response with "Memento-Datetime" and "Link" headers added, so the user agent can tell it's a Memento 🦋 In Figure 21, the "Location" header has the same value as the original response, so it identifies an Original Resource. The user agent then goes looking for a Memento of that Original Resource 🔥 Web archives sometimes overwrite the value originally in the "Location" header so it points at a Memento they hold of the resource the redirect originally led to. That's shown in Figure 22, and here the user agent may decide it found an appropriate Memento 🌈

HTTP/1.1 301 Moved Permanently
Date: Fri, 11 Apr 2008 00:06:50 GMT
Server: Apache
Location: http://b.example.org
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

                 Figure 20: Response Is a Redirect

HTTP/1.1 301 Moved Permanently
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
Location: http://b.example.org
Link: <http://a.example.org>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate"
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

        Figure 21: Response is a Memento of a Redirect; Leads
                       to an Original Resource

HTTP/1.1 301 Moved Permanently
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
Location:
 http://arxiv.example.net/web/20080411000655/http://b.example.org
Link: <http://a.example.org>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate"
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

 Figure 22: Response is a Memento of a Redirect; Leads to a Memento

4.5.5. Memento of Responses with 4XX or 5XX HTTP Status Codes 💀

Okay so, sometimes archives save responses with 4XX and 5XX status codes too 😭 (yes, the classic 404 page, we've all seen it). If the Memento a user agent asks for is an archived copy of one of those responses, the server's response MUST have the same 4XX or 5XX HTTP status code 🫶. Headers and links work the way they already do for Mementos in each scenario we covered 🎀.

For example, Figure 23 shows the 404 response to an HTTP GET for http://a.example.org, issued on April 11, 2008. That response gets archived as a Memento of http://a.example.org, with the URI-M http://arxiv.example.net/web/20080411000650/http://a.example.org. The response to an HTTP HEAD on that URI-M is in Figure 24. It's basically a replay of the original response with "Memento-Datetime" and "Link" headers added, so the user agent can tell it's a Memento 🦋.

HTTP/1.1 404 Not Found
Date: Fri, 11 Apr 2008 00:06:50 GMT
Server: Apache
Content-Length: 255
Content-Type: text/plain; charset=UTF-8
Connection: close

                    Figure 23: Response Is a 404

HTTP/1.1 404 Not Found
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
Link: <http://a.example.org>; rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org>
   ; rel="timemap"; type="application/link-format",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate"
Content-Length: 255
Content-Type: text/plain; charset=UTF-8
Connection: close

              Figure 24: Response Is a Memento of a 404

4.5.6. Sticky "Memento-Datetime" and "original" Link for Mementos 📌

A response to an HTTP HEAD/GET request issued against a Memento:

• Includes a "Memento-Datetime" header that makes a promise: the response is archived, frozen in time 🧊. The value of the header expresses the archival datetime of the Memento.
• Includes a link in the HTTP "Link" header with an "original" Relation Type that unambiguously points to the Original Resource associated with the Memento. The Target IRI of the link is the URI-R of that Original Resource.

Both the "Memento-Datetime" header and the "original" link MUST be "sticky" in the following ways 💜:

• The server that originally assigns them MUST retain them in all responses to HTTP requests (with or without an "Accept-Datetime" request header) that occur against the Memento after the time of their original assignment. The server MUST NOT change the value of the "Memento-Datetime" header, nor the Target IRI of the "original" link.
• Applications that mirror Mementos at a different URI MUST retain them and MUST NOT change them unless mirroring involves a meaningful state change. This allows, among other things, duplicating a Web archive at a new location while keeping the value of the "Memento-Datetime" header and the link with the "original" Relation Type for the archived resources. For example, when mirroring, the "Last-Modified" header will be updated to reflect the time of mirroring at the new URI, whereas the value for "Memento-Datetime" will be maintained 🍓.

4.5.7. Intermediate Resources 🧚

An intermediate resource is a resource that issues a redirect to a TimeGate, to a Memento, or to another intermediate resource. That means it plays an active role in the Memento infrastructure 🔥. Intermediate resources commonly exist in Web archives on the path from a TimeGate to an appropriate Memento.

A response from an intermediate resource has an HTTP status code that indicates HTTP redirection (e.g., 302). It also uses Memento headers and links so user agents can recognize that the resource plays a role in the Memento framework:

• A "Vary" header that includes an "accept-datetime" value MUST NOT be provided.
• The response MUST NOT include a "Memento-Datetime" header.
• The "Link" header MUST be provided, and it MUST have a link with the "original" Relation Type that has the URI-R of the associated Original Resource as Target IRI. Links with "timegate", "timemap", and "memento" Relation Types are OPTIONAL. If provided, they MUST pertain to the Original Resource for which the user agent is trying to obtain a Memento.

A user agent MUST follow a redirection provided by an intermediate resource, and multiple such redirections can be chained 🔗.

Picture this: a user agent follows the "timegate" link provided in Figure 10 and does datetime negotiation with the assumed TimeGate, the way Figure 11 shows. But instead of the response in Figure 12, it gets the one in Figure 25 below. That response is unambiguously recognizable as coming from an intermediate resource 👀.

HTTP/1.1 302 Found
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Location:
 http://arxiv.example.net/new-timegate/http://a.example.org/
Link: <http://a.example.org>; rel="original"
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Connection: close

       Figure 25: Redirecting Resource Redirects to a TimeGate

4.5.8. Resources Excluded from Datetime Negotiation 🙈

When a Web archive delivers a Memento to a user agent, it often jazzes up the archived content. For example, it might add a banner with branding that highlights the archival status of the Memento 🎨. The resources that handle this system-specific stuff, usually JavaScript or images, must be used in their current state.

A server that generally supports datetime negotiation should make resources that need to be excluded from datetime negotiation recognizable. That way, a user agent can skip trying to access a Memento for them 🙌. To do this, the server SHOULD include a special-purpose link in the HTTP "Link" header when responding to an HTTP HEAD/GET request to a resource excluded from datetime negotiation. This link has "http://mementoweb.org/terms/donotnegotiate" as its Target IRI, and "type", defined in [RFC6903], as the value of the "rel" attribute. Other Memento headers as defined in Section 2.1 SHOULD NOT be provided.

Figure 26 shows the response to an HTTP HEAD request from a resource excluded from datetime negotiation:

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:09:40 GMT
Server: Apache-Coyote/1.1
Link: <http://mementoweb.org/terms/donotnegotiate>; rel="type"
Content-Length: 238
Content-Type: application/javascript; charset=UTF-8
Connection: close

Figure 26: Response to an HTTP HEAD Request from a Resource Excluded
                     from Datetime Negotiation

---

5. TimeMaps: Content and Serialization 🗂️

A TimeMap is introduced to support retrieving a complete list of all Mementos for a specific Original Resource known to a server 💅. The entity-body of a response to an HTTP GET request issued against a TimeMap's URI-T:

• MUST list the URI-R of the Original Resource that the TimeMap is about;
• MUST list the URI-M and archival datetime of each Memento for the Original Resource known to the server, preferably in a single document, or, alternatively, in multiple documents that can be gathered by following contained links with a "timemap" Relation Type;
• SHOULD list the URI-G of one or more TimeGates for the Original Resource known to the responding server;
• SHOULD, for self-containment, list the URI-T of the TimeMap itself;
• MUST unambiguously type listed resources as being Original Resource, TimeGate, Memento, or TimeMap 🏷️.

The entity-body of a response from a TimeMap MAY be serialized in various ways, but the link-value format serialization described here MUST be supported 🫶. In this serialization, the entity-body MUST be formatted in the same way as the value of an HTTP "Link" header, and hence MUST comply to the "link-value" construction rule of Section 5. The Link header field of [RFC5988], and the media type of the entity-body, MUST be "application/link-format" as introduced in [RFC6690]. Links contained in the entity-body MUST be interpreted as follows:

• The Context IRI is set to the anchor parameter, when specified;
• The Context IRI of links with the "self" Relation Types is the URI-T of the TimeMap, i.e., the URI of the resource from which the TimeMap was requested;
• The Context IRI of all other links is the URI-R of the Original Resource, which is provided as the Target IRI of the link with an "original" Relation Type.

To grab the link-value serialization of a TimeMap, a user agent sends an "Accept" request header with the value set to "application/link-format". Here's how that looks in Figure 27 👇

GET /timemap/http://a.example.org/ HTTP/1.1
Host: arxiv.example.net
Accept: application/link-format;q=1.0
Connection: close

                  Figure 27: Request for a TimeMap

If the TimeMap requested by the user agent exists, the server's response has a "200 OK" HTTP status code, and the list of Mementos is provided in the entity-body of the response 🎉. Such a response is shown in Figure 28.

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Content-Length: 4883
Content-Type: application/link-format
Connection: close

 <http://a.example.org>;rel="original",
 <http://arxiv.example.net/timemap/http://a.example.org>
   ; rel="self";type="application/link-format"
   ; from="Tue, 20 Jun 2000 18:02:59 GMT"
   ; until="Wed, 09 Apr 2008 20:30:51 GMT",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate",
 <http://arxiv.example.net/web/20000620180259/http://a.example.org>
   ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
   ; license="http://creativecommons.org/publicdomain/zero/1.0/",
 <http://arxiv.example.net/web/20091027204954/http://a.example.org>
    ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
    ; license="http://creativecommons.org/publicdomain/zero/1.0/",
 <http://arxiv.example.net/web/20000621011731/http://a.example.org>
   ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
   ; license="http://creativecommons.org/publicdomain/zero/1.0/",
 <http://arxiv.example.net/web/20000621044156/http://a.example.org>
   ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
   ; license="http://creativecommons.org/publicdomain/zero/1.0/",
 ...

                  Figure 28: Response from a TimeMap

5.1. Special Cases ✨

5.1.1. Index and Paging TimeMaps 🗂️

okay so a TimeMap can point at other TimeMaps, and there are two flavors of this 💅

• Index TimeMap - An index TimeMap is basically a table of contents. It just points at other TimeMaps and doesn't list any Mementos itself 📚. This happens when Mementos are spread across a few archives that share a front-end. Figure 29 shows one.
• Paging TimeMap - Sometimes there are so many Mementos that you need several TimeMaps you can page through 📄. Figure 30 shows one. Lowkey iconic detail: a Paging TimeMap links to other TimeMaps and actually lists Mementos too 🧚

In both cases, including the "from" and "until" attributes for "timemap" links is RECOMMENDED. They tell you the temporal span of Mementos each TimeMap covers ⏳. Also, TimeMaps you reach by following a "timemap" link can link to even more TimeMaps, so it goes deeper than you'd think 🌀

<http://a.example.org>;rel="original",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate",
 <http://arxiv.example.net/timemap/http://a.example.org>
   ; rel="self";type="application/link-format",
 <http://arxiv1.example.net/timemap/http://a.example.org>
   ; rel="timemap";type="application/link-format"
   ; from="Wed, 21 Jun 2000 04:41:56 GMT"
   ; until="Wed, 09 Apr 2008 20:30:51 GMT",
 <http://arxiv2.example.net/timemap/http://a.example.org>
   ; rel="timemap";type="application/link-format"
   ; from="Thu, 10 Apr 2008 20:30:51 GMT"
   ; until="Tue, 27 Oct 2009 20:49:54 GMT",
 <http://arxiv3.example.net/timemap/http://a.example.org>
   ; rel="timemap";type="application/link-format"
   ; from="Thu, 29 Oct 2009 20:30:51 GMT"

                      Figure 29: Index TimeMap

<http://a.example.org>;rel="original",
 <http://arxiv.example.net/timegate/http://a.example.org>
   ; rel="timegate",
 <http://arxiv.example.net/timemap/1/http://a.example.org>
   ; rel="self";type="application/link-format"
   ; from="Tue, 20 Jun 2000 18:02:59 GMT"
   ; until="Wed, 09 Apr 2008 20:30:51 GMT",
 <http://arxiv.example.net/timemap/2/http://a.example.org>
   ; rel="timemap";type="application/link-format"
   ; from="Thu, 10 Apr 2008 20:30:51 GMT"
   ; until="Tue, 27 Oct 2009 20:49:54 GMT",
 <http://arxiv.example.net/timemap/3/http://a.example.org>
   ; rel="timemap";type="application/link-format"
   ; from="Thu, 29 Oct 2009 20:30:51 GMT"
   ; until="Fri, 31 Aug 2012 12:22:34 GMT"
 <http://arxiv.example.net/web/20000620180259/http://a.example.org>
   ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
 <http://arxiv.example.net/web/20000621011731/http://a.example.org>
   ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
 <http://arxiv.example.net/web/20000621044156/http://a.example.org>
   ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
 ...

                      Figure 30: Paging TimeMap

5.1.2. Mementos for TimeMaps 🪞

Get this: a TimeMap can also be an Original Resource with its own TimeGate and Mementos 🤯 So the response from a TimeMap could include a "timegate" link to a TimeGate where you can reach earlier versions of the TimeMap. And if URI-T=URI-R=URI-G (the TimeMap is an Original Resource that acts as its own TimeGate), then an "original" link pointing at the TimeMap URI-T would show up too 🔁

That means you have to be careful when a TimeMap for an Original Resource wants to say, in a "Link" header, which Original Resource it's a TimeMap for 🧐 The move is a "timemap" link with the URI-R of the Original Resource as Context IRI and the URI-T of the TimeMap as Target IRI.

Figure 31 shows the response to an HTTP HEAD request against a TimeMap with http://arxiv.example.net/timemap/http://a.example.org as URI-T 💌 This TimeMap describes Mementos for the Original Resource with http://a.example.org as URI-R. The response includes an "original" link pointing at the Original Resource this TimeMap is about. Notice the "anchor" attribute on that link: that's how it carries the URI-R of that Original Resource ✨

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 00:06:50 GMT
Server: Apache
Link: <http://arxiv.example.net/timemap/http://a.example.org>
          ; anchor="http://a.example.org"; rel="timemap"
          ; type="application/link-format"
Content-Length: 0
Content-Type: application/link-format; charset=UTF-8
Connection: close

    Figure 31: TimeMap Links to the Original Resource It Is about

---

6. IANA Considerations 🌸

6.1. HTTP Headers 🎀

IANA has registered the "Accept-Datetime" and "Memento-Datetime" HTTP headers (defined in Section 2.1.1) in the "Permanent Message Header Field Names" registry 📝

• Header field name: Accept-Datetime
• Applicable protocol: "http" (RFC 2616)
• Status: informational
• Author/Change controller: Herbert Van de Sompel, Los Alamos National Laboratory, hvdsomp@gmail.com
• Specification document(s): this document
• Header field name: Memento-Datetime
• Applicable protocol: "http" (RFC 2616)
• Status: informational
• Author/Change controller: Herbert Van de Sompel, Los Alamos National Laboratory, hvdsomp@gmail.com
• Specification document(s): this document

6.2. Link Relation Types 🔗

IANA has registered the Relation Types "original", "timegate", "timemap", and "memento" (defined in Section 2.2) in the "Link Relation Types" registry 💖

• Relation Name: original
• Description: The Target IRI points to an Original Resource.
• Reference: this document
• Notes: An Original Resource is a resource that exists or used to exist, and for which access to one of its prior states may be required.
• Relation Name: timegate
• Description: The Target IRI points to a TimeGate for an Original Resource.
• Reference: this document
• Notes: A TimeGate for an Original Resource is a resource that is capable of datetime negotiation to support access to prior states of the Original Resource.
• Relation Name: timemap
• Description: The Target IRI points to a TimeMap for an Original Resource.
• Reference: this document
• Notes: A TimeMap for an Original Resource is a resource from which a list of URIs of Mementos of the Original Resource is available.
• Relation Name: memento
• Description: The Target IRI points to a Memento, a fixed resource that will not change state anymore.
• Reference: this document
• Notes: A Memento for an Original Resource is a resource that encapsulates a prior state of the Original Resource.

7. Security Considerations 🔐

Okay, bestie, this one is serious, so read it carefully 🙈

Providing a "timegate" HTTP "Link" header in responses to requests for an Original Resource that is protected (for example, 401 or 403 HTTP response codes) is OPTIONAL. Whether to include this Link when authentication is requested is up to the server. There can be cases where a server protects the current state of a resource but offers open access to prior states, so it chooses to send this HTTP "Link" header anyway 🔓 On the flip side, the server may decide not to advertise TimeGate URIs (for example, if they live in an intranet archive) to unauthenticated requests 🚫

The veracity of archives and the relationships between Original Resources and Mementos is beyond the scope of this document 🤷‍♀️ Even without any malice, separate archives can end up with different Mementos for the same Original Resource at the same datetime. That happens when the state of the Original Resource depends on the requesting archive's user agent IP address, specific HTTP request headers, and possibly other factors 🌈

Further authentication, encryption, and other security-related issues are otherwise orthogonal to Memento 💅

8. Acknowledgements 🫶

The Memento effort is funded by the Library of Congress 🏛️ Many thanks to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry Masinter, Gordon Mohr, David Rosenthal, Ed Summers, James Anderson, Tim Starling, Martin Klein, and Mark Nottingham for feedback 💜 Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla Balakireva, Frank McCown, Harihar Shankar, Brad Tofel, Andrew Jackson, Ahmed Alsum, Mat Kelly, and Ilya Kreymer for the implementations that informed the specification 🧚

9. References 📚

9.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2616]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
            Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC5829]   Brown, A., Clemm, G., and J. Reschke, "Link Relation
            Types for Simple Version Navigation between Web
            Resources", RFC 5829, April 2010.

[RFC5988]   Nottingham, M., "Web Linking", RFC 5988, October 2010.

[RFC6690]   Shelby, Z., "Constrained RESTful Environments (CoRE) Link
            Format", RFC 6690, August 2012.

[RFC6903]   Snell, J., "Additional Link Relation Types", RFC 6903,
            March 2013.

9.2. Informative References

[DATED-URI] Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
            dated URIs", Work in Progress, January 2012.

[Fitch]     Fitch, K., "Web site archiving - an approach to recording
            every materially different response produced by a
            website", July 2003,
            <http://ausweb.scu.edu.au/aw03/papers/fitch/paper.html>.

[RFC1123]   Braden, R., "Requirements for Internet Hosts -
            Application and Support", STD 3, RFC 1123, October 1989.

[W3C.REC-aww-20041215]
            Jacobs, I. and N. Walsh, "Architecture of the World Wide
            Web", December 2004, <http://www.w3.org/TR/webarch/>.

[W3C.gen-ont-20090420]
            Berners-Lee, T., "Architecture of the World Wide Web",
            April 2009, <http://www.w3.org/2006/gen/ont>.

Appendix A. Use of Headers and Relation Types per Pattern ✨

okay bestie, this appendix is basically a giant cheat sheet 🧚 it shows which response headers (Vary: accept-datetime, Vary: Memento-Datetime, Link rel="original", Link rel="timegate", and Link rel="timemap") each pattern uses, and whether each one shows up on the Original Resource, the TimeGate, or the Memento. the table gets split into a few chunks because it's so long, but it's one big grid 💅

Each cell says 1 (it's there), 0 (it's not), >=0 (it can show up any number of times, including zero), or NA (not applicable). Scan across a row to see what a pattern needs from each resource type 🫶

   +-----------------+-----------------+----------+----------+---------+
   | Response Header |     Pattern     | Original | TimeGate | Memento |
   |                 |                 | Resource |          |         |
   +-----------------+-----------------+----------+----------+---------+
   |      Vary:      |   Pattern 1.1   |     1    |     1    |    0    |
   | accept-datetime | (Section 4.1.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 1.2  |          |          |         |
   |                 | (Section 4.1.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 1.3   |     1    |     1    |    1    |
   |                 | (Section 4.1.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.1   |     0    |     1    |    0    |
   |                 | (Section 4.2.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 2.2  |          |          |         |
   |                 | (Section 4.2.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.3   |     0    |     1    |    1    |
   |                 | (Section 4.2.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 3    |     1    |    NA    |    1    |
   |                 |  (Section 4.3)  |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 4    |     0    |    NA    |    1    |
   |                 |  (Section 4.4)  |          |          |         |
   +-----------------+-----------------+----------+----------+---------+

(cont.)

   +-----------------+-----------------+----------+----------+---------+
   | Response Header |     Pattern     | Original | TimeGate | Memento |
   |                 |                 | Resource |          |         |
   +-----------------+-----------------+----------+----------+---------+
   |     Vary:       |                 |          |          |         |
   | Memento-        |   Pattern 1.1   |     0    |     0    |    1    |
   |    Datetime     | (Section 4.1.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 1.2  |          |          |         |
   |                 | (Section 4.1.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 1.3   |     1    |     1    |    1    |
   |                 | (Section 4.1.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.1   |     0    |     0    |    1    |
   |                 | (Section 4.2.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 2.2  |          |          |         |
   |                 | (Section 4.2.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.3   |     0    |     1    |    1    |
   |                 | (Section 4.2.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 3    |     1    |    NA    |    1    |
   |                 |  (Section 4.3)  |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 4    |     0    |    NA    |    1    |
   |                 |  (Section 4.4)  |          |          |         |
   +-----------------+-----------------+----------+----------+---------+

(cont.)

   +-----------------+-----------------+----------+----------+---------+
   | Response Header |     Pattern     | Original | TimeGate | Memento |
   |                 |                 | Resource |          |         |
   +-----------------+-----------------+----------+----------+---------+
   |       Link:     |                 |          |          |         |
   |  rel="original" |   Pattern 1.1   |     0    |     1    |    1    |
   |                 | (Section 4.1.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 1.2  |          |          |         |
   |                 | (Section 4.1.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 1.3   |     1    |     1    |    1    |
   |                 | (Section 4.1.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.1   |     0    |     1    |    1    |
   |                 | (Section 4.2.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 2.2  |          |          |         |
   |                 | (Section 4.2.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.3   |     0    |     1    |    1    |
   |                 | (Section 4.2.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 3    |     1    |    NA    |    1    |
   |                 |  (Section 4.3)  |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 4    |     0    |    NA    |    1    |
   |                 |  (Section 4.4)  |          |          |         |
   +-----------------+-----------------+----------+----------+---------+

(cont.)

   +-----------------+-----------------+----------+----------+---------+
   | Response Header |     Pattern     | Original | TimeGate | Memento |
   |                 |                 | Resource |          |         |
   +-----------------+-----------------+----------+----------+---------+
   |      Link:      |                 |          |          |         |
   |  rel="timegate" |   Pattern 1.1   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.1.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 1.2  |          |          |         |
   |                 | (Section 4.1.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 1.3   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.1.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.1   |    >=0   |     0    |   >=0   |
   |                 | (Section 4.2.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 2.2  |          |          |         |
   |                 | (Section 4.2.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.3   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.2.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 3    |    NA    |    NA    |    NA   |
   |                 |  (Section 4.3)  |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 4    |    NA    |    NA    |    NA   |
   |                 |  (Section 4.4)  |          |          |         |
   +-----------------+-----------------+----------+----------+---------+

(cont.)

   +-----------------+-----------------+----------+----------+---------+
   | Response Header |     Pattern     | Original | TimeGate | Memento |
   |                 |                 | Resource |          |         |
   +-----------------+-----------------+----------+----------+---------+
   |     Link:       |                 |          |          |         |
   |  rel="timemap"  |   Pattern 1.1   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.1.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 1.2  |          |          |         |
   |                 | (Section 4.1.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 1.3   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.1.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.1   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.2.1) |          |          |         |
   |                 |         &       |          |          |         |
   |                 |    Pattern 2.2  |          |          |         |
   |                 | (Section 4.2.2) |          |          |         |
   |                 |                 |          |          |         |
   |                 |   Pattern 2.3   |    >=0   |    >=0   |   >=0   |
   |                 | (Section 4.2.3) |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 3    |    >=0   |    NA    |   >=0   |
   |                 |  (Section 4.3)  |          |          |         |
   |                 |                 |          |          |         |
   |                 |    Pattern 4    |    >=0   |    NA    |   >=0   |
   |                 |  (Section 4.4)  |          |          |         |
   |                 |                 |          |          |         |
   +-----------------+-----------------+----------+----------+---------+

+-----------------+-----------------+----------+----------+---------+
| Response Header |     Pattern     | Original | TimeGate | Memento |
|                 |                 | Resource |          |         |
+-----------------+-----------------+----------+----------+---------+
|      Link:      |                 |          |          |         |
|  rel="memento"  |   Pattern 1.1   |    >=0   |    >=0   |   >=0   |
|                 | (Section 4.1.1) |          |          |         |
|                 |         &       |          |          |         |
|                 |    Pattern 1.2  |          |          |         |
|                 | (Section 4.1.2) |          |          |         |
|                 |                 |          |          |         |
|                 |   Pattern 1.3   |    >=0   |    >=0   |   >=0   |
|                 | (Section 4.1.3) |          |          |         |
|                 |                 |          |          |         |
|                 |   Pattern 2.1   |    >=0   |    >=0   |   >=0   |
|                 | (Section 4.2.1) |          |          |         |
|                 |         &       |          |          |         |
|                 |    Pattern 2.2  |          |          |         |
|                 | (Section 4.2.2) |          |          |         |
|                 |                 |          |          |         |
|                 |   Pattern 2.3   |    >=0   |    >=0   |   >=0   |
|                 | (Section 4.2.3) |          |          |         |
|                 |                 |          |          |         |
|                 |    Pattern 3    |    >=0   |    NA    |   >=0   |
|                 |  (Section 4.3)  |          |          |         |
|                 |                 |          |          |         |
|                 |    Pattern 4    |    >=0   |    NA    |   >=0   |
|                 |  (Section 4.4)  |          |          |         |
+-----------------+-----------------+----------+----------+---------+

Table 5: Memento Headers 🎀 that's the whole grid of who gets which header, bestie, so screenshot it 📸

Authors' Addresses 🧚

Meet the squad behind this RFC 💜

Herbert Van de Sompel
Los Alamos National Laboratory
PO Box 1663
Los Alamos, New Mexico  87545
USA

Phone: +1 505 667 1267
EMail: hvdsomp@gmail.com
URI:   http://public.lanl.gov/herbertv/


Michael Nelson
Old Dominion University
Norfolk, Virginia  23529
USA

Phone: +1 757 683 6393
EMail: mln@cs.odu.edu
URI:   http://www.cs.odu.edu/~mln/


Robert Sanderson
Los Alamos National Laboratory
PO Box 1663
Los Alamos, New Mexico  87545
USA

Phone: +1 505 665 5804
EMail: azaroth42@gmail.com
URI:   http://public.lanl.gov/rsanderson/