idnits 2.17.1
draft-vandesompel-memento-07.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 (March 29, 2013) is 4045 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 1875, but no explicit
reference was found in the text
== Unused Reference: 'RFC4287' is defined on line 1878, but no explicit
reference was found in the text
== Unused Reference: 'RFC5785' is defined on line 1881, but no explicit
reference was found in the text
== Unused Reference: 'RFC6415' is defined on line 1891, 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.L. Nelson
5 Expires: September 30, 2013 Old Dominion University
6 R.D. Sanderson
7 Los Alamos National Laboratory
8 March 29, 2013
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-07
13 Abstract
15 The HTTP-based Memento framework bridges the present and past Web.
16 It 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 September 30, 2013.
42 Copyright Notice
44 Copyright (c) 2013 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
62 1.3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. HTTP headers, Link Relation Types . . . . . . . . . . . . . . 6
64 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 6
65 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 6
66 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . 7
67 2.1.3. Link . . . . . . . . . . . . . . . . . . . . . . . . 8
68 2.2. Link Relation Types . . . . . . . . . . . . . . . . . . . 8
69 2.2.1. Link Relation Type "original" . . . . . . . . . . . . 8
70 2.2.2. Link Relation Type "timegate" . . . . . . . . . . . . 8
71 2.2.3. Link Relation Type "timemap" . . . . . . . . . . . . 9
72 2.2.4. Link Relation Type "memento" . . . . . . . . . . . . 9
73 3. Overview of the Memento Framework . . . . . . . . . . . . . . 10
74 3.1. Datetime Negotiation . . . . . . . . . . . . . . . . . . 10
75 3.2. TimeMaps . . . . . . . . . . . . . . . . . . . . . . . . 13
76 4. Datetime Negotiation: HTTP Interactions . . . . . . . . . . . 14
77 4.1. Pattern 1 - The Original Resource acts as its own
78 TimeGate . . . . . . . . . . . . . . . . . . . . . . . . 15
79 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ;
80 distinct URI-M for Mementos . . . . . . . . . . . . . 15
81 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ;
82 distinct URI-M for Mementos . . . . . . . . . . . . . 17
83 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ;
84 no distinct URI-M for Mementos . . . . . . . . . . . 18
85 4.2. Pattern 2 - A remote resource acts as a TimeGate for the
86 Original Resource . . . . . . . . . . . . . . . . . . . . 19
87 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ;
88 distinct URI-M for Mementos . . . . . . . . . . . . . 21
89 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ;
90 distinct URI-M for Mementos . . . . . . . . . . . . . 23
91 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ;
92 no distinct URI-M for Mementos . . . . . . . . . . . 24
93 4.3. Pattern 3 - The Original Resource is a Fixed Resource . . 25
94 4.4. Pattern 4 - Mementos without a TimeGate . . . . . . . . . 26
95 4.5. Special Cases . . . . . . . . . . . . . . . . . . . . . . 27
96 4.5.1. Original Resource provides no "timegate" link . . . . 27
97 4.5.2. Server exists but Original Resource no longer does . 27
98 4.5.3. Issues with Accept-Datetime . . . . . . . . . . . . . 28
99 4.5.4. Memento of a 3XX response . . . . . . . . . . . . . . 28
100 4.5.5. Memento of responses with 4XX or 5XX HTTP status
101 codes . . . . . . . . . . . . . . . . . . . . . . . . 30
102 4.5.6. Sticky "Memento-Datetime" value for Mementos . . . . 31
103 4.5.7. Intermediate Resources . . . . . . . . . . . . . . . 31
104 5. TimeMaps: Content and Serialization . . . . . . . . . . . . . 32
105 5.1. Special Cases . . . . . . . . . . . . . . . . . . . . . . 34
106 5.1.1. Index and Paging TimeMaps . . . . . . . . . . . . . . 34
107 5.1.2. Mementos for TimeMaps . . . . . . . . . . . . . . . . 36
108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
110 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 37
111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
113 10.1. Normative References . . . . . . . . . . . . . . . . . . 40
114 10.2. Informative References . . . . . . . . . . . . . . . . . 41
115 Appendix A. Appendix: Use of Headers and Relation Types per
116 Pattern . . . . . . . . . . . . . . . . . . . . . . 41
117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
119 1. Introduction
121 1.1. Terminology
123 This specification uses the terms "resource", "request", "response",
124 "entity-body", "content negotiation", "user agent", "server" as
125 described in [RFC2616], and it uses the terms "representation" and
126 "resource state" as described in [W3C.REC-aww-20041215].
128 In addition, the following terms specific to the Memento framework
129 are introduced:
131 o Original Resource: An Original Resource is a resource that exists
132 or used to exist, and for which access to one of its prior states
133 may be required.
135 o Memento: A Memento for an Original Resource is a resource that
136 encapsulates a prior state of the Original Resource. A Memento
137 for an Original Resource as it existed at time T is a resource
138 that encapsulates the state the Original Resource had at time T.
140 o TimeGate: A TimeGate for an Original Resource is a resource that
141 is capable of datetime negotiation to support access to prior
142 states of the Original Resource.
144 o TimeMap: A TimeMap for an Original Resource is a resource from
145 which a list of URIs of Mementos of the Original Resource is
146 available.
148 1.2. Notational Conventions
150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in [RFC2119].
154 When needed for extra clarity, the following conventions are used:
156 o URI-R is used to denote the URI of an Original Resource.
158 o URI-G is used to denote the URI of a TimeGate.
160 o URI-M is used to denote the URI of a Memento.
162 o URI-T is used to denote the URI of a TimeMap.
164 1.3. Purpose
166 The state of an Original Resource may change over time.
167 Dereferencing its URI at any specific moment yields a response that
168 reflects the resource's state at that moment: a representation of the
169 resource's state (e.g. "200 OK" HTTP status code), an indication of
170 its non-existence (e.g. "404 Not Found" HTTP status code), a
171 relation to another resource (e.g. "302 Found" HTTP status code),
172 etc. However, responses may also exist that reflect prior states of
173 an Original Resource: a representation of a prior state of the
174 Original Resource, an indication that the Original Resource did not
175 exist at some time in the past, a relation that the Original Resource
176 had to another resource at some time in the past, etc. Mementos that
177 provide such responses exist in web archives, content management
178 systems, or revision control systems, among others. For any given
179 Original Resource several Mementos may exist, each one reflecting a
180 frozen prior state of the Original Resource.
182 Examples are:
184 Mementos for Original Resource http://www.ietf.org/ :
186 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
188 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
189 www.ietf.org/
191 Mementos for Original Resource http://en.wikipedia.org/wiki/
192 Hypertext_Transfer_Protocol :
194 o http://en.wikipedia.org/w/
195 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
197 o http://en.wikipedia.org/w/
198 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
200 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
201 wiki/Hypertext_Transfer_Protocol
203 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
205 o http://www.w3.org/TR/2004/PR-webarch-20041105/
207 o http://www.w3.org/TR/2002/WD-webarch-20020830/
209 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
210 www.w3.org/TR/webarch/
212 In the abstract, the Memento framework introduces a mechanism to
213 access versions of web resources that:
215 o Is fully distributed in the sense that resource versions may
216 reside on multiple servers, and that any such server is likely
217 only aware of the versions it holds;
219 o Uses the global notion of datetime as a resource version indicator
220 and access key;
222 o Leverages the following primitives of [W3C.REC-aww-20041215]:
223 resource, resource state, representation, content negotiation, and
224 link.
226 The core components of Memento's mechanism to access resource
227 versions are:
229 1. The abstract notion of the state of an Original Resource (URI-R)
230 as it existed at datetime T. Note the relationship with the ability
231 to identify the state of a resource at datetime T by means of a URI
232 as intended by the proposed Dated URI scheme
233 [I-D.masinter-dated-uri].
235 2. A "bridge" from the present to the past, consisting of:
237 o The existence of a TimeGate (URI-G), which is aware of (at least
238 part of the) version history of the Original Resource (URI-R);
240 o The ability to negotiate in the datetime dimension with that
241 TimeGate (URI-G), as a means to access the state that the Original
242 Resource (URI-R) had at datetime T.
244 3. A "bridge" from the past to the present, consisting of an
245 appropriately typed link from a Memento (URI-M), which encapsulates
246 the state the Original Resource (URI-R) had at datetime T, to the
247 Original Resource (URI-R).
249 4. The existence of a TimeMap (URI-T) from which a list of all
250 Mementos that encapsulate a prior state of the Original Resource
251 (URI-R) can be obtained.
253 This document is concerned with specifying an instantiation of these
254 abstractions for resources that are identified by HTTP(S) URIs.
256 2. HTTP headers, Link Relation Types
258 The Memento framework is concerned with HEAD and GET interactions
259 with Original Resources, TimeGates, Mementos, and TimeMaps that are
260 identified by HTTP or HTTPS URIs. Details are only provided for
261 resources identified by HTTP URIs but apply similarly to those with
262 HTTPS URIs.
264 2.1. HTTP Headers
266 The Memento framework operates at the level of HTTP request and
267 response headers. It introduces two new headers ("Accept-Datetime",
268 "Memento-Datetime") and introduces new values for two existing
269 headers ("Vary", "Link"). Other HTTP headers are present or absent
270 in Memento response/request cycles as specified by [RFC2616].
272 2.1.1. Accept-Datetime, Memento-Datetime
274 The "Accept-Datetime" request header is trasnmitted by a user agent
275 to indicate it wants to access a past state of an Original Resource.
276 To that end, the "Accept-Datetime" header is conveyed in an HTTP
277 request issued against a TimeGate for an Original Resource, and its
278 value indicates the datetime of the desired past state of the
279 Original Resource.
281 Example of an "Accept-Datetime" request header:
283 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
285 The "Memento-Datetime" response header is used by a server to
286 indicate that a response reflects a prior state of an Original
287 Resource. Its value expresses the datetime of that state. The URI
288 of the Original Resource for which the response reflects a prior
289 state is provided as the Target IRI of a link provided in the HTTP
290 "Link" header that has a Relation Type of "original" (see
291 Section 2.2).
293 The presence of a "Memento-Datetime" header and associated value for
294 a given response constitutes a promise that the resource state
295 reflected in the response will no longer change (see Section 4.5.6).
297 Example of a "Memento-Datetime" response header:
299 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
301 Values for the "Accept-Datetime" and "Memento-Datetime" headers
302 consist of a MANDATORY datetime expressed according to the [RFC1123]
303 format, which is formalized by the rfc1123-date construction rule of
304 the BNF in Figure 1. The datetime is case-sensitive with names for
305 days and months exactly as shown in the wkday and month construction
306 rules of the BNF, respectively. The datetime MUST be represented in
307 Greenwich Mean Time (GMT).
309 accept-dt-value = rfc1123-date
310 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
311 date1 = 2DIGIT SP month SP 4DIGIT
312 ; day month year (e.g., 20 Mar 1957)
313 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
314 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
315 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
316 "Sun"
317 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
318 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
320 Figure 1: BNF for the datetime format
322 2.1.2. Vary
324 Generally, the "Vary" header is used in HTTP responses to indicate
325 the dimensions in which content negotiation is possible. In the
326 Memento framework, a TimeGate uses the "Vary" header with a value
327 that includes "accept-datetime" to convey that datetime negotation is
328 possible.
330 For example, this use of the "Vary" header indicates that datetime is
331 the only dimension in which negotiation is possible:
333 Vary: accept-datetime
335 The use of the "Vary" header in this example shows that both datetime
336 negotiation, and media type content negotiation are possible:
338 Vary: accept-datetime, accept
340 2.1.3. Link
342 The Memento framework defines the "original", "timegate", "timemap",
343 and "memento" Relation Types to convey typed links among Original
344 Resources, TimeGates, Mementos, and TimeMaps. The are defined in
345 Section 2.2, below. In addition, existing Relation Types may be
346 used, for example, to support navigating among Mementos. Examples
347 are "first", "last", "prev", "next", "predecessor-version",
348 "successor-version" as detailed in [RFC5988] and [RFC5829].
350 2.2. Link Relation Types
352 This section introduces the Relation Types used in the Memento
353 framework. They are defined in a general way and their use in HTTP
354 "Link" Headers [RFC5988] is described in detail. The use of these
355 Relation Types in TimeMaps is described in Section 5.
357 2.2.1. Link Relation Type "original"
359 "original" -- A link with an "original" Relation Type is used to
360 point from a TimeGate or a Memento to its associated Original
361 Resource.
363 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
364 issued against a TimeGate or a Memento MUST include exactly one link
365 with an "original" Relation Type in their HTTP "Link" header.
367 2.2.2. Link Relation Type "timegate"
369 "timegate" -- A link with a "timegate" Relation Type is used to point
370 from the Original Resource, as well as from a Memento associated with
371 the Original Resource, to a TimeGate for the Original Resource.
373 Use in HTTP "Link" headers: If there is a TimeGate associated with an
374 Original Resource or Memento that is preferred for use, then
375 responses to HTTP HEAD/GET requests issued against these latter
376 resources MUST include a link with a "timegate" Relation Type in
377 their HTTP "Link" header. Since multiple TimeGates can exist for any
378 Original Resource, multiple "timegate" links MAY occur, each with a
379 distinct Target IRI.
381 2.2.3. Link Relation Type "timemap"
383 "timemap" -- A link with a "timemap" Relation Type is used to point
384 from a TimeGate or a Memento associated with an Original Resource, as
385 well as from the Original Resource itself, to a TimeMap for the
386 Original Resource.
388 Attributes: A link with a "timemap" Relation Type SHOULD use the
389 "type" attribute to convey the mime type of the TimeMap
390 serialization. The "from" and "until" attributes may be used to
391 express the start and end of the temporal interval covered by
392 Mementos listed in the TimeMap. That is, the linked TimeMap will not
393 contain Mementos with archival datetimes outside of the expressed
394 temporal interval. Attempts SHOULD be made to convey this interval
395 as accurately as possible. The value for the these attributes MUST
396 be a datetime expressed according to the rfc1123-date construction
397 rule of the BNF in Figure 1 and it MUST be represented in Greenwich
398 Mean Time (GMT).
400 Use in HTTP "Link" headers: If there is a TimeMap associated with an
401 Original Resource, a TimeGate or a Memento that is preferred for use,
402 then responses to HTTP HEAD/GET requests issued against these latter
403 resources MUST include a link with a "timemap" Relation Type in their
404 HTTP "Link" header. Multiple such links, each with a distinct Target
405 IRI, MAY be expressed as a means to point to different TimeMaps or to
406 different serializations of the same TimeMap. In all cases, use of
407 the "from" and "until" attributes is OPTIONAL.
409 2.2.4. Link Relation Type "memento"
411 "memento" -- A link with a "memento" Relation Type is used to point
412 from a TimeGate or a Memento for an Original Resource, as well as
413 from the Original Resource itself, to a Memento for the Original
414 Resource.
416 Attributes: A link with a "memento" Relation Type MUST include a
417 "datetime" attribute with a value that matches the "Memento-Datetime"
418 of the Memento that is the target of the link; that is, the value of
419 the "Memento-Datetime" header that is returned when the URI of the
420 linked Memento is dereferenced. The value for the "datetime"
421 attribute MUST be a datetime expressed according to the rfc1123-date
422 construction rule of the BNF in Figure 1 and it MUST be represented
423 in Greenwich Mean Time (GMT). This link MAY include a "license"
424 attribute to associate a license with the Memento; the value for the
425 "license" attribute MUST be a URI.
427 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests
428 issued against an Original Resource, a TimeGate and a Memento MAY
429 include links in their HTTP "Link" headers with a "memento" Relation
430 Type. For responses in which a Memento is selected, the provision of
431 navigational links that lead to Mementos other than the selected one
432 can be beneficial to the user agent. Of special importance are links
433 that lead to the temporally first and last Memento known to the
434 responding server, as well as links leading to Mementos that are
435 temporally adjacent to the selected one.
437 3. Overview of the Memento Framework
439 The Memento framework defines two complementary approaches to support
440 obtaining representations of prior states of an Original Resource:
442 o Datetime Negotiation: Datetime negotiation is a variation on
443 content negotiation by which a user agent expresses a datetime
444 preference pertaining to the representation of an Original
445 Resource, instead of, for example, a media type preference. Based
446 on the responding server's knowledge of the past of the Original
447 Resource, it selects a Memento of the Original Resource that best
448 meets the user agent's datetime preference. An overview is
449 provided in Section 3.1; details are in Section 4.
451 o TimeMaps: A TimeMap is a resource from which a list can be
452 obtained that provides a comprehensive overview of the past of an
453 Original Resource. A server makes a TimeMap available that
454 enumerates all Mementos that the server is aware of, along with
455 their archival datetime. A user agent can obtain the TimeMap and
456 select Mementos from it. An overview is provided in Section 3.2;
457 details are in Section 5.
459 3.1. Datetime Negotiation
460 Figure 2 provides a schematic overview of a successful request/
461 response chain that involves datetime negotiation. Dashed lines
462 depict HTTP transactions between user agent and server. The
463 interactions are for a scenario where the Original Resource resides
464 on one server, whereas both its TimeGate and Mementos reside on
465 another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also
466 exist in which all these resources are on the same server (for
467 example, content management systems) or all are on different servers
468 (for example, an aggregator of TimeGates).
470 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R
471 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
472 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G
473 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
474 URI-R,URI-T ------------------------------------------> URI-G
475 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M
476 6: UA <-- HTTP 200; Memento-Datetime: T; Link:
477 URI-R,URI-T,URI-G ------------------------------------- URI-M
479 Figure 2: A datetime negotiation request/response chain
481 o Step 1: The user agent that wants to access a prior state of the
482 Original Resource issues an HTTP HEAD/GET against URI-R that has
483 an "Accept-Datetime" HTTP header with a value of the datetime of
484 the desired state.
486 o Step 2: The response from URI-R includes an HTTP "Link" header
487 with a Relation Type of "timegate" pointing at a TimeGate (URI-G)
488 for the Original Resource.
490 o Step 3: The user agent starts the datetime negotiation process
491 with the TimeGate by issuing an HTTP GET request against URI-G
492 that has an "Accept-Datetime" HTTP header with a value of the
493 datetime of the desired prior state of the Original Resource.
495 o Step 4: The response from URI-G includes a "Location" header
496 pointing at a Memento (URI-M) for the Original Resource. In
497 addition, the response contains an HTTP "Link" header with a
498 Relation Type of "original" pointing at the Original Resource
499 (URI-R), and an HTTP "Link" header with a Relation Type of
500 "timemap" pointing at a TimeMap (URI-T).
502 o Step 5: The user agent issues an HTTP GET request against URI-M.
504 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP
505 header with a value of the archival datetime of the Memento. It
506 also contains an HTTP "Link" header with a Relation Type of
507 "original" pointing at the Original Resource (URI-R), with a
508 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the
509 Original Resource, and with a Relation Type of "timemap" pointing
510 at a TimeMap (URI-T) for the Original Resource. The state that is
511 expressed by the response is the state the Original Resource had
512 at the archival datetime expressed in the "Memento-Datetime"
513 header.
515 In order to respond to a datetime negotiation request, the server
516 uses an internal algorithm to select the Memento that best meets the
517 user agent's datetime preference. The exact nature of the selection
518 algorithm is at the server's discretion but is intented to be
519 consistent, for example, always selecting the Memento that is nearest
520 in time relative to the requested datetime, always selecting the
521 Memento that is nearest in the past relative to the requested
522 datetime, etc.
524 Due to the sparseness of Mementos in most systems, the value of the
525 "Memento-Datetime" header returned by a server may differ
526 (significantly) from the value conveyed by the user agent in "Accept-
527 Datetime".
529 Although a Memento encapsulates a prior state of an Original
530 Resource, the entity-body returned in response to an HTTP GET request
531 issued against a Memento may very well not be byte-to-byte the same
532 as an entity-body that was previously returned by that Original
533 Resource. Various reasons exist why there are significant chances
534 these would be different yet do convey substantially the same
535 information. These include format migrations as part of a digital
536 preservation strategy, URI-rewriting as applied by some web archives,
537 and the addition of banners as a means to brand web archives.
539 When negotiating in the datetime dimension, the regular content
540 negotiation dimensions (media type, character encoding, language, and
541 compression) remain available. It is the TimeGate server's
542 responsibility to honor (or not) such content negotiation, and in
543 doing so it MUST always first select a Memento that meets the user
544 agent's datetime preference, and then consider honoring regular
545 content negotiation for it. As a result of this approach, the
546 returned Memento will not necessarily meet the user agent's regular
547 content negotiation preferences. Therefore, it is RECOMMENDED that
548 the server provides "memento" links in the HTTP "Link" header
549 pointing at Mementos that do meet the user agent's regular content
550 negotiation requests and that have a value for the "Memento-Datetime"
551 header in the temporal vicinity of the user agent's preferred
552 datetime value.
554 A user agent that engages in datetime negotiation with a resource
555 typically starts by issuing an HTTP HEAD, not GET, request with an
556 "Accept-Datetime" header in order to determine how to proceed. This
557 strategy is related to the existence of various server implementation
558 patterns as will become clear in the below.
560 Details about the HTTP interactions involved in datetime negotation
561 are provided in Section 4.
563 3.2. TimeMaps
565 Figure 3 provides a schematic overview of a successful request/
566 response chain that shows a user agent obtaining a TimeMap. The
567 pictoral conventions are the same as the ones used in Figure 2, as is
568 the scenario. Note that, in addition to a TimeGate, an Original
569 Resource and a Memento can also provide a link to a TimeMap.
571 1: UA --- HTTP HEAD/GET ------------------------------------> URI-R
572 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
573 3: UA --- HTTP HEAD/GET ------------------------------------> URI-G
574 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
575 URI-R,URI-T ------------------------------------------> URI-G
576 5: UA --- HTTP GET URI-T -----------------------------------> URI-T
577 6: UA <-- HTTP 200 ------------------------------------------ URI-T
579 Figure 3: A request/response chain to obtain a TimeMap
581 o Step 1: The user agent that wants to access a TimeMap for the
582 Original Resource issues an HTTP HEAD/GET against URI-R. This can
583 be done with or without an "Accept-Datetime" HTTP header.
585 o Step 2: Irrespective of the use of an "Accept-Datetime" HTTP
586 header in Step 1, the response from URI-R includes an HTTP "Link"
587 header with a Relation Type of "timegate" pointing at a TimeGate
588 (URI-G) for the Original Resource.
590 o Step 3: The user agent issues an HTTP GET request against URI-G.
591 This can be done with or without an "Accept-Datetime" HTTP header.
593 o Step 4: Irrespective of the use of an "Accept-Datetime" HTTP
594 header in Step 1, the response contains an HTTP "Link" header with
595 a Relation Type of "timemap" pointing at a TimeMap (URI-T).
597 o Step 5: The user agent issues an HTTP GET request against URI-T.
599 o Step 6: The response from URI-T has an entity-body that lists all
600 Mementos for the Original Resource known to the responding server,
601 as well as their archival datetimes.
603 Details about the content and serialization of TimeMaps are provided
604 in Section 5.
606 4. Datetime Negotiation: HTTP Interactions
608 Figure 2 depicts a specific pattern to implement the Memento
609 framework. Multiple patterns exist and they can be grouped as
610 follows:
612 o Pattern 1 (Section 4.1) - The Original Resource acts as its own
613 TimeGate
615 o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for
616 the Original Resource
618 o Pattern 3 (Section 4.3) - The Original Resource is a Fixed
619 Resource
621 o Pattern 4 (Section 4.4) - Mementos without a TimeGate
623 Details of the HTTP interactions for common cases for each of those
624 patterns are provided in Section 4.1 through Section 4.4. Appendix A
625 summarizes the use of the "Vary", "Memento-Datetime", and "Link"
626 headers in responses from Original Resources, TimeGates, and Mementos
627 for the various patterns. Special cases are described in
628 Section 4.5. Note that in the following sections, the HTTP status
629 code of the responses with an entity-body is shown as "200 OK", but a
630 series of "206 Partial Content" responses could be substituted.
632 Figure 4 shows a user agent that attemtps to datetime negotiate with
633 the Original Resource http://a.example.org/ by including an "Accept-
634 Datetime" header in its HTTP HEAD request. This initiating request
635 is the same for Pattern 1 (Section 4.1) through Pattern 3
636 (Section 4.3).
638 HEAD / HTTP/1.1
639 Host: a.example.org
640 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
641 Connection: close
643 Figure 4: User Agent Attempts Datetime Negotiation With Original
644 Resource
646 4.1. Pattern 1 - The Original Resource acts as its own TimeGate
648 In this implementation pattern, the Original Resource acts as its own
649 TimeGate, which means that URI-R and URI-G coincide. Content
650 management systems and revision control systems can support datetime
651 negotiation in this way as they are commonly aware of the version
652 history of their own resources.
654 The response to this request when datetime negotiation for this
655 resource is supported depends on the negotiation style it uses
656 (200-style or 302-style) and on the existence or absence of a URI-M
657 for Mementos that is distinct from the URI-R of the associated
658 Original Resource. The various cases are summarized in the below
659 table and the server responses for each are detailed in the remainder
660 of this section.
662 +--------------+------------+------------+----------+---------------+
663 | Pattern | Original | TimeGate | Memento | Negotiation |
664 | | Resource | | | Style |
665 +--------------+------------+------------+----------+---------------+
666 | Pattern 1.1 | URI-R | URI-R | URI-M | 302 |
667 | (Section | | | | |
668 | 4.1.1) | | | | |
669 | Pattern 1.2 | URI-R | URI-R | URI-M | 200 |
670 | (Section | | | | |
671 | 4.1.2) | | | | |
672 | Pattern 1.3 | URI-R | URI-R | URI-R | 200 |
673 | (Section | | | | |
674 | 4.1.3) | | | | |
675 +--------------+------------+------------+----------+---------------+
677 Table 1: Pattern 1
679 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; distinct
680 URI-M for Mementos
682 In this case, the response to the user agent's request of Figure 4
683 has a "302 Found" HTTP status code, and the "Location" header conveys
684 the URI-M of the selected Memento. The use of Memento response
685 headers and links in the response from URI-R=URI-G is as follows:
687 o The "Vary" header MUST be provided and it MUST include the
688 "accept-datetime" value.
690 o The response MUST NOT contain a "Memento-Datetime" header.
692 o The "Link" header MUST be provided and it MUST contain at least a
693 link with the "original" Relation Type that has the URI-R of the
694 Original Resource as Target IRI. The provision of other links is
695 encouraged and is subject to the considerations described in
696 Section 2.2.
698 The server's response to the request of Figure 4 is shown in Figure
699 5. Note the inclusion of the recommended link to the TimeGate that,
700 in this case, has a Target IRI that is the URI-R of the Original
701 Resource.
703 HTTP/1.1 302 Found
704 Date: Thu, 21 Jan 2010 00:06:50 GMT
705 Server: Apache
706 Vary: accept-datetime
707 Location:
708 http://a.example.org/?version=20010911203610
709 Link: ; rel="original timegate"
710 Content-Length: 0
711 Content-Type: text/plain; charset=UTF-8
712 Connection: close
714 Figure 5: Response from URI-R=URI-G for Pattern 1.1
716 In a subsequent request, shown in Figure 6, the user agent can obtain
717 the selected Memento by issuing an HTTP GET request against the URI-M
718 that was provided in the "Location" header. The inclusion of the
719 "Accept-Datetime" header in this request is not needed but will
720 typically occur as the user agent is in datetime negotiation mode.
722 GET /?version=20010911203610 HTTP/1.1
723 Host: a.example.org
724 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
725 Connection: close
727 Figure 6: User Agent Requests Selected Memento
729 The response has a "200 OK" HTTP status code and the entity-body of
730 the response contains the representation of the selected Memento.
731 The use of Memento response headers and links in the response from
732 URI-M is as follows:
734 o A "Vary" header that includes an "accept-datetime" value MUST NOT
735 be provided.
737 o The response MUST include a "Memento-Datetime" header. Its value
738 expresses the archival datetime of the Memento.
740 o The "Link" header MUST be provided and it MUST contain at least a
741 link with the "original" Relation Type that has the URI-R of the
742 Original Resource as Target IRI. The provision of other links is
743 encouraged and is subject to the considerations described in
744 Section 2.2.
746 The server's response to the request of Figure 6 is shown in Figure
747 7. Note the provision of the required "original", and the
748 recommended "timegate" and "timemap" links. The former two point to
749 the Original Resource, which acts as its own TimeGate. The latter
750 has "from" and "until" attributes to indicate the temporal interval
751 covered by Mementos listed in the linked TimeMap.
753 HTTP/1.1 200 OK
754 Date: Thu, 21 Jan 2010 00:06:51 GMT
755 Server: Apache-Coyote/1.1
756 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
757 Link: ; rel="original timegate",
758
759 ; rel="timemap"; type="application/link-format"
760 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
761 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
762 Content-Length: 23364
763 Content-Type: text/html;charset=utf-8
764 Connection: close
766 Figure 7: Response from URI-M for Pattern 1.1
768 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; distinct
769 URI-M for Mementos
771 In this case, the response to the user agent's request of Figure 4
772 has a "200 OK" HTTP status code, and the "Content-Location" header
773 conveys the URI-M of the selected Memento. The use of Memento
774 response headers and links in the response from URI-R=URI-G is as
775 follows:
777 o The "Vary" header MUST be provided and it MUST include the
778 "accept-datetime" value.
780 o The response MUST include a "Memento-Datetime" header. Its value
781 expresses the archival datetime of the selected Memento.
783 o The "Link" header MUST be provided and it MUST contain at least a
784 link with the "original" Relation Type that has the URI-R of the
785 Original Resource as Target IRI. The provision of other links is
786 encouraged and is subject to the considerations described in
787 Section 2.2.
789 The server's response to the request of Figure 4 is shown in Figure
790 8. Note the provision of optional "memento" links pointing at the
791 oldest and most recent Memento for the Original Resource known to the
792 responding server.
794 HTTP/1.1 200 OK
795 Date: Thu, 21 Jan 2010 00:06:50 GMT
796 Server: Apache
797 Vary: accept-datetime
798 Content-Location:
799 http://a.example.org/?version=20010911203610
800 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
801 Link: ; rel="original timegate",
802
803 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
804
805 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT"
806 Content-Length: 2312
807 Content-Type: text/html; charset=UTF-8
808 Connection: close
810 Figure 8: Response from URI-R=URI-G for Pattern 1.2
812 In a subsequent request, which is the same as Figure 4 but with HTTP
813 GET instead of HEAD, the user agent can obtain the representation of
814 the selected Memento. It will be provided as the entity-body of a
815 response that has the same Memento headers as in Figure 8.
817 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; no distinct
818 URI-M for Mementos
820 In this case, the response to the user agent's request of Figure 4
821 has a "200 OK" HTTP status code, and it does not contain a "Content-
822 Location" nor "Location" header as there is no URI-M of the selected
823 Memento to convey. The use of Memento response headers and links in
824 the response from URI-R=URI-G is as follows:
826 o The "Vary" header MUST be provided and it MUST include the
827 "accept-datetime" value.
829 o The response MUST include a "Memento-Datetime" header. Its value
830 expresses the archival datetime of the selected Memento.
832 o The "Link" header MUST be provided and it MUST contain at least a
833 link with the "original" Relation Type that has the URI-R of the
834 Original Resource as Target IRI. The provision of other links is
835 encouraged and is subject to the considerations described in
836 Section 2.2.
838 The server's response to the request of Figure 4 is shown in Figure
839 9. The recommended "timemap" and "timegate" links are included in
840 addition to the mandatory "original" link.
842 HTTP/1.1 200 OK
843 Date: Thu, 21 Jan 2010 00:06:50 GMT
844 Server: Apache
845 Vary: accept-datetime
846 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
847 Link: ; rel="original timegate",
848
849 ; rel="timemap"; type="application/link-format"
850 Content-Length: 0
851 Content-Type: text/plain; charset=UTF-8
852 Connection: close
854 Figure 9: Response from URI-R=URI-G for Pattern 1.3
856 In a subsequent request, which is the same as Figure 4 but with HTTP
857 GET instead of HEAD, the user agent can obtain the representation of
858 the selected Memento. It will be provided as the entity-body of a
859 response that has the same Memento headers as in Figure 9.
861 4.2. Pattern 2 - A remote resource acts as a TimeGate for the Original
862 Resource
864 In this implementation pattern, the Original Resource does not act as
865 its own TimeGate, which means that URI-R and URI-G are different.
866 This pattern is typically implemented by servers for which the
867 history of their resources is recorded in remote systems such as web
868 archives and transactional archives [Fitch]. But servers that
869 maintain their own history, such as content management systems and
870 Version Control Systems, may also implement this pattern, for
871 example, to distribute the load involved in responding to requests
872 for current and prior representations of resources between different
873 servers.
875 This pattern is summarized in the below table and is detailed in the
876 remainder of this section. Three cases exist that differ regarding
877 the negotiation style that is used by the remote TimeGate and
878 regarding the existence of a URI-M for Mementos that is distinct from
879 the URI-G of the TimeGate.
881 +--------------+------------+------------+----------+---------------+
882 | Pattern | Original | TimeGate | Memento | Negotiation |
883 | | Resource | | | Style |
884 +--------------+------------+------------+----------+---------------+
885 | Pattern 2.1 | URI-R | URI-G | URI-M | 302 |
886 | (Section | | | | |
887 | 4.2.1) | | | | |
888 | Pattern 2.2 | URI-R | URI-G | URI-M | 200 |
889 | (Section | | | | |
890 | 4.2.2) | | | | |
891 | Pattern 2.3 | URI-R | URI-G | URI-G | 200 |
892 | (Section | | | | |
893 | 4.2.3) | | | | |
894 +--------------+------------+------------+----------+---------------+
896 Table 2: Pattern 2
898 The response by the Original Resource to the request shown in Figure
899 4 is the same for all three cases. The use of headers and links in
900 the response from URI-R is as follows:
902 o A "Vary" header that includes an "accept-datetime" value MUST NOT
903 be provided.
905 o The response MUST NOT contain a "Memento-Datetime" header.
907 o The "Link" header SHOULD be provided. It MUST NOT include a link
908 with an "original" Relation Type. If a preferred TimeGate is
909 associated with the Original Resource, then it MUST include a link
910 with a "timegate" Relation Type that has the URI-G of the TimeGate
911 as Target IRI. If a preferred TimeMap is associated with the
912 Original Resource, then it SHOULD include a link with a "timemap"
913 Relation Type that has the URI-T of the TimeGate as Target IRI.
914 Multiple "timegate" and "timemap" links can be provided to
915 accommodate situations in which the server is aware of multiple
916 TimeGates or Timemaps for the Original Resource.
918 Figure 10 shows such a response. Note the absence of an "original"
919 link as the responding resource is neither a TimeGate or a Memento.
921 HTTP/1.1 200 OK
922 Date: Thu, 21 Jan 2010 00:02:12 GMT
923 Server: Apache
924 Link:
925 ; rel="timegate"
926 Content-Length: 255
927 Connection: close
928 Content-Type: text/html; charset=iso-8859-1
930 Figure 10: Response from URI-R<>URI-G for Pattern 2
932 Once a user agent has obtained the URI-G of a remote TimeGate for the
933 Original Resource it can engage in datetime negotation with that
934 TimeGate. Figure 11 shows the request issued against the TimeGate
935 whereas Section 4.2.1 through Section 4.2.3 detail the responses for
936 various TimeGate implementation patterns.
938 HEAD /timegate/http://a.example.org/ HTTP/1.1
939 Host: arxiv.example.net
940 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
941 Connection: close
943 Figure 11: User Agent Engages in Datetime Negotiation With Remote
944 TimeGate
946 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; distinct
947 URI-M for Mementos
949 In case the TimeGate uses a 302 negotiation style, the response to
950 the user agent's request of Figure 11 has a "302 Found" HTTP status
951 code, and the "Location" header conveys the URI-M of the selected
952 Memento. The use of Memento response headers and links in the
953 response from URI-G is as follows:
955 o The "Vary" header MUST be provided and it MUST include the
956 "accept-datetime" value.
958 o The response MUST NOT contain a "Memento-Datetime" header.
960 o The "Link" header MUST be provided and it MUST contain at least a
961 link with the "original" Relation Type that has the URI-R of the
962 Original Resource as Target IRI. The provision of other links is
963 encouraged and is subject to the considerations described in
964 Section 2.2.
966 The server's response to the request of Figure 11 is shown in Figure
967 12. It contains the mandatory "original" link that points back to
968 the Original Resource associated with this TimeGate and it shows the
969 recommended "timemap" link that includes "from" and "until"
970 attributes.
972 HTTP/1.1 302 Found
973 Date: Thu, 21 Jan 2010 00:02:14 GMT
974 Server: Apache
975 Vary: accept-datetime
976 Location:
977 http://arxiv.example.net/web/20010911203610/http://a.example.org/
978 Link: ; rel="original",
979
980 ; rel="timemap"; type="application/link-format"
981 ; from="Tue, 15 Sep 2000 11:28:26 GMT"
982 ; until="Wed, 20 Jan 2010 09:34:33 GMT"
983 Content-Length: 0
984 Content-Type: text/plain; charset=UTF-8
985 Connection: close
987 Figure 12: Response from URI-G<>URI-R for Pattern 2.1
989 In a subsequent HTTP GET request, shown in Figure 13, the user agent
990 can obtain the selected Memento by issuing an HTTP GET request
991 against the URI-M that was provided in the "Location" header. The
992 inclusion of the "Accept-Datetime" header in this request is not
993 needed but will typically occur as the user agent is in datetime
994 negotiation mode.
996 GET /web/20010911203610/http://a.example.org/ HTTP/1.1
997 Host: arxiv.example.net/
998 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
999 Connection: close
1001 Figure 13: User Agent Requests Selected Memento
1003 The response has a "200 OK" HTTP status code. The use of Memento
1004 response headers and links in the response from URI-M is as follows:
1006 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1007 be provided.
1009 o The response MUST include a "Memento-Datetime" header. Its value
1010 expresses the archival datetime of the Memento.
1012 o The "Link" header MUST be provided and it MUST contain at least a
1013 link with the "original" Relation Type that has the URI-R of the
1014 Original Resource as Target IRI. The provision of other links is
1015 encouraged and is subject to the considerations described in
1016 Section 2.2.
1018 The server's response to the request of Figure 13 is shown in Figure
1019 14. Note the provision of the recommended "timegate" and "timemap"
1020 links.
1022 HTTP/1.1 200 OK
1023 Date: Thu, 21 Jan 2010 00:02:15 GMT
1024 Server: Apache-Coyote/1.1
1025 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1026 Link: ; rel="original",
1027
1028 ; rel="timemap"; type="application/link-format",
1029
1030 ; rel="timegate"
1031 Content-Length: 23364
1032 Content-Type: text/html;charset=utf-8
1033 Connection: close
1035 Figure 14: Response from URI-M for Pattern 2.1
1037 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; distinct
1038 URI-M for Mementos
1040 In case the TimeGate uses a 200 negotiation style, and each Memento
1041 has a distinct URI-M, the response to the user agent's request of
1042 Figure 11 has a "200 OK" HTTP status code, and the "Content-Location"
1043 header conveys the URI-M of the selected Memento. The use of Memento
1044 response headers and links in the response from URI-G is as follows:
1046 o The "Vary" header MUST be provided and it MUST include the
1047 "accept-datetime" value.
1049 o The response MUST include a "Memento-Datetime" header. Its value
1050 expresses the archival datetime of the Memento.
1052 o The "Link" header MUST be provided and it MUST contain at least a
1053 link with the "original" Relation Type that has the URI-R of the
1054 Original Resource as Target IRI. The provision of other links is
1055 encouraged and is subject to the considerations described in
1056 Section 2.2.
1058 The server's response to the request of Figure 11 is shown in Figure
1059 15.
1061 HTTP/1.1 200 OK
1062 Date: Thu, 21 Jan 2010 00:09:40 GMT
1063 Server: Apache-Coyote/1.1
1064 Vary: accept-datetime
1065 Content-Location:
1066 http://arxiv.example.net/web/20010911203610/http://a.example.org/
1067 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1068 Link: ; rel="original",
1069
1070 ; rel="timemap"; type="application/link-format",
1071
1072 ; rel="timegate"
1073 Content-Length: 23364
1074 Content-Type: text/html; charset=UTF-8
1075 Connection: close
1077 Figure 15: Response from URI-G<>URI-R for Pattern 2.2
1079 In a subsequent request, which is the same as Figure 11 but with HTTP
1080 GET instead of HEAD, the user agent can obtain the representation of
1081 the selected Memento. It will be provided as the entity-body of a
1082 response that has the same Memento headers as Figure 15.
1084 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct
1085 URI-M for Mementos
1087 In case the TimeGate uses a 200 negotiation style, but Mementos have
1088 no distinct URIs, the response to the user agent's request of Figure
1089 11 has a "200 OK" HTTP status code, and it does not contain a
1090 "Content-Location" nor "Location" header as there is no URI-M of the
1091 selected Memento to convey. The use of Memento response headers and
1092 links in the response from URI-G is as follows:
1094 o The "Vary" header MUST be provided and it MUST include the
1095 "accept-datetime" value.
1097 o The response MUST include a "Memento-Datetime" header. Its value
1098 expresses the archival datetime of the Memento.
1100 o The "Link" header MUST be provided and it MUST contain at least a
1101 link with the "original" Relation Type that has the URI-R of the
1102 Original Resource as Target IRI. The provision of other links is
1103 encouraged and is subject to the considerations described in
1104 Section 2.2.
1106 The server's response to the request of Figure 11 is shown in Figure
1107 16.
1109 HTTP/1.1 200 OK
1110 Date: Thu, 21 Jan 2010 00:09:40 GMT
1111 Server: Apache-Coyote/1.1
1112 Vary: accept-datetime
1113 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1114 Link: ; rel="original",
1115
1116 ; rel="timemap"; type="application/link-format",
1117
1118 ; rel="timegate"
1119 Content-Length: 23364
1120 Content-Type: text/html; charset=UTF-8
1121 Connection: close
1123 Figure 16: Response from URI-G<>URI-R for Pattern 2.3
1125 In a subsequent request, which is the same as Figure 11 but with HTTP
1126 GET instead of HEAD, the user agent can obtain the representation of
1127 the selected Memento. It will be provided as the entity-body of a
1128 response that has the same Memento headers as Figure 16.
1130 4.3. Pattern 3 - The Original Resource is a Fixed Resource
1132 This pattern does not involve datetime negotiation with a TimeGate
1133 but it can be implemented for Original Resources that never change
1134 state or do not change anymore past a certain point in their
1135 existence, meaning that URI-R and URI-M coincide either from the
1136 outset or starting at some point in time. This pattern is summarized
1137 in the below table. Examples are tweets or stable media resources on
1138 news sites.
1140 +-----------+--------------+------------+----------+----------------+
1141 | Pattern | Original | TimeGate | Memento | Negotiation |
1142 | | Resource | | | Style |
1143 +-----------+--------------+------------+----------+----------------+
1144 | Pattern 3 | URI-R | - | URI-R | - |
1145 +-----------+--------------+------------+----------+----------------+
1147 Table 3: Pattern 3
1149 Servers that host such resources can support the Memento framework by
1150 treating the stable resource (FixedResource as per
1151 [W3C.gen-ont-20090420]) as a Memento. The use of Memento response
1152 headers and links in responses from such a stable resource is as
1153 follows:
1155 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1156 be provided.
1158 o The response MUST include a "Memento-Datetime" header. Its value
1159 expresses the datetime at which the resource became stable.
1160 Providing this value includes a promise that the resource has not
1161 changed since this datetime and will not change anymore beyond it.
1163 o The "Link" header MUST be provided and MUST have a link with the
1164 "original" Relation Type that has the URI-R of the stable resource
1165 itself as Target IRI.
1167 Figure 17 shows a response to an HTTP HEAD request for the resource
1168 with URI-R http://a.example.org/ that has been stable since March
1169 20th 2009.
1171 HTTP/1.1 200 OK
1172 Date: Thu, 21 Jan 2010 00:09:40 GMT
1173 Server: Apache-Coyote/1.1
1174 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
1175 Link: ; rel="original"
1176 Content-Length: 0
1177 Content-Type: text/plain; charset=UTF-8
1178 Connection: close
1180 Figure 17: Response from URI-R=URI-M for Pattern 3
1182 4.4. Pattern 4 - Mementos without a TimeGate
1184 Cases may occur in which a server hosts Mementos but does not expose
1185 a TimeGate for them. This can, for example, be the case if the
1186 server's Mementos result from taking a snapshot of the state of a set
1187 of Original Resources from another server as it is being retired. As
1188 a result, only a single Memento per Original Resource is hosted,
1189 making the introduction of a TimeGate unnecessary. But it may also
1190 be the case for servers that host multiple Mementos for an Original
1191 Resource but consider exposing TimeGates too expensive. In this
1192 case, URI-R and URI-M are distinct, but a TimeGate is absent. This
1193 case is summarized in the below table.
1195 +-----------+--------------+------------+----------+----------------+
1196 | Pattern | Original | TimeGate | Memento | Negotiation |
1197 | | Resource | | | Style |
1198 +-----------+--------------+------------+----------+----------------+
1199 | Pattern 4 | URI-R | - | URI-M | - |
1200 +-----------+--------------+------------+----------+----------------+
1202 Table 4: Pattern 4
1204 Servers that host such Mementos without TimeGates can still support
1205 the Memento framework by providing the appropriate Memento headers
1206 and links. Their use is as follows for a response from URI-M:
1208 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1209 be provided.
1211 o The response MUST include a "Memento-Datetime" header. Its value
1212 expresses the archival datetime of the Memento.
1214 o The "Link" header MUST be provided and it MUST have a link with
1215 the "original" Relation Type that has the URI-R of the associated
1216 Original Resource as Target IRI. The provision of other links is
1217 encouraged and is subject to the considerations described in
1218 Section 2.2.
1220 Figure 18 shows a response to an HTTP HEAD request for the Memento
1221 with URI-M http://arxiv.example.net/web/20010911203610/http://
1222 a.example.org/. Note the use of links: three links have the URI-M of
1223 the Memento as Target IRI and have respective Relation Types
1224 "memento", "first", and "last". This combination indicates that this
1225 is the only Memento for the Original Resource with Target IRI
1226 provided by the "original" link (http://a.example.org/) that the
1227 server is aware of. Note also that such a response does not imply
1228 that there is no server whatsoever that exposes a TimeGate; it merely
1229 means that the responding server neither provides nor is aware of the
1230 location of a TimeGate.
1232 HTTP/1.1 200 OK
1233 Date: Thu, 21 Jan 2010 00:09:40 GMT
1234 Server: Apache-Coyote/1.1
1235 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1236 Link: ; rel="original",
1237
1238 ; rel="first last memento"
1239 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT"
1240 Content-Length: 0
1241 Content-Type: text/plain; charset=UTF-8
1242 Connection: close
1244 Figure 18: Response from URI-M<>URI-R for Pattern 4
1246 4.5. Special Cases
1248 4.5.1. Original Resource provides no "timegate" link
1250 Cases exist in which the response from the Original Resource does not
1251 contain a "timegate" link, including:
1253 o The Original Resource's server does not support the Memento
1254 framework;
1256 o The Original Resource no longer exists and the responding server
1257 is not aware of its prior existence;
1259 o The server that hosted the Original Resource no longer exists.
1261 In all these cases, the user agent should attempt to determine an
1262 appropriate TimeGate for the Original Resource, either automatically
1263 or interactively supported by the user.
1265 4.5.2. Server exists but Original Resource no longer does
1267 Cases exist in which the server knows that an Original Resource used
1268 to exist, but no longer provides a current representation. If there
1269 is a preferred TimeGate for such a discontinued Original Resource,
1270 then the server MUST include a "timegate" link in responses to
1271 requests for it. This may allow access to Mementos for the Original
1272 Resource even if it no longer exists. A server's response to a
1273 request for the discontinued resource http://a.example.org/pic is
1274 illustrated in Figure 19.
1276 HTTP/1.1 404 Not Found
1277 Date: Thu, 21 Jan 2010 00:02:12 GMT
1278 Server: Apache
1279 Link:
1280
1281 ; rel="timegate"
1282 Content-Length: 255
1283 Connection: close
1284 Content-Type: text/html; charset=iso-8909-1
1286 Figure 19: Response from an Original Resource that not longer exists
1288 4.5.3. Issues with Accept-Datetime
1290 The following special cases may occur regarding the "Accept-Datetime"
1291 header when a user agent issues a request against a TimeGate:
1293 o If the value of the "Accept-Datetime" is either earlier than the
1294 datetime of the first Memento or later than the datetime of the
1295 most recent Memento known to the TimeGate, the first or most
1296 recent Memento MUST be selected, respectively.
1298 o If the value of the "Accept-Datetime" does not conform to the
1299 rfc1123-date construction rule of the BNF in Figure 1, the
1300 response MUST have a "400 Bad Request" HTTP status code.
1302 o If a user agent issues a request against a TimeGate and fails to
1303 include an "Accept-Datetime" request header, the most recent
1304 Memento SHOULD be selected.
1306 In all cases, the use of headers and links in responses is as
1307 described for TimeGates in the respective scenarios.
1309 4.5.4. Memento of a 3XX response
1311 Cases exist in which HTTP responses with 3XX status codes are
1312 archived. For example, crawl-based web archives commonly archive
1313 responses with HTTP status codes "301 Moved Permanently" and "302
1314 Found" whereas Linked Data archives hold on to "303 See Other"
1315 responses.
1317 If the Memento requested by the user agent is an archived version of
1318 an HTTP response with a 3XX status code, the server's response MUST
1319 have the same 3XX HTTP status code. The use of other Memento headers
1320 is as described for Mementos in the respective scenarios.
1322 The user agent's handling of an HTTP response with a 3XX status code
1323 is not affected by the presence of a "Memento-Datetime" header. The
1324 user agent MUST behave in the same manner as it does with HTTP
1325 responses with a 3XX status code that do not have a "Memento-
1326 Datetime" header.
1328 However, the user agent MUST be aware that the URI that was selected
1329 from the "Location" header of an HTTP response with a 3XX status code
1330 might not be that of a Memento but rather of an Original Resource.
1331 In the latter case it SHOULD proceed by looking for a Memento of the
1332 selected Original Resource.
1334 For example, Figure 20 shows the response to an HTTP GET request for
1335 http://a.example.org issued on April 11 2008. This response is
1336 archived as a Memento of http://a.example.org that has as URI-M http:
1337 //arxiv.example.net/web/20080411000650/http://a.example.org. The
1338 response to an HTTP GET on this URI-M is shown in Figure 21. It is a
1339 replay of the original response with "Memento-Datetime" and "Link"
1340 headers added, to allow a user agent to understand the response is a
1341 Memento. In Figure 21, the value of the "Location" header is the
1342 same as in the original response; it identifies an Original Resource.
1343 The user agent proceeds with finding a Memento for this Original
1344 Resource. Web archives sometimes overwrite the value that was
1345 originally provided in the "Location" header in order to point at a
1346 Memento they hold of the resource to which the redirect originally
1347 led. This is shown in Figure 22. In this case, the user agent may
1348 decide it found an appropriate Memento.
1350 HTTP/1.1 301 Moved Permanently
1351 Date: Fri, 11 Apr 2008 00:06:50 GMT
1352 Server: Apache
1353 Location: http://b.example.org
1354 Content-Length: 0
1355 Content-Type: text/plain; charset=UTF-8
1356 Connection: close
1358 Figure 20: Response is a redirect
1360 HTTP/1.1 301 Moved Permanently
1361 Date: Thu, 21 Jan 2010 00:09:40 GMT
1362 Server: Apache-Coyote/1.1
1363 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1364 Location: http://b.example.org
1365 Link: ; rel="original",
1366
1367 ; rel="timemap"; type="application/link-format",
1368
1369 ; rel="timegate"
1370 Content-Length: 0
1371 Content-Type: text/plain; charset=UTF-8
1372 Connection: close
1374 Figure 21: Response is a Memento of a redirect; leads to an Original
1375 Resource
1377 HTTP/1.1 301 Moved Permanently
1378 Date: Thu, 21 Jan 2010 00:09:40 GMT
1379 Server: Apache-Coyote/1.1
1380 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1381 Location:
1382 http://arxiv.example.net/web/20080411000655/http://b.example.org
1383 Link: ; rel="original",
1384
1385 ; rel="timemap"; type="application/link-format",
1386
1387 ; rel="timegate"
1388 Content-Length: 0
1389 Content-Type: text/plain; charset=UTF-8
1390 Connection: close
1392 Figure 22: Response is a Memento of a redirect; leads to a Memento
1394 4.5.5. Memento of responses with 4XX or 5XX HTTP status codes
1396 Cases exist in which responses with 4XX and 5XX HTTP status codes are
1397 archived. If the Memento requested by the user agent is an archived
1398 version of such an HTTP response, the server's response MUST have the
1399 same 4XX or 5XX HTTP status code. The use of headers and links in
1400 responses is as described for Mementos in the respective scenarios.
1402 For example, Figure 23 shows the 404 response to an HTTP GET request
1403 for http://a.example.org issued on April 11 2008. This response is
1404 archived as a Memento of http://a.example.org, that has as URI-M
1405 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1406 The response to an HTTP HEAD on this URI-M is shown in Figure 24. It
1407 is a replay of the original response with "Memento-Datetime" and
1408 "Link" headers added, to allow a user agent to understand the
1409 response is a Memento.
1411 HTTP/1.1 404 Not Found
1412 Date: Fri, 11 Apr 2008 00:06:50 GMT
1413 Server: Apache
1414 Content-Length: 0
1415 Content-Type: text/plain; charset=UTF-8
1416 Connection: close
1418 Figure 23: Response is a 404
1420 HTTP/1.1 404 Not Found
1421 Date: Thu, 21 Jan 2010 00:09:40 GMT
1422 Server: Apache-Coyote/1.1
1423 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1424 Link: ; rel="original",
1425
1426 ; rel="timemap"; type="application/link-format",
1427
1428 ; rel="timegate"
1429 Content-Length: 0
1430 Content-Type: text/plain; charset=UTF-8
1431 Connection: close
1433 Figure 24: Response is a Memento of a 404
1435 4.5.6. Sticky "Memento-Datetime" value for Mementos
1437 The provision of a "Memento-Datetime" in a response entails a promise
1438 that the response is frozen in time. As a consequence, the "Memento-
1439 Datetime" header associated with a Memento MUST be "sticky" in the
1440 following ways:
1442 o The server that originally assigns the "Memento-Datetime" header
1443 and value to a specific response MUST retain that header in all
1444 future responses to HTTP requests (with or without "Accept-
1445 Datetime" header) that occur against the Memento after the time of
1446 the original assignment of the header, and it MUST NOT change its
1447 associated value.
1449 o Applications that mirror Mementos at a different URI MUST retain
1450 the "Memento-Datetime" header and MUST NOT change its value unless
1451 mirroring involves a meaningful state change. This allows, for
1452 example, duplicating a web archive at a new location while
1453 preserving the value of the "Memento-Datetime" header of the
1454 archived resources. In this example, the "Last-Modified" header
1455 will be updated to reflect the time of mirroring at the new URI,
1456 whereas the value for "Memento-Datetime" will be maintained.
1458 4.5.7. Intermediate Resources
1459 An intermediate resource is a resource that issues a redirect to a
1460 TimeGate, to a Memento, or to another intermediate resource, and thus
1461 plays an active role in the Memento infrastructure. Intermediate
1462 resources commonly exist in web archives on the path from a TimeGate
1463 to an appropriate Memento.
1465 A response of an intermediate resource has an HTTP status code
1466 indicative of HTTP redirection (e.g. 302) and uses Memento headers
1467 and links that allow to recognize that the resource plays a role in
1468 the Memento framework:
1470 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1471 be provided.
1473 o The response MUST NOT include a "Memento-Datetime" header.
1475 o The "Link" header MUST be provided and it MUST have a link with
1476 the "original" Relation Type that has the URI-R of the associated
1477 Original Resource as Target IRI. Links with "timegate",
1478 "timemap", and "memento" Relation Types are OPTIONAL and, if
1479 provided, MUST pertain to the Original Resource for which the user
1480 agent is trying to obtain a Memento.
1482 A user agent MUST follow a redirection provided by an intermediate
1483 resource; multiple such redirections can be chained.
1485 Consider the case where a user agent follows the "timegate" link
1486 provided in Figure 10 and engages in datetime negotiation with the
1487 assumed TimeGate in the manner shown in Figure 11. But instead of
1488 receiving a response as shown in Figure 12, it receives the one shown
1489 below in Figure 25. Such a response is umabiguosuly recognizable as
1490 coming from an intermediate resource.
1492 HTTP/1.1 302 Found
1493 Date: Thu, 21 Jan 2010 00:06:50 GMT
1494 Server: Apache
1495 Location:
1496 http://arxiv.example.net/new-timegate/http://a.example.org/
1497 Link: ; rel="original"
1498 Content-Length: 0
1499 Content-Type: text/plain; charset=UTF-8
1500 Connection: close
1502 Figure 25: Redirecting Resource redirects to a TimeGate
1504 5. TimeMaps: Content and Serialization
1505 A TimeMap is introduced to support retrieving a comprehensive list of
1506 all Mementos for a specific Original Resource known to a server. The
1507 entity-body of a response to an HTTP GET request issued against a
1508 TimeMap's URI-T:
1510 o MUST list the URI-R of the Original Resource that the TimeMap is
1511 about;
1513 o MUST list the URI-M and archival datetime of each Memento for the
1514 Original Resource known to the server, preferably in a single
1515 document, or, alternatively in multiple documents that can be
1516 gathered by following contained links with a "timemap" Relation
1517 Type;
1519 o SHOULD list the URI-G of one or more TimeGates for the Original
1520 Resource known to the responding server;
1522 o SHOULD, for self-containment, list the URI-T of the TimeMap
1523 itself;
1525 o MUST unambiguously type listed resources as being Original
1526 Resource, TimeGate, Memento, or TimeMap.
1528 The entity-body of a response from a TimeMap MAY be serialized in
1529 various ways, but the link-value format serialization described here
1530 MUST be supported. In this serialization, the entity-body MUST be
1531 formatted in the same way as the value of an HTTP "Link" header, and
1532 hence MUST comply to the "link-value" construction rule of
1533 "Section 5. The Link Header Field" of [RFC5988], and the media type
1534 of the entity-body MUST be "application/link-format" as introduced in
1535 [RFC6690]. Links contained in the entity-body MUST be interpreted as
1536 follows:
1538 o The Context IRI is set to the anchor parameter, when specified;
1540 o The Context IRI of links with the "self" Relation Types is the
1541 URI-T of the TimeMap, i.e. the URI of the resource from which the
1542 TimeMap was requested;
1544 o The Context IRI of all other links is the URI-R of the Original
1545 Resource, which is provided as the Target IRI of the link with an
1546 "original" Relation Type.
1548 In order to retrieve the link-value serialization of a TimeMap, a
1549 user agent uses an "Accept" request header with a value set to
1550 "application/link-format". This is shown in Figure 26.
1552 GET /timemap/http://a.example.org/ HTTP/1.1
1553 Host: arxiv.example.net
1554 Accept: application/link-format;q=1.0
1555 Connection: close
1557 Figure 26: Request for a TimeMap
1559 If the TimeMap requested by the user agent exists, the server's
1560 response has a "200 OK" HTTP status code and the list of Mementos is
1561 provided in the entity-body of the response. Such a response is
1562 shown in Figure 27
1564 HTTP/1.1 200 OK
1565 Date: Thu, 21 Jan 2010 00:06:50 GMT
1566 Server: Apache
1567 Content-Length: 4883
1568 Content-Type: application/link-format
1569 Connection: close
1571 ;rel="original",
1572
1573 ; rel="self";type="application/link-format"
1574 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1575 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1576
1577 ; rel="timegate",
1578
1579 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
1580 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1581
1582 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
1583 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1584
1585 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
1586 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1587
1588 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
1589 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1590 ...
1592 Figure 27: Response from a TimeMap
1594 5.1. Special Cases
1596 5.1.1. Index and Paging TimeMaps
1598 Cases exist in which a TimeMap points at one or more other TimeMaps:
1600 o Index Timemap - A TimeMap can merely point at other TimeMaps and
1601 not list any Mementos itself. This can happen when Mementos are
1602 spread across several archives that share a front-end. An example
1603 is shown in Figure 28.
1605 o Paging Timemap - The number of available Mementos can require
1606 introducing multiple TimeMaps that can be paged. An example is
1607 shown in Figure 29. Note that a Paging TimeMap contains links to
1608 other TimeMaps but actually also lists Mementos.
1610 In both cases, including the "from" and "until" attributes for
1611 "timemap" links is RECOMMENDED as a means to express the temporal
1612 span of Mementos listed in each TimeMap. Note that TimeMaps obtained
1613 by following a "timemap" link can contain links to further TimeMaps.
1615 ;rel="original",
1616
1617 ; rel="timegate",
1618
1619 ; rel="self";type="application/link-format",
1620
1621 ; rel="timemap";type="application/link-format"
1622 ; from="Wed, 21 Jun 2000 04:41:56 GMT"
1623 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1624
1625 ; rel="timemap";type="application/link-format"
1626 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1627 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1628
1629 ; rel="timemap";type="application/link-format"
1630 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1632 Figure 28: Index TimeMap
1634 ;rel="original",
1635
1636 ; rel="timegate",
1637
1638 ; rel="self";type="application/link-format"
1639 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1640 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1641
1642 ; rel="timemap";type="application/link-format"
1643 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1644 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1645
1646 ; rel="timemap";type="application/link-format"
1647 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1648 ; until="Fri, 31 Aug 2012 12:22:34 GMT"
1649
1650 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1651
1652 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1653
1654 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1655 ...
1657 Figure 29: Paging TimeMap
1659 5.1.2. Mementos for TimeMaps
1661 A TimeMap can itself act as an Original Resource for which a TimeGate
1662 and Mementos may exist. Hence, the response from a TimeMap could
1663 include a "timegate" link to a TimeGate via which prior TimeMap
1664 versions are available. And, in cases where URI-T=URI-R=URI-G (a
1665 TimeMap is an Original Resource that acts as its own TimeGate), an
1666 "original" link pointing at the TimeMap URI-T would be included.
1668 Therefore, caution is required in cases where a TimeMap for an
1669 Original Resource wants to explicitly express in a Link header for
1670 which Original Resource it is a TimeMap. It can do so by including a
1671 "timemap" link that has the URI-R of the Original Resource as Context
1672 IRI and the URI-T of the TimeMap as Target IRI.
1674 Figure 30 shows the response to an HTTP HEAD request against a
1675 TimeMap that has http://arxiv.example.net/timemap/http://
1676 a.example.org as URI-T. This TimeMap provides information about
1677 Mementos for the Original Resource that has http://a.example.org as
1678 URI-R. The response includes an "original" link pointing to the
1679 Original Resource that this TimeMap is about. Note the use of the
1680 "anchor" attribute in this link to convey the URI-R of that Original
1681 Resource.
1683 HTTP/1.1 200 OK
1684 Date: Thu, 21 Jan 2010 00:06:50 GMT
1685 Server: Apache
1686 Link:
1687 ; anchor="http://a.example.org"; rel="timemap"
1688 ; type="application/link-format"
1689 Content-Length: 0
1690 Content-Type: application/link-format; charset=UTF-8
1691 Connection: close
1693 Figure 30: TimeMap links to the Original Resource it is about
1695 6. IANA Considerations
1697 This memo requires IANA to register the Accept-Datetime and Memento-
1698 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1699 IANA registry.
1701 This memo requires IANA to register the Relation Types "original",
1702 "timegate", "timemap", and "memento" defined in Section 2.2 in the
1703 appropriate IANA registry.
1705 This memo requires IANA to register the "datetime" and "license"
1706 attributes for the "memento" Relation Type, as defined in
1707 Section 2.2.4, in the appropriate IANA registry.
1709 This memo requires IANA to register the "from" and "until" attributes
1710 for the "timemap" Relation Type, as defined in Section 2.2.4, in the
1711 appropriate IANA registry.
1713 7. Security Considerations
1715 Provision of a "timegate" HTTP "Link" header in responses to requests
1716 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1717 response codes) is OPTIONAL. The inclusion of this Link when
1718 requesting authentication is at the server's discretion; cases may
1719 exist in which a server protects the current state of a resource, but
1720 supports open access to prior states and thus chooses to supply a
1721 "timegate" HTTP "Link" header. Conversely, the server may choose to
1722 not advertise the TimeGate URIs (e.g., they exist in an intranet
1723 archive) for unauthenticated requests.
1725 The veracity of archives and the relationships between Original
1726 Resources and Mementos is beyond the scope of this document. Even in
1727 the absence of malice, it is possible for separate archives to have
1728 different Mementos for the same Original Resource at the same
1729 datetime if the state of the Original Resource was dependent on the
1730 requesting archive's user agent IP address, specific HTTP request
1731 headers, and possibly other factors.
1733 Further authentication, encryption and other security related issues
1734 are otherwise orthogonal to Memento.
1736 8. Changelog
1738 v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07
1740 o Introduced "Overview" section to make the existence of two
1741 components (datetime negotiation and TimeMaps) more explicit.
1743 o Replaced the hard-to-interpret summary table detailing the use of
1744 headers (introduced in version 06 ) with an explicit version in
1745 the appendix.
1747 o Revised the abstract.
1749 o Added TimeMaps to the enumeration of core components in the
1750 Purpose section.
1752 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06
1754 o Major overhaul of the presentation of the specification.
1756 o Specification of patterns whereby URI-R=URI-G and with both 200
1757 and 302 negotation style.
1759 o Removal of Discovery section to increase focus on datetime
1760 negotation aspects.
1762 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05
1764 o Clarified the section on Memento Relation Types.
1766 o Re-introduced "license" attribute for "memento" Relation Type as
1767 it will become essential for IIPC.
1769 o Introduced from and until attributes for "timemap" links to
1770 accomodate paged TimeMap cases.
1772 o Introduced the notion of Redirecting Resource and inserted related
1773 information in various sections.
1775 o Added discovery of Mementos via host-meta.
1777 o Corrected ambiguous uses of the term "representation".
1779 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
1781 o Removed the possibility to use an interval indicator in an Accept-
1782 Datetime header as no one is implementing it.
1784 o Corrected typo in Other Relation Types table.
1786 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap
1787 paging.
1789 o Changed Discovery component from using robots.txt with Memento-
1790 specific add-ons to well-known URI and host-meta.
1792 o Removed "embargo" and "license" attributes for links with a
1793 "memento" Relation Type because no one is using them.
1795 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1797 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1798 5XX status code.
1800 o Clarified that a TimeGate must not use the "Memento-Datetime"
1801 header.
1803 o Added wording to warn for possible cache problems with Memento
1804 implementations that choose to have an Original Resource and and
1805 its TimeGate coincide.
1807 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1809 o Added scenario in which a TimeGate redirects to another TimeGate.
1811 o Reorganized TimeGate section to better reflect the difference
1812 between requests with and without interval indicator.
1814 o Added recommendation to provide "memento" links to Mementos in the
1815 vicinity of the preferred interval provided by the user agent, in
1816 case of a 406 response.
1818 o Removed TimeMap Feed material from the Discovery section as a
1819 result of discussions regarding (lack of) scalability of the
1820 approach with representatives of the International Internet
1821 Preservation Consortium. An alternative approach to support batch
1822 discovery of Mementos will be specified.
1824 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1826 o Introduced wording and reference to indicate a Memento is a
1827 FixedResource.
1829 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1830 about retaining "Memento-Datetime" headers and values when a
1831 Memento is mirrored at different URI.
1833 o Introduced section about handling both datetime and regular
1834 negotiation.
1836 o Introduced section about Mementos Without TimeGate.
1838 o Made various changes in the section Relation Type "memento",
1839 including addition of "license" and "embargo" attributes, and
1840 clarification of rules regarding the use of "memento" links.
1842 o Moved section about TimeMaps inside the Datetime Negotiation
1843 section, and updated it.
1845 o Restarted the Discovery section from scratch.
1847 v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel-
1848 memento-00
1850 v00 2010-10-19 HVDS MLN RS Limited circulation version
1852 2010-07-22 HVDS MLN First internal version
1854 9. Acknowledgements
1856 The Memento effort is funded by the Library of Congress. Many thanks
1857 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1858 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers,
1859 James Anderson, Tim Starling, Martin Klein, Mark Nottingham for
1860 feedback. Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla
1861 Balakireva, Frank McCown, Harihar Shankar, Brad Tofel for early
1862 implementations.
1864 10. References
1866 10.1. Normative References
1868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1869 Requirement Levels", BCP 14, RFC 2119, March 1997.
1871 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1872 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1873 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1875 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
1876 4151, October 2005.
1878 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1879 Syndication Format", RFC 4287, December 2005.
1881 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
1882 Uniform Resource Identifiers (URIs)", RFC 5785, April
1883 2010.
1885 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
1886 for Simple Version Navigation between Web Resources", RFC
1887 5829, April 2010.
1889 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
1891 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC
1892 6415, October 2011.
1894 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
1895 Format", RFC 6690, August 2012.
1897 10.2. Informative References
1899 [Fitch] Fitch, , "Web site archiving - an approach to recording
1900 every materially different response produced by a
1901 website", July 2003,
1902 .
1904 [I-D.masinter-dated-uri]
1905 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
1906 dated URIs", draft-masinter-dated-uri-10 (work in
1907 progress), January 2012.
1909 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1910 and Support", STD 3, RFC 1123, October 1989.
1912 [W3C.REC-aww-20041215]
1913 Jacobs, and Walsh, "Architecture of the World Wide Web",
1914 December 2004, .
1916 [W3C.gen-ont-20090420]
1917 Berners-Lee, , "Architecture of the World Wide Web", April
1918 2009, .
1920 Appendix A. Appendix: Use of Headers and Relation Types per Pattern
1922 +--------------------+--------------+----------+----------+---------+
1923 | Response Header | Pattern | Original | TimeGate | Memento |
1924 | | | Resource | | |
1925 +--------------------+--------------+----------+----------+---------+
1926 | Vary: accept- | Pattern 1.1 | 1 | 1 | 0 |
1927 | datetime | (Section | | | |
1928 | | 4.1.1) ; | | | |
1929 | | Pattern 1.2 | | | |
1930 | | (Section | | | |
1931 | | 4.1.2) | | | |
1932 | | Pattern 1.3 | 1 | 1 | 1 |
1933 | | (Section | | | |
1934 | | 4.1.3) | | | |
1935 | | Pattern 2.1 | 0 | 1 | 0 |
1936 | | (Section | | | |
1937 | | 4.2.1) ; | | | |
1938 | | Pattern 2.2 | | | |
1939 | | (Section | | | |
1940 | | 4.2.2) | | | |
1941 | | Pattern 2.3 | 0 | 1 | 1 |
1942 | | (Section | | | |
1943 | | 4.2.3) | | | |
1944 | | Pattern 3 | 1 | NA | 1 |
1945 | | (Section | | | |
1946 | | 4.3) | | | |
1947 | | Pattern 4 | 0 | NA | 1 |
1948 | | (Section | | | |
1949 | | 4.4) | | | |
1950 | Memento-Datetime | Pattern 1.1 | 0 | 0 | 1 |
1951 | | (Section | | | |
1952 | | 4.1.1) ; | | | |
1953 | | Pattern 1.2 | | | |
1954 | | (Section | | | |
1955 | | 4.1.1) | | | |
1956 | | Pattern 1.3 | 1 | 1 | 1 |
1957 | | (Section | | | |
1958 | | 4.1.3) | | | |
1959 | | Pattern 2.1 | 0 | 0 | 1 |
1960 | | (Section | | | |
1961 | | 4.2.1) ; | | | |
1962 | | Pattern 2.2 | | | |
1963 | | (Section | | | |
1964 | | 4.2.2) | | | |
1965 | | Pattern 2.3 | 0 | 1 | 1 |
1966 | | (Section | | | |
1967 | | 4.2.3) | | | |
1968 | | Pattern 3 | 1 | NA | 1 |
1969 | | (Section | | | |
1970 | | 4.3) | | | |
1971 | | Pattern 4 | 0 | NA | 1 |
1972 | | (Section | | | |
1973 | | 4.4) | | | |
1974 | Link | | | | |
1975 | rel="original" | Pattern 1.1 | 0 | 1 | 1 |
1976 | | (Section | | | |
1977 | | 4.1.1) ; | | | |
1978 | | Pattern 1.2 | | | |
1979 | | (Section | | | |
1980 | | 4.1.1) | | | |
1981 | | Pattern 1.3 | 1 | 1 | 1 |
1982 | | (Section | | | |
1983 | | 4.1.3) | | | |
1984 | | Pattern 2.1 | 0 | 1 | 1 |
1985 | | (Section | | | |
1986 | | 4.2.1) ; | | | |
1987 | | Pattern 2.2 | | | |
1988 | | (Section | | | |
1989 | | 4.2.2) | | | |
1990 | | Pattern 2.3 | 0 | 1 | 1 |
1991 | | (Section | | | |
1992 | | 4.2.3) | | | |
1993 | | Pattern 3 | 1 | NA | 1 |
1994 | | (Section | | | |
1995 | | 4.3) | | | |
1996 | | Pattern 4 | 0 | NA | 1 |
1997 | | (Section | | | |
1998 | | 4.4) | | | |
1999 | rel="timegate" | Pattern 1.1 | >=0 | >=0 | >=0 |
2000 | | (Section | | | |
2001 | | 4.1.1) ; | | | |
2002 | | Pattern 1.2 | | | |
2003 | | (Section | | | |
2004 | | 4.1.1) | | | |
2005 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2006 | | (Section | | | |
2007 | | 4.1.3) | | | |
2008 | | Pattern 2.1 | >=0 | 0 | >=0 |
2009 | | (Section | | | |
2010 | | 4.2.1) ; | | | |
2011 | | Pattern 2.2 | | | |
2012 | | (Section | | | |
2013 | | 4.2.2) | | | |
2014 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2015 | | (Section | | | |
2016 | | 4.2.3) | | | |
2017 | | Pattern 3 | NA | NA | NA |
2018 | | (Section | | | |
2019 | | 4.3) | | | |
2020 | | Pattern 4 | NA | NA | NA |
2021 | | (Section | | | |
2022 | | 4.4) | | | |
2023 | rel="timemap" | Pattern 1.1 | >=0 | >=0 | >=0 |
2024 | | (Section | | | |
2025 | | 4.1.1) ; | | | |
2026 | | Pattern 1.2 | | | |
2027 | | (Section | | | |
2028 | | 4.1.1) | | | |
2029 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2030 | | (Section | | | |
2031 | | 4.1.3) | | | |
2032 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2033 | | (Section | | | |
2034 | | 4.2.1) ; | | | |
2035 | | Pattern 2.2 | | | |
2036 | | (Section | | | |
2037 | | 4.2.2) | | | |
2038 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2039 | | (Section | | | |
2040 | | 4.2.3) | | | |
2041 | | Pattern 3 | >=0 | NA | >=0 |
2042 | | (Section | | | |
2043 | | 4.3) | | | |
2044 | | Pattern 4 | >=0 | NA | >=0 |
2045 | | (Section | | | |
2046 | | 4.4) | | | |
2047 | rel="memento" | Pattern 1.1 | >=0 | >=0 | >=0 |
2048 | | (Section | | | |
2049 | | 4.1.1) ; | | | |
2050 | | Pattern 1.2 | | | |
2051 | | (Section | | | |
2052 | | 4.1.1) | | | |
2053 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2054 | | (Section | | | |
2055 | | 4.1.3) | | | |
2056 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2057 | | (Section | | | |
2058 | | 4.2.1) ; | | | |
2059 | | Pattern 2.2 | | | |
2060 | | (Section | | | |
2061 | | 4.2.2) | | | |
2062 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2063 | | (Section | | | |
2064 | | 4.2.3) | | | |
2065 | | Pattern 3 | >=0 | NA | >=0 |
2066 | | (Section | | | |
2067 | | 4.3) | | | |
2068 | | Pattern 4 | >=0 | NA | >=0 |
2069 | | (Section | | | |
2070 | | 4.4) | | | |
2071 +--------------------+--------------+----------+----------+---------+
2073 Table 5: Memento Headers
2075 Authors' Addresses
2076 Herbert VandeSompel
2077 Los Alamos National Laboratory
2078 PO Box 1663
2079 Los Alamos, New Mexico 87545
2080 USA
2082 Phone: +1 505 667 1267
2083 Email: hvdsomp@gmail.com
2084 URI: http://public.lanl.gov/herbertv/
2086 Michael Nelson
2087 Old Dominion University
2088 Norfolk, Virginia 23529
2089 USA
2091 Phone: +1 757 683 6393
2092 Email: mln@cs.odu.edu
2093 URI: http://www.cs.odu.edu/~mln/
2095 Robert Sanderson
2096 Los Alamos National Laboratory
2097 PO Box 1663
2098 Los Alamos, New Mexico 87545
2099 USA
2101 Phone: +1 505 665 5804
2102 Email: azaroth42@gmail.com
2103 URI: http://public.lanl.gov/rsanderson/