idnits 2.17.1
draft-vandesompel-memento-09.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 (September 10, 2013) is 3874 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 1935, but no explicit
reference was found in the text
== Unused Reference: 'RFC4287' is defined on line 1938, but no explicit
reference was found in the text
== Unused Reference: 'RFC5785' is defined on line 1941, but no explicit
reference was found in the text
== Unused Reference: 'RFC6415' is defined on line 1951, 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: March 14, 2014 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 September 10, 2013
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-09
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 March 14, 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 . . . . . . . . . . . . . . 29
100 4.5.5. Memento of responses with 4XX or 5XX HTTP status
101 codes . . . . . . . . . . . . . . . . . . . . . . . . 30
102 4.5.6. Sticky "Memento-Datetime" and "original" link for
103 Mementos . . . . . . . . . . . . . . . . . . . . . . 31
104 4.5.7. Intermediate Resources . . . . . . . . . . . . . . . 32
105 4.5.8. Resources excluded from datetime negotiation . . . . 33
106 5. TimeMaps: Content and Serialization . . . . . . . . . . . . . 33
107 5.1. Special Cases . . . . . . . . . . . . . . . . . . . . . . 35
108 5.1.1. Index and Paging TimeMaps . . . . . . . . . . . . . . 35
109 5.1.2. Mementos for TimeMaps . . . . . . . . . . . . . . . . 37
110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
112 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38
113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
115 10.1. Normative References . . . . . . . . . . . . . . . . . . 41
116 10.2. Informative References . . . . . . . . . . . . . . . . . 42
117 Appendix A. Appendix: Use of Headers and Relation Types per
118 Pattern . . . . . . . . . . . . . . . . . . . . . . 43
119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
121 1. Introduction
123 1.1. Terminology
125 This specification uses the terms "resource", "request", "response",
126 "entity-body", "content negotiation", "user agent", "server" as
127 described in [RFC2616], and it uses the terms "representation" and
128 "resource state" as described in [W3C.REC-aww-20041215].
130 In addition, the following terms specific to the Memento framework
131 are introduced:
133 o Original Resource: An Original Resource is a resource that exists
134 or used to exist, and for which access to one of its prior states
135 may be required.
137 o Memento: A Memento for an Original Resource is a resource that
138 encapsulates a prior state of the Original Resource. A Memento
139 for an Original Resource as it existed at time T is a resource
140 that encapsulates the state the Original Resource had at time T.
142 o TimeGate: A TimeGate for an Original Resource is a resource that
143 is capable of datetime negotiation to support access to prior
144 states of the Original Resource.
146 o TimeMap: A TimeMap for an Original Resource is a resource from
147 which a list of URIs of Mementos of the Original Resource is
148 available.
150 1.2. Notational Conventions
152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
154 document are to be interpreted as described in [RFC2119].
156 When needed for extra clarity, the following conventions are used:
158 o URI-R is used to denote the URI of an Original Resource.
160 o URI-G is used to denote the URI of a TimeGate.
162 o URI-M is used to denote the URI of a Memento.
164 o URI-T is used to denote the URI of a TimeMap.
166 1.3. Purpose
168 The state of an Original Resource may change over time.
169 Dereferencing its URI at any specific moment yields a response that
170 reflects the resource's state at that moment: a representation of the
171 resource's state (e.g. "200 OK" HTTP status code), an indication of
172 its non-existence (e.g. "404 Not Found" HTTP status code), a relation
173 to another resource (e.g. "302 Found" HTTP status code), etc.
174 However, responses may also exist that reflect prior states of an
175 Original Resource: a representation of a prior state of the Original
176 Resource, an indication that the Original Resource did not exist at
177 some time in the past, a relation that the Original Resource had to
178 another resource at some time in the past, etc. Mementos that
179 provide such responses exist in web archives, content management
180 systems, or revision control systems, among others. For any given
181 Original Resource several Mementos may exist, each one reflecting a
182 frozen prior state of the Original Resource.
184 Examples are:
186 Mementos for Original Resource http://www.ietf.org/ :
188 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
190 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
191 www.ietf.org/
193 Mementos for Original Resource http://en.wikipedia.org/wiki/
194 Hypertext_Transfer_Protocol :
196 o http://en.wikipedia.org/w/
197 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
199 o http://en.wikipedia.org/w/
200 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
202 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
203 wiki/Hypertext_Transfer_Protocol
205 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
207 o http://www.w3.org/TR/2004/PR-webarch-20041105/
209 o http://www.w3.org/TR/2002/WD-webarch-20020830/
211 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
212 www.w3.org/TR/webarch/
214 In the abstract, the Memento framework introduces a mechanism to
215 access versions of web resources that:
217 o Is fully distributed in the sense that resource versions may
218 reside on multiple servers, and that any such server is likely
219 only aware of the versions it holds;
221 o Uses the global notion of datetime as a resource version indicator
222 and access key;
224 o Leverages the following primitives of [W3C.REC-aww-20041215]:
225 resource, resource state, representation, content negotiation, and
226 link.
228 The core components of Memento's mechanism to access resource
229 versions are:
231 1. The abstract notion of the state of an Original Resource (URI-R)
232 as it existed at datetime T. Note the relationship with the ability
233 to identify the state of a resource at datetime T by means of a URI
234 as intended by the proposed Dated URI scheme
235 [I-D.masinter-dated-uri].
237 2. A "bridge" from the present to the past, consisting of:
239 o The existence of a TimeGate (URI-G), which is aware of (at least
240 part of the) version history of the Original Resource (URI-R);
242 o The ability to negotiate in the datetime dimension with that
243 TimeGate (URI-G), as a means to access the state that the Original
244 Resource (URI-R) had at datetime T.
246 3. A "bridge" from the past to the present, consisting of an
247 appropriately typed link from a Memento (URI-M), which encapsulates
248 the state the Original Resource (URI-R) had at datetime T, to the
249 Original Resource (URI-R).
251 4. The existence of a TimeMap (URI-T) from which a list of all
252 Mementos that encapsulate a prior state of the Original Resource
253 (URI-R) can be obtained.
255 This document is concerned with specifying an instantiation of these
256 abstractions for resources that are identified by HTTP(S) URIs.
258 2. HTTP headers, Link Relation Types
260 The Memento framework is concerned with HEAD and GET interactions
261 with Original Resources, TimeGates, Mementos, and TimeMaps that are
262 identified by HTTP or HTTPS URIs. Details are only provided for
263 resources identified by HTTP URIs but apply similarly to those with
264 HTTPS URIs.
266 2.1. HTTP Headers
268 The Memento framework operates at the level of HTTP request and
269 response headers. It introduces two new headers ("Accept-Datetime",
270 "Memento-Datetime") and introduces new values for two existing
271 headers ("Vary", "Link"). Other HTTP headers are present or absent
272 in Memento response/request cycles as specified by [RFC2616].
274 2.1.1. Accept-Datetime, Memento-Datetime
276 The "Accept-Datetime" request header is trasnmitted by a user agent
277 to indicate it wants to access a past state of an Original Resource.
278 To that end, the "Accept-Datetime" header is conveyed in an HTTP
279 request issued against a TimeGate for an Original Resource, and its
280 value indicates the datetime of the desired past state of the
281 Original Resource.
283 Example of an "Accept-Datetime" request header:
285 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
287 The "Memento-Datetime" response header is used by a server to
288 indicate that a response reflects a prior state of an Original
289 Resource. Its value expresses the datetime of that state. The URI
290 of the Original Resource for which the response reflects a prior
291 state is provided as the Target IRI of a link provided in the HTTP
292 "Link" header that has a Relation Type of "original" (see
293 Section 2.2).
295 The presence of a "Memento-Datetime" header and associated value for
296 a given response constitutes a promise that the resource state
297 reflected in the response will no longer change (see Section 4.5.6).
299 Example of a "Memento-Datetime" response header:
301 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
303 Values for the "Accept-Datetime" and "Memento-Datetime" headers
304 consist of a MANDATORY datetime expressed according to the [RFC1123]
305 format, which is formalized by the rfc1123-date construction rule of
306 the BNF in Figure 1. The datetime is case-sensitive with names for
307 days and months exactly as shown in the wkday and month construction
308 rules of the BNF, respectively. The datetime MUST be represented in
309 Greenwich Mean Time (GMT).
311 accept-dt-value = rfc1123-date
312 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
313 date1 = 2DIGIT SP month SP 4DIGIT
314 ; day month year (e.g., 20 Mar 1957)
315 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
316 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
317 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
318 "Sun"
319 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
320 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
322 Figure 1: BNF for the datetime format
324 2.1.2. Vary
326 Generally, the "Vary" header is used in HTTP responses to indicate
327 the dimensions in which content negotiation is possible. In the
328 Memento framework, a TimeGate uses the "Vary" header with a value
329 that includes "accept-datetime" to convey that datetime negotation is
330 possible.
332 For example, this use of the "Vary" header indicates that datetime is
333 the only dimension in which negotiation is possible:
335 Vary: accept-datetime
337 The use of the "Vary" header in this example shows that both datetime
338 negotiation, and media type content negotiation are possible:
340 Vary: accept-datetime, accept
342 2.1.3. Link
344 The Memento framework defines the "original", "timegate", "timemap",
345 and "memento" Relation Types to convey typed links among Original
346 Resources, TimeGates, Mementos, and TimeMaps. The are defined in
347 Section 2.2, below. In addition, existing Relation Types may be
348 used, for example, to support navigating among Mementos. Examples
349 are "first", "last", "prev", "next", "predecessor-version",
350 "successor-version" as detailed in [RFC5988] and [RFC5829].
352 2.2. Link Relation Types
354 This section introduces the Relation Types used in the Memento
355 framework. They are defined in a general way and their use in HTTP
356 "Link" Headers [RFC5988] is described in detail. The use of these
357 Relation Types in TimeMaps is described in Section 5.
359 2.2.1. Link Relation Type "original"
361 "original" -- A link with an "original" Relation Type is used to
362 point from a TimeGate or a Memento to its associated Original
363 Resource.
365 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
366 issued against a TimeGate or a Memento MUST include exactly one link
367 with an "original" Relation Type in their HTTP "Link" header.
369 2.2.2. Link Relation Type "timegate"
371 "timegate" -- A link with a "timegate" Relation Type is used to point
372 from the Original Resource, as well as from a Memento associated with
373 the Original Resource, to a TimeGate for the Original Resource.
375 Use in HTTP "Link" headers: If there is a TimeGate associated with an
376 Original Resource or Memento that is preferred for use, then
377 responses to HTTP HEAD/GET requests issued against these latter
378 resources MUST include a link with a "timegate" Relation Type in
379 their HTTP "Link" header. Since multiple TimeGates can exist for any
380 Original Resource, multiple "timegate" links MAY occur, each with a
381 distinct Target IRI.
383 2.2.3. Link Relation Type "timemap"
385 "timemap" -- A link with a "timemap" Relation Type is used to point
386 from a TimeGate or a Memento associated with an Original Resource, as
387 well as from the Original Resource itself, to a TimeMap for the
388 Original Resource.
390 Attributes: A link with a "timemap" Relation Type SHOULD use the
391 "type" attribute to convey the mime type of the TimeMap
392 serialization. The "from" and "until" attributes may be used to
393 express the start and end of the temporal interval covered by
394 Mementos listed in the TimeMap. That is, the linked TimeMap will not
395 contain Mementos with archival datetimes outside of the expressed
396 temporal interval. Attempts SHOULD be made to convey this interval
397 as accurately as possible. The value for the these attributes MUST
398 be a datetime expressed according to the rfc1123-date construction
399 rule of the BNF in Figure 1 and it MUST be represented in Greenwich
400 Mean Time (GMT).
402 Use in HTTP "Link" headers: If there is a TimeMap associated with an
403 Original Resource, a TimeGate or a Memento that is preferred for use,
404 then responses to HTTP HEAD/GET requests issued against these latter
405 resources MUST include a link with a "timemap" Relation Type in their
406 HTTP "Link" header. Multiple such links, each with a distinct Target
407 IRI, MAY be expressed as a means to point to different TimeMaps or to
408 different serializations of the same TimeMap. In all cases, use of
409 the "from" and "until" attributes is OPTIONAL.
411 2.2.4. Link Relation Type "memento"
413 "memento" -- A link with a "memento" Relation Type is used to point
414 from a TimeGate or a Memento for an Original Resource, as well as
415 from the Original Resource itself, to a Memento for the Original
416 Resource.
418 Attributes: A link with a "memento" Relation Type MUST include a
419 "datetime" attribute with a value that matches the "Memento-Datetime"
420 of the Memento that is the target of the link; that is, the value of
421 the "Memento-Datetime" header that is returned when the URI of the
422 linked Memento is dereferenced. The value for the "datetime"
423 attribute MUST be a datetime expressed according to the rfc1123-date
424 construction rule of the BNF in Figure 1 and it MUST be represented
425 in Greenwich Mean Time (GMT). This link MAY include a "license"
426 attribute to associate a license with the Memento; the value for the
427 "license" attribute MUST be a URI.
429 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
430 issued against an Original Resource, a TimeGate and a Memento MAY
431 include links in their HTTP "Link" headers with a "memento" Relation
432 Type. For responses in which a Memento is selected, the provision of
433 navigational links that lead to Mementos other than the selected one
434 can be beneficial to the user agent. Of special importance are links
435 that lead to the temporally first and last Memento known to the
436 responding server, as well as links leading to Mementos that are
437 temporally adjacent to the selected one.
439 3. Overview of the Memento Framework
441 The Memento framework defines two complementary approaches to support
442 obtaining representations of prior states of an Original Resource:
444 o Datetime Negotiation: Datetime negotiation is a variation on
445 content negotiation by which a user agent expresses a datetime
446 preference pertaining to the representation of an Original
447 Resource, instead of, for example, a media type preference. Based
448 on the responding server's knowledge of the past of the Original
449 Resource, it selects a Memento of the Original Resource that best
450 meets the user agent's datetime preference. An overview is
451 provided in Section 3.1; details are in Section 4.
453 o TimeMaps: A TimeMap is a resource from which a list can be
454 obtained that provides a comprehensive overview of the past of an
455 Original Resource. A server makes a TimeMap available that
456 enumerates all Mementos that the server is aware of, along with
457 their archival datetime. A user agent can obtain the TimeMap and
458 select Mementos from it. An overview is provided in Section 3.2;
459 details are in Section 5.
461 3.1. Datetime Negotiation
462 Figure 2 provides a schematic overview of a successful request/
463 response chain that involves datetime negotiation. Dashed lines
464 depict HTTP transactions between user agent and server. The
465 interactions are for a scenario where the Original Resource resides
466 on one server, whereas both its TimeGate and Mementos reside on
467 another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also
468 exist in which all these resources are on the same server (for
469 example, content management systems) or all are on different servers
470 (for example, an aggregator of TimeGates).
472 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R
473 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
474 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G
475 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
476 URI-R,URI-T ------------------------------------------> URI-G
477 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M
478 6: UA <-- HTTP 200; Memento-Datetime: T; Link:
479 URI-R,URI-T,URI-G ------------------------------------- URI-M
481 Figure 2: A datetime negotiation request/response chain
483 o Step 1: The user agent that wants to access a prior state of the
484 Original Resource issues an HTTP HEAD/GET against URI-R that has
485 an "Accept-Datetime" HTTP header with a value of the datetime of
486 the desired state.
488 o Step 2: The response from URI-R includes an HTTP "Link" header
489 with a Relation Type of "timegate" pointing at a TimeGate (URI-G)
490 for the Original Resource.
492 o Step 3: The user agent starts the datetime negotiation process
493 with the TimeGate by issuing an HTTP GET request against URI-G
494 that has an "Accept-Datetime" HTTP header with a value of the
495 datetime of the desired prior state of the Original Resource.
497 o Step 4: The response from URI-G includes a "Location" header
498 pointing at a Memento (URI-M) for the Original Resource. In
499 addition, the response contains an HTTP "Link" header with a
500 Relation Type of "original" pointing at the Original Resource
501 (URI-R), and an HTTP "Link" header with a Relation Type of
502 "timemap" pointing at a TimeMap (URI-T).
504 o Step 5: The user agent issues an HTTP GET request against URI-M.
506 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP
507 header with a value of the archival datetime of the Memento. It
508 also contains an HTTP "Link" header with a Relation Type of
509 "original" pointing at the Original Resource (URI-R), with a
510 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the
511 Original Resource, and with a Relation Type of "timemap" pointing
512 at a TimeMap (URI-T) for the Original Resource. The state that is
513 expressed by the response is the state the Original Resource had
514 at the archival datetime expressed in the "Memento-Datetime"
515 header.
517 In order to respond to a datetime negotiation request, the server
518 uses an internal algorithm to select the Memento that best meets the
519 user agent's datetime preference. The exact nature of the selection
520 algorithm is at the server's discretion but is intented to be
521 consistent, for example, always selecting the Memento that is nearest
522 in time relative to the requested datetime, always selecting the
523 Memento that is nearest in the past relative to the requested
524 datetime, etc.
526 Due to the sparseness of Mementos in most systems, the value of the
527 "Memento-Datetime" header returned by a server may differ
528 (significantly) from the value conveyed by the user agent in "Accept-
529 Datetime".
531 Although a Memento encapsulates a prior state of an Original
532 Resource, the entity-body returned in response to an HTTP GET request
533 issued against a Memento may very well not be byte-to-byte the same
534 as an entity-body that was previously returned by that Original
535 Resource. Various reasons exist why there are significant chances
536 these would be different yet do convey substantially the same
537 information. These include format migrations as part of a digital
538 preservation strategy, URI-rewriting as applied by some web archives,
539 and the addition of banners as a means to brand web archives.
541 When negotiating in the datetime dimension, the regular content
542 negotiation dimensions (media type, character encoding, language, and
543 compression) remain available. It is the TimeGate server's
544 responsibility to honor (or not) such content negotiation, and in
545 doing so it MUST always first select a Memento that meets the user
546 agent's datetime preference, and then consider honoring regular
547 content negotiation for it. As a result of this approach, the
548 returned Memento will not necessarily meet the user agent's regular
549 content negotiation preferences. Therefore, it is RECOMMENDED that
550 the server provides "memento" links in the HTTP "Link" header
551 pointing at Mementos that do meet the user agent's regular content
552 negotiation requests and that have a value for the "Memento-Datetime"
553 header in the temporal vicinity of the user agent's preferred
554 datetime value.
556 A user agent that engages in datetime negotiation with a resource
557 typically starts by issuing an HTTP HEAD, not GET, request with an
558 "Accept-Datetime" header in order to determine how to proceed. This
559 strategy is related to the existence of various server implementation
560 patterns as will become clear in the below.
562 Details about the HTTP interactions involved in datetime negotation
563 are provided in Section 4.
565 3.2. TimeMaps
567 Figure 3 provides a schematic overview of a successful request/
568 response chain that shows a user agent obtaining a TimeMap. The
569 pictoral conventions are the same as the ones used in Figure 2, as is
570 the scenario. Note that, in addition to a TimeGate, an Original
571 Resource and a Memento can also provide a link to a TimeMap.
573 1: UA --- HTTP HEAD/GET ------------------------------------> URI-R
574 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
575 3: UA --- HTTP HEAD/GET ------------------------------------> URI-G
576 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
577 URI-R,URI-T ------------------------------------------> URI-G
578 5: UA --- HTTP GET URI-T -----------------------------------> URI-T
579 6: UA <-- HTTP 200 ------------------------------------------ URI-T
581 Figure 3: A request/response chain to obtain a TimeMap
583 o Step 1: The user agent that wants to access a TimeMap for the
584 Original Resource issues an HTTP HEAD/GET against URI-R. This can
585 be done with or without an "Accept-Datetime" HTTP header.
587 o Step 2: Irrespective of the use of an "Accept-Datetime" HTTP
588 header in Step 1, the response from URI-R includes an HTTP "Link"
589 header with a Relation Type of "timegate" pointing at a TimeGate
590 (URI-G) for the Original Resource.
592 o Step 3: The user agent issues an HTTP GET request against URI-G.
593 This can be done with or without an "Accept-Datetime" HTTP header.
595 o Step 4: Irrespective of the use of an "Accept-Datetime" HTTP
596 header in Step 1, the response contains an HTTP "Link" header with
597 a Relation Type of "timemap" pointing at a TimeMap (URI-T).
599 o Step 5: The user agent issues an HTTP GET request against URI-T.
601 o Step 6: The response from URI-T has an entity-body that lists all
602 Mementos for the Original Resource known to the responding server,
603 as well as their archival datetimes.
605 Details about the content and serialization of TimeMaps are provided
606 in Section 5.
608 4. Datetime Negotiation: HTTP Interactions
610 Figure 2 depicts a specific pattern to implement the Memento
611 framework. Multiple patterns exist and they can be grouped as
612 follows:
614 o Pattern 1 (Section 4.1) - The Original Resource acts as its own
615 TimeGate
617 o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for
618 the Original Resource
620 o Pattern 3 (Section 4.3) - The Original Resource is a Fixed
621 Resource
623 o Pattern 4 (Section 4.4) - Mementos without a TimeGate
625 Details of the HTTP interactions for common cases for each of those
626 patterns are provided in Section 4.1 through Section 4.4. Appendix A
627 summarizes the use of the "Vary", "Memento-Datetime", and "Link"
628 headers in responses from Original Resources, TimeGates, and Mementos
629 for the various patterns. Special cases are described in
630 Section 4.5. Note that in the following sections, the HTTP status
631 code of the responses with an entity-body is shown as "200 OK", but a
632 series of "206 Partial Content" responses could be substituted.
634 Figure 4 shows a user agent that attemtps to datetime negotiate with
635 the Original Resource http://a.example.org/ by including an "Accept-
636 Datetime" header in its HTTP HEAD request. This initiating request
637 is the same for Pattern 1 (Section 4.1) through Pattern 3
638 (Section 4.3).
640 HEAD / HTTP/1.1
641 Host: a.example.org
642 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
643 Connection: close
645 Figure 4: User Agent Attempts Datetime Negotiation With Original
646 Resource
648 4.1. Pattern 1 - The Original Resource acts as its own TimeGate
650 In this implementation pattern, the Original Resource acts as its own
651 TimeGate, which means that URI-R and URI-G coincide. Content
652 management systems and revision control systems can support datetime
653 negotiation in this way as they are commonly aware of the version
654 history of their own resources.
656 The response to this request when datetime negotiation for this
657 resource is supported depends on the negotiation style it uses
658 (200-style or 302-style) and on the existence or absence of a URI-M
659 for Mementos that is distinct from the URI-R of the associated
660 Original Resource. The various cases are summarized in the below
661 table and the server responses for each are detailed in the remainder
662 of this section.
664 +--------------+------------+------------+----------+---------------+
665 | Pattern | Original | TimeGate | Memento | Negotiation |
666 | | Resource | | | Style |
667 +--------------+------------+------------+----------+---------------+
668 | Pattern 1.1 | URI-R | URI-R | URI-M | 302 |
669 | (Section | | | | |
670 | 4.1.1) | | | | |
671 | Pattern 1.2 | URI-R | URI-R | URI-M | 200 |
672 | (Section | | | | |
673 | 4.1.2) | | | | |
674 | Pattern 1.3 | URI-R | URI-R | URI-R | 200 |
675 | (Section | | | | |
676 | 4.1.3) | | | | |
677 +--------------+------------+------------+----------+---------------+
679 Table 1: Pattern 1
681 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; distinct
682 URI-M for Mementos
684 In this case, the response to the user agent's request of Figure 4
685 has a "302 Found" HTTP status code, and the "Location" header conveys
686 the URI-M of the selected Memento. The use of Memento response
687 headers and links in the response from URI-R=URI-G is as follows:
689 o The "Vary" header MUST be provided and it MUST include the
690 "accept-datetime" value.
692 o The response MUST NOT contain a "Memento-Datetime" header.
694 o The "Link" header MUST be provided and it MUST contain at least a
695 link with the "original" Relation Type that has the URI-R of the
696 Original Resource as Target IRI. The provision of other links is
697 encouraged and is subject to the considerations described in
698 Section 2.2.
700 The server's response to the request of Figure 4 is shown in Figure
701 5. Note the inclusion of the recommended link to the TimeGate that,
702 in this case, has a Target IRI that is the URI-R of the Original
703 Resource.
705 HTTP/1.1 302 Found
706 Date: Thu, 21 Jan 2010 00:06:50 GMT
707 Server: Apache
708 Vary: accept-datetime
709 Location:
710 http://a.example.org/?version=20010911203610
711 Link: ; rel="original timegate"
712 Content-Length: 0
713 Content-Type: text/plain; charset=UTF-8
714 Connection: close
716 Figure 5: Response from URI-R=URI-G for Pattern 1.1
718 In a subsequent request, shown in Figure 6, the user agent can obtain
719 the selected Memento by issuing an HTTP GET request against the URI-M
720 that was provided in the "Location" header. The inclusion of the
721 "Accept-Datetime" header in this request is not needed but will
722 typically occur as the user agent is in datetime negotiation mode.
724 GET /?version=20010911203610 HTTP/1.1
725 Host: a.example.org
726 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
727 Connection: close
729 Figure 6: User Agent Requests Selected Memento
731 The response has a "200 OK" HTTP status code and the entity-body of
732 the response contains the representation of the selected Memento.
733 The use of Memento response headers and links in the response from
734 URI-M is as follows:
736 o A "Vary" header that includes an "accept-datetime" value MUST NOT
737 be provided.
739 o The response MUST include a "Memento-Datetime" header. Its value
740 expresses the archival datetime of the Memento.
742 o The "Link" header MUST be provided and it MUST contain at least a
743 link with the "original" Relation Type that has the URI-R of the
744 Original Resource as Target IRI. The provision of other links is
745 encouraged and is subject to the considerations described in
746 Section 2.2.
748 The server's response to the request of Figure 6 is shown in Figure
749 7. Note the provision of the required "original", and the
750 recommended "timegate" and "timemap" links. The former two point to
751 the Original Resource, which acts as its own TimeGate. The latter
752 has "from" and "until" attributes to indicate the temporal interval
753 covered by Mementos listed in the linked TimeMap.
755 HTTP/1.1 200 OK
756 Date: Thu, 21 Jan 2010 00:06:51 GMT
757 Server: Apache-Coyote/1.1
758 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
759 Link: ; rel="original timegate",
760
761 ; rel="timemap"; type="application/link-format"
762 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
763 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
764 Content-Length: 23364
765 Content-Type: text/html;charset=utf-8
766 Connection: close
768 Figure 7: Response from URI-M for Pattern 1.1
770 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; distinct
771 URI-M for Mementos
773 In this case, the response to the user agent's request of Figure 4
774 has a "200 OK" HTTP status code, and the "Content-Location" header
775 conveys the URI-M of the selected Memento. The use of Memento
776 response headers and links in the response from URI-R=URI-G is as
777 follows:
779 o The "Vary" header MUST be provided and it MUST include the
780 "accept-datetime" value.
782 o The response MUST include a "Memento-Datetime" header. Its value
783 expresses the archival datetime of the selected Memento.
785 o The "Link" header MUST be provided and it MUST contain at least a
786 link with the "original" Relation Type that has the URI-R of the
787 Original Resource as Target IRI. The provision of other links is
788 encouraged and is subject to the considerations described in
789 Section 2.2.
791 The server's response to the request of Figure 4 is shown in Figure
792 8. Note the provision of optional "memento" links pointing at the
793 oldest and most recent Memento for the Original Resource known to the
794 responding server.
796 HTTP/1.1 200 OK
797 Date: Thu, 21 Jan 2010 00:06:50 GMT
798 Server: Apache
799 Vary: accept-datetime
800 Content-Location:
801 http://a.example.org/?version=20010911203610
802 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
803 Link: ; rel="original timegate",
804
805 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
806
807 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT",
808
809 ; rel="timemap"; type="application/link-format"
810 Content-Length: 2312
811 Content-Type: text/html; charset=UTF-8
812 Connection: close
814 Figure 8: Response from URI-R=URI-G for Pattern 1.2
816 In a subsequent request, which is the same as Figure 4 but with HTTP
817 GET instead of HEAD, the user agent can obtain the representation of
818 the selected Memento. It will be provided as the entity-body of a
819 response that has the same Memento headers as in Figure 8.
821 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; no distinct
822 URI-M for Mementos
824 In this case, the response to the user agent's request of Figure 4
825 has a "200 OK" HTTP status code, and it does not contain a "Content-
826 Location" nor "Location" header as there is no URI-M of the selected
827 Memento to convey. The use of Memento response headers and links in
828 the response from URI-R=URI-G is as follows:
830 o The "Vary" header MUST be provided and it MUST include the
831 "accept-datetime" value.
833 o The response MUST include a "Memento-Datetime" header. Its value
834 expresses the archival datetime of the selected Memento.
836 o The "Link" header MUST be provided and it MUST contain at least a
837 link with the "original" Relation Type that has the URI-R of the
838 Original Resource as Target IRI. The provision of other links is
839 encouraged and is subject to the considerations described in
840 Section 2.2.
842 The server's response to the request of Figure 4 is shown in Figure
843 9. The recommended "timemap" and "timegate" links are included in
844 addition to the mandatory "original" link.
846 HTTP/1.1 200 OK
847 Date: Thu, 21 Jan 2010 00:06:50 GMT
848 Server: Apache
849 Vary: accept-datetime
850 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
851 Link: ; rel="original timegate",
852
853 ; rel="timemap"; type="application/link-format"
854 Content-Length: 0
855 Content-Type: text/plain; charset=UTF-8
856 Connection: close
858 Figure 9: Response from URI-R=URI-G for Pattern 1.3
860 In a subsequent request, which is the same as Figure 4 but with HTTP
861 GET instead of HEAD, the user agent can obtain the representation of
862 the selected Memento. It will be provided as the entity-body of a
863 response that has the same Memento headers as in Figure 9.
865 4.2. Pattern 2 - A remote resource acts as a TimeGate for the Original
866 Resource
868 In this implementation pattern, the Original Resource does not act as
869 its own TimeGate, which means that URI-R and URI-G are different.
870 This pattern is typically implemented by servers for which the
871 history of their resources is recorded in remote systems such as web
872 archives and transactional archives [Fitch]. But servers that
873 maintain their own history, such as content management systems and
874 Version Control Systems, may also implement this pattern, for
875 example, to distribute the load involved in responding to requests
876 for current and prior representations of resources between different
877 servers.
879 This pattern is summarized in the below table and is detailed in the
880 remainder of this section. Three cases exist that differ regarding
881 the negotiation style that is used by the remote TimeGate and
882 regarding the existence of a URI-M for Mementos that is distinct from
883 the URI-G of the TimeGate.
885 +--------------+------------+------------+----------+---------------+
886 | Pattern | Original | TimeGate | Memento | Negotiation |
887 | | Resource | | | Style |
888 +--------------+------------+------------+----------+---------------+
889 | Pattern 2.1 | URI-R | URI-G | URI-M | 302 |
890 | (Section | | | | |
891 | 4.2.1) | | | | |
892 | Pattern 2.2 | URI-R | URI-G | URI-M | 200 |
893 | (Section | | | | |
894 | 4.2.2) | | | | |
895 | Pattern 2.3 | URI-R | URI-G | URI-G | 200 |
896 | (Section | | | | |
897 | 4.2.3) | | | | |
898 +--------------+------------+------------+----------+---------------+
900 Table 2: Pattern 2
902 The response by the Original Resource to the request shown in Figure
903 4 is the same for all three cases. The use of headers and links in
904 the response from URI-R is as follows:
906 o A "Vary" header that includes an "accept-datetime" value MUST NOT
907 be provided.
909 o The response MUST NOT contain a "Memento-Datetime" header.
911 o The "Link" header SHOULD be provided. It MUST NOT include a link
912 with an "original" Relation Type. If a preferred TimeGate is
913 associated with the Original Resource, then it MUST include a link
914 with a "timegate" Relation Type that has the URI-G of the TimeGate
915 as Target IRI. If a preferred TimeMap is associated with the
916 Original Resource, then it SHOULD include a link with a "timemap"
917 Relation Type that has the URI-T of the TimeGate as Target IRI.
918 Multiple "timegate" and "timemap" links can be provided to
919 accommodate situations in which the server is aware of multiple
920 TimeGates or Timemaps for the Original Resource.
922 Figure 10 shows such a response. Note the absence of an "original"
923 link as the responding resource is neither a TimeGate or a Memento.
925 HTTP/1.1 200 OK
926 Date: Thu, 21 Jan 2010 00:02:12 GMT
927 Server: Apache
928 Link:
929 ; rel="timegate"
930 Content-Length: 255
931 Connection: close
932 Content-Type: text/html; charset=iso-8859-1
934 Figure 10: Response from URI-R<>URI-G for Pattern 2
936 Once a user agent has obtained the URI-G of a remote TimeGate for the
937 Original Resource it can engage in datetime negotation with that
938 TimeGate. Figure 11 shows the request issued against the TimeGate
939 whereas Section 4.2.1 through Section 4.2.3 detail the responses for
940 various TimeGate implementation patterns.
942 HEAD /timegate/http://a.example.org/ HTTP/1.1
943 Host: arxiv.example.net
944 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
945 Connection: close
947 Figure 11: User Agent Engages in Datetime Negotiation With Remote
948 TimeGate
950 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; distinct
951 URI-M for Mementos
953 In case the TimeGate uses a 302 negotiation style, the response to
954 the user agent's request of Figure 11 has a "302 Found" HTTP status
955 code, and the "Location" header conveys the URI-M of the selected
956 Memento. The use of Memento response headers and links in the
957 response from URI-G is as follows:
959 o The "Vary" header MUST be provided and it MUST include the
960 "accept-datetime" value.
962 o The response MUST NOT contain a "Memento-Datetime" header.
964 o The "Link" header MUST be provided and it MUST contain at least a
965 link with the "original" Relation Type that has the URI-R of the
966 Original Resource as Target IRI. The provision of other links is
967 encouraged and is subject to the considerations described in
968 Section 2.2.
970 The server's response to the request of Figure 11 is shown in Figure
971 12. It contains the mandatory "original" link that points back to
972 the Original Resource associated with this TimeGate and it shows the
973 recommended "timemap" link that includes "from" and "until"
974 attributes.
976 HTTP/1.1 302 Found
977 Date: Thu, 21 Jan 2010 00:02:14 GMT
978 Server: Apache
979 Vary: accept-datetime
980 Location:
981 http://arxiv.example.net/web/20010911203610/http://a.example.org/
982 Link: ; rel="original",
983
984 ; rel="timemap"; type="application/link-format"
985 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
986 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
987 Content-Length: 0
988 Content-Type: text/plain; charset=UTF-8
989 Connection: close
991 Figure 12: Response from URI-G<>URI-R for Pattern 2.1
993 In a subsequent HTTP GET request, shown in Figure 13, the user agent
994 can obtain the selected Memento by issuing an HTTP GET request
995 against the URI-M that was provided in the "Location" header. The
996 inclusion of the "Accept-Datetime" header in this request is not
997 needed but will typically occur as the user agent is in datetime
998 negotiation mode.
1000 GET /web/20010911203610/http://a.example.org/ HTTP/1.1
1001 Host: arxiv.example.net/
1002 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1003 Connection: close
1005 Figure 13: User Agent Requests Selected Memento
1007 The response has a "200 OK" HTTP status code. The use of Memento
1008 response headers and links in the response from URI-M is as follows:
1010 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1011 be provided.
1013 o The response MUST include a "Memento-Datetime" header. Its value
1014 expresses the archival datetime of the Memento.
1016 o The "Link" header MUST be provided and it MUST contain at least a
1017 link with the "original" Relation Type that has the URI-R of the
1018 Original Resource as Target IRI. The provision of other links is
1019 encouraged and is subject to the considerations described in
1020 Section 2.2.
1022 The server's response to the request of Figure 13 is shown in Figure
1023 14. Note the provision of the recommended "timegate" and "timemap"
1024 links.
1026 HTTP/1.1 200 OK
1027 Date: Thu, 21 Jan 2010 00:02:15 GMT
1028 Server: Apache-Coyote/1.1
1029 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1030 Link: ; rel="original",
1031
1032 ; rel="timemap"; type="application/link-format",
1033
1034 ; rel="timegate"
1035 Content-Length: 23364
1036 Content-Type: text/html;charset=utf-8
1037 Connection: close
1039 Figure 14: Response from URI-M for Pattern 2.1
1041 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; distinct
1042 URI-M for Mementos
1044 In case the TimeGate uses a 200 negotiation style, and each Memento
1045 has a distinct URI-M, the response to the user agent's request of
1046 Figure 11 has a "200 OK" HTTP status code, and the "Content-Location"
1047 header conveys the URI-M of the selected Memento. The use of Memento
1048 response headers and links in the response from URI-G is as follows:
1050 o The "Vary" header MUST be provided and it MUST include the
1051 "accept-datetime" value.
1053 o The response MUST include a "Memento-Datetime" header. Its value
1054 expresses the archival datetime of the Memento.
1056 o The "Link" header MUST be provided and it MUST contain at least a
1057 link with the "original" Relation Type that has the URI-R of the
1058 Original Resource as Target IRI. The provision of other links is
1059 encouraged and is subject to the considerations described in
1060 Section 2.2.
1062 The server's response to the request of Figure 11 is shown in Figure
1063 15.
1065 HTTP/1.1 200 OK
1066 Date: Thu, 21 Jan 2010 00:09:40 GMT
1067 Server: Apache-Coyote/1.1
1068 Vary: accept-datetime
1069 Content-Location:
1070 http://arxiv.example.net/web/20010911203610/http://a.example.org/
1071 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1072 Link: ; rel="original",
1073
1074 ; rel="timemap"; type="application/link-format",
1075
1076 ; rel="timegate"
1077 Content-Length: 23364
1078 Content-Type: text/html; charset=UTF-8
1079 Connection: close
1080 Figure 15: Response from URI-G<>URI-R for Pattern 2.2
1082 In a subsequent request, which is the same as Figure 11 but with HTTP
1083 GET instead of HEAD, the user agent can obtain the representation of
1084 the selected Memento. It will be provided as the entity-body of a
1085 response that has the same Memento headers as Figure 15.
1087 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct
1088 URI-M for Mementos
1090 In case the TimeGate uses a 200 negotiation style, but Mementos have
1091 no distinct URIs, the response to the user agent's request of Figure
1092 11 has a "200 OK" HTTP status code, and it does not contain a
1093 "Content-Location" nor "Location" header as there is no URI-M of the
1094 selected Memento to convey. The use of Memento response headers and
1095 links in the response from URI-G is as follows:
1097 o The "Vary" header MUST be provided and it MUST include the
1098 "accept-datetime" value.
1100 o The response MUST include a "Memento-Datetime" header. Its value
1101 expresses the archival datetime of the Memento.
1103 o The "Link" header MUST be provided and it MUST contain at least a
1104 link with the "original" Relation Type that has the URI-R of the
1105 Original Resource as Target IRI. The provision of other links is
1106 encouraged and is subject to the considerations described in
1107 Section 2.2.
1109 The server's response to the request of Figure 11 is shown in Figure
1110 16.
1112 HTTP/1.1 200 OK
1113 Date: Thu, 21 Jan 2010 00:09:40 GMT
1114 Server: Apache-Coyote/1.1
1115 Vary: accept-datetime
1116 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1117 Link: ; rel="original",
1118
1119 ; rel="timemap"; type="application/link-format",
1120
1121 ; rel="timegate"
1122 Content-Length: 23364
1123 Content-Type: text/html; charset=UTF-8
1124 Connection: close
1126 Figure 16: Response from URI-G<>URI-R for Pattern 2.3
1128 In a subsequent request, which is the same as Figure 11 but with HTTP
1129 GET instead of HEAD, the user agent can obtain the representation of
1130 the selected Memento. It will be provided as the entity-body of a
1131 response that has the same Memento headers as Figure 16.
1133 4.3. Pattern 3 - The Original Resource is a Fixed Resource
1135 This pattern does not involve datetime negotiation with a TimeGate
1136 but it can be implemented for Original Resources that never change
1137 state or do not change anymore past a certain point in their
1138 existence, meaning that URI-R and URI-M coincide either from the
1139 outset or starting at some point in time. This pattern is summarized
1140 in the below table. Examples are tweets or stable media resources on
1141 news sites.
1143 +-----------+--------------+------------+----------+----------------+
1144 | Pattern | Original | TimeGate | Memento | Negotiation |
1145 | | Resource | | | Style |
1146 +-----------+--------------+------------+----------+----------------+
1147 | Pattern 3 | URI-R | - | URI-R | - |
1148 +-----------+--------------+------------+----------+----------------+
1150 Table 3: Pattern 3
1152 Servers that host such resources can support the Memento framework by
1153 treating the stable resource (FixedResource as per
1154 [W3C.gen-ont-20090420]) as a Memento. The use of Memento response
1155 headers and links in responses from such a stable resource is as
1156 follows:
1158 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1159 be provided.
1161 o The response MUST include a "Memento-Datetime" header. Its value
1162 expresses the datetime at which the resource became stable.
1163 Providing this value includes a promise that the resource has not
1164 changed since this datetime and will not change anymore beyond it.
1166 o The "Link" header MUST be provided and MUST have a link with the
1167 "original" Relation Type that has the URI-R of the stable resource
1168 itself as Target IRI.
1170 Figure 17 shows a response to an HTTP HEAD request for the resource
1171 with URI-R http://a.example.org/ that has been stable since March
1172 20th 2009.
1174 HTTP/1.1 200 OK
1175 Date: Thu, 21 Jan 2010 00:09:40 GMT
1176 Server: Apache-Coyote/1.1
1177 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
1178 Link: ; rel="original"
1179 Content-Length: 0
1180 Content-Type: text/plain; charset=UTF-8
1181 Connection: close
1183 Figure 17: Response from URI-R=URI-M for Pattern 3
1185 4.4. Pattern 4 - Mementos without a TimeGate
1187 Cases may occur in which a server hosts Mementos but does not expose
1188 a TimeGate for them. This can, for example, be the case if the
1189 server's Mementos result from taking a snapshot of the state of a set
1190 of Original Resources from another server as it is being retired. As
1191 a result, only a single Memento per Original Resource is hosted,
1192 making the introduction of a TimeGate unnecessary. But it may also
1193 be the case for servers that host multiple Mementos for an Original
1194 Resource but consider exposing TimeGates too expensive. In this
1195 case, URI-R and URI-M are distinct, but a TimeGate is absent. This
1196 case is summarized in the below table.
1198 +-----------+--------------+------------+----------+----------------+
1199 | Pattern | Original | TimeGate | Memento | Negotiation |
1200 | | Resource | | | Style |
1201 +-----------+--------------+------------+----------+----------------+
1202 | Pattern 4 | URI-R | - | URI-M | - |
1203 +-----------+--------------+------------+----------+----------------+
1205 Table 4: Pattern 4
1207 Servers that host such Mementos without TimeGates can still support
1208 the Memento framework by providing the appropriate Memento headers
1209 and links. Their use is as follows for a response from URI-M:
1211 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1212 be provided.
1214 o The response MUST include a "Memento-Datetime" header. Its value
1215 expresses the archival datetime of the Memento.
1217 o The "Link" header MUST be provided and it MUST have a link with
1218 the "original" Relation Type that has the URI-R of the associated
1219 Original Resource as Target IRI. The provision of other links is
1220 encouraged and is subject to the considerations described in
1221 Section 2.2.
1223 Figure 18 shows a response to an HTTP HEAD request for the Memento
1224 with URI-M http://arxiv.example.net/web/20010911203610/http://
1225 a.example.org/. Note the use of links: three links have the URI-M of
1226 the Memento as Target IRI and have respective Relation Types
1227 "memento", "first", and "last". This combination indicates that this
1228 is the only Memento for the Original Resource with Target IRI
1229 provided by the "original" link (http://a.example.org/) that the
1230 server is aware of. Note also that such a response does not imply
1231 that there is no server whatsoever that exposes a TimeGate; it merely
1232 means that the responding server neither provides nor is aware of the
1233 location of a TimeGate.
1235 HTTP/1.1 200 OK
1236 Date: Thu, 21 Jan 2010 00:09:40 GMT
1237 Server: Apache-Coyote/1.1
1238 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1239 Link: ; rel="original",
1240
1241 ; rel="first last memento"
1242 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT"
1243 Content-Length: 0
1244 Content-Type: text/plain; charset=UTF-8
1245 Connection: close
1247 Figure 18: Response from URI-M<>URI-R for Pattern 4
1249 4.5. Special Cases
1251 4.5.1. Original Resource provides no "timegate" link
1253 Cases exist in which the response from the Original Resource does not
1254 contain a "timegate" link, including:
1256 o The Original Resource's server does not support the Memento
1257 framework;
1259 o The Original Resource no longer exists and the responding server
1260 is not aware of its prior existence;
1262 o The server that hosted the Original Resource no longer exists.
1264 In all these cases, the user agent should attempt to determine an
1265 appropriate TimeGate for the Original Resource, either automatically
1266 or interactively supported by the user.
1268 4.5.2. Server exists but Original Resource no longer does
1269 Cases exist in which the server knows that an Original Resource used
1270 to exist, but no longer provides a current representation. If there
1271 is a preferred TimeGate for such a discontinued Original Resource,
1272 then the server MUST include a "timegate" link in responses to
1273 requests for it. This may allow access to Mementos for the Original
1274 Resource even if it no longer exists. A server's response to a
1275 request for the discontinued resource http://a.example.org/pic is
1276 illustrated in Figure 19.
1278 HTTP/1.1 404 Not Found
1279 Date: Thu, 21 Jan 2010 00:02:12 GMT
1280 Server: Apache
1281 Link:
1282
1283 ; rel="timegate"
1284 Content-Length: 255
1285 Connection: close
1286 Content-Type: text/html; charset=iso-8909-1
1288 Figure 19: Response from an Original Resource that not longer exists
1290 4.5.3. Issues with Accept-Datetime
1292 The following special cases may occur regarding the "Accept-Datetime"
1293 header when a user agent issues a request against a TimeGate:
1295 o If the value of the "Accept-Datetime" is either earlier than the
1296 datetime of the first Memento or later than the datetime of the
1297 most recent Memento known to the TimeGate, the first or most
1298 recent Memento MUST be selected, respectively.
1300 o If the value of the "Accept-Datetime" does not conform to the
1301 rfc1123-date construction rule of the BNF in Figure 1, the
1302 response MUST have a "400 Bad Request" HTTP status code.
1304 o If a user agent issues a request against a TimeGate and fails to
1305 include an "Accept-Datetime" request header, the most recent
1306 Memento SHOULD be selected.
1308 In all cases, the use of headers and links in responses is as
1309 described for TimeGates in the respective scenarios.
1311 4.5.4. Memento of a 3XX response
1313 Cases exist in which HTTP responses with 3XX status codes are
1314 archived. For example, crawl-based web archives commonly archive
1315 responses with HTTP status codes "301 Moved Permanently" and "302
1316 Found" whereas Linked Data archives hold on to "303 See Other"
1317 responses.
1319 If the Memento requested by the user agent is an archived version of
1320 an HTTP response with a 3XX status code, the server's response MUST
1321 have the same 3XX HTTP status code. The use of other Memento headers
1322 is as described for Mementos in the respective scenarios.
1324 The user agent's handling of an HTTP response with a 3XX status code
1325 is not affected by the presence of a "Memento-Datetime" header. The
1326 user agent MUST behave in the same manner as it does with HTTP
1327 responses with a 3XX status code that do not have a "Memento-
1328 Datetime" header.
1330 However, the user agent MUST be aware that the URI that was selected
1331 from the "Location" header of an HTTP response with a 3XX status code
1332 might not be that of a Memento but rather of an Original Resource.
1333 In the latter case it SHOULD proceed by looking for a Memento of the
1334 selected Original Resource.
1336 For example, Figure 20 shows the response to an HTTP GET request for
1337 http://a.example.org issued on April 11 2008. This response is
1338 archived as a Memento of http://a.example.org that has as URI-M http:
1339 //arxiv.example.net/web/20080411000650/http://a.example.org. The
1340 response to an HTTP GET on this URI-M is shown in Figure 21. It is a
1341 replay of the original response with "Memento-Datetime" and "Link"
1342 headers added, to allow a user agent to understand the response is a
1343 Memento. In Figure 21, the value of the "Location" header is the
1344 same as in the original response; it identifies an Original Resource.
1345 The user agent proceeds with finding a Memento for this Original
1346 Resource. Web archives sometimes overwrite the value that was
1347 originally provided in the "Location" header in order to point at a
1348 Memento they hold of the resource to which the redirect originally
1349 led. This is shown in Figure 22. In this case, the user agent may
1350 decide it found an appropriate Memento.
1352 HTTP/1.1 301 Moved Permanently
1353 Date: Fri, 11 Apr 2008 00:06:50 GMT
1354 Server: Apache
1355 Location: http://b.example.org
1356 Content-Length: 0
1357 Content-Type: text/plain; charset=UTF-8
1358 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.
1408 The response to an HTTP HEAD on this URI-M is shown in Figure 24. It
1409 is a replay of the original response with "Memento-Datetime" and
1410 "Link" headers added, to allow a user agent to understand the
1411 response is a Memento.
1413 HTTP/1.1 404 Not Found
1414 Date: Fri, 11 Apr 2008 00:06:50 GMT
1415 Server: Apache
1416 Content-Length: 0
1417 Content-Type: text/plain; charset=UTF-8
1418 Connection: close
1420 Figure 23: Response is a 404
1422 HTTP/1.1 404 Not Found
1423 Date: Thu, 21 Jan 2010 00:09:40 GMT
1424 Server: Apache-Coyote/1.1
1425 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1426 Link: ; rel="original",
1427
1428 ; rel="timemap"; type="application/link-format",
1429
1430 ; rel="timegate"
1431 Content-Length: 0
1432 Content-Type: text/plain; charset=UTF-8
1433 Connection: close
1435 Figure 24: Response is a Memento of a 404
1437 4.5.6. Sticky "Memento-Datetime" and "original" link for Mementos
1439 A response to an HTTP HEAD/GET request issued against a Memento:
1441 o Includes a "Memento-Datetime" header that entails a promise that
1442 the response is archived, frozen in time. The value of the header
1443 expresses the archival datetime of the Memento.
1445 o Includes a link in the HTTP Link header with an "original"
1446 relation type that unambiguously points to the Original Resource
1447 associated with the Memento. The Target IRI of the link is the
1448 URI-R of that Original Resource.
1450 Both the "Memento-Datetime" header and the "original" link MUST be
1451 "sticky" in the following ways:
1453 o The server that originally assigns them MUST retain them in all
1454 responses to HTTP requests (with or without "Accept-Datetime"
1455 request header) that occur against the Memento after the time of
1456 their original assignment and the server MUST NOT change the value
1457 of the "Memento-Datetime" header nor the Target IRI of the
1458 "original" link.
1460 o Applications that mirror Mementos at a different URI MUST retain
1461 them and MUST NOT change them unless mirroring involves a
1462 meaningful state change. This allows, among others, duplicating a
1463 web archive at a new location while preserving the value of the
1464 "Memento-Datetime" header and the link with the "original"
1465 relation type for the archived resources. For example, when
1466 mirroring, the "Last-Modified" header will be updated to reflect
1467 the time of mirroring at the new URI, whereas the value for
1468 "Memento-Datetime" will be maintained.
1470 4.5.7. Intermediate Resources
1472 An intermediate resource is a resource that issues a redirect to a
1473 TimeGate, to a Memento, or to another intermediate resource, and thus
1474 plays an active role in the Memento infrastructure. Intermediate
1475 resources commonly exist in web archives on the path from a TimeGate
1476 to an appropriate Memento.
1478 A response of an intermediate resource has an HTTP status code
1479 indicative of HTTP redirection (e.g. 302) and uses Memento headers
1480 and links that allow to recognize that the resource plays a role in
1481 the Memento framework:
1483 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1484 be provided.
1486 o The response MUST NOT include a "Memento-Datetime" header.
1488 o The "Link" header MUST be provided and it MUST have a link with
1489 the "original" Relation Type that has the URI-R of the associated
1490 Original Resource as Target IRI. Links with "timegate",
1491 "timemap", and "memento" Relation Types are OPTIONAL and, if
1492 provided, MUST pertain to the Original Resource for which the user
1493 agent is trying to obtain a Memento.
1495 A user agent MUST follow a redirection provided by an intermediate
1496 resource; multiple such redirections can be chained.
1498 Consider the case where a user agent follows the "timegate" link
1499 provided in Figure 10 and engages in datetime negotiation with the
1500 assumed TimeGate in the manner shown in Figure 11. But instead of
1501 receiving a response as shown in Figure 12, it receives the one shown
1502 below in Figure 25. Such a response is umabiguosuly recognizable as
1503 coming from an intermediate resource.
1505 HTTP/1.1 302 Found
1506 Date: Thu, 21 Jan 2010 00:06:50 GMT
1507 Server: Apache
1508 Location:
1509 http://arxiv.example.net/new-timegate/http://a.example.org/
1510 Link: ; rel="original"
1511 Content-Length: 0
1512 Content-Type: text/plain; charset=UTF-8
1513 Connection: close
1515 Figure 25: Redirecting Resource redirects to a TimeGate
1517 4.5.8. Resources excluded from datetime negotiation
1519 When delivering a Memento to a user agent, a web archive commonly
1520 enhances that Memento's archived content, for example, by including a
1521 banner that provides branding and highlights the archival status of
1522 the Memento. The resources that are involved in providing such
1523 system-specific functionality, many times Javascript or images, must
1524 be used in their current state.
1526 A server that generally supports datetime negotiation should make
1527 resources that need to be excluded from datetime negotiation
1528 recognizable. Doing so allows a user agent to refrain from
1529 attempting to access a Memento for them. In order to achieve this,
1530 the server SHOULD include a special-purpose link in the HTTP "Link"
1531 header when responding to a HTTP HEAD/GET request to a resource
1532 excluded from datetime negotiation. This link has "http://
1533 mementoweb.org/terms/donotnegotiate" as Target IRI and "type",
1534 defined in [RFC6903], as the value of the rel attribute. Other
1535 Memento headers as defined in Section 2.1. SHOULD NOT be provided.
1537 Figure 26 shows the response to a HTTP HEAD request from a resource
1538 excluded from datetime negotiation.
1540 HTTP/1.1 200 OK
1541 Date: Thu, 21 Jan 2010 00:09:40 GMT
1542 Server: Apache-Coyote/1.1
1543 Link: ; rel="type"
1544 Content-Length: 238
1545 Content-Type: application/javascript; charset=UTF-8
1546 Connection: close
1548 Figure 26: Response to a HTTP HEAD request from a resource excluded
1549 from datetime negotiation
1551 5. TimeMaps: Content and Serialization
1552 A TimeMap is introduced to support retrieving a comprehensive list of
1553 all Mementos for a specific Original Resource known to a server. The
1554 entity-body of a response to an HTTP GET request issued against a
1555 TimeMap's URI-T:
1557 o MUST list the URI-R of the Original Resource that the TimeMap is
1558 about;
1560 o MUST list the URI-M and archival datetime of each Memento for the
1561 Original Resource known to the server, preferably in a single
1562 document, or, alternatively in multiple documents that can be
1563 gathered by following contained links with a "timemap" Relation
1564 Type;
1566 o SHOULD list the URI-G of one or more TimeGates for the Original
1567 Resource known to the responding server;
1569 o SHOULD, for self-containment, list the URI-T of the TimeMap
1570 itself;
1572 o MUST unambiguously type listed resources as being Original
1573 Resource, TimeGate, Memento, or TimeMap.
1575 The entity-body of a response from a TimeMap MAY be serialized in
1576 various ways, but the link-value format serialization described here
1577 MUST be supported. In this serialization, the entity-body MUST be
1578 formatted in the same way as the value of an HTTP "Link" header, and
1579 hence MUST comply to the "link-value" construction rule of
1580 "Section 5. The Link Header Field" of [RFC5988], and the media type
1581 of the entity-body MUST be "application/link-format" as introduced in
1582 [RFC6690]. Links contained in the entity-body MUST be interpreted as
1583 follows:
1585 o The Context IRI is set to the anchor parameter, when specified;
1587 o The Context IRI of links with the "self" Relation Types is the
1588 URI-T of the TimeMap, i.e. the URI of the resource from which the
1589 TimeMap was requested;
1591 o The Context IRI of all other links is the URI-R of the Original
1592 Resource, which is provided as the Target IRI of the link with an
1593 "original" Relation Type.
1595 In order to retrieve the link-value serialization of a TimeMap, a
1596 user agent uses an "Accept" request header with a value set to
1597 "application/link-format". This is shown in Figure 27.
1599 GET /timemap/http://a.example.org/ HTTP/1.1
1600 Host: arxiv.example.net
1601 Accept: application/link-format;q=1.0
1602 Connection: close
1604 Figure 27: Request for a TimeMap
1606 If the TimeMap requested by the user agent exists, the server's
1607 response has a "200 OK" HTTP status code and the list of Mementos is
1608 provided in the entity-body of the response. Such a response is
1609 shown in Figure 28
1611 HTTP/1.1 200 OK
1612 Date: Thu, 21 Jan 2010 00:06:50 GMT
1613 Server: Apache
1614 Content-Length: 4883
1615 Content-Type: application/link-format
1616 Connection: close
1618 ;rel="original",
1619
1620 ; rel="self";type="application/link-format"
1621 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1622 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1623
1624 ; rel="timegate",
1625
1626 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
1627 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1628
1629 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
1630 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1631
1632 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
1633 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1634
1635 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
1636 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1637 ...
1639 Figure 28: Response from a TimeMap
1641 5.1. Special Cases
1643 5.1.1. Index and Paging TimeMaps
1645 Cases exist in which a TimeMap points at one or more other TimeMaps:
1647 o Index Timemap - A TimeMap can merely point at other TimeMaps and
1648 not list any Mementos itself. This can happen when Mementos are
1649 spread across several archives that share a front-end. An example
1650 is shown in Figure 29.
1652 o Paging Timemap - The number of available Mementos can require
1653 introducing multiple TimeMaps that can be paged. An example is
1654 shown in Figure 30. Note that a Paging TimeMap contains links to
1655 other TimeMaps but actually also lists Mementos.
1657 In both cases, including the "from" and "until" attributes for
1658 "timemap" links is RECOMMENDED as a means to express the temporal
1659 span of Mementos listed in each TimeMap. Note that TimeMaps obtained
1660 by following a "timemap" link can contain links to further TimeMaps.
1662 ;rel="original",
1663
1664 ; rel="timegate",
1665
1666 ; rel="self";type="application/link-format",
1667
1668 ; rel="timemap";type="application/link-format"
1669 ; from="Wed, 21 Jun 2000 04:41:56 GMT"
1670 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1671
1672 ; rel="timemap";type="application/link-format"
1673 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1674 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1675
1676 ; rel="timemap";type="application/link-format"
1677 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1679 Figure 29: Index TimeMap
1681 ;rel="original",
1682
1683 ; rel="timegate",
1684
1685 ; rel="self";type="application/link-format"
1686 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1687 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1688
1689 ; rel="timemap";type="application/link-format"
1690 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1691 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1692
1693 ; rel="timemap";type="application/link-format"
1694 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1695 ; until="Fri, 31 Aug 2012 12:22:34 GMT"
1696
1697 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1698
1699 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1700
1701 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1702 ...
1704 Figure 30: Paging TimeMap
1706 5.1.2. Mementos for TimeMaps
1708 A TimeMap can itself act as an Original Resource for which a TimeGate
1709 and Mementos may exist. Hence, the response from a TimeMap could
1710 include a "timegate" link to a TimeGate via which prior TimeMap
1711 versions are available. And, in cases where URI-T=URI-R=URI-G (a
1712 TimeMap is an Original Resource that acts as its own TimeGate), an
1713 "original" link pointing at the TimeMap URI-T would be included.
1715 Therefore, caution is required in cases where a TimeMap for an
1716 Original Resource wants to explicitly express in a Link header for
1717 which Original Resource it is a TimeMap. It can do so by including a
1718 "timemap" link that has the URI-R of the Original Resource as Context
1719 IRI and the URI-T of the TimeMap as Target IRI.
1721 Figure 31 shows the response to an HTTP HEAD request against a
1722 TimeMap that has http://arxiv.example.net/timemap/http://
1723 a.example.org as URI-T. This TimeMap provides information about
1724 Mementos for the Original Resource that has http://a.example.org as
1725 URI-R. The response includes an "original" link pointing to the
1726 Original Resource that this TimeMap is about. Note the use of the
1727 "anchor" attribute in this link to convey the URI-R of that Original
1728 Resource.
1730 HTTP/1.1 200 OK
1731 Date: Thu, 21 Jan 2010 00:06:50 GMT
1732 Server: Apache
1733 Link:
1734 ; anchor="http://a.example.org"; rel="timemap"
1735 ; type="application/link-format"
1736 Content-Length: 0
1737 Content-Type: application/link-format; charset=UTF-8
1738 Connection: close
1740 Figure 31: TimeMap links to the Original Resource it is about
1742 6. IANA Considerations
1744 This memo requires IANA to register the Accept-Datetime and Memento-
1745 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1746 IANA registry.
1748 This memo requires IANA to register the Relation Types "original",
1749 "timegate", "timemap", and "memento" defined in Section 2.2 in the
1750 appropriate IANA registry.
1752 This memo requires IANA to register the "datetime" and "license"
1753 attributes for the "memento" Relation Type, as defined in
1754 Section 2.2.4, in the appropriate IANA registry.
1756 This memo requires IANA to register the "from" and "until" attributes
1757 for the "timemap" Relation Type, as defined in Section 2.2.4, in the
1758 appropriate IANA registry.
1760 7. Security Considerations
1762 Provision of a "timegate" HTTP "Link" header in responses to requests
1763 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1764 response codes) is OPTIONAL. The inclusion of this Link when
1765 requesting authentication is at the server's discretion; cases may
1766 exist in which a server protects the current state of a resource, but
1767 supports open access to prior states and thus chooses to supply a
1768 "timegate" HTTP "Link" header. Conversely, the server may choose to
1769 not advertise the TimeGate URIs (e.g., they exist in an intranet
1770 archive) for unauthenticated requests.
1772 The veracity of archives and the relationships between Original
1773 Resources and Mementos is beyond the scope of this document. Even in
1774 the absence of malice, it is possible for separate archives to have
1775 different Mementos for the same Original Resource at the same
1776 datetime if the state of the Original Resource was dependent on the
1777 requesting archive's user agent IP address, specific HTTP request
1778 headers, and possibly other factors.
1780 Further authentication, encryption and other security related issues
1781 are otherwise orthogonal to Memento.
1783 8. Changelog
1785 v09 2013-09-09 HVDS MLN RS draft-vandesompel-memento-09
1787 o Added timemap link to the example for Pattern 1.2.
1789 o Clarified that both Memento-Datetime value and the "original" link
1790 must be sticky.
1792 v08 2013-07-08 HVDS MLN RS draft-vandesompel-memento-08
1794 o Added the Special Case where a server that generally supports
1795 datetime negotiation indicates that a given resource is not
1796 subject to datetime negotiation.
1798 v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07
1800 o Introduced "Overview" section to make the existence of two
1801 components (datetime negotiation and TimeMaps) more explicit.
1803 o Replaced the hard-to-interpret summary table detailing the use of
1804 headers (introduced in version 06 ) with an explicit version in
1805 the appendix.
1807 o Revised the abstract.
1809 o Added TimeMaps to the enumeration of core components in the
1810 Purpose section.
1812 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06
1814 o Major overhaul of the presentation of the specification.
1816 o Specification of patterns whereby URI-R=URI-G and with both 200
1817 and 302 negotation style.
1819 o Removal of Discovery section to increase focus on datetime
1820 negotation aspects.
1822 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05
1824 o Clarified the section on Memento Relation Types.
1826 o Re-introduced "license" attribute for "memento" Relation Type as
1827 it will become essential for IIPC.
1829 o Introduced from and until attributes for "timemap" links to
1830 accomodate paged TimeMap cases.
1832 o Introduced the notion of Redirecting Resource and inserted related
1833 information in various sections.
1835 o Added discovery of Mementos via host-meta.
1837 o Corrected ambiguous uses of the term "representation".
1839 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
1841 o Removed the possibility to use an interval indicator in an Accept-
1842 Datetime header as no one is implementing it.
1844 o Corrected typo in Other Relation Types table.
1846 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap
1847 paging.
1849 o Changed Discovery component from using robots.txt with Memento-
1850 specific add-ons to well-known URI and host-meta.
1852 o Removed "embargo" and "license" attributes for links with a
1853 "memento" Relation Type because no one is using them.
1855 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1857 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1858 5XX status code.
1860 o Clarified that a TimeGate must not use the "Memento-Datetime"
1861 header.
1863 o Added wording to warn for possible cache problems with Memento
1864 implementations that choose to have an Original Resource and and
1865 its TimeGate coincide.
1867 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1869 o Added scenario in which a TimeGate redirects to another TimeGate.
1871 o Reorganized TimeGate section to better reflect the difference
1872 between requests with and without interval indicator.
1874 o Added recommendation to provide "memento" links to Mementos in the
1875 vicinity of the preferred interval provided by the user agent, in
1876 case of a 406 response.
1878 o Removed TimeMap Feed material from the Discovery section as a
1879 result of discussions regarding (lack of) scalability of the
1880 approach with representatives of the International Internet
1881 Preservation Consortium. An alternative approach to support batch
1882 discovery of Mementos will be specified.
1884 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1885 o Introduced wording and reference to indicate a Memento is a
1886 FixedResource.
1888 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1889 about retaining "Memento-Datetime" headers and values when a
1890 Memento is mirrored at different URI.
1892 o Introduced section about handling both datetime and regular
1893 negotiation.
1895 o Introduced section about Mementos Without TimeGate.
1897 o Made various changes in the section Relation Type "memento",
1898 including addition of "license" and "embargo" attributes, and
1899 clarification of rules regarding the use of "memento" links.
1901 o Moved section about TimeMaps inside the Datetime Negotiation
1902 section, and updated it.
1904 o Restarted the Discovery section from scratch.
1906 v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel-
1907 memento-00
1909 v00 2010-10-19 HVDS MLN RS Limited circulation version
1911 2010-07-22 HVDS MLN First internal version
1913 9. Acknowledgements
1915 The Memento effort is funded by the Library of Congress. Many thanks
1916 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1917 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers,
1918 James Anderson, Tim Starling, Martin Klein, Mark Nottingham for
1919 feedback. Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla
1920 Balakireva, Frank McCown, Harihar Shankar, Brad Tofel, Andrew
1921 Jackson, Ahmed Alsum, Mat Kelly, Ilya Kreymer for implementations
1922 that informed the specification.
1924 10. References
1926 10.1. Normative References
1928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1929 Requirement Levels", BCP 14, RFC 2119, March 1997.
1931 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1932 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1933 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1935 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
1936 4151, October 2005.
1938 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1939 Syndication Format", RFC 4287, December 2005.
1941 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
1942 Uniform Resource Identifiers (URIs)", RFC 5785, April
1943 2010.
1945 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
1946 for Simple Version Navigation between Web Resources", RFC
1947 5829, April 2010.
1949 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
1951 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC
1952 6415, October 2011.
1954 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
1955 Format", RFC 6690, August 2012.
1957 [RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903,
1958 March 2013.
1960 10.2. Informative References
1962 [Fitch] Fitch, ., "Web site archiving - an approach to recording
1963 every materially different response produced by a
1964 website", July 2003,
1965 .
1967 [I-D.masinter-dated-uri]
1968 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
1969 dated URIs", draft-masinter-dated-uri-10 (work in
1970 progress), January 2012.
1972 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1973 and Support", STD 3, RFC 1123, October 1989.
1975 [W3C.REC-aww-20041215]
1976 Jacobs, . and . Walsh, "Architecture of the World Wide
1977 Web", December 2004, .
1979 [W3C.gen-ont-20090420]
1980 Berners-Lee, ., "Architecture of the World Wide Web",
1981 April 2009, .
1983 Appendix A. Appendix: Use of Headers and Relation Types per Pattern
1985 +--------------------+--------------+----------+----------+---------+
1986 | Response Header | Pattern | Original | TimeGate | Memento |
1987 | | | Resource | | |
1988 +--------------------+--------------+----------+----------+---------+
1989 | Vary: accept- | Pattern 1.1 | 1 | 1 | 0 |
1990 | datetime | (Section | | | |
1991 | | 4.1.1) ; | | | |
1992 | | Pattern 1.2 | | | |
1993 | | (Section | | | |
1994 | | 4.1.2) | | | |
1995 | | Pattern 1.3 | 1 | 1 | 1 |
1996 | | (Section | | | |
1997 | | 4.1.3) | | | |
1998 | | Pattern 2.1 | 0 | 1 | 0 |
1999 | | (Section | | | |
2000 | | 4.2.1) ; | | | |
2001 | | Pattern 2.2 | | | |
2002 | | (Section | | | |
2003 | | 4.2.2) | | | |
2004 | | Pattern 2.3 | 0 | 1 | 1 |
2005 | | (Section | | | |
2006 | | 4.2.3) | | | |
2007 | | Pattern 3 | 1 | NA | 1 |
2008 | | (Section | | | |
2009 | | 4.3) | | | |
2010 | | Pattern 4 | 0 | NA | 1 |
2011 | | (Section | | | |
2012 | | 4.4) | | | |
2013 | Memento-Datetime | Pattern 1.1 | 0 | 0 | 1 |
2014 | | (Section | | | |
2015 | | 4.1.1) ; | | | |
2016 | | Pattern 1.2 | | | |
2017 | | (Section | | | |
2018 | | 4.1.1) | | | |
2019 | | Pattern 1.3 | 1 | 1 | 1 |
2020 | | (Section | | | |
2021 | | 4.1.3) | | | |
2022 | | Pattern 2.1 | 0 | 0 | 1 |
2023 | | (Section | | | |
2024 | | 4.2.1) ; | | | |
2025 | | Pattern 2.2 | | | |
2026 | | (Section | | | |
2027 | | 4.2.2) | | | |
2028 | | Pattern 2.3 | 0 | 1 | 1 |
2029 | | (Section | | | |
2030 | | 4.2.3) | | | |
2031 | | Pattern 3 | 1 | NA | 1 |
2032 | | (Section | | | |
2033 | | 4.3) | | | |
2034 | | Pattern 4 | 0 | NA | 1 |
2035 | | (Section | | | |
2036 | | 4.4) | | | |
2037 | Link | | | | |
2038 | rel="original" | Pattern 1.1 | 0 | 1 | 1 |
2039 | | (Section | | | |
2040 | | 4.1.1) ; | | | |
2041 | | Pattern 1.2 | | | |
2042 | | (Section | | | |
2043 | | 4.1.1) | | | |
2044 | | Pattern 1.3 | 1 | 1 | 1 |
2045 | | (Section | | | |
2046 | | 4.1.3) | | | |
2047 | | Pattern 2.1 | 0 | 1 | 1 |
2048 | | (Section | | | |
2049 | | 4.2.1) ; | | | |
2050 | | Pattern 2.2 | | | |
2051 | | (Section | | | |
2052 | | 4.2.2) | | | |
2053 | | Pattern 2.3 | 0 | 1 | 1 |
2054 | | (Section | | | |
2055 | | 4.2.3) | | | |
2056 | | Pattern 3 | 1 | NA | 1 |
2057 | | (Section | | | |
2058 | | 4.3) | | | |
2059 | | Pattern 4 | 0 | NA | 1 |
2060 | | (Section | | | |
2061 | | 4.4) | | | |
2062 | rel="timegate" | Pattern 1.1 | >=0 | >=0 | >=0 |
2063 | | (Section | | | |
2064 | | 4.1.1) ; | | | |
2065 | | Pattern 1.2 | | | |
2066 | | (Section | | | |
2067 | | 4.1.1) | | | |
2068 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2069 | | (Section | | | |
2070 | | 4.1.3) | | | |
2071 | | Pattern 2.1 | >=0 | 0 | >=0 |
2072 | | (Section | | | |
2073 | | 4.2.1) ; | | | |
2074 | | Pattern 2.2 | | | |
2075 | | (Section | | | |
2076 | | 4.2.2) | | | |
2077 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2078 | | (Section | | | |
2079 | | 4.2.3) | | | |
2080 | | Pattern 3 | NA | NA | NA |
2081 | | (Section | | | |
2082 | | 4.3) | | | |
2083 | | Pattern 4 | NA | NA | NA |
2084 | | (Section | | | |
2085 | | 4.4) | | | |
2086 | rel="timemap" | Pattern 1.1 | >=0 | >=0 | >=0 |
2087 | | (Section | | | |
2088 | | 4.1.1) ; | | | |
2089 | | Pattern 1.2 | | | |
2090 | | (Section | | | |
2091 | | 4.1.1) | | | |
2092 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2093 | | (Section | | | |
2094 | | 4.1.3) | | | |
2095 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2096 | | (Section | | | |
2097 | | 4.2.1) ; | | | |
2098 | | Pattern 2.2 | | | |
2099 | | (Section | | | |
2100 | | 4.2.2) | | | |
2101 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2102 | | (Section | | | |
2103 | | 4.2.3) | | | |
2104 | | Pattern 3 | >=0 | NA | >=0 |
2105 | | (Section | | | |
2106 | | 4.3) | | | |
2107 | | Pattern 4 | >=0 | NA | >=0 |
2108 | | (Section | | | |
2109 | | 4.4) | | | |
2110 | rel="memento" | Pattern 1.1 | >=0 | >=0 | >=0 |
2111 | | (Section | | | |
2112 | | 4.1.1) ; | | | |
2113 | | Pattern 1.2 | | | |
2114 | | (Section | | | |
2115 | | 4.1.1) | | | |
2116 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2117 | | (Section | | | |
2118 | | 4.1.3) | | | |
2119 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2120 | | (Section | | | |
2121 | | 4.2.1) ; | | | |
2122 | | Pattern 2.2 | | | |
2123 | | (Section | | | |
2124 | | 4.2.2) | | | |
2125 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2126 | | (Section | | | |
2127 | | 4.2.3) | | | |
2128 | | Pattern 3 | >=0 | NA | >=0 |
2129 | | (Section | | | |
2130 | | 4.3) | | | |
2131 | | Pattern 4 | >=0 | NA | >=0 |
2132 | | (Section | | | |
2133 | | 4.4) | | | |
2134 +--------------------+--------------+----------+----------+---------+
2136 Table 5: Memento Headers
2138 Authors' Addresses
2140 Herbert VandeSompel
2141 Los Alamos National Laboratory
2142 PO Box 1663
2143 Los Alamos, New Mexico 87545
2144 USA
2146 Phone: +1 505 667 1267
2147 Email: hvdsomp@gmail.com
2148 URI: http://public.lanl.gov/herbertv/
2150 Michael Nelson
2151 Old Dominion University
2152 Norfolk, Virginia 23529
2153 USA
2155 Phone: +1 757 683 6393
2156 Email: mln@cs.odu.edu
2157 URI: http://www.cs.odu.edu/~mln/
2159 Robert Sanderson
2160 Los Alamos National Laboratory
2161 PO Box 1663
2162 Los Alamos, New Mexico 87545
2163 USA
2165 Phone: +1 505 665 5804
2166 Email: azaroth42@gmail.com
2167 URI: http://public.lanl.gov/rsanderson/