idnits 2.17.1
draft-vandesompel-memento-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 09, 2013) is 3944 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 1917, but no explicit
reference was found in the text
== Unused Reference: 'RFC4287' is defined on line 1920, but no explicit
reference was found in the text
== Unused Reference: 'RFC5785' is defined on line 1923, but no explicit
reference was found in the text
== Unused Reference: 'RFC6415' is defined on line 1933, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615)
** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288)
Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force H. VandeSompel
3 Internet-Draft Los Alamos National Laboratory
4 Intended status: Informational M. Nelson
5 Expires: January 10, 2014 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 July 09, 2013
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-08
13 Abstract
15 The HTTP-based Memento framework bridges the present and past Web. It
16 facilitates obtaining representations of prior states of a given
17 resource by introducing datetime negotiation and TimeMaps. Datetime
18 negotiation is a variation on content negotiation that leverages the
19 given resource's URI and a user agent's preferred datetime. TimeMaps
20 are lists that enumerate URIs of resources that encapsulate prior
21 states of the given resource. The framework also facilitates
22 recognizing a resource that encapsulates a frozen prior state of
23 another resource.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on January 10, 2014.
42 Copyright Notice
44 Copyright (c) 2013 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
62 1.3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. HTTP headers, Link Relation Types . . . . . . . . . . . . . . 6
64 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 6
65 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 6
66 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . 7
67 2.1.3. Link . . . . . . . . . . . . . . . . . . . . . . . . 8
68 2.2. Link Relation Types . . . . . . . . . . . . . . . . . . . 8
69 2.2.1. Link Relation Type "original" . . . . . . . . . . . . 8
70 2.2.2. Link Relation Type "timegate" . . . . . . . . . . . . 8
71 2.2.3. Link Relation Type "timemap" . . . . . . . . . . . . 9
72 2.2.4. Link Relation Type "memento" . . . . . . . . . . . . 9
73 3. Overview of the Memento Framework . . . . . . . . . . . . . . 10
74 3.1. Datetime Negotiation . . . . . . . . . . . . . . . . . . 10
75 3.2. TimeMaps . . . . . . . . . . . . . . . . . . . . . . . . 13
76 4. Datetime Negotiation: HTTP Interactions . . . . . . . . . . . 14
77 4.1. Pattern 1 - The Original Resource acts as its own
78 TimeGate . . . . . . . . . . . . . . . . . . . . . . . . 15
79 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ;
80 distinct URI-M for Mementos . . . . . . . . . . . . . 15
81 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ;
82 distinct URI-M for Mementos . . . . . . . . . . . . . 17
83 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ;
84 no distinct URI-M for Mementos . . . . . . . . . . . 18
85 4.2. Pattern 2 - A remote resource acts as a TimeGate for the
86 Original Resource . . . . . . . . . . . . . . . . . . . . 19
87 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ;
88 distinct URI-M for Mementos . . . . . . . . . . . . . 21
89 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ;
90 distinct URI-M for Mementos . . . . . . . . . . . . . 23
91 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ;
92 no distinct URI-M for Mementos . . . . . . . . . . . 24
93 4.3. Pattern 3 - The Original Resource is a Fixed Resource . . 25
94 4.4. Pattern 4 - Mementos without a TimeGate . . . . . . . . . 26
95 4.5. Special Cases . . . . . . . . . . . . . . . . . . . . . . 27
96 4.5.1. Original Resource provides no "timegate" link . . . . 27
97 4.5.2. Server exists but Original Resource no longer does . 27
98 4.5.3. Issues with Accept-Datetime . . . . . . . . . . . . . 28
99 4.5.4. Memento of a 3XX response . . . . . . . . . . . . . . 28
100 4.5.5. Memento of responses with 4XX or 5XX HTTP status
101 codes . . . . . . . . . . . . . . . . . . . . . . . . 30
102 4.5.6. Sticky "Memento-Datetime" value for Mementos . . . . 31
103 4.5.7. Intermediate Resources . . . . . . . . . . . . . . . 31
104 4.5.8. Resources excluded from datetime negotiation . . . . 32
105 5. TimeMaps: Content and Serialization . . . . . . . . . . . . . 33
106 5.1. Special Cases . . . . . . . . . . . . . . . . . . . . . . 35
107 5.1.1. Index and Paging TimeMaps . . . . . . . . . . . . . . 35
108 5.1.2. Mementos for TimeMaps . . . . . . . . . . . . . . . . 36
109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
111 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38
112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
114 10.1. Normative References . . . . . . . . . . . . . . . . . . 41
115 10.2. Informative References . . . . . . . . . . . . . . . . . 42
116 Appendix A. Appendix: Use of Headers and Relation Types per
117 Pattern . . . . . . . . . . . . . . . . . . . . . . 42
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
120 1. Introduction
122 1.1. Terminology
124 This specification uses the terms "resource", "request", "response",
125 "entity-body", "content negotiation", "user agent", "server" as
126 described in [RFC2616], and it uses the terms "representation" and
127 "resource state" as described in [W3C.REC-aww-20041215].
129 In addition, the following terms specific to the Memento framework
130 are introduced:
132 o Original Resource: An Original Resource is a resource that exists
133 or used to exist, and for which access to one of its prior states
134 may be required.
136 o Memento: A Memento for an Original Resource is a resource that
137 encapsulates a prior state of the Original Resource. A Memento
138 for an Original Resource as it existed at time T is a resource
139 that encapsulates the state the Original Resource had at time T.
141 o TimeGate: A TimeGate for an Original Resource is a resource that
142 is capable of datetime negotiation to support access to prior
143 states of the Original Resource.
145 o TimeMap: A TimeMap for an Original Resource is a resource from
146 which a list of URIs of Mementos of the Original Resource is
147 available.
149 1.2. Notational Conventions
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
153 document are to be interpreted as described in [RFC2119].
155 When needed for extra clarity, the following conventions are used:
157 o URI-R is used to denote the URI of an Original Resource.
159 o URI-G is used to denote the URI of a TimeGate.
161 o URI-M is used to denote the URI of a Memento.
163 o URI-T is used to denote the URI of a TimeMap.
165 1.3. Purpose
167 The state of an Original Resource may change over time.
168 Dereferencing its URI at any specific moment yields a response that
169 reflects the resource's state at that moment: a representation of the
170 resource's state (e.g. "200 OK" HTTP status code), an indication of
171 its non-existence (e.g. "404 Not Found" HTTP status code), a relation
172 to another resource (e.g. "302 Found" HTTP status code), etc.
173 However, responses may also exist that reflect prior states of an
174 Original Resource: a representation of a prior state of the Original
175 Resource, an indication that the Original Resource did not exist at
176 some time in the past, a relation that the Original Resource had to
177 another resource at some time in the past, etc. Mementos that
178 provide such responses exist in web archives, content management
179 systems, or revision control systems, among others. For any given
180 Original Resource several Mementos may exist, each one reflecting a
181 frozen prior state of the Original Resource.
183 Examples are:
185 Mementos for Original Resource http://www.ietf.org/ :
187 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
189 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
190 www.ietf.org/
192 Mementos for Original Resource http://en.wikipedia.org/wiki/
193 Hypertext_Transfer_Protocol :
195 o http://en.wikipedia.org/w/
196 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
198 o http://en.wikipedia.org/w/
199 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
201 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
202 wiki/Hypertext_Transfer_Protocol
204 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
206 o http://www.w3.org/TR/2004/PR-webarch-20041105/
208 o http://www.w3.org/TR/2002/WD-webarch-20020830/
210 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
211 www.w3.org/TR/webarch/
213 In the abstract, the Memento framework introduces a mechanism to
214 access versions of web resources that:
216 o Is fully distributed in the sense that resource versions may
217 reside on multiple servers, and that any such server is likely
218 only aware of the versions it holds;
220 o Uses the global notion of datetime as a resource version indicator
221 and access key;
223 o Leverages the following primitives of [W3C.REC-aww-20041215]:
224 resource, resource state, representation, content negotiation, and
225 link.
227 The core components of Memento's mechanism to access resource
228 versions are:
230 1. The abstract notion of the state of an Original Resource (URI-R)
231 as it existed at datetime T. Note the relationship with the ability
232 to identify the state of a resource at datetime T by means of a URI
233 as intended by the proposed Dated URI scheme
234 [I-D.masinter-dated-uri].
236 2. A "bridge" from the present to the past, consisting of:
238 o The existence of a TimeGate (URI-G), which is aware of (at least
239 part of the) version history of the Original Resource (URI-R);
241 o The ability to negotiate in the datetime dimension with that
242 TimeGate (URI-G), as a means to access the state that the Original
243 Resource (URI-R) had at datetime T.
245 3. A "bridge" from the past to the present, consisting of an
246 appropriately typed link from a Memento (URI-M), which encapsulates
247 the state the Original Resource (URI-R) had at datetime T, to the
248 Original Resource (URI-R).
250 4. The existence of a TimeMap (URI-T) from which a list of all
251 Mementos that encapsulate a prior state of the Original Resource
252 (URI-R) can be obtained.
254 This document is concerned with specifying an instantiation of these
255 abstractions for resources that are identified by HTTP(S) URIs.
257 2. HTTP headers, Link Relation Types
259 The Memento framework is concerned with HEAD and GET interactions
260 with Original Resources, TimeGates, Mementos, and TimeMaps that are
261 identified by HTTP or HTTPS URIs. Details are only provided for
262 resources identified by HTTP URIs but apply similarly to those with
263 HTTPS URIs.
265 2.1. HTTP Headers
267 The Memento framework operates at the level of HTTP request and
268 response headers. It introduces two new headers ("Accept-Datetime",
269 "Memento-Datetime") and introduces new values for two existing
270 headers ("Vary", "Link"). Other HTTP headers are present or absent
271 in Memento response/request cycles as specified by [RFC2616].
273 2.1.1. Accept-Datetime, Memento-Datetime
275 The "Accept-Datetime" request header is trasnmitted by a user agent
276 to indicate it wants to access a past state of an Original Resource.
277 To that end, the "Accept-Datetime" header is conveyed in an HTTP
278 request issued against a TimeGate for an Original Resource, and its
279 value indicates the datetime of the desired past state of the
280 Original Resource.
282 Example of an "Accept-Datetime" request header:
284 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
286 The "Memento-Datetime" response header is used by a server to
287 indicate that a response reflects a prior state of an Original
288 Resource. Its value expresses the datetime of that state. The URI
289 of the Original Resource for which the response reflects a prior
290 state is provided as the Target IRI of a link provided in the HTTP
291 "Link" header that has a Relation Type of "original" (see
292 Section 2.2).
294 The presence of a "Memento-Datetime" header and associated value for
295 a given response constitutes a promise that the resource state
296 reflected in the response will no longer change (see Section 4.5.6).
298 Example of a "Memento-Datetime" response header:
300 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
302 Values for the "Accept-Datetime" and "Memento-Datetime" headers
303 consist of a MANDATORY datetime expressed according to the [RFC1123]
304 format, which is formalized by the rfc1123-date construction rule of
305 the BNF in Figure 1. The datetime is case-sensitive with names for
306 days and months exactly as shown in the wkday and month construction
307 rules of the BNF, respectively. The datetime MUST be represented in
308 Greenwich Mean Time (GMT).
310 accept-dt-value = rfc1123-date
311 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
312 date1 = 2DIGIT SP month SP 4DIGIT
313 ; day month year (e.g., 20 Mar 1957)
314 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
315 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
316 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
317 "Sun"
318 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
319 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
321 Figure 1: BNF for the datetime format
323 2.1.2. Vary
325 Generally, the "Vary" header is used in HTTP responses to indicate
326 the dimensions in which content negotiation is possible. In the
327 Memento framework, a TimeGate uses the "Vary" header with a value
328 that includes "accept-datetime" to convey that datetime negotation is
329 possible.
331 For example, this use of the "Vary" header indicates that datetime is
332 the only dimension in which negotiation is possible:
334 Vary: accept-datetime
336 The use of the "Vary" header in this example shows that both datetime
337 negotiation, and media type content negotiation are possible:
339 Vary: accept-datetime, accept
341 2.1.3. Link
343 The Memento framework defines the "original", "timegate", "timemap",
344 and "memento" Relation Types to convey typed links among Original
345 Resources, TimeGates, Mementos, and TimeMaps. The are defined in
346 Section 2.2, below. In addition, existing Relation Types may be
347 used, for example, to support navigating among Mementos. Examples
348 are "first", "last", "prev", "next", "predecessor-version",
349 "successor-version" as detailed in [RFC5988] and [RFC5829].
351 2.2. Link Relation Types
353 This section introduces the Relation Types used in the Memento
354 framework. They are defined in a general way and their use in HTTP
355 "Link" Headers [RFC5988] is described in detail. The use of these
356 Relation Types in TimeMaps is described in Section 5.
358 2.2.1. Link Relation Type "original"
360 "original" -- A link with an "original" Relation Type is used to
361 point from a TimeGate or a Memento to its associated Original
362 Resource.
364 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
365 issued against a TimeGate or a Memento MUST include exactly one link
366 with an "original" Relation Type in their HTTP "Link" header.
368 2.2.2. Link Relation Type "timegate"
370 "timegate" -- A link with a "timegate" Relation Type is used to point
371 from the Original Resource, as well as from a Memento associated with
372 the Original Resource, to a TimeGate for the Original Resource.
374 Use in HTTP "Link" headers: If there is a TimeGate associated with an
375 Original Resource or Memento that is preferred for use, then
376 responses to HTTP HEAD/GET requests issued against these latter
377 resources MUST include a link with a "timegate" Relation Type in
378 their HTTP "Link" header. Since multiple TimeGates can exist for any
379 Original Resource, multiple "timegate" links MAY occur, each with a
380 distinct Target IRI.
382 2.2.3. Link Relation Type "timemap"
384 "timemap" -- A link with a "timemap" Relation Type is used to point
385 from a TimeGate or a Memento associated with an Original Resource, as
386 well as from the Original Resource itself, to a TimeMap for the
387 Original Resource.
389 Attributes: A link with a "timemap" Relation Type SHOULD use the
390 "type" attribute to convey the mime type of the TimeMap
391 serialization. The "from" and "until" attributes may be used to
392 express the start and end of the temporal interval covered by
393 Mementos listed in the TimeMap. That is, the linked TimeMap will not
394 contain Mementos with archival datetimes outside of the expressed
395 temporal interval. Attempts SHOULD be made to convey this interval
396 as accurately as possible. The value for the these attributes MUST
397 be a datetime expressed according to the rfc1123-date construction
398 rule of the BNF in Figure 1 and it MUST be represented in Greenwich
399 Mean Time (GMT).
401 Use in HTTP "Link" headers: If there is a TimeMap associated with an
402 Original Resource, a TimeGate or a Memento that is preferred for use,
403 then responses to HTTP HEAD/GET requests issued against these latter
404 resources MUST include a link with a "timemap" Relation Type in their
405 HTTP "Link" header. Multiple such links, each with a distinct Target
406 IRI, MAY be expressed as a means to point to different TimeMaps or to
407 different serializations of the same TimeMap. In all cases, use of
408 the "from" and "until" attributes is OPTIONAL.
410 2.2.4. Link Relation Type "memento"
412 "memento" -- A link with a "memento" Relation Type is used to point
413 from a TimeGate or a Memento for an Original Resource, as well as
414 from the Original Resource itself, to a Memento for the Original
415 Resource.
417 Attributes: A link with a "memento" Relation Type MUST include a
418 "datetime" attribute with a value that matches the "Memento-Datetime"
419 of the Memento that is the target of the link; that is, the value of
420 the "Memento-Datetime" header that is returned when the URI of the
421 linked Memento is dereferenced. The value for the "datetime"
422 attribute MUST be a datetime expressed according to the rfc1123-date
423 construction rule of the BNF in Figure 1 and it MUST be represented
424 in Greenwich Mean Time (GMT). This link MAY include a "license"
425 attribute to associate a license with the Memento; the value for the
426 "license" attribute MUST be a URI.
428 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
429 issued against an Original Resource, a TimeGate and a Memento MAY
430 include links in their HTTP "Link" headers with a "memento" Relation
431 Type. For responses in which a Memento is selected, the provision of
432 navigational links that lead to Mementos other than the selected one
433 can be beneficial to the user agent. Of special importance are links
434 that lead to the temporally first and last Memento known to the
435 responding server, as well as links leading to Mementos that are
436 temporally adjacent to the selected one.
438 3. Overview of the Memento Framework
440 The Memento framework defines two complementary approaches to support
441 obtaining representations of prior states of an Original Resource:
443 o Datetime Negotiation: Datetime negotiation is a variation on
444 content negotiation by which a user agent expresses a datetime
445 preference pertaining to the representation of an Original
446 Resource, instead of, for example, a media type preference. Based
447 on the responding server's knowledge of the past of the Original
448 Resource, it selects a Memento of the Original Resource that best
449 meets the user agent's datetime preference. An overview is
450 provided in Section 3.1; details are in Section 4.
452 o TimeMaps: A TimeMap is a resource from which a list can be
453 obtained that provides a comprehensive overview of the past of an
454 Original Resource. A server makes a TimeMap available that
455 enumerates all Mementos that the server is aware of, along with
456 their archival datetime. A user agent can obtain the TimeMap and
457 select Mementos from it. An overview is provided in Section 3.2;
458 details are in Section 5.
460 3.1. Datetime Negotiation
461 Figure 2 provides a schematic overview of a successful request/
462 response chain that involves datetime negotiation. Dashed lines
463 depict HTTP transactions between user agent and server. The
464 interactions are for a scenario where the Original Resource resides
465 on one server, whereas both its TimeGate and Mementos reside on
466 another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also
467 exist in which all these resources are on the same server (for
468 example, content management systems) or all are on different servers
469 (for example, an aggregator of TimeGates).
471 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R
472 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
473 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G
474 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
475 URI-R,URI-T ------------------------------------------> URI-G
476 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M
477 6: UA <-- HTTP 200; Memento-Datetime: T; Link:
478 URI-R,URI-T,URI-G ------------------------------------- URI-M
480 Figure 2: A datetime negotiation request/response chain
482 o Step 1: The user agent that wants to access a prior state of the
483 Original Resource issues an HTTP HEAD/GET against URI-R that has
484 an "Accept-Datetime" HTTP header with a value of the datetime of
485 the desired state.
487 o Step 2: The response from URI-R includes an HTTP "Link" header
488 with a Relation Type of "timegate" pointing at a TimeGate (URI-G)
489 for the Original Resource.
491 o Step 3: The user agent starts the datetime negotiation process
492 with the TimeGate by issuing an HTTP GET request against URI-G
493 that has an "Accept-Datetime" HTTP header with a value of the
494 datetime of the desired prior state of the Original Resource.
496 o Step 4: The response from URI-G includes a "Location" header
497 pointing at a Memento (URI-M) for the Original Resource. In
498 addition, the response contains an HTTP "Link" header with a
499 Relation Type of "original" pointing at the Original Resource
500 (URI-R), and an HTTP "Link" header with a Relation Type of
501 "timemap" pointing at a TimeMap (URI-T).
503 o Step 5: The user agent issues an HTTP GET request against URI-M.
505 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP
506 header with a value of the archival datetime of the Memento. It
507 also contains an HTTP "Link" header with a Relation Type of
508 "original" pointing at the Original Resource (URI-R), with a
509 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the
510 Original Resource, and with a Relation Type of "timemap" pointing
511 at a TimeMap (URI-T) for the Original Resource. The state that is
512 expressed by the response is the state the Original Resource had
513 at the archival datetime expressed in the "Memento-Datetime"
514 header.
516 In order to respond to a datetime negotiation request, the server
517 uses an internal algorithm to select the Memento that best meets the
518 user agent's datetime preference. The exact nature of the selection
519 algorithm is at the server's discretion but is intented to be
520 consistent, for example, always selecting the Memento that is nearest
521 in time relative to the requested datetime, always selecting the
522 Memento that is nearest in the past relative to the requested
523 datetime, etc.
525 Due to the sparseness of Mementos in most systems, the value of the
526 "Memento-Datetime" header returned by a server may differ
527 (significantly) from the value conveyed by the user agent in "Accept-
528 Datetime".
530 Although a Memento encapsulates a prior state of an Original
531 Resource, the entity-body returned in response to an HTTP GET request
532 issued against a Memento may very well not be byte-to-byte the same
533 as an entity-body that was previously returned by that Original
534 Resource. Various reasons exist why there are significant chances
535 these would be different yet do convey substantially the same
536 information. These include format migrations as part of a digital
537 preservation strategy, URI-rewriting as applied by some web archives,
538 and the addition of banners as a means to brand web archives.
540 When negotiating in the datetime dimension, the regular content
541 negotiation dimensions (media type, character encoding, language, and
542 compression) remain available. It is the TimeGate server's
543 responsibility to honor (or not) such content negotiation, and in
544 doing so it MUST always first select a Memento that meets the user
545 agent's datetime preference, and then consider honoring regular
546 content negotiation for it. As a result of this approach, the
547 returned Memento will not necessarily meet the user agent's regular
548 content negotiation preferences. Therefore, it is RECOMMENDED that
549 the server provides "memento" links in the HTTP "Link" header
550 pointing at Mementos that do meet the user agent's regular content
551 negotiation requests and that have a value for the "Memento-Datetime"
552 header in the temporal vicinity of the user agent's preferred
553 datetime value.
555 A user agent that engages in datetime negotiation with a resource
556 typically starts by issuing an HTTP HEAD, not GET, request with an
557 "Accept-Datetime" header in order to determine how to proceed. This
558 strategy is related to the existence of various server implementation
559 patterns as will become clear in the below.
561 Details about the HTTP interactions involved in datetime negotation
562 are provided in Section 4.
564 3.2. TimeMaps
566 Figure 3 provides a schematic overview of a successful request/
567 response chain that shows a user agent obtaining a TimeMap. The
568 pictoral conventions are the same as the ones used in Figure 2, as is
569 the scenario. Note that, in addition to a TimeGate, an Original
570 Resource and a Memento can also provide a link to a TimeMap.
572 1: UA --- HTTP HEAD/GET ------------------------------------> URI-R
573 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
574 3: UA --- HTTP HEAD/GET ------------------------------------> URI-G
575 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
576 URI-R,URI-T ------------------------------------------> URI-G
577 5: UA --- HTTP GET URI-T -----------------------------------> URI-T
578 6: UA <-- HTTP 200 ------------------------------------------ URI-T
580 Figure 3: A request/response chain to obtain a TimeMap
582 o Step 1: The user agent that wants to access a TimeMap for the
583 Original Resource issues an HTTP HEAD/GET against URI-R. This can
584 be done with or without an "Accept-Datetime" HTTP header.
586 o Step 2: Irrespective of the use of an "Accept-Datetime" HTTP
587 header in Step 1, the response from URI-R includes an HTTP "Link"
588 header with a Relation Type of "timegate" pointing at a TimeGate
589 (URI-G) for the Original Resource.
591 o Step 3: The user agent issues an HTTP GET request against URI-G.
592 This can be done with or without an "Accept-Datetime" HTTP header.
594 o Step 4: Irrespective of the use of an "Accept-Datetime" HTTP
595 header in Step 1, the response contains an HTTP "Link" header with
596 a Relation Type of "timemap" pointing at a TimeMap (URI-T).
598 o Step 5: The user agent issues an HTTP GET request against URI-T.
600 o Step 6: The response from URI-T has an entity-body that lists all
601 Mementos for the Original Resource known to the responding server,
602 as well as their archival datetimes.
604 Details about the content and serialization of TimeMaps are provided
605 in Section 5.
607 4. Datetime Negotiation: HTTP Interactions
609 Figure 2 depicts a specific pattern to implement the Memento
610 framework. Multiple patterns exist and they can be grouped as
611 follows:
613 o Pattern 1 (Section 4.1) - The Original Resource acts as its own
614 TimeGate
616 o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for
617 the Original Resource
619 o Pattern 3 (Section 4.3) - The Original Resource is a Fixed
620 Resource
622 o Pattern 4 (Section 4.4) - Mementos without a TimeGate
624 Details of the HTTP interactions for common cases for each of those
625 patterns are provided in Section 4.1 through Section 4.4. Appendix A
626 summarizes the use of the "Vary", "Memento-Datetime", and "Link"
627 headers in responses from Original Resources, TimeGates, and Mementos
628 for the various patterns. Special cases are described in
629 Section 4.5. Note that in the following sections, the HTTP status
630 code of the responses with an entity-body is shown as "200 OK", but a
631 series of "206 Partial Content" responses could be substituted.
633 Figure 4 shows a user agent that attemtps to datetime negotiate with
634 the Original Resource http://a.example.org/ by including an "Accept-
635 Datetime" header in its HTTP HEAD request. This initiating request
636 is the same for Pattern 1 (Section 4.1) through Pattern 3
637 (Section 4.3).
639 HEAD / HTTP/1.1
640 Host: a.example.org
641 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
642 Connection: close
644 Figure 4: User Agent Attempts Datetime Negotiation With Original
645 Resource
647 4.1. Pattern 1 - The Original Resource acts as its own TimeGate
649 In this implementation pattern, the Original Resource acts as its own
650 TimeGate, which means that URI-R and URI-G coincide. Content
651 management systems and revision control systems can support datetime
652 negotiation in this way as they are commonly aware of the version
653 history of their own resources.
655 The response to this request when datetime negotiation for this
656 resource is supported depends on the negotiation style it uses
657 (200-style or 302-style) and on the existence or absence of a URI-M
658 for Mementos that is distinct from the URI-R of the associated
659 Original Resource. The various cases are summarized in the below
660 table and the server responses for each are detailed in the remainder
661 of this section.
663 +--------------+------------+------------+----------+---------------+
664 | Pattern | Original | TimeGate | Memento | Negotiation |
665 | | Resource | | | Style |
666 +--------------+------------+------------+----------+---------------+
667 | Pattern 1.1 | URI-R | URI-R | URI-M | 302 |
668 | (Section | | | | |
669 | 4.1.1) | | | | |
670 | Pattern 1.2 | URI-R | URI-R | URI-M | 200 |
671 | (Section | | | | |
672 | 4.1.2) | | | | |
673 | Pattern 1.3 | URI-R | URI-R | URI-R | 200 |
674 | (Section | | | | |
675 | 4.1.3) | | | | |
676 +--------------+------------+------------+----------+---------------+
678 Table 1: Pattern 1
680 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; distinct
681 URI-M for Mementos
683 In this case, the response to the user agent's request of Figure 4
684 has a "302 Found" HTTP status code, and the "Location" header conveys
685 the URI-M of the selected Memento. The use of Memento response
686 headers and links in the response from URI-R=URI-G is as follows:
688 o The "Vary" header MUST be provided and it MUST include the
689 "accept-datetime" value.
691 o The response MUST NOT contain a "Memento-Datetime" header.
693 o The "Link" header MUST be provided and it MUST contain at least a
694 link with the "original" Relation Type that has the URI-R of the
695 Original Resource as Target IRI. The provision of other links is
696 encouraged and is subject to the considerations described in
697 Section 2.2.
699 The server's response to the request of Figure 4 is shown in Figure
700 5. Note the inclusion of the recommended link to the TimeGate that,
701 in this case, has a Target IRI that is the URI-R of the Original
702 Resource.
704 HTTP/1.1 302 Found
705 Date: Thu, 21 Jan 2010 00:06:50 GMT
706 Server: Apache
707 Vary: accept-datetime
708 Location:
709 http://a.example.org/?version=20010911203610
710 Link: ; rel="original timegate"
711 Content-Length: 0
712 Content-Type: text/plain; charset=UTF-8
713 Connection: close
715 Figure 5: Response from URI-R=URI-G for Pattern 1.1
717 In a subsequent request, shown in Figure 6, the user agent can obtain
718 the selected Memento by issuing an HTTP GET request against the URI-M
719 that was provided in the "Location" header. The inclusion of the
720 "Accept-Datetime" header in this request is not needed but will
721 typically occur as the user agent is in datetime negotiation mode.
723 GET /?version=20010911203610 HTTP/1.1
724 Host: a.example.org
725 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
726 Connection: close
728 Figure 6: User Agent Requests Selected Memento
730 The response has a "200 OK" HTTP status code and the entity-body of
731 the response contains the representation of the selected Memento.
732 The use of Memento response headers and links in the response from
733 URI-M is as follows:
735 o A "Vary" header that includes an "accept-datetime" value MUST NOT
736 be provided.
738 o The response MUST include a "Memento-Datetime" header. Its value
739 expresses the archival datetime of the Memento.
741 o The "Link" header MUST be provided and it MUST contain at least a
742 link with the "original" Relation Type that has the URI-R of the
743 Original Resource as Target IRI. The provision of other links is
744 encouraged and is subject to the considerations described in
745 Section 2.2.
747 The server's response to the request of Figure 6 is shown in Figure
748 7. Note the provision of the required "original", and the
749 recommended "timegate" and "timemap" links. The former two point to
750 the Original Resource, which acts as its own TimeGate. The latter
751 has "from" and "until" attributes to indicate the temporal interval
752 covered by Mementos listed in the linked TimeMap.
754 HTTP/1.1 200 OK
755 Date: Thu, 21 Jan 2010 00:06:51 GMT
756 Server: Apache-Coyote/1.1
757 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
758 Link: ; rel="original timegate",
759
760 ; rel="timemap"; type="application/link-format"
761 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
762 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
763 Content-Length: 23364
764 Content-Type: text/html;charset=utf-8
765 Connection: close
767 Figure 7: Response from URI-M for Pattern 1.1
769 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; distinct
770 URI-M for Mementos
772 In this case, the response to the user agent's request of Figure 4
773 has a "200 OK" HTTP status code, and the "Content-Location" header
774 conveys the URI-M of the selected Memento. The use of Memento
775 response headers and links in the response from URI-R=URI-G is as
776 follows:
778 o The "Vary" header MUST be provided and it MUST include the
779 "accept-datetime" value.
781 o The response MUST include a "Memento-Datetime" header. Its value
782 expresses the archival datetime of the selected Memento.
784 o The "Link" header MUST be provided and it MUST contain at least a
785 link with the "original" Relation Type that has the URI-R of the
786 Original Resource as Target IRI. The provision of other links is
787 encouraged and is subject to the considerations described in
788 Section 2.2.
790 The server's response to the request of Figure 4 is shown in Figure
791 8. Note the provision of optional "memento" links pointing at the
792 oldest and most recent Memento for the Original Resource known to the
793 responding server.
795 HTTP/1.1 200 OK
796 Date: Thu, 21 Jan 2010 00:06:50 GMT
797 Server: Apache
798 Vary: accept-datetime
799 Content-Location:
800 http://a.example.org/?version=20010911203610
801 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
802 Link: ; rel="original timegate",
803
804 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
805
806 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT"
807 Content-Length: 2312
808 Content-Type: text/html; charset=UTF-8
809 Connection: close
811 Figure 8: Response from URI-R=URI-G for Pattern 1.2
813 In a subsequent request, which is the same as Figure 4 but with HTTP
814 GET instead of HEAD, the user agent can obtain the representation of
815 the selected Memento. It will be provided as the entity-body of a
816 response that has the same Memento headers as in Figure 8.
818 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; no distinct
819 URI-M for Mementos
821 In this case, the response to the user agent's request of Figure 4
822 has a "200 OK" HTTP status code, and it does not contain a "Content-
823 Location" nor "Location" header as there is no URI-M of the selected
824 Memento to convey. The use of Memento response headers and links in
825 the response from URI-R=URI-G is as follows:
827 o The "Vary" header MUST be provided and it MUST include the
828 "accept-datetime" value.
830 o The response MUST include a "Memento-Datetime" header. Its value
831 expresses the archival datetime of the selected Memento.
833 o The "Link" header MUST be provided and it MUST contain at least a
834 link with the "original" Relation Type that has the URI-R of the
835 Original Resource as Target IRI. The provision of other links is
836 encouraged and is subject to the considerations described in
837 Section 2.2.
839 The server's response to the request of Figure 4 is shown in Figure
840 9. The recommended "timemap" and "timegate" links are included in
841 addition to the mandatory "original" link.
843 HTTP/1.1 200 OK
844 Date: Thu, 21 Jan 2010 00:06:50 GMT
845 Server: Apache
846 Vary: accept-datetime
847 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
848 Link: ; rel="original timegate",
849
850 ; rel="timemap"; type="application/link-format"
851 Content-Length: 0
852 Content-Type: text/plain; charset=UTF-8
853 Connection: close
855 Figure 9: Response from URI-R=URI-G for Pattern 1.3
857 In a subsequent request, which is the same as Figure 4 but with HTTP
858 GET instead of HEAD, the user agent can obtain the representation of
859 the selected Memento. It will be provided as the entity-body of a
860 response that has the same Memento headers as in Figure 9.
862 4.2. Pattern 2 - A remote resource acts as a TimeGate for the Original
863 Resource
865 In this implementation pattern, the Original Resource does not act as
866 its own TimeGate, which means that URI-R and URI-G are different.
867 This pattern is typically implemented by servers for which the
868 history of their resources is recorded in remote systems such as web
869 archives and transactional archives [Fitch]. But servers that
870 maintain their own history, such as content management systems and
871 Version Control Systems, may also implement this pattern, for
872 example, to distribute the load involved in responding to requests
873 for current and prior representations of resources between different
874 servers.
876 This pattern is summarized in the below table and is detailed in the
877 remainder of this section. Three cases exist that differ regarding
878 the negotiation style that is used by the remote TimeGate and
879 regarding the existence of a URI-M for Mementos that is distinct from
880 the URI-G of the TimeGate.
882 +--------------+------------+------------+----------+---------------+
883 | Pattern | Original | TimeGate | Memento | Negotiation |
884 | | Resource | | | Style |
885 +--------------+------------+------------+----------+---------------+
886 | Pattern 2.1 | URI-R | URI-G | URI-M | 302 |
887 | (Section | | | | |
888 | 4.2.1) | | | | |
889 | Pattern 2.2 | URI-R | URI-G | URI-M | 200 |
890 | (Section | | | | |
891 | 4.2.2) | | | | |
892 | Pattern 2.3 | URI-R | URI-G | URI-G | 200 |
893 | (Section | | | | |
894 | 4.2.3) | | | | |
895 +--------------+------------+------------+----------+---------------+
897 Table 2: Pattern 2
899 The response by the Original Resource to the request shown in Figure
900 4 is the same for all three cases. The use of headers and links in
901 the response from URI-R is as follows:
903 o A "Vary" header that includes an "accept-datetime" value MUST NOT
904 be provided.
906 o The response MUST NOT contain a "Memento-Datetime" header.
908 o The "Link" header SHOULD be provided. It MUST NOT include a link
909 with an "original" Relation Type. If a preferred TimeGate is
910 associated with the Original Resource, then it MUST include a link
911 with a "timegate" Relation Type that has the URI-G of the TimeGate
912 as Target IRI. If a preferred TimeMap is associated with the
913 Original Resource, then it SHOULD include a link with a "timemap"
914 Relation Type that has the URI-T of the TimeGate as Target IRI.
915 Multiple "timegate" and "timemap" links can be provided to
916 accommodate situations in which the server is aware of multiple
917 TimeGates or Timemaps for the Original Resource.
919 Figure 10 shows such a response. Note the absence of an "original"
920 link as the responding resource is neither a TimeGate or a Memento.
922 HTTP/1.1 200 OK
923 Date: Thu, 21 Jan 2010 00:02:12 GMT
924 Server: Apache
925 Link:
926 ; rel="timegate"
927 Content-Length: 255
928 Connection: close
929 Content-Type: text/html; charset=iso-8859-1
931 Figure 10: Response from URI-R<>URI-G for Pattern 2
933 Once a user agent has obtained the URI-G of a remote TimeGate for the
934 Original Resource it can engage in datetime negotation with that
935 TimeGate. Figure 11 shows the request issued against the TimeGate
936 whereas Section 4.2.1 through Section 4.2.3 detail the responses for
937 various TimeGate implementation patterns.
939 HEAD /timegate/http://a.example.org/ HTTP/1.1
940 Host: arxiv.example.net
941 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
942 Connection: close
944 Figure 11: User Agent Engages in Datetime Negotiation With Remote
945 TimeGate
947 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; distinct
948 URI-M for Mementos
950 In case the TimeGate uses a 302 negotiation style, the response to
951 the user agent's request of Figure 11 has a "302 Found" HTTP status
952 code, and the "Location" header conveys the URI-M of the selected
953 Memento. The use of Memento response headers and links in the
954 response from URI-G is as follows:
956 o The "Vary" header MUST be provided and it MUST include the
957 "accept-datetime" value.
959 o The response MUST NOT contain a "Memento-Datetime" header.
961 o The "Link" header MUST be provided and it MUST contain at least a
962 link with the "original" Relation Type that has the URI-R of the
963 Original Resource as Target IRI. The provision of other links is
964 encouraged and is subject to the considerations described in
965 Section 2.2.
967 The server's response to the request of Figure 11 is shown in Figure
968 12. It contains the mandatory "original" link that points back to
969 the Original Resource associated with this TimeGate and it shows the
970 recommended "timemap" link that includes "from" and "until"
971 attributes.
973 HTTP/1.1 302 Found
974 Date: Thu, 21 Jan 2010 00:02:14 GMT
975 Server: Apache
976 Vary: accept-datetime
977 Location:
978 http://arxiv.example.net/web/20010911203610/http://a.example.org/
979 Link: ; rel="original",
980
981 ; rel="timemap"; type="application/link-format"
982 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
983 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
984 Content-Length: 0
985 Content-Type: text/plain; charset=UTF-8
986 Connection: close
988 Figure 12: Response from URI-G<>URI-R for Pattern 2.1
990 In a subsequent HTTP GET request, shown in Figure 13, the user agent
991 can obtain the selected Memento by issuing an HTTP GET request
992 against the URI-M that was provided in the "Location" header. The
993 inclusion of the "Accept-Datetime" header in this request is not
994 needed but will typically occur as the user agent is in datetime
995 negotiation mode.
997 GET /web/20010911203610/http://a.example.org/ HTTP/1.1
998 Host: arxiv.example.net/
999 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1000 Connection: close
1002 Figure 13: User Agent Requests Selected Memento
1004 The response has a "200 OK" HTTP status code. The use of Memento
1005 response headers and links in the response from URI-M is as follows:
1007 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1008 be provided.
1010 o The response MUST include a "Memento-Datetime" header. Its value
1011 expresses the archival datetime of the Memento.
1013 o The "Link" header MUST be provided and it MUST contain at least a
1014 link with the "original" Relation Type that has the URI-R of the
1015 Original Resource as Target IRI. The provision of other links is
1016 encouraged and is subject to the considerations described in
1017 Section 2.2.
1019 The server's response to the request of Figure 13 is shown in Figure
1020 14. Note the provision of the recommended "timegate" and "timemap"
1021 links.
1023 HTTP/1.1 200 OK
1024 Date: Thu, 21 Jan 2010 00:02:15 GMT
1025 Server: Apache-Coyote/1.1
1026 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1027 Link: ; rel="original",
1028
1029 ; rel="timemap"; type="application/link-format",
1030
1031 ; rel="timegate"
1032 Content-Length: 23364
1033 Content-Type: text/html;charset=utf-8
1034 Connection: close
1036 Figure 14: Response from URI-M for Pattern 2.1
1038 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; distinct
1039 URI-M for Mementos
1041 In case the TimeGate uses a 200 negotiation style, and each Memento
1042 has a distinct URI-M, the response to the user agent's request of
1043 Figure 11 has a "200 OK" HTTP status code, and the "Content-Location"
1044 header conveys the URI-M of the selected Memento. The use of Memento
1045 response headers and links in the response from URI-G is as follows:
1047 o The "Vary" header MUST be provided and it MUST include the
1048 "accept-datetime" value.
1050 o The response MUST include a "Memento-Datetime" header. Its value
1051 expresses the archival datetime of the Memento.
1053 o The "Link" header MUST be provided and it MUST contain at least a
1054 link with the "original" Relation Type that has the URI-R of the
1055 Original Resource as Target IRI. The provision of other links is
1056 encouraged and is subject to the considerations described in
1057 Section 2.2.
1059 The server's response to the request of Figure 11 is shown in Figure
1060 15.
1062 HTTP/1.1 200 OK
1063 Date: Thu, 21 Jan 2010 00:09:40 GMT
1064 Server: Apache-Coyote/1.1
1065 Vary: accept-datetime
1066 Content-Location:
1067 http://arxiv.example.net/web/20010911203610/http://a.example.org/
1068 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1069 Link: ; rel="original",
1070
1071 ; rel="timemap"; type="application/link-format",
1072
1073 ; rel="timegate"
1074 Content-Length: 23364
1075 Content-Type: text/html; charset=UTF-8
1076 Connection: close
1078 Figure 15: Response from URI-G<>URI-R for Pattern 2.2
1080 In a subsequent request, which is the same as Figure 11 but with HTTP
1081 GET instead of HEAD, the user agent can obtain the representation of
1082 the selected Memento. It will be provided as the entity-body of a
1083 response that has the same Memento headers as Figure 15.
1085 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct
1086 URI-M for Mementos
1088 In case the TimeGate uses a 200 negotiation style, but Mementos have
1089 no distinct URIs, the response to the user agent's request of Figure
1090 11 has a "200 OK" HTTP status code, and it does not contain a
1091 "Content-Location" nor "Location" header as there is no URI-M of the
1092 selected Memento to convey. The use of Memento response headers and
1093 links in the response from URI-G is as follows:
1095 o The "Vary" header MUST be provided and it MUST include the
1096 "accept-datetime" value.
1098 o The response MUST include a "Memento-Datetime" header. Its value
1099 expresses the archival datetime of the Memento.
1101 o The "Link" header MUST be provided and it MUST contain at least a
1102 link with the "original" Relation Type that has the URI-R of the
1103 Original Resource as Target IRI. The provision of other links is
1104 encouraged and is subject to the considerations described in
1105 Section 2.2.
1107 The server's response to the request of Figure 11 is shown in Figure
1108 16.
1110 HTTP/1.1 200 OK
1111 Date: Thu, 21 Jan 2010 00:09:40 GMT
1112 Server: Apache-Coyote/1.1
1113 Vary: accept-datetime
1114 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1115 Link: ; rel="original",
1116
1117 ; rel="timemap"; type="application/link-format",
1118
1119 ; rel="timegate"
1120 Content-Length: 23364
1121 Content-Type: text/html; charset=UTF-8
1122 Connection: close
1124 Figure 16: Response from URI-G<>URI-R for Pattern 2.3
1126 In a subsequent request, which is the same as Figure 11 but with HTTP
1127 GET instead of HEAD, the user agent can obtain the representation of
1128 the selected Memento. It will be provided as the entity-body of a
1129 response that has the same Memento headers as Figure 16.
1131 4.3. Pattern 3 - The Original Resource is a Fixed Resource
1133 This pattern does not involve datetime negotiation with a TimeGate
1134 but it can be implemented for Original Resources that never change
1135 state or do not change anymore past a certain point in their
1136 existence, meaning that URI-R and URI-M coincide either from the
1137 outset or starting at some point in time. This pattern is summarized
1138 in the below table. Examples are tweets or stable media resources on
1139 news sites.
1141 +-----------+--------------+------------+----------+----------------+
1142 | Pattern | Original | TimeGate | Memento | Negotiation |
1143 | | Resource | | | Style |
1144 +-----------+--------------+------------+----------+----------------+
1145 | Pattern 3 | URI-R | - | URI-R | - |
1146 +-----------+--------------+------------+----------+----------------+
1148 Table 3: Pattern 3
1150 Servers that host such resources can support the Memento framework by
1151 treating the stable resource (FixedResource as per
1152 [W3C.gen-ont-20090420]) as a Memento. The use of Memento response
1153 headers and links in responses from such a stable resource is as
1154 follows:
1156 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1157 be provided.
1159 o The response MUST include a "Memento-Datetime" header. Its value
1160 expresses the datetime at which the resource became stable.
1161 Providing this value includes a promise that the resource has not
1162 changed since this datetime and will not change anymore beyond it.
1164 o The "Link" header MUST be provided and MUST have a link with the
1165 "original" Relation Type that has the URI-R of the stable resource
1166 itself as Target IRI.
1168 Figure 17 shows a response to an HTTP HEAD request for the resource
1169 with URI-R http://a.example.org/ that has been stable since March
1170 20th 2009.
1172 HTTP/1.1 200 OK
1173 Date: Thu, 21 Jan 2010 00:09:40 GMT
1174 Server: Apache-Coyote/1.1
1175 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
1176 Link: ; rel="original"
1177 Content-Length: 0
1178 Content-Type: text/plain; charset=UTF-8
1179 Connection: close
1181 Figure 17: Response from URI-R=URI-M for Pattern 3
1183 4.4. Pattern 4 - Mementos without a TimeGate
1185 Cases may occur in which a server hosts Mementos but does not expose
1186 a TimeGate for them. This can, for example, be the case if the
1187 server's Mementos result from taking a snapshot of the state of a set
1188 of Original Resources from another server as it is being retired. As
1189 a result, only a single Memento per Original Resource is hosted,
1190 making the introduction of a TimeGate unnecessary. But it may also
1191 be the case for servers that host multiple Mementos for an Original
1192 Resource but consider exposing TimeGates too expensive. In this
1193 case, URI-R and URI-M are distinct, but a TimeGate is absent. This
1194 case is summarized in the below table.
1196 +-----------+--------------+------------+----------+----------------+
1197 | Pattern | Original | TimeGate | Memento | Negotiation |
1198 | | Resource | | | Style |
1199 +-----------+--------------+------------+----------+----------------+
1200 | Pattern 4 | URI-R | - | URI-M | - |
1201 +-----------+--------------+------------+----------+----------------+
1203 Table 4: Pattern 4
1205 Servers that host such Mementos without TimeGates can still support
1206 the Memento framework by providing the appropriate Memento headers
1207 and links. Their use is as follows for a response from URI-M:
1209 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1210 be provided.
1212 o The response MUST include a "Memento-Datetime" header. Its value
1213 expresses the archival datetime of the Memento.
1215 o The "Link" header MUST be provided and it MUST have a link with
1216 the "original" Relation Type that has the URI-R of the associated
1217 Original Resource as Target IRI. The provision of other links is
1218 encouraged and is subject to the considerations described in
1219 Section 2.2.
1221 Figure 18 shows a response to an HTTP HEAD request for the Memento
1222 with URI-M http://arxiv.example.net/web/20010911203610/http://
1223 a.example.org/. Note the use of links: three links have the URI-M of
1224 the Memento as Target IRI and have respective Relation Types
1225 "memento", "first", and "last". This combination indicates that this
1226 is the only Memento for the Original Resource with Target IRI
1227 provided by the "original" link (http://a.example.org/) that the
1228 server is aware of. Note also that such a response does not imply
1229 that there is no server whatsoever that exposes a TimeGate; it merely
1230 means that the responding server neither provides nor is aware of the
1231 location of a TimeGate.
1233 HTTP/1.1 200 OK
1234 Date: Thu, 21 Jan 2010 00:09:40 GMT
1235 Server: Apache-Coyote/1.1
1236 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1237 Link: ; rel="original",
1238
1239 ; rel="first last memento"
1240 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT"
1241 Content-Length: 0
1242 Content-Type: text/plain; charset=UTF-8
1243 Connection: close
1245 Figure 18: Response from URI-M<>URI-R for Pattern 4
1247 4.5. Special Cases
1249 4.5.1. Original Resource provides no "timegate" link
1251 Cases exist in which the response from the Original Resource does not
1252 contain a "timegate" link, including:
1254 o The Original Resource's server does not support the Memento
1255 framework;
1257 o The Original Resource no longer exists and the responding server
1258 is not aware of its prior existence;
1260 o The server that hosted the Original Resource no longer exists.
1262 In all these cases, the user agent should attempt to determine an
1263 appropriate TimeGate for the Original Resource, either automatically
1264 or interactively supported by the user.
1266 4.5.2. Server exists but Original Resource no longer does
1268 Cases exist in which the server knows that an Original Resource used
1269 to exist, but no longer provides a current representation. If there
1270 is a preferred TimeGate for such a discontinued Original Resource,
1271 then the server MUST include a "timegate" link in responses to
1272 requests for it. This may allow access to Mementos for the Original
1273 Resource even if it no longer exists. A server's response to a
1274 request for the discontinued resource http://a.example.org/pic is
1275 illustrated in Figure 19.
1277 HTTP/1.1 404 Not Found
1278 Date: Thu, 21 Jan 2010 00:02:12 GMT
1279 Server: Apache
1280 Link:
1281
1282 ; rel="timegate"
1283 Content-Length: 255
1284 Connection: close
1285 Content-Type: text/html; charset=iso-8909-1
1287 Figure 19: Response from an Original Resource that not longer exists
1289 4.5.3. Issues with Accept-Datetime
1291 The following special cases may occur regarding the "Accept-Datetime"
1292 header when a user agent issues a request against a TimeGate:
1294 o If the value of the "Accept-Datetime" is either earlier than the
1295 datetime of the first Memento or later than the datetime of the
1296 most recent Memento known to the TimeGate, the first or most
1297 recent Memento MUST be selected, respectively.
1299 o If the value of the "Accept-Datetime" does not conform to the
1300 rfc1123-date construction rule of the BNF in Figure 1, the
1301 response MUST have a "400 Bad Request" HTTP status code.
1303 o If a user agent issues a request against a TimeGate and fails to
1304 include an "Accept-Datetime" request header, the most recent
1305 Memento SHOULD be selected.
1307 In all cases, the use of headers and links in responses is as
1308 described for TimeGates in the respective scenarios.
1310 4.5.4. Memento of a 3XX response
1312 Cases exist in which HTTP responses with 3XX status codes are
1313 archived. For example, crawl-based web archives commonly archive
1314 responses with HTTP status codes "301 Moved Permanently" and "302
1315 Found" whereas Linked Data archives hold on to "303 See Other"
1316 responses.
1318 If the Memento requested by the user agent is an archived version of
1319 an HTTP response with a 3XX status code, the server's response MUST
1320 have the same 3XX HTTP status code. The use of other Memento headers
1321 is as described for Mementos in the respective scenarios.
1323 The user agent's handling of an HTTP response with a 3XX status code
1324 is not affected by the presence of a "Memento-Datetime" header. The
1325 user agent MUST behave in the same manner as it does with HTTP
1326 responses with a 3XX status code that do not have a "Memento-
1327 Datetime" header.
1329 However, the user agent MUST be aware that the URI that was selected
1330 from the "Location" header of an HTTP response with a 3XX status code
1331 might not be that of a Memento but rather of an Original Resource.
1332 In the latter case it SHOULD proceed by looking for a Memento of the
1333 selected Original Resource.
1335 For example, Figure 20 shows the response to an HTTP GET request for
1336 http://a.example.org issued on April 11 2008. This response is
1337 archived as a Memento of http://a.example.org that has as URI-M http:
1338 //arxiv.example.net/web/20080411000650/http://a.example.org. The
1339 response to an HTTP GET on this URI-M is shown in Figure 21. It is a
1340 replay of the original response with "Memento-Datetime" and "Link"
1341 headers added, to allow a user agent to understand the response is a
1342 Memento. In Figure 21, the value of the "Location" header is the
1343 same as in the original response; it identifies an Original Resource.
1344 The user agent proceeds with finding a Memento for this Original
1345 Resource. Web archives sometimes overwrite the value that was
1346 originally provided in the "Location" header in order to point at a
1347 Memento they hold of the resource to which the redirect originally
1348 led. This is shown in Figure 22. In this case, the user agent may
1349 decide it found an appropriate Memento.
1351 HTTP/1.1 301 Moved Permanently
1352 Date: Fri, 11 Apr 2008 00:06:50 GMT
1353 Server: Apache
1354 Location: http://b.example.org
1355 Content-Length: 0
1356 Content-Type: text/plain; charset=UTF-8
1357 Connection: close
1359 Figure 20: Response is a redirect
1361 HTTP/1.1 301 Moved Permanently
1362 Date: Thu, 21 Jan 2010 00:09:40 GMT
1363 Server: Apache-Coyote/1.1
1364 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1365 Location: http://b.example.org
1366 Link: ; rel="original",
1367
1368 ; rel="timemap"; type="application/link-format",
1369
1370 ; rel="timegate"
1371 Content-Length: 0
1372 Content-Type: text/plain; charset=UTF-8
1373 Connection: close
1375 Figure 21: Response is a Memento of a redirect; leads to an Original
1376 Resource
1378 HTTP/1.1 301 Moved Permanently
1379 Date: Thu, 21 Jan 2010 00:09:40 GMT
1380 Server: Apache-Coyote/1.1
1381 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1382 Location:
1383 http://arxiv.example.net/web/20080411000655/http://b.example.org
1384 Link: ; rel="original",
1385
1386 ; rel="timemap"; type="application/link-format",
1387
1388 ; rel="timegate"
1389 Content-Length: 0
1390 Content-Type: text/plain; charset=UTF-8
1391 Connection: close
1393 Figure 22: Response is a Memento of a redirect; leads to a Memento
1395 4.5.5. Memento of responses with 4XX or 5XX HTTP status codes
1397 Cases exist in which responses with 4XX and 5XX HTTP status codes are
1398 archived. If the Memento requested by the user agent is an archived
1399 version of such an HTTP response, the server's response MUST have the
1400 same 4XX or 5XX HTTP status code. The use of headers and links in
1401 responses is as described for Mementos in the respective scenarios.
1403 For example, Figure 23 shows the 404 response to an HTTP GET request
1404 for http://a.example.org issued on April 11 2008. This response is
1405 archived as a Memento of http://a.example.org, that has as URI-M
1406 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1407 The response to an HTTP HEAD on this URI-M is shown in Figure 24. It
1408 is a replay of the original response with "Memento-Datetime" and
1409 "Link" headers added, to allow a user agent to understand the
1410 response is a Memento.
1412 HTTP/1.1 404 Not Found
1413 Date: Fri, 11 Apr 2008 00:06:50 GMT
1414 Server: Apache
1415 Content-Length: 0
1416 Content-Type: text/plain; charset=UTF-8
1417 Connection: close
1419 Figure 23: Response is a 404
1421 HTTP/1.1 404 Not Found
1422 Date: Thu, 21 Jan 2010 00:09:40 GMT
1423 Server: Apache-Coyote/1.1
1424 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1425 Link: ; rel="original",
1426
1427 ; rel="timemap"; type="application/link-format",
1428
1429 ; rel="timegate"
1430 Content-Length: 0
1431 Content-Type: text/plain; charset=UTF-8
1432 Connection: close
1434 Figure 24: Response is a Memento of a 404
1436 4.5.6. Sticky "Memento-Datetime" value for Mementos
1438 The provision of a "Memento-Datetime" in a response entails a promise
1439 that the response is frozen in time. As a consequence, the "Memento-
1440 Datetime" header associated with a Memento MUST be "sticky" in the
1441 following ways:
1443 o The server that originally assigns the "Memento-Datetime" header
1444 and value to a specific response MUST retain that header in all
1445 future responses to HTTP requests (with or without "Accept-
1446 Datetime" header) that occur against the Memento after the time of
1447 the original assignment of the header, and it MUST NOT change its
1448 associated value.
1450 o Applications that mirror Mementos at a different URI MUST retain
1451 the "Memento-Datetime" header and MUST NOT change its value unless
1452 mirroring involves a meaningful state change. This allows, for
1453 example, duplicating a web archive at a new location while
1454 preserving the value of the "Memento-Datetime" header of the
1455 archived resources. In this example, the "Last-Modified" header
1456 will be updated to reflect the time of mirroring at the new URI,
1457 whereas the value for "Memento-Datetime" will be maintained.
1459 4.5.7. Intermediate Resources
1460 An intermediate resource is a resource that issues a redirect to a
1461 TimeGate, to a Memento, or to another intermediate resource, and thus
1462 plays an active role in the Memento infrastructure. Intermediate
1463 resources commonly exist in web archives on the path from a TimeGate
1464 to an appropriate Memento.
1466 A response of an intermediate resource has an HTTP status code
1467 indicative of HTTP redirection (e.g. 302) and uses Memento headers
1468 and links that allow to recognize that the resource plays a role in
1469 the Memento framework:
1471 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1472 be provided.
1474 o The response MUST NOT include a "Memento-Datetime" header.
1476 o The "Link" header MUST be provided and it MUST have a link with
1477 the "original" Relation Type that has the URI-R of the associated
1478 Original Resource as Target IRI. Links with "timegate",
1479 "timemap", and "memento" Relation Types are OPTIONAL and, if
1480 provided, MUST pertain to the Original Resource for which the user
1481 agent is trying to obtain a Memento.
1483 A user agent MUST follow a redirection provided by an intermediate
1484 resource; multiple such redirections can be chained.
1486 Consider the case where a user agent follows the "timegate" link
1487 provided in Figure 10 and engages in datetime negotiation with the
1488 assumed TimeGate in the manner shown in Figure 11. But instead of
1489 receiving a response as shown in Figure 12, it receives the one shown
1490 below in Figure 25. Such a response is umabiguosuly recognizable as
1491 coming from an intermediate resource.
1493 HTTP/1.1 302 Found
1494 Date: Thu, 21 Jan 2010 00:06:50 GMT
1495 Server: Apache
1496 Location:
1497 http://arxiv.example.net/new-timegate/http://a.example.org/
1498 Link: ; rel="original"
1499 Content-Length: 0
1500 Content-Type: text/plain; charset=UTF-8
1501 Connection: close
1503 Figure 25: Redirecting Resource redirects to a TimeGate
1505 4.5.8. Resources excluded from datetime negotiation
1506 When delivering a Memento to a user agent, a web archive commonly
1507 enhances that Memento's archived content, for example, by including a
1508 banner that provides branding and highlights the archival status of
1509 the Memento. The resources that are involved in providing such
1510 system-specific functionality, many times Javascript or images, must
1511 be used in their current state.
1513 A server that generally supports datetime negotiation should make
1514 resources that need to be excluded from datetime negotiation
1515 recognizable. Doing so allows a user agent to refrain from
1516 attempting to access a Memento for them. In order to achieve this,
1517 the server SHOULD include a special-purpose link in the HTTP "Link"
1518 header when responding to a HTTP HEAD/GET request to a resource
1519 excluded from datetime negotiation. This link has "http://
1520 mementoweb.org/terms/donotnegotiate" as Target IRI and "type",
1521 defined in [RFC6903], as the value of the rel attribute. Other
1522 Memento headers as defined in Section 2.1. SHOULD NOT be provided.
1524 Figure 26 shows the response to a HTTP HEAD request from a resource
1525 excluded from datetime negotiation.
1527 HTTP/1.1 200 OK
1528 Date: Thu, 21 Jan 2010 00:09:40 GMT
1529 Server: Apache-Coyote/1.1
1530 Link: ; rel="type"
1531 Content-Length: 238
1532 Content-Type: application/javascript; charset=UTF-8
1533 Connection: close
1535 Figure 26: Response to a HTTP HEAD request from a resource excluded
1536 from datetime negotiation
1538 5. TimeMaps: Content and Serialization
1540 A TimeMap is introduced to support retrieving a comprehensive list of
1541 all Mementos for a specific Original Resource known to a server. The
1542 entity-body of a response to an HTTP GET request issued against a
1543 TimeMap's URI-T:
1545 o MUST list the URI-R of the Original Resource that the TimeMap is
1546 about;
1548 o MUST list the URI-M and archival datetime of each Memento for the
1549 Original Resource known to the server, preferably in a single
1550 document, or, alternatively in multiple documents that can be
1551 gathered by following contained links with a "timemap" Relation
1552 Type;
1554 o SHOULD list the URI-G of one or more TimeGates for the Original
1555 Resource known to the responding server;
1557 o SHOULD, for self-containment, list the URI-T of the TimeMap
1558 itself;
1560 o MUST unambiguously type listed resources as being Original
1561 Resource, TimeGate, Memento, or TimeMap.
1563 The entity-body of a response from a TimeMap MAY be serialized in
1564 various ways, but the link-value format serialization described here
1565 MUST be supported. In this serialization, the entity-body MUST be
1566 formatted in the same way as the value of an HTTP "Link" header, and
1567 hence MUST comply to the "link-value" construction rule of
1568 "Section 5. The Link Header Field" of [RFC5988], and the media type
1569 of the entity-body MUST be "application/link-format" as introduced in
1570 [RFC6690]. Links contained in the entity-body MUST be interpreted as
1571 follows:
1573 o The Context IRI is set to the anchor parameter, when specified;
1575 o The Context IRI of links with the "self" Relation Types is the
1576 URI-T of the TimeMap, i.e. the URI of the resource from which the
1577 TimeMap was requested;
1579 o The Context IRI of all other links is the URI-R of the Original
1580 Resource, which is provided as the Target IRI of the link with an
1581 "original" Relation Type.
1583 In order to retrieve the link-value serialization of a TimeMap, a
1584 user agent uses an "Accept" request header with a value set to
1585 "application/link-format". This is shown in Figure 27.
1587 GET /timemap/http://a.example.org/ HTTP/1.1
1588 Host: arxiv.example.net
1589 Accept: application/link-format;q=1.0
1590 Connection: close
1592 Figure 27: Request for a TimeMap
1594 If the TimeMap requested by the user agent exists, the server's
1595 response has a "200 OK" HTTP status code and the list of Mementos is
1596 provided in the entity-body of the response. Such a response is
1597 shown in Figure 28
1599 HTTP/1.1 200 OK
1600 Date: Thu, 21 Jan 2010 00:06:50 GMT
1601 Server: Apache
1602 Content-Length: 4883
1603 Content-Type: application/link-format
1604 Connection: close
1606 ;rel="original",
1607
1608 ; rel="self";type="application/link-format"
1609 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1610 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1611
1612 ; rel="timegate",
1613
1614 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
1615 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1616
1617 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
1618 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1619
1620 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
1621 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1622
1623 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
1624 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1625 ...
1627 Figure 28: Response from a TimeMap
1629 5.1. Special Cases
1631 5.1.1. Index and Paging TimeMaps
1633 Cases exist in which a TimeMap points at one or more other TimeMaps:
1635 o Index Timemap - A TimeMap can merely point at other TimeMaps and
1636 not list any Mementos itself. This can happen when Mementos are
1637 spread across several archives that share a front-end. An example
1638 is shown in Figure 29.
1640 o Paging Timemap - The number of available Mementos can require
1641 introducing multiple TimeMaps that can be paged. An example is
1642 shown in Figure 30. Note that a Paging TimeMap contains links to
1643 other TimeMaps but actually also lists Mementos.
1645 In both cases, including the "from" and "until" attributes for
1646 "timemap" links is RECOMMENDED as a means to express the temporal
1647 span of Mementos listed in each TimeMap. Note that TimeMaps obtained
1648 by following a "timemap" link can contain links to further TimeMaps.
1650 ;rel="original",
1651
1652 ; rel="timegate",
1653
1654 ; rel="self";type="application/link-format",
1655
1656 ; rel="timemap";type="application/link-format"
1657 ; from="Wed, 21 Jun 2000 04:41:56 GMT"
1658 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1659
1660 ; rel="timemap";type="application/link-format"
1661 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1662 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1663
1664 ; rel="timemap";type="application/link-format"
1665 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1667 Figure 29: Index TimeMap
1669 ;rel="original",
1670
1671 ; rel="timegate",
1672
1673 ; rel="self";type="application/link-format"
1674 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1675 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1676
1677 ; rel="timemap";type="application/link-format"
1678 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1679 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1680
1681 ; rel="timemap";type="application/link-format"
1682 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1683 ; until="Fri, 31 Aug 2012 12:22:34 GMT"
1684
1685 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1686
1687 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1688
1689 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1690 ...
1692 Figure 30: Paging TimeMap
1694 5.1.2. Mementos for TimeMaps
1696 A TimeMap can itself act as an Original Resource for which a TimeGate
1697 and Mementos may exist. Hence, the response from a TimeMap could
1698 include a "timegate" link to a TimeGate via which prior TimeMap
1699 versions are available. And, in cases where URI-T=URI-R=URI-G (a
1700 TimeMap is an Original Resource that acts as its own TimeGate), an
1701 "original" link pointing at the TimeMap URI-T would be included.
1703 Therefore, caution is required in cases where a TimeMap for an
1704 Original Resource wants to explicitly express in a Link header for
1705 which Original Resource it is a TimeMap. It can do so by including a
1706 "timemap" link that has the URI-R of the Original Resource as Context
1707 IRI and the URI-T of the TimeMap as Target IRI.
1709 Figure 31 shows the response to an HTTP HEAD request against a
1710 TimeMap that has http://arxiv.example.net/timemap/http://
1711 a.example.org as URI-T. This TimeMap provides information about
1712 Mementos for the Original Resource that has http://a.example.org as
1713 URI-R. The response includes an "original" link pointing to the
1714 Original Resource that this TimeMap is about. Note the use of the
1715 "anchor" attribute in this link to convey the URI-R of that Original
1716 Resource.
1718 HTTP/1.1 200 OK
1719 Date: Thu, 21 Jan 2010 00:06:50 GMT
1720 Server: Apache
1721 Link:
1722 ; anchor="http://a.example.org"; rel="timemap"
1723 ; type="application/link-format"
1724 Content-Length: 0
1725 Content-Type: application/link-format; charset=UTF-8
1726 Connection: close
1728 Figure 31: TimeMap links to the Original Resource it is about
1730 6. IANA Considerations
1732 This memo requires IANA to register the Accept-Datetime and Memento-
1733 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1734 IANA registry.
1736 This memo requires IANA to register the Relation Types "original",
1737 "timegate", "timemap", and "memento" defined in Section 2.2 in the
1738 appropriate IANA registry.
1740 This memo requires IANA to register the "datetime" and "license"
1741 attributes for the "memento" Relation Type, as defined in
1742 Section 2.2.4, in the appropriate IANA registry.
1744 This memo requires IANA to register the "from" and "until" attributes
1745 for the "timemap" Relation Type, as defined in Section 2.2.4, in the
1746 appropriate IANA registry.
1748 7. Security Considerations
1750 Provision of a "timegate" HTTP "Link" header in responses to requests
1751 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1752 response codes) is OPTIONAL. The inclusion of this Link when
1753 requesting authentication is at the server's discretion; cases may
1754 exist in which a server protects the current state of a resource, but
1755 supports open access to prior states and thus chooses to supply a
1756 "timegate" HTTP "Link" header. Conversely, the server may choose to
1757 not advertise the TimeGate URIs (e.g., they exist in an intranet
1758 archive) for unauthenticated requests.
1760 The veracity of archives and the relationships between Original
1761 Resources and Mementos is beyond the scope of this document. Even in
1762 the absence of malice, it is possible for separate archives to have
1763 different Mementos for the same Original Resource at the same
1764 datetime if the state of the Original Resource was dependent on the
1765 requesting archive's user agent IP address, specific HTTP request
1766 headers, and possibly other factors.
1768 Further authentication, encryption and other security related issues
1769 are otherwise orthogonal to Memento.
1771 8. Changelog
1773 v07 2013-07-08 HVDS MLN RS draft-vandesompel-memento-08
1775 o Added the Special Case where a server that generally supports
1776 datetime negotiation indicates that a given resource is not
1777 subject to datetime negotiation.
1779 v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07
1781 o Introduced "Overview" section to make the existence of two
1782 components (datetime negotiation and TimeMaps) more explicit.
1784 o Replaced the hard-to-interpret summary table detailing the use of
1785 headers (introduced in version 06 ) with an explicit version in
1786 the appendix.
1788 o Revised the abstract.
1790 o Added TimeMaps to the enumeration of core components in the
1791 Purpose section.
1793 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06
1795 o Major overhaul of the presentation of the specification.
1797 o Specification of patterns whereby URI-R=URI-G and with both 200
1798 and 302 negotation style.
1800 o Removal of Discovery section to increase focus on datetime
1801 negotation aspects.
1803 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05
1805 o Clarified the section on Memento Relation Types.
1807 o Re-introduced "license" attribute for "memento" Relation Type as
1808 it will become essential for IIPC.
1810 o Introduced from and until attributes for "timemap" links to
1811 accomodate paged TimeMap cases.
1813 o Introduced the notion of Redirecting Resource and inserted related
1814 information in various sections.
1816 o Added discovery of Mementos via host-meta.
1818 o Corrected ambiguous uses of the term "representation".
1820 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
1822 o Removed the possibility to use an interval indicator in an Accept-
1823 Datetime header as no one is implementing it.
1825 o Corrected typo in Other Relation Types table.
1827 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap
1828 paging.
1830 o Changed Discovery component from using robots.txt with Memento-
1831 specific add-ons to well-known URI and host-meta.
1833 o Removed "embargo" and "license" attributes for links with a
1834 "memento" Relation Type because no one is using them.
1836 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1838 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1839 5XX status code.
1841 o Clarified that a TimeGate must not use the "Memento-Datetime"
1842 header.
1844 o Added wording to warn for possible cache problems with Memento
1845 implementations that choose to have an Original Resource and and
1846 its TimeGate coincide.
1848 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1850 o Added scenario in which a TimeGate redirects to another TimeGate.
1852 o Reorganized TimeGate section to better reflect the difference
1853 between requests with and without interval indicator.
1855 o Added recommendation to provide "memento" links to Mementos in the
1856 vicinity of the preferred interval provided by the user agent, in
1857 case of a 406 response.
1859 o Removed TimeMap Feed material from the Discovery section as a
1860 result of discussions regarding (lack of) scalability of the
1861 approach with representatives of the International Internet
1862 Preservation Consortium. An alternative approach to support batch
1863 discovery of Mementos will be specified.
1865 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1867 o Introduced wording and reference to indicate a Memento is a
1868 FixedResource.
1870 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1871 about retaining "Memento-Datetime" headers and values when a
1872 Memento is mirrored at different URI.
1874 o Introduced section about handling both datetime and regular
1875 negotiation.
1877 o Introduced section about Mementos Without TimeGate.
1879 o Made various changes in the section Relation Type "memento",
1880 including addition of "license" and "embargo" attributes, and
1881 clarification of rules regarding the use of "memento" links.
1883 o Moved section about TimeMaps inside the Datetime Negotiation
1884 section, and updated it.
1886 o Restarted the Discovery section from scratch.
1888 v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel-
1889 memento-00
1891 v00 2010-10-19 HVDS MLN RS Limited circulation version
1893 2010-07-22 HVDS MLN First internal version
1895 9. Acknowledgements
1897 The Memento effort is funded by the Library of Congress. Many thanks
1898 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1899 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers,
1900 James Anderson, Tim Starling, Martin Klein, Mark Nottingham for
1901 feedback. Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla
1902 Balakireva, Frank McCown, Harihar Shankar, Brad Tofel, Andrew
1903 Jackson, Ahmed Alsum, Mat Kelly, Ilya Kreymer for implementations
1904 that informed the specification.
1906 10. References
1908 10.1. Normative References
1910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1911 Requirement Levels", BCP 14, RFC 2119, March 1997.
1913 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1914 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1915 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1917 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
1918 4151, October 2005.
1920 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1921 Syndication Format", RFC 4287, December 2005.
1923 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
1924 Uniform Resource Identifiers (URIs)", RFC 5785, April
1925 2010.
1927 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
1928 for Simple Version Navigation between Web Resources", RFC
1929 5829, April 2010.
1931 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
1933 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC
1934 6415, October 2011.
1936 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
1937 Format", RFC 6690, August 2012.
1939 [RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903,
1940 March 2013.
1942 10.2. Informative References
1944 [Fitch] Fitch, ., "Web site archiving - an approach to recording
1945 every materially different response produced by a
1946 website", July 2003,
1947 .
1949 [I-D.masinter-dated-uri]
1950 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
1951 dated URIs", draft-masinter-dated-uri-10 (work in
1952 progress), January 2012.
1954 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1955 and Support", STD 3, RFC 1123, October 1989.
1957 [W3C.REC-aww-20041215]
1958 Jacobs, . and . Walsh, "Architecture of the World Wide
1959 Web", December 2004, .
1961 [W3C.gen-ont-20090420]
1962 Berners-Lee, ., "Architecture of the World Wide Web",
1963 April 2009, .
1965 Appendix A. Appendix: Use of Headers and Relation Types per Pattern
1967 +--------------------+--------------+----------+----------+---------+
1968 | Response Header | Pattern | Original | TimeGate | Memento |
1969 | | | Resource | | |
1970 +--------------------+--------------+----------+----------+---------+
1971 | Vary: accept- | Pattern 1.1 | 1 | 1 | 0 |
1972 | datetime | (Section | | | |
1973 | | 4.1.1) ; | | | |
1974 | | Pattern 1.2 | | | |
1975 | | (Section | | | |
1976 | | 4.1.2) | | | |
1977 | | Pattern 1.3 | 1 | 1 | 1 |
1978 | | (Section | | | |
1979 | | 4.1.3) | | | |
1980 | | Pattern 2.1 | 0 | 1 | 0 |
1981 | | (Section | | | |
1982 | | 4.2.1) ; | | | |
1983 | | Pattern 2.2 | | | |
1984 | | (Section | | | |
1985 | | 4.2.2) | | | |
1986 | | Pattern 2.3 | 0 | 1 | 1 |
1987 | | (Section | | | |
1988 | | 4.2.3) | | | |
1989 | | Pattern 3 | 1 | NA | 1 |
1990 | | (Section | | | |
1991 | | 4.3) | | | |
1992 | | Pattern 4 | 0 | NA | 1 |
1993 | | (Section | | | |
1994 | | 4.4) | | | |
1995 | Memento-Datetime | Pattern 1.1 | 0 | 0 | 1 |
1996 | | (Section | | | |
1997 | | 4.1.1) ; | | | |
1998 | | Pattern 1.2 | | | |
1999 | | (Section | | | |
2000 | | 4.1.1) | | | |
2001 | | Pattern 1.3 | 1 | 1 | 1 |
2002 | | (Section | | | |
2003 | | 4.1.3) | | | |
2004 | | Pattern 2.1 | 0 | 0 | 1 |
2005 | | (Section | | | |
2006 | | 4.2.1) ; | | | |
2007 | | Pattern 2.2 | | | |
2008 | | (Section | | | |
2009 | | 4.2.2) | | | |
2010 | | Pattern 2.3 | 0 | 1 | 1 |
2011 | | (Section | | | |
2012 | | 4.2.3) | | | |
2013 | | Pattern 3 | 1 | NA | 1 |
2014 | | (Section | | | |
2015 | | 4.3) | | | |
2016 | | Pattern 4 | 0 | NA | 1 |
2017 | | (Section | | | |
2018 | | 4.4) | | | |
2019 | Link | | | | |
2020 | rel="original" | Pattern 1.1 | 0 | 1 | 1 |
2021 | | (Section | | | |
2022 | | 4.1.1) ; | | | |
2023 | | Pattern 1.2 | | | |
2024 | | (Section | | | |
2025 | | 4.1.1) | | | |
2026 | | Pattern 1.3 | 1 | 1 | 1 |
2027 | | (Section | | | |
2028 | | 4.1.3) | | | |
2029 | | Pattern 2.1 | 0 | 1 | 1 |
2030 | | (Section | | | |
2031 | | 4.2.1) ; | | | |
2032 | | Pattern 2.2 | | | |
2033 | | (Section | | | |
2034 | | 4.2.2) | | | |
2035 | | Pattern 2.3 | 0 | 1 | 1 |
2036 | | (Section | | | |
2037 | | 4.2.3) | | | |
2038 | | Pattern 3 | 1 | NA | 1 |
2039 | | (Section | | | |
2040 | | 4.3) | | | |
2041 | | Pattern 4 | 0 | NA | 1 |
2042 | | (Section | | | |
2043 | | 4.4) | | | |
2044 | rel="timegate" | Pattern 1.1 | >=0 | >=0 | >=0 |
2045 | | (Section | | | |
2046 | | 4.1.1) ; | | | |
2047 | | Pattern 1.2 | | | |
2048 | | (Section | | | |
2049 | | 4.1.1) | | | |
2050 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2051 | | (Section | | | |
2052 | | 4.1.3) | | | |
2053 | | Pattern 2.1 | >=0 | 0 | >=0 |
2054 | | (Section | | | |
2055 | | 4.2.1) ; | | | |
2056 | | Pattern 2.2 | | | |
2057 | | (Section | | | |
2058 | | 4.2.2) | | | |
2059 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2060 | | (Section | | | |
2061 | | 4.2.3) | | | |
2062 | | Pattern 3 | NA | NA | NA |
2063 | | (Section | | | |
2064 | | 4.3) | | | |
2065 | | Pattern 4 | NA | NA | NA |
2066 | | (Section | | | |
2067 | | 4.4) | | | |
2068 | rel="timemap" | Pattern 1.1 | >=0 | >=0 | >=0 |
2069 | | (Section | | | |
2070 | | 4.1.1) ; | | | |
2071 | | Pattern 1.2 | | | |
2072 | | (Section | | | |
2073 | | 4.1.1) | | | |
2074 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2075 | | (Section | | | |
2076 | | 4.1.3) | | | |
2077 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2078 | | (Section | | | |
2079 | | 4.2.1) ; | | | |
2080 | | Pattern 2.2 | | | |
2081 | | (Section | | | |
2082 | | 4.2.2) | | | |
2083 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2084 | | (Section | | | |
2085 | | 4.2.3) | | | |
2086 | | Pattern 3 | >=0 | NA | >=0 |
2087 | | (Section | | | |
2088 | | 4.3) | | | |
2089 | | Pattern 4 | >=0 | NA | >=0 |
2090 | | (Section | | | |
2091 | | 4.4) | | | |
2092 | rel="memento" | Pattern 1.1 | >=0 | >=0 | >=0 |
2093 | | (Section | | | |
2094 | | 4.1.1) ; | | | |
2095 | | Pattern 1.2 | | | |
2096 | | (Section | | | |
2097 | | 4.1.1) | | | |
2098 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2099 | | (Section | | | |
2100 | | 4.1.3) | | | |
2101 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2102 | | (Section | | | |
2103 | | 4.2.1) ; | | | |
2104 | | Pattern 2.2 | | | |
2105 | | (Section | | | |
2106 | | 4.2.2) | | | |
2107 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2108 | | (Section | | | |
2109 | | 4.2.3) | | | |
2110 | | Pattern 3 | >=0 | NA | >=0 |
2111 | | (Section | | | |
2112 | | 4.3) | | | |
2113 | | Pattern 4 | >=0 | NA | >=0 |
2114 | | (Section | | | |
2115 | | 4.4) | | | |
2116 +--------------------+--------------+----------+----------+---------+
2118 Table 5: Memento Headers
2120 Authors' Addresses
2121 Herbert VandeSompel
2122 Los Alamos National Laboratory
2123 PO Box 1663
2124 Los Alamos, New Mexico 87545
2125 USA
2127 Phone: +1 505 667 1267
2128 Email: hvdsomp@gmail.com
2129 URI: http://public.lanl.gov/herbertv/
2131 Michael Nelson
2132 Old Dominion University
2133 Norfolk, Virginia 23529
2134 USA
2136 Phone: +1 757 683 6393
2137 Email: mln@cs.odu.edu
2138 URI: http://www.cs.odu.edu/~mln/
2140 Robert Sanderson
2141 Los Alamos National Laboratory
2142 PO Box 1663
2143 Los Alamos, New Mexico 87545
2144 USA
2146 Phone: +1 505 665 5804
2147 Email: azaroth42@gmail.com
2148 URI: http://public.lanl.gov/rsanderson/