summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7089.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7089.txt')
-rw-r--r--doc/rfc/rfc7089.txt2803
1 files changed, 2803 insertions, 0 deletions
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: <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
+
+ 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: <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
+
+ 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: <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
+
+ 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: <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
+
+ 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: <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
+
+
+
+
+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: <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
+
+ 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: <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
+
+ 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: <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 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: <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 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: <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
+
+ 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: <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
+
+ 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:
+ <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
+
+ 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: <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
+
+ 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: <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:
+
+ 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: <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 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: <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
+
+
+
+
+
+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
+
+ <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
+
+
+
+
+
+
+
+
+
+
+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.
+
+ <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
+
+
+
+
+
+
+
+
+
+
+
+
+Van de Sompel, et al. Informational [Page 38]
+
+RFC 7089 HTTP Memento December 2013
+
+
+ <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
+
+ 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: <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:
+
+ 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,
+ <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.
+
+
+
+
+
+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, <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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+