| Internet Engineering Task Force | H. VandeSompel |
| Internet-Draft | Los Alamos National Laboratory |
| Intended status: Informational | M.L. Nelson |
| Expires: March 13, 2014 | Old Dominion University |
| R.D. Sanderson | |
| Los Alamos National Laboratory | |
| September 09, 2013 |
HTTP framework for time-based access to resource states -- Memento
draft-vandesompel-memento-09
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2014.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This specification uses the terms "resource", "request", "response", "entity-body", "content negotiation", "user agent", "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:
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:
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 non-existence (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/ :
Mementos for Original Resource http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol :
Mementos for Original Resource http://www.w3.org/TR/webarch/ :
In the abstract, the Memento framework introduces a mechanism to access versions of web resources that:
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 [I-D.masinter-dated-uri].
2. A "bridge" from the present to the past, consisting of:
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.
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.
The Memento framework operates at the level of HTTP request and response headers. It introduces two new headers ("Accept-Datetime", "Memento-Datetime") and introduces new values for two existing headers ("Vary", "Link"). Other HTTP headers are present or absent in Memento response/request cycles as specified by [RFC2616].
The "Accept-Datetime" request header is trasnmitted 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 the BNF in Figure 1. 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
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 negotation 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
The Memento framework defines the "original", "timegate", "timemap", and "memento" Relation Types to convey typed links among Original Resources, TimeGates, Mementos, and TimeMaps. The 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", "successor-version" as detailed in [RFC5988] and [RFC5829].
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.
"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.
"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.
"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 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.
"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.
The Memento framework defines two complementary approaches to support obtaining representations of prior states of an Original Resource:
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 [Pattern2.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
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 intented 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".
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 the below.
Details about the HTTP interactions involved in datetime negotation are provided in Section 4.
Figure 3 provides a schematic overview of a successful request/response chain that shows a user agent obtaining a TimeMap. The pictoral 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.
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
Details about the content and serialization of TimeMaps are provided in Section 5.
Figure 2 depicts a specific pattern to implement the Memento framework. Multiple patterns exist and they can be grouped as follows:
Details of the HTTP interactions for common cases for each of those patterns are provided in Section 4.1 through Section 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 attemtps 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 [Pattern1] through Pattern 3 [Pattern3].
HEAD / HTTP/1.1 Host: a.example.org Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT Connection: close
Figure 4: User Agent Attempts Datetime Negotiation With Original Resource
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.
| Pattern | Original Resource | TimeGate | Memento | Negotiation Style |
|---|---|---|---|---|
| Pattern 1.1 [Pattern1.1] | URI-R | URI-R | URI-M | 302 |
| Pattern 1.2 [Pattern1.2] | URI-R | URI-R | URI-M | 200 |
| Pattern 1.3 [Pattern1.3] | URI-R | URI-R | URI-R | 200 |
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:
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.
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=20010911203610 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=20010911203610 HTTP/1.1 Host: a.example.org Accept-Datetime: Tue, 11 Sep 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:
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 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, 11 Sep 2001 20: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
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:
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.
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=20010911203610 Memento-Datetime: Tue, 11 Sep 2001 20: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: 2312 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.
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 "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:
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, 11 Sep 2001 20: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: 0 Content-Type: text/plain; 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.
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.
| Pattern | Original Resource | TimeGate | Memento | Negotiation Style |
|---|---|---|---|---|
| Pattern 2.1 [Pattern2.1] | URI-R | URI-G | URI-M | 302 |
| Pattern 2.2 [Pattern2.2] | URI-R | URI-G | URI-M | 200 |
| Pattern 2.3 [Pattern2.3] | URI-R | URI-G | URI-G | 200 |
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:
Figure 10 shows such a response. Note the absence of an "original" link as the responding resource is neither a TimeGate or a Memento.
HTTP/1.1 200 OK Date: Thu, 21 Jan 2010 00:02:12 GMT Server: Apache Link: <http://arxiv.example.net/timegate/http://a.example.org/> ; rel="timegate" Content-Length: 255 Connection: close Content-Type: text/html; charset=iso-8859-1
Figure 10: Response from URI-R<>URI-G for Pattern 2
Once a user agent has obtained the URI-G of a remote TimeGate for the Original Resource it can engage in datetime negotation with that TimeGate. Figure 11 shows the request issued against the TimeGate whereas Section 4.2.1 through Section 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, 11 Sep 2001 20:35:00 GMT Connection: close
Figure 11: User Agent Engages in Datetime Negotiation With Remote TimeGate
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:
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.
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/20010911203610/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/20010911203610/http://a.example.org/ HTTP/1.1 Host: arxiv.example.net/ Accept-Datetime: Tue, 11 Sep 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:
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: Tue, 11 Sep 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: 23364 Content-Type: text/html;charset=utf-8 Connection: close
Figure 14: Response from URI-M for Pattern 2.1
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:
The server's response to the request of Figure 11 is shown in Figure 15.
HTTP/1.1 200 OK Date: Thu, 21 Jan 2010 00:09:40 GMT Server: Apache-Coyote/1.1 Vary: accept-datetime Content-Location: http://arxiv.example.net/web/20010911203610/http://a.example.org/ Memento-Datetime: Tue, 11 Sep 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: 23364 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.
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:
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: Tue, 11 Sep 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: 23364 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.
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 Resource | TimeGate | Memento | Negotiation Style |
|---|---|---|---|---|
| Pattern 3 | URI-R | - | URI-R | - |
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:
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 20th 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: 0 Content-Type: text/plain; charset=UTF-8 Connection: close
Figure 17: Response from URI-R=URI-M for Pattern 3
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.
| Pattern | Original Resource | TimeGate | Memento | Negotiation Style |
|---|---|---|---|---|
| Pattern 4 | URI-R | - | URI-M | - |
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:
Figure 18 shows a response to an HTTP HEAD request for the Memento with URI-M http://arxiv.example.net/web/20010911203610/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/) that the server is aware of. 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.
HTTP/1.1 200 OK Date: Thu, 21 Jan 2010 00:09:40 GMT Server: Apache-Coyote/1.1 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT Link: <http://a.example.org/>; rel="original", <http://arxiv.example.net/web/20010911203610/http://a.example.org/> ; rel="first last memento" ; datetime="Tue, 11 Sep 2001 20:36:10 GMT" Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Connection: close
Figure 18: Response from URI-M<>URI-R for Pattern 4
Cases exist in which the response from the Original Resource does not contain a "timegate" link, including:
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.
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.
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 Connection: close Content-Type: text/html; charset=iso-8909-1
Figure 19: Response from an Original Resource that not longer exists
The following special cases may occur regarding the "Accept-Datetime" header when a user agent issues a request against a TimeGate:
In all cases, the use of headers and links in responses is as described for TimeGates in the respective scenarios.
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.
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
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
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 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: 0 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: 0 Content-Type: text/plain; charset=UTF-8 Connection: close
Figure 24: Response is a Memento of a 404
A response to an HTTP HEAD/GET request issued against a Memento:
Both the "Memento-Datetime" header and the "original" link MUST be "sticky" in the following ways:
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 to recognize that the resource plays a role in the Memento framework:
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 umabiguosuly recognizable as coming from an intermediate resource.
HTTP/1.1 302 Found Date: Thu, 21 Jan 2010 00:06:50 GMT Server: Apache Location: http://arxiv.example.net/new-timegate/http://a.example.org/ Link: <http://a.example.org>; rel="original" Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Connection: close
Figure 25: Redirecting Resource redirects to a TimeGate
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 a 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 a 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 a HTTP HEAD request from a resource excluded from datetime negotiation
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:
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:
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.
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
Cases exist in which a TimeMap points at one or more other TimeMaps:
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
<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
A TimeMap can itself 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.
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
This memo requires IANA to register the Accept-Datetime and Memento-Datetime HTTP headers defined in Section 2.1.1 in the appropriate IANA registry.
This memo requires IANA to register the Relation Types "original", "timegate", "timemap", and "memento" defined in Section 2.2 in the appropriate IANA registry.
This memo requires IANA to register the "datetime" and "license" attributes for the "memento" Relation Type, as defined in Section 2.2.4, in the appropriate IANA registry.
This memo requires IANA to register the "from" and "until" attributes for the "timemap" Relation Type, as defined in Section 2.2.4, in the appropriate IANA registry.
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 a "timegate" 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.
v09 2013-09-09 HVDS MLN RS draft-vandesompel-memento-09
v08 2013-07-08 HVDS MLN RS draft-vandesompel-memento-08
v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07
v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06
v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05
v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel-memento-00
v00 2010-10-19 HVDS MLN RS Limited circulation version
2010-07-22 HVDS MLN First internal version
The Memento effort is funded by the Library of Congress. Many thanks to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers, James Anderson, Tim Starling, Martin Klein, 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, Ilya Kreymer for implementations that informed the specification.
| [RFC1123] | Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. |
| [I-D.masinter-dated-uri] | Masinter, L., "The 'tdb' and 'duri' URI schemes, based on dated URIs", Internet-Draft draft-masinter-dated-uri-10, January 2012. |
| [W3C.gen-ont-20090420] | Berners-Lee, , "Architecture of the World Wide Web", April 2009. |
| [W3C.REC-aww-20041215] | Jacobs, and Walsh, "Architecture of the World Wide Web", December 2004. |
| [Fitch] | Fitch, , "Web site archiving - an approach to recording every materially different response produced by a website", July 2003. |
| Response Header | Pattern | Original Resource | TimeGate | Memento |
|---|---|---|---|---|
| Vary: accept-datetime | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.2] | 1 | 1 | 0 |
| Pattern 1.3 [Pattern1.3] | 1 | 1 | 1 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | 0 | 1 | 0 | |
| Pattern 2.3 [Pattern2.3] | 0 | 1 | 1 | |
| Pattern 3 [Pattern3] | 1 | NA | 1 | |
| Pattern 4 [Pattern4] | 0 | NA | 1 | |
| Memento-Datetime | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.1] | 0 | 0 | 1 |
| Pattern 1.3 [Pattern1.3] | 1 | 1 | 1 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | 0 | 0 | 1 | |
| Pattern 2.3 [Pattern2.3] | 0 | 1 | 1 | |
| Pattern 3 [Pattern3] | 1 | NA | 1 | |
| Pattern 4 [Pattern4] | 0 | NA | 1 | |
| Link | ||||
| rel="original" | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.1] | 0 | 1 | 1 |
| Pattern 1.3 [Pattern1.3] | 1 | 1 | 1 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | 0 | 1 | 1 | |
| Pattern 2.3 [Pattern2.3] | 0 | 1 | 1 | |
| Pattern 3 [Pattern3] | 1 | NA | 1 | |
| Pattern 4 [Pattern4] | 0 | NA | 1 | |
| rel="timegate" | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.1] | >=0 | >=0 | >=0 |
| Pattern 1.3 [Pattern1.3] | >=0 | >=0 | >=0 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | >=0 | 0 | >=0 | |
| Pattern 2.3 [Pattern2.3] | >=0 | >=0 | >=0 | |
| Pattern 3 [Pattern3] | NA | NA | NA | |
| Pattern 4 [Pattern4] | NA | NA | NA | |
| rel="timemap" | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.1] | >=0 | >=0 | >=0 |
| Pattern 1.3 [Pattern1.3] | >=0 | >=0 | >=0 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | >=0 | >=0 | >=0 | |
| Pattern 2.3 [Pattern2.3] | >=0 | >=0 | >=0 | |
| Pattern 3 [Pattern3] | >=0 | NA | >=0 | |
| Pattern 4 [Pattern4] | >=0 | NA | >=0 | |
| rel="memento" | Pattern 1.1 [Pattern1.1] ; Pattern 1.2 [Pattern1.1] | >=0 | >=0 | >=0 |
| Pattern 1.3 [Pattern1.3] | >=0 | >=0 | >=0 | |
| Pattern 2.1 [Pattern2.1] ; Pattern 2.2 [Pattern2.2] | >=0 | >=0 | >=0 | |
| Pattern 2.3 [Pattern2.3] | >=0 | >=0 | >=0 | |
| Pattern 3 [Pattern3] | >=0 | NA | >=0 | |
| Pattern 4 [Pattern4] | >=0 | NA | >=0 |