From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7089.txt | 2803 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2803 insertions(+) create mode 100644 doc/rfc/rfc7089.txt (limited to 'doc/rfc/rfc7089.txt') diff --git a/doc/rfc/rfc7089.txt b/doc/rfc/rfc7089.txt new file mode 100644 index 0000000..d9462b0 --- /dev/null +++ b/doc/rfc/rfc7089.txt @@ -0,0 +1,2803 @@ + + + + + + +Independent Submission H. Van de Sompel +Request for Comments: 7089 Los Alamos National Laboratory +Category: Informational M. Nelson +ISSN: 2070-1721 Old Dominion University + R. Sanderson + Los Alamos National Laboratory + December 2013 + + + HTTP Framework for Time-Based Access to Resource States -- Memento + +Abstract + + The HTTP-based Memento framework bridges the present and past Web. + It facilitates obtaining representations of prior states of a given + resource by introducing datetime negotiation and TimeMaps. Datetime + negotiation is a variation on content negotiation that leverages the + given resource's URI and 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 facilitates + recognizing a resource that encapsulates a frozen prior state of + another resource. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its 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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7089. + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 1] + +RFC 7089 HTTP Memento December 2013 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to 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 + + + +Van de Sompel, et al. Informational [Page 2] + +RFC 7089 HTTP Memento December 2013 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 3] + +RFC 7089 HTTP Memento December 2013 + + +1. Introduction + +1.1. Terminology + + This specification uses the terms "resource", "request", "response", + "entity-body", "content negotiation", "user agent", and "server" as + described in [RFC2616], and it uses the terms "representation" and + "resource state" as described in [W3C.REC-aww-20041215]. + + In addition, the following terms specific to the Memento framework + are introduced: + + o 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. + + o 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. + + o 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. + + o 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 needed for extra clarity, the following conventions are used: + + o URI-R is used to denote the URI of an Original Resource. + + o URI-G is used to denote the URI of a TimeGate. + + o URI-M is used to denote the URI of a Memento. + + o URI-T is used to denote the URI of a TimeMap. + + + + + + + +Van de Sompel, et al. Informational [Page 4] + +RFC 7089 HTTP Memento December 2013 + + +1.3. Purpose + + The state of an Original Resource may change over time. + Dereferencing its URI at any specific moment yields a response that + reflects the resource's state at that moment: a representation of the + resource's state (e.g., "200 OK" HTTP status code), an indication of + its nonexistence (e.g., "404 Not Found" HTTP status code), a relation + to another resource (e.g., "302 Found" HTTP status code), etc. + However, responses may also exist that reflect prior states of an + Original Resource: a representation of a prior state of the Original + Resource, an indication that the Original Resource did not exist at + some time in the past, a relation that the Original Resource had to + another resource at some time in the past, etc. Mementos that + provide such responses exist in Web archives, content management + systems, or revision control systems, among others. For any given + Original Resource several Mementos may exist, each one reflecting a + frozen prior state of the Original Resource. + + Examples are: + + Mementos for Original Resource http://www.ietf.org/ are as follows: + + o http://web.archive.org/web/19970107171109/http://www.ietf.org/ + + o 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: + + o http://en.wikipedia.org/w/ + index.php?title=Hypertext_Transfer_Protocol&oldid=366806574 + + o http://en.wikipedia.org/w/ + index.php?title=Hypertext_Transfer_Protocol&oldid=33912 + + o 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: + + o http://www.w3.org/TR/2004/PR-webarch-20041105/ + + o http://www.w3.org/TR/2002/WD-webarch-20020830/ + + o http://archive.is/20120527002537/http://www.w3.org/TR/webarch/ + + + +Van de Sompel, et al. Informational [Page 5] + +RFC 7089 HTTP Memento December 2013 + + + In the abstract, the Memento framework introduces a mechanism to + access versions of Web resources that: + + o 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; + + o Uses the global notion of datetime as a resource version indicator + and access key; + + o 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: + + o The existence of a TimeGate (URI-G), which is aware of (at + least part of the) version history of the Original Resource + (URI-R); + + o 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. + + + + + + + +Van de Sompel, et al. Informational [Page 6] + +RFC 7089 HTTP Memento December 2013 + + +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 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 + + The "Accept-Datetime" request header is transmitted by a user agent + to indicate it wants to access a past state of an Original Resource. + To that end, the "Accept-Datetime" header is conveyed in an HTTP + request issued against a TimeGate for an Original Resource, and its + value indicates the datetime of the desired past state of the + Original Resource. + + Example of an "Accept-Datetime" request header: + + Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT + + The "Memento-Datetime" response header is used by a server to + indicate that a response reflects a prior state of an Original + Resource. Its value expresses the datetime of that state. The URI + of the Original Resource for which the response reflects a prior + state is provided as the Target IRI of a link provided in the HTTP + "Link" header that has a Relation Type of "original" (see + Section 2.2). + + The presence of a "Memento-Datetime" header and associated value for + a given response constitutes 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 MANDATORY datetime expressed according to the [RFC1123] + format, which is formalized by the rfc1123-date construction rule of + + + +Van de Sompel, et al. Informational [Page 7] + +RFC 7089 HTTP Memento December 2013 + + + 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 indicate + 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 convey that datetime negotiation + is possible. + + For example, this use of the "Vary" header indicates that datetime is + the only dimension in which negotiation is possible: + + Vary: accept-datetime + + The use of the "Vary" header in this example 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 are defined in + Section 2.2, below. In addition, existing Relation Types may be + used, for example, to support navigating among Mementos. Examples + are "first", "last", "prev", "next", "predecessor-version", and + "successor-version" as detailed in [RFC5988] and [RFC5829]. + + + + +Van de Sompel, et al. Informational [Page 8] + +RFC 7089 HTTP Memento December 2013 + + +2.2. Link Relation Types + + This section introduces the Relation Types used in the Memento + framework. They are 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 the these attributes MUST + + + + + +Van de Sompel, et al. Informational [Page 9] + +RFC 7089 HTTP Memento December 2013 + + + 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" + + "memento" -- A link with a "memento" Relation Type is used to point + from a TimeGate or a Memento for an Original Resource, as well as + from the Original Resource itself, to a Memento for the Original + Resource. + + Attributes: A link with a "memento" Relation Type MUST include a + "datetime" attribute with a value that matches the "Memento-Datetime" + of the Memento that is the target of the link; that is, the value of + the "Memento-Datetime" header that is returned when the URI of the + linked Memento is dereferenced. The value for the "datetime" + attribute 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). This link MAY include a "license" + attribute to associate a license with the Memento; the value for the + "license" attribute MUST be a URI. + + Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests + issued against an Original Resource, a TimeGate, and a Memento MAY + include links in their HTTP "Link" headers with a "memento" Relation + Type. For responses in which a Memento is selected, the provision of + navigational links that lead to Mementos other than the selected one + can be beneficial to the user agent. Of special importance are links + that lead to the temporally first and last Memento known to the + responding server, as well as links leading to Mementos that are + temporally adjacent to the selected one. + + + + + + + + + + +Van de Sompel, et al. Informational [Page 10] + +RFC 7089 HTTP Memento December 2013 + + +3. Overview of the Memento Framework + + The Memento framework defines two complementary approaches to support + obtaining representations of prior states of an Original Resource: + + o Datetime Negotiation: Datetime negotiation is a variation on + content negotiation by which a user agent expresses a datetime + preference pertaining to the representation of an Original + Resource, instead of, for example, a media type preference. Based + on the responding server's knowledge of the past of the Original + Resource, it selects a Memento of the Original Resource that best + meets the user agent's datetime preference. An overview is + provided in Section 3.1; details are in Section 4. + + o TimeMaps: A TimeMap is a resource from which a list can be + obtained that provides a comprehensive overview of the past of an + Original Resource. A server makes a TimeMap available that + enumerates all Mementos that the server is aware of, along with + their archival datetime. A user agent can obtain the TimeMap and + select Mementos from it. An overview is provided in Section 3.2; + details are in Section 5. + +3.1. Datetime Negotiation + + Figure 2 provides a schematic overview of a successful request/ + response chain that involves datetime negotiation. Dashed lines + depict HTTP transactions between user agent and server. The + interactions are for a scenario where the Original Resource resides + on one server, whereas both its TimeGate and Mementos reside on + another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also + exist in which all these resources are on the same server (for + example, content management systems) or all are on different servers + (for example, 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 + + + + + + + +Van de Sompel, et al. Informational [Page 11] + +RFC 7089 HTTP Memento December 2013 + + + Step 1: The user agent that wants to access a prior state of the + Original Resource issues an HTTP HEAD/GET against URI-R that + has an "Accept-Datetime" HTTP header with a value of the + datetime of the desired state. + + Step 2: The response from URI-R includes an HTTP "Link" header with + a Relation Type of "timegate" pointing at a TimeGate (URI-G) + for the Original Resource. + + Step 3: The user agent starts the datetime negotiation process with + the TimeGate by issuing an HTTP GET request against URI-G + that has an "Accept-Datetime" HTTP header with a value of + the datetime of the desired prior state of the Original + Resource. + + Step 4: The response from URI-G includes a "Location" header + pointing at a Memento (URI-M) for the Original Resource. In + addition, the response contains an HTTP "Link" header with a + Relation Type of "original" pointing at the Original + Resource (URI-R), and an HTTP "Link" header with a Relation + Type of "timemap" pointing at a TimeMap (URI-T). + + Step 5: The user agent issues an HTTP GET request against URI-M. + + Step 6: The response from URI-M includes a "Memento-Datetime" HTTP + header with a value of the archival datetime of the Memento. + It also contains an HTTP "Link" header with a Relation Type + of "original" pointing at the Original Resource (URI-R), + with a Relation Type of "timegate" pointing at a TimeGate + (URI-G) for the Original Resource, and with a Relation Type + of "timemap" pointing at a TimeMap (URI-T) for the Original + Resource. The state that is expressed by the response is + the state the Original Resource had at the archival datetime + expressed in the "Memento-Datetime" header. + + In order to respond to a datetime negotiation request, the server + uses an internal algorithm to select the Memento that best meets the + user agent's datetime preference. The exact nature of the selection + algorithm is at the server's discretion but is intended to be + consistent, for example, always selecting the Memento that is nearest + in time relative to the requested datetime, always selecting the + Memento that is nearest in the past relative to the requested + datetime, etc. + + Due to the sparseness of Mementos in most systems, the value of the + "Memento-Datetime" header returned by a server may differ + (significantly) from the value conveyed by the user agent in "Accept- + Datetime". + + + +Van de Sompel, et al. Informational [Page 12] + +RFC 7089 HTTP Memento December 2013 + + + Although a Memento encapsulates a prior state of an Original + Resource, the entity-body returned in response to an HTTP GET request + issued against a Memento may very well not be byte-to-byte the same + as an entity-body that was previously returned by that Original + Resource. Various reasons exist why there are significant chances + these would be different yet do convey substantially the same + information. These include format migrations as part of a digital + preservation strategy, URI-rewriting as applied by some Web archives, + and the addition of banners as a means to brand Web archives. + + When negotiating in the datetime dimension, the regular content + negotiation dimensions (media type, character encoding, language, and + compression) remain available. It is the TimeGate server's + responsibility to honor (or not) such content negotiation, and in + doing so it MUST always first select a Memento that meets the user + agent's datetime preference, and then consider honoring regular + content negotiation for it. As a result of this approach, the + returned Memento will not necessarily meet the user agent's regular + content negotiation preferences. Therefore, it is RECOMMENDED that + the server provides "memento" links in the HTTP "Link" header + pointing at Mementos that do meet the user agent's regular content + negotiation requests and that have a value for the "Memento-Datetime" + header in the temporal vicinity of the user agent's preferred + datetime value. + + A user agent that engages in datetime negotiation with a resource + typically starts by issuing an HTTP HEAD, not GET, request with an + "Accept-Datetime" header in order to determine how to proceed. This + strategy is related to the existence of various server implementation + patterns as will become clear in Section 4. + + Details about the HTTP interactions involved in datetime negotiation + are provided in Section 4. + +3.2. TimeMaps + + Figure 3 provides a schematic overview of a successful request/ + response chain that shows a user agent obtaining a TimeMap. The + pictorial conventions are the same as the ones used in Figure 2, as + is the scenario. Note that, in addition to a TimeGate, an Original + Resource and a Memento can also provide a link to a TimeMap. + + + + + + + + + + +Van de Sompel, et al. Informational [Page 13] + +RFC 7089 HTTP Memento December 2013 + + + 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 to access a TimeMap for the + Original Resource issues an HTTP HEAD/GET against URI-R. + This can be done with or without an "Accept-Datetime" HTTP + header. + + Step 2: Irrespective of the use of an "Accept-Datetime" HTTP header + in Step 1, the response from URI-R includes an HTTP "Link" + header with a Relation Type of "timegate" pointing at a + TimeGate (URI-G) for the Original Resource. + + Step 3: The user agent issues an HTTP GET request against URI-G. + This can be done with or without an "Accept-Datetime" HTTP + header. + + Step 4: Irrespective of the use of an "Accept-Datetime" HTTP header + in Step 1, the response contains an HTTP "Link" header with + a Relation Type of "timemap" pointing at a TimeMap (URI-T). + + Step 5: The user agent issues an HTTP GET request against URI-T. + + Step 6: The response from URI-T has an entity-body that lists all + Mementos for the Original Resource known to the responding + server, as well as their archival datetimes. + + Details about the content and serialization of TimeMaps are provided + in Section 5. + +4. Datetime Negotiation: HTTP Interactions + + Figure 2 depicts a specific pattern to implement the Memento + framework. Multiple patterns exist, and they can be grouped as + follows: + + o Pattern 1 (Section 4.1) - The Original Resource acts as its own + TimeGate + + o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for + the Original Resource + + + +Van de Sompel, et al. Informational [Page 14] + +RFC 7089 HTTP Memento December 2013 + + + o Pattern 3 (Section 4.3) - The Original Resource is a Fixed + Resource + + o Pattern 4 (Section 4.4) - Mementos without a TimeGate + + Details of the HTTP interactions for common cases for each of those + patterns are provided in Sections 4.1 through 4.4. Appendix A + summarizes the use of the "Vary", "Memento-Datetime", and "Link" + headers in responses from Original Resources, TimeGates, and Mementos + for the various patterns. Special cases are described in + Section 4.5. Note that in the following sections, the HTTP status + code of the responses with an entity-body is shown as "200 OK", but a + series of "206 Partial Content" responses could be substituted. + + Figure 4 shows a user agent that attempts to datetime negotiate with + the Original Resource http://a.example.org/ by including an "Accept- + Datetime" header in its HTTP HEAD request. This initiating request + is the same for Pattern 1 (Section 4.1) through Pattern 3 + (Section 4.3). + + 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 implementation pattern, the Original Resource acts as its own + TimeGate, which means that URI-R and URI-G coincide. Content + management systems and revision control systems can support datetime + negotiation in this way as they are commonly aware of the version + history of their own resources. + + The response to this request when datetime negotiation for this + resource is supported depends on the negotiation style it uses (200- + style or 302-style) and on the existence or absence of a URI-M for + Mementos that is distinct from the URI-R of the associated Original + Resource. The various cases are summarized in the below table, and + the server responses for each are detailed in the remainder of this + section. + + + + + + + + +Van de Sompel, et al. Informational [Page 15] + +RFC 7089 HTTP Memento December 2013 + + + +-------------------+------------+----------+---------+-------------+ + | 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 request of Figure 4 + has a "302 Found" HTTP status code, and the "Location" header conveys + the URI-M of the selected Memento. The use of Memento response + headers and links in the response from URI-R=URI-G is as follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST NOT contain a "Memento-Datetime" header. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + The server's response to the request of Figure 4 is shown in + Figure 5. Note the inclusion of the recommended link to the TimeGate + that, in this case, has a Target IRI that is the URI-R of the + Original Resource. + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 16] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; 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 + + In a subsequent request, shown in Figure 6, the user agent can obtain + the selected Memento by issuing an HTTP GET request against the URI-M + that was provided in the "Location" header. The inclusion of the + "Accept-Datetime" header in this request is not needed but will + typically occur as the user agent is in datetime negotiation mode. + + 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 has a "200 OK" HTTP status code, and the entity-body of + the response contains the representation of the selected Memento. + The use of Memento response headers and links in the response from + URI-M is as follows: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + The server's response to the request of Figure 6 is shown in + Figure 7. Note the provision of the required "original", and the + recommended "timegate" and "timemap" links. The former two point to + + + + + +Van de Sompel, et al. Informational [Page 17] + +RFC 7089 HTTP Memento December 2013 + + + the Original Resource, which acts as its own TimeGate. The latter + has "from" and "until" attributes to indicate the temporal interval + covered by Mementos listed 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: ; rel="original timegate", + + ; 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 + + In this case, the response to the user agent's request of Figure 4 + has a "200 OK" HTTP status code, and the "Content-Location" header + conveys the URI-M of the selected Memento. The use of Memento + response headers and links in the response from URI-R=URI-G is as + follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the selected Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + The server's response to the request of Figure 4 is shown in + Figure 8. Note the provision of optional "memento" links pointing at + the oldest and most recent Memento for the Original Resource known to + the responding server. + + + + + + + + +Van de Sompel, et al. Informational [Page 18] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; rel="original timegate", + + ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", + + ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT", + + ; 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 + + In a subsequent request, which is the same as Figure 4 but with HTTP + GET instead of HEAD, the user agent can obtain the representation of + the selected Memento. It will be provided as the entity-body of a + response that has the same Memento headers as in Figure 8. + +4.1.3. Pattern 1.3 - URI-R=URI-G; 200-Style Negotiation; No Distinct + URI-M + + In this case, the response to the user agent's request of Figure 4 + has a "200 OK" HTTP status code, and it does not contain a "Content- + Location" nor a "Location" header as there is no URI-M of the + selected Memento to convey. The use of Memento response headers and + links in the response from URI-R=URI-G is as follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the selected Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + + + + + +Van de Sompel, et al. Informational [Page 19] + +RFC 7089 HTTP Memento December 2013 + + + The server's response to the request of Figure 4 is shown in + Figure 9. The recommended "timemap" and "timegate" links are + included in addition to 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: ; rel="original timegate", + + ; 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 + + In a subsequent request, which is the same as Figure 4 but with HTTP + GET instead of HEAD, the user agent can obtain the representation of + the selected Memento. It will be provided as the entity-body of a + response that has the same Memento headers as in Figure 9. + +4.2. Pattern 2 - A Remote Resource Acts as a TimeGate for the Original + Resource + + In this implementation pattern, the Original Resource does not act as + its own TimeGate, which means that URI-R and URI-G are different. + This pattern is typically implemented by servers for which the + history of their resources is recorded in remote systems such as Web + archives and transactional archives [Fitch]. But servers that + maintain their own history, such as content management systems and + version control systems, may also implement this pattern, for + example, to distribute the load involved in responding to requests + for current and prior representations of resources between different + servers. + + This pattern is summarized in the below table and is detailed in the + remainder of this section. Three cases exist that differ regarding + the negotiation style that is used by the remote TimeGate and + regarding the existence of a URI-M for Mementos that is distinct from + the URI-G of the TimeGate. + + + + + + + + + +Van de Sompel, et al. Informational [Page 20] + +RFC 7089 HTTP Memento December 2013 + + + +-------------------+------------+----------+---------+-------------+ + | 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 response by the Original Resource to the request shown in + Figure 4 is the same for all three cases. The use of headers and + links in the response from URI-R is as follows: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST NOT contain a "Memento-Datetime" header. + + o 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 to + accommodate situations in which the server is aware of multiple + TimeGates or TimeMaps for the Original Resource. + + Figure 10 shows such a response. Note the absence of an "original" + link as 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: + ; 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 + + + + +Van de Sompel, et al. Informational [Page 21] + +RFC 7089 HTTP Memento December 2013 + + + Once a user agent has obtained the URI-G of a remote TimeGate for the + Original Resource, it can engage in datetime negotiation with that + TimeGate. Figure 11 shows the request issued against the TimeGate, + whereas Sections 4.2.1 through 4.2.3 detail the responses for various + TimeGate implementation patterns. + + 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 + + In case the TimeGate uses a 302 negotiation style, the response to + the user agent's request of Figure 11 has a "302 Found" HTTP status + code, and the "Location" header conveys the URI-M of the selected + Memento. The use of Memento response headers and links in the + response from URI-G is as follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST NOT contain a "Memento-Datetime" header. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + The server's response to the request of Figure 11 is shown in + Figure 12. It contains the mandatory "original" link that points + back to the Original Resource associated with this TimeGate, and it + shows the recommended "timemap" link that includes "from" and "until" + attributes. + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 22] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; rel="original", + + ; 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 + + In a subsequent HTTP GET request, shown in Figure 13, the user agent + can obtain the selected Memento by issuing an HTTP GET request + against the URI-M that was provided in the "Location" header. The + inclusion of the "Accept-Datetime" header in this request is not + needed but will typically occur as the user agent is 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. The use of Memento + response headers and links in the response from URI-M is as follows: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + + + + + +Van de Sompel, et al. Informational [Page 23] + +RFC 7089 HTTP Memento December 2013 + + + The server's response to the request of Figure 13 is shown in + Figure 14. Note the provision of the recommended "timegate" and + "timemap" links. + + 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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 + + In case the TimeGate uses a 200 negotiation style, and each Memento + has a distinct URI-M, the response to the user agent's request of + Figure 11 has a "200 OK" HTTP status code, and the "Content-Location" + header conveys the URI-M of the selected Memento. The use of Memento + response headers and links in the response from URI-G is as follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + The server's response to the request of Figure 11 is shown in + Figure 15. + + + + + + + + + +Van de Sompel, et al. Informational [Page 24] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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 subsequent request, which is the same as Figure 11 but with HTTP + GET instead of HEAD, the user agent can obtain the representation of + the selected Memento. It will be provided as the entity-body of a + response that has the same Memento headers as Figure 15. + +4.2.3. Pattern 2.3 - URI-R<>URI-G; 200-Style Negotiation; No Distinct + URI-M + + In case the TimeGate uses a 200 negotiation style, but Mementos have + no distinct URIs, the response to the user agent's request of + Figure 11 has a "200 OK" HTTP status code, and it does not contain a + "Content-Location" nor "Location" header as there is no URI-M of the + selected Memento to convey. The use of Memento response headers and + links in the response from URI-G is as follows: + + o The "Vary" header MUST be provided, and it MUST include the + "accept-datetime" value. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described in + Section 2.2. + + + + + + + +Van de Sompel, et al. Informational [Page 25] + +RFC 7089 HTTP Memento December 2013 + + + The server's response to the request of 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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 subsequent request, which is the same as Figure 11 but with HTTP + GET instead of HEAD, the user agent can obtain the representation of + the selected Memento. It will be provided as the entity-body of a + response that has the same Memento headers as Figure 16. + +4.3. Pattern 3 - The Original Resource is a Fixed Resource + + This pattern does not involve datetime negotiation with a TimeGate, + but it can be implemented for Original Resources that never change + state or do not change anymore past a certain point in their + existence, meaning that URI-R and URI-M coincide either from the + outset or starting at some point in time. This pattern is summarized + in the below table. Examples are tweets or stable media resources on + news sites. + + +----------+----------------+----------+---------+------------------+ + | Pattern | Original | TimeGate | Memento | Negotiation | + | | Resource | | | Style | + +----------+----------------+----------+---------+------------------+ + | Pattern | URI-R | - | URI-R | - | + | 3 | | | | | + +----------+----------------+----------+---------+------------------+ + + Table 3: Pattern 3 + + + + + + + + +Van de Sompel, et al. Informational [Page 26] + +RFC 7089 HTTP Memento December 2013 + + + Servers that host such resources can support the Memento framework by + treating the stable resource (FixedResource as per + [W3C.gen-ont-20090420]) as a Memento. The use of Memento response + headers and links in responses from such a stable resource is as + follows: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the datetime at which the resource became stable. + Providing this value includes a promise that the resource has not + changed since this datetime and will not change anymore beyond it. + + o 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: ; 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 + + Cases may occur in which a server hosts Mementos but does not expose + a TimeGate for them. This can, for example, be the case if the + server's Mementos result from taking a snapshot of the state of a set + of Original Resources from another server as it is being retired. As + a result, only a single Memento per Original Resource is hosted, + making the introduction of a TimeGate unnecessary. But it may also + be the case for servers that host multiple Mementos for an Original + Resource but consider exposing TimeGates too expensive. In this + case, URI-R and URI-M are distinct, but a TimeGate is absent. This + case is summarized in the below table. + + + + + + +Van de Sompel, et al. Informational [Page 27] + +RFC 7089 HTTP Memento December 2013 + + + +----------+----------------+----------+---------+------------------+ + | Pattern | Original | TimeGate | Memento | Negotiation | + | | Resource | | | Style | + +----------+----------------+----------+---------+------------------+ + | Pattern | URI-R | - | URI-M | - | + | 4 | | | | | + +----------+----------------+----------+---------+------------------+ + + Table 4: Pattern 4 + + Servers that host such Mementos without TimeGates can still support + the Memento framework by providing the appropriate Memento headers + and links. Their use is as follows for a response from URI-M: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST include a "Memento-Datetime" header. Its value + expresses the archival datetime of the Memento. + + o 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. The provision of other links is + encouraged and is subject to the considerations described 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/. + Note the use of links: three links have the URI-M of the Memento as + Target IRI and have respective Relation Types "memento", "first", and + "last". This combination indicates that this is the only Memento for + the Original Resource with Target IRI provided by the "original" link + (http://a.example.org/) of which the server is aware. Note also that + such a response does not imply that there is no server whatsoever + that exposes a TimeGate; it merely means that the responding server + neither provides nor is aware of the location of a TimeGate. + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 28] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; rel="original", + + ; 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 + + Cases exist in which the response from the Original Resource does not + contain a "timegate" link, including: + + o The Original Resource's server does not support the Memento + framework; + + o The Original Resource no longer exists, and the responding server + is not aware of its prior existence; + + o The server that hosted the Original Resource no longer exists. + + In all these cases, the user agent should attempt to determine an + appropriate TimeGate for the Original Resource, either automatically + or interactively supported by the user. + +4.5.2. Server Exists but Original Resource No Longer Does + + Cases exist in which the server knows that an Original Resource used + to exist, but no longer provides a current representation. If there + is a preferred TimeGate for such a discontinued Original Resource, + then the server MUST include a "timegate" link in responses to + requests for it. This may allow access to Mementos for the Original + Resource even if it no longer exists. A server's response to a + request for the discontinued resource http://a.example.org/pic is + illustrated in Figure 19. + + + + + + + + +Van de Sompel, et al. Informational [Page 29] + +RFC 7089 HTTP Memento December 2013 + + + HTTP/1.1 404 Not Found + Date: Thu, 21 Jan 2010 00:02:12 GMT + Server: Apache + Link: + + ; 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 + + The following special cases may occur regarding the "Accept-Datetime" + header when a user agent issues a request against a TimeGate: + + o If the value of the "Accept-Datetime" is either earlier than the + datetime of the first Memento or later than the datetime of the + most recent Memento known to the TimeGate, the first or most + recent Memento MUST be selected, respectively. + + o If the value of the "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. + + o If a user agent issues a request against a TimeGate and fails to + include an "Accept-Datetime" request header, the most recent + Memento SHOULD be selected. + + In all cases, the use of headers and links in responses is as + described for TimeGates in the respective scenarios. + +4.5.4. Memento of a 3XX Response + + Cases exist in which HTTP responses with 3XX status codes are + archived. For example, crawl-based Web archives commonly archive + responses with HTTP status codes "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. The use of other Memento headers + is as described for Mementos in the respective scenarios. + + + + + + +Van de Sompel, et al. Informational [Page 30] + +RFC 7089 HTTP Memento December 2013 + + + 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 in the same manner as it does with HTTP + responses with a 3XX status code that do not have a "Memento- + Datetime" header. + + However, the user agent MUST be aware that the URI that was selected + from the "Location" header of an HTTP response with a 3XX status code + might not be that of a Memento but rather of an Original Resource. + In the latter case, it SHOULD proceed by looking for a Memento of the + selected Original Resource. + + For example, 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 that has as 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 + is a replay of the original response with "Memento-Datetime" and + "Link" headers added, to allow a user agent to understand the + response is a Memento. In Figure 21, the value of the "Location" + header is the same as in the original response; it identifies an + Original Resource. The user agent proceeds with finding a Memento + for this Original Resource. Web archives sometimes overwrite the + value that was originally provided in the "Location" header in order + to point at a Memento they hold of the resource to which the redirect + originally led. This is shown in Figure 22. In this case, 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 + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 31] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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 + + Cases exist in which responses with 4XX and 5XX HTTP status codes are + archived. If the Memento requested by the user agent is an archived + version of such an HTTP response, the server's response MUST have the + same 4XX or 5XX HTTP status code. The use of headers and links in + responses is as described for Mementos in the respective scenarios. + + For example, Figure 23 shows the 404 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 that has as URI-M + http://arxiv.example.net/web/20080411000650/http://a.example.org. + The response to an HTTP HEAD on this URI-M is shown in Figure 24. It + + + + +Van de Sompel, et al. Informational [Page 32] + +RFC 7089 HTTP Memento December 2013 + + + is a replay of the original response with "Memento-Datetime" and + "Link" headers added, to allow a user agent to understand the + response is 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: ; rel="original", + + ; rel="timemap"; type="application/link-format", + + ; 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: + + o Includes a "Memento-Datetime" header that entails a promise that + the response is archived, frozen in time. The value of the header + expresses the archival datetime of the Memento. + + o 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: + + o 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 + + + + +Van de Sompel, et al. Informational [Page 33] + +RFC 7089 HTTP Memento December 2013 + + + their original assignment, and the server MUST NOT change the + value of the "Memento-Datetime" header nor the Target IRI of the + "original" link. + + o 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 others, duplicating a + Web archive at a new location while preserving 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, and thus + 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 of an intermediate resource has an HTTP status code + indicative of HTTP redirection (e.g., 302) and uses Memento headers + and links that allow user agents to recognize that the resource plays + a role in the Memento framework: + + o A "Vary" header that includes an "accept-datetime" value MUST NOT + be provided. + + o The response MUST NOT include a "Memento-Datetime" header. + + o 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 and, if + provided, 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; multiple such redirections can be chained. + + Consider the case where a user agent follows the "timegate" link + provided in Figure 10 and engages in datetime negotiation with the + assumed TimeGate in the manner shown in Figure 11. But instead of + receiving a response as shown in Figure 12, it receives the one shown + below in Figure 25. Such a response is unambiguously recognizable as + coming from an intermediate resource. + + + +Van de Sompel, et al. Informational [Page 34] + +RFC 7089 HTTP Memento December 2013 + + + 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: ; 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 delivering a Memento to a user agent, a Web archive commonly + enhances that Memento's archived content, for example, by including a + banner that provides branding and highlights the archival status of + the Memento. The resources that are involved in providing such + system-specific functionality, many times 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. Doing so allows a user agent to refrain from + attempting to access a Memento for them. In order to achieve 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 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: ; 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 + + + + + +Van de Sompel, et al. Informational [Page 35] + +RFC 7089 HTTP Memento December 2013 + + +5. TimeMaps: Content and Serialization + + A TimeMap is introduced to support retrieving a comprehensive 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: + + o MUST list the URI-R of the Original Resource that the TimeMap is + about; + + o 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; + + o SHOULD list the URI-G of one or more TimeGates for the Original + Resource known to the responding server; + + o SHOULD, for self-containment, list the URI-T of the TimeMap + itself; + + o 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: + + o The Context IRI is set to the anchor parameter, when specified; + + o 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; + + o 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. + + In order to retrieve the link-value serialization of a TimeMap, a + user agent uses an "Accept" request header with a value set to + "application/link-format". This is shown in Figure 27. + + + + +Van de Sompel, et al. Informational [Page 36] + +RFC 7089 HTTP Memento December 2013 + + + 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 + + ;rel="original", + + ; rel="self";type="application/link-format" + ; from="Tue, 20 Jun 2000 18:02:59 GMT" + ; until="Wed, 09 Apr 2008 20:30:51 GMT", + + ; rel="timegate", + + ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" + ; license="http://creativecommons.org/publicdomain/zero/1.0/", + + ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" + ; license="http://creativecommons.org/publicdomain/zero/1.0/", + + ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" + ; license="http://creativecommons.org/publicdomain/zero/1.0/", + + ; 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 + + + + + + + + + + +Van de Sompel, et al. Informational [Page 37] + +RFC 7089 HTTP Memento December 2013 + + +5.1. Special Cases + +5.1.1. Index and Paging TimeMaps + + Cases exist in which a TimeMap points at one or more other TimeMaps: + + o Index TimeMap - A TimeMap can merely point at other TimeMaps and + not list any Mementos itself. This can happen when Mementos are + spread across several archives that share a front-end. An example + is shown in Figure 29. + + o Paging TimeMap - The number of available Mementos can require + introducing multiple TimeMaps that can be paged. An example is + shown in Figure 30. Note that a Paging TimeMap contains links to + other TimeMaps but actually also lists Mementos. + + In both cases, including the "from" and "until" attributes for + "timemap" links is RECOMMENDED as a means to express the temporal + span of Mementos listed in each TimeMap. Note that TimeMaps obtained + by following a "timemap" link can contain links to further TimeMaps. + + ;rel="original", + + ; rel="timegate", + + ; rel="self";type="application/link-format", + + ; rel="timemap";type="application/link-format" + ; from="Wed, 21 Jun 2000 04:41:56 GMT" + ; until="Wed, 09 Apr 2008 20:30:51 GMT", + + ; rel="timemap";type="application/link-format" + ; from="Thu, 10 Apr 2008 20:30:51 GMT" + ; until="Tue, 27 Oct 2009 20:49:54 GMT", + + ; rel="timemap";type="application/link-format" + ; from="Thu, 29 Oct 2009 20:30:51 GMT" + + Figure 29: Index TimeMap + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 38] + +RFC 7089 HTTP Memento December 2013 + + + ;rel="original", + + ; rel="timegate", + + ; rel="self";type="application/link-format" + ; from="Tue, 20 Jun 2000 18:02:59 GMT" + ; until="Wed, 09 Apr 2008 20:30:51 GMT", + + ; rel="timemap";type="application/link-format" + ; from="Thu, 10 Apr 2008 20:30:51 GMT" + ; until="Tue, 27 Oct 2009 20:49:54 GMT", + + ; rel="timemap";type="application/link-format" + ; from="Thu, 29 Oct 2009 20:30:51 GMT" + ; until="Fri, 31 Aug 2012 12:22:34 GMT" + + ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", + + ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT", + + ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT", + ... + + Figure 30: Paging TimeMap + +5.1.2. Mementos for TimeMaps + + A TimeMap itself can act as an Original Resource for which a TimeGate + and Mementos may exist. Hence, the response from a TimeMap could + include a "timegate" link to a TimeGate via which prior TimeMap + versions are available. And, in cases where URI-T=URI-R=URI-G (a + TimeMap is an Original Resource that acts as its own TimeGate), an + "original" link pointing at the TimeMap URI-T would be included. + + Therefore, caution is required in cases where a TimeMap for an + Original Resource wants to explicitly express in a "Link" header for + which Original Resource it is a TimeMap. It can do so by including a + "timemap" link that has 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 that has + http://arxiv.example.net/timemap/http://a.example.org as URI-T. This + TimeMap provides information about Mementos for the Original Resource + that has http://a.example.org as URI-R. The response includes an + "original" link pointing to the Original Resource that this TimeMap + is about. Note the use of the "anchor" attribute in this link to + convey the URI-R of that Original Resource. + + + +Van de Sompel, et al. Informational [Page 39] + +RFC 7089 HTTP Memento December 2013 + + + HTTP/1.1 200 OK + Date: Thu, 21 Jan 2010 00:06:50 GMT + Server: Apache + Link: + ; 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: + + o Header field name: Accept-Datetime + o Applicable protocol: "http" (RFC 2616) + o Status: informational + o Author/Change controller: Herbert Van de Sompel, Los Alamos + National Laboratory, hvdsomp@gmail.com + o Specification document(s): this document + + o Header field name: Memento-Datetime + o Applicable protocol: "http" (RFC 2616) + o Status: informational + o Author/Change controller: Herbert Van de Sompel, Los Alamos + National Laboratory, hvdsomp@gmail.com + o 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: + + o Relation Name: original + o Description: The Target IRI points to an Original Resource. + o Reference: this document + o 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. + + + + + +Van de Sompel, et al. Informational [Page 40] + +RFC 7089 HTTP Memento December 2013 + + + o Relation Name: timegate + o Description: The Target IRI points to a TimeGate for an Original + Resource. + o Reference: this document + o 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. + + o Relation Name: timemap + o Description: The Target IRI points to a TimeMap for an Original + Resource. + o Reference: this document + o Notes: A TimeMap for an Original Resource is a resource from which + a list of URIs of Mementos of the Original Resource is available. + + o Relation Name: memento + o Description: The Target IRI points to a Memento, a fixed resource + that will not change state anymore. + o Reference: this document + o Notes: A Memento for an Original Resource is a resource that + encapsulates a prior state of the Original Resource. + +7. Security Considerations + + Provision of a "timegate" HTTP "Link" header in responses to requests + for an Original Resource that is protected (e.g., 401 or 403 HTTP + response codes) is OPTIONAL. The inclusion of this Link when + requesting authentication is at the server's discretion; cases may + exist in which a server protects the current state of a resource, but + supports open access to prior states and thus chooses to supply this + HTTP "Link" header. Conversely, the server may choose to not + advertise the TimeGate URIs (e.g., they exist in an intranet archive) + for unauthenticated requests. + + The veracity of archives and the relationships between Original + Resources and Mementos is beyond the scope of this document. Even in + the absence of malice, it is possible for separate archives to have + different Mementos for the same Original Resource at the same + datetime if the state of the Original Resource was dependent 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. + + + + + + + +Van de Sompel, et al. Informational [Page 41] + +RFC 7089 HTTP Memento December 2013 + + +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 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, + . + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + + + + +Van de Sompel, et al. Informational [Page 42] + +RFC 7089 HTTP Memento December 2013 + + + [W3C.REC-aww-20041215] + Jacobs, I. and N. Walsh, "Architecture of the World Wide + Web", December 2004, . + + [W3C.gen-ont-20090420] + Berners-Lee, T., "Architecture of the World Wide Web", + April 2009, . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 43] + +RFC 7089 HTTP Memento December 2013 + + +Appendix A. Use of Headers and Relation Types per Pattern + + +-----------------+-----------------+----------+----------+---------+ + | 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.) + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 44] + +RFC 7089 HTTP Memento December 2013 + + + +-----------------+-----------------+----------+----------+---------+ + | 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.) + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 45] + +RFC 7089 HTTP Memento December 2013 + + + +-----------------+-----------------+----------+----------+---------+ + | 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.) + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 46] + +RFC 7089 HTTP Memento December 2013 + + + +-----------------+-----------------+----------+----------+---------+ + | 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.) + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 47] + +RFC 7089 HTTP Memento December 2013 + + + +-----------------+-----------------+----------+----------+---------+ + | 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) | | | | + | | | | | | + +-----------------+-----------------+----------+----------+---------+ +(cont.) + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 48] + +RFC 7089 HTTP Memento December 2013 + + + +-----------------+-----------------+----------+----------+---------+ + | 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 + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 49] + +RFC 7089 HTTP Memento December 2013 + + +Authors' Addresses + + 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/ + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 50] + -- cgit v1.2.3