idnits 2.17.1
draft-vandesompel-memento-11.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 (October 10, 2013) is 3813 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 2008, but no explicit
reference was found in the text
== Unused Reference: 'RFC4287' is defined on line 2011, but no explicit
reference was found in the text
== Unused Reference: 'RFC5785' is defined on line 2014, but no explicit
reference was found in the text
== Unused Reference: 'RFC6415' is defined on line 2024, 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. Van de Sompel
3 Internet-Draft Los Alamos National Laboratory
4 Intended status: Informational M. Nelson
5 Expires: April 13, 2014 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 October 10, 2013
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-11
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 April 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . 12
76 4. Datetime Negotiation: HTTP Interactions . . . . . . . . . . . 13
77 4.1. Pattern 1 - The Original Resource acts as its own
78 TimeGate . . . . . . . . . . . . . . . . . . . . . . . . 14
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" 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 . . . . . . . . . . . . . . . . . . . . . 37
111 6.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 37
112 6.2. Link Relation Types . . . . . . . . . . . . . . . . . . . 38
113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
114 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 40
115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
117 10.1. Normative References . . . . . . . . . . . . . . . . . . 43
118 10.2. Informative References . . . . . . . . . . . . . . . . . 44
119 Appendix A. Appendix: Use of Headers and Relation Types per
120 Pattern . . . . . . . . . . . . . . . . . . . . . . 44
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
123 1. Introduction
125 1.1. Terminology
127 This specification uses the terms "resource", "request", "response",
128 "entity-body", "content negotiation", "user agent", "server" as
129 described in [RFC2616], and it uses the terms "representation" and
130 "resource state" as described in [W3C.REC-aww-20041215].
132 In addition, the following terms specific to the Memento framework
133 are introduced:
135 o Original Resource: An Original Resource is a resource that exists
136 or used to exist, and for which access to one of its prior states
137 may be required.
139 o Memento: A Memento for an Original Resource is a resource that
140 encapsulates a prior state of the Original Resource. A Memento
141 for an Original Resource as it existed at time T is a resource
142 that encapsulates the state the Original Resource had at time T.
144 o TimeGate: A TimeGate for an Original Resource is a resource that
145 is capable of datetime negotiation to support access to prior
146 states of the Original Resource.
148 o TimeMap: A TimeMap for an Original Resource is a resource from
149 which a list of URIs of Mementos of the Original Resource is
150 available.
152 1.2. Notational Conventions
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156 document are to be interpreted as described in [RFC2119].
158 When needed for extra clarity, the following conventions are used:
160 o URI-R is used to denote the URI of an Original Resource.
162 o URI-G is used to denote the URI of a TimeGate.
164 o URI-M is used to denote the URI of a Memento.
166 o URI-T is used to denote the URI of a TimeMap.
168 1.3. Purpose
170 The state of an Original Resource may change over time.
171 Dereferencing its URI at any specific moment yields a response that
172 reflects the resource's state at that moment: a representation of the
173 resource's state (e.g. "200 OK" HTTP status code), an indication of
174 its non-existence (e.g. "404 Not Found" HTTP status code), a relation
175 to another resource (e.g. "302 Found" HTTP status code), etc.
176 However, responses may also exist that reflect prior states of an
177 Original Resource: a representation of a prior state of the Original
178 Resource, an indication that the Original Resource did not exist at
179 some time in the past, a relation that the Original Resource had to
180 another resource at some time in the past, etc. Mementos that
181 provide such responses exist in web archives, content management
182 systems, or revision control systems, among others. For any given
183 Original Resource several Mementos may exist, each one reflecting a
184 frozen prior state of the Original Resource.
186 Examples are:
188 Mementos for Original Resource http://www.ietf.org/ :
190 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
191 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
192 www.ietf.org/
194 Mementos for Original Resource http://en.wikipedia.org/wiki/
195 Hypertext_Transfer_Protocol :
197 o http://en.wikipedia.org/w/
198 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
200 o http://en.wikipedia.org/w/
201 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
203 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
204 wiki/Hypertext_Transfer_Protocol
206 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
208 o http://www.w3.org/TR/2004/PR-webarch-20041105/
210 o http://www.w3.org/TR/2002/WD-webarch-20020830/
212 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
213 www.w3.org/TR/webarch/
215 In the abstract, the Memento framework introduces a mechanism to
216 access versions of web resources that:
218 o Is fully distributed in the sense that resource versions may
219 reside on multiple servers, and that any such server is likely
220 only aware of the versions it holds;
222 o Uses the global notion of datetime as a resource version indicator
223 and access key;
225 o Leverages the following primitives of [W3C.REC-aww-20041215]:
226 resource, resource state, representation, content negotiation, and
227 link.
229 The core components of Memento's mechanism to access resource
230 versions are:
232 1. The abstract notion of the state of an Original Resource (URI-R)
233 as it existed at datetime T. Note the relationship with the ability
234 to identify the state of a resource at datetime T by means of a URI
235 as intended by the proposed Dated URI scheme
236 [I-D.masinter-dated-uri].
238 2. A "bridge" from the present to the past, consisting of:
240 o The existence of a TimeGate (URI-G), which is aware of (at least
241 part of the) version history of the Original Resource (URI-R);
243 o The ability to negotiate in the datetime dimension with that
244 TimeGate (URI-G), as a means to access the state that the Original
245 Resource (URI-R) had at datetime T.
247 3. A "bridge" from the past to the present, consisting of an
248 appropriately typed link from a Memento (URI-M), which encapsulates
249 the state the Original Resource (URI-R) had at datetime T, to the
250 Original Resource (URI-R).
252 4. The existence of a TimeMap (URI-T) from which a list of all
253 Mementos that encapsulate a prior state of the Original Resource
254 (URI-R) can be obtained.
256 This document is concerned with specifying an instantiation of these
257 abstractions for resources that are identified by HTTP(S) URIs.
259 2. HTTP headers, Link Relation Types
261 The Memento framework is concerned with HEAD and GET interactions
262 with Original Resources, TimeGates, Mementos, and TimeMaps that are
263 identified by HTTP or HTTPS URIs. Details are only provided for
264 resources identified by HTTP URIs but apply similarly to those with
265 HTTPS URIs.
267 2.1. HTTP Headers
269 The Memento framework operates at the level of HTTP request and
270 response headers. It introduces two new headers ("Accept-Datetime",
271 "Memento-Datetime") and introduces new values for two existing
272 headers ("Vary", "Link"). Other HTTP headers are present or absent
273 in Memento response/request cycles as specified by [RFC2616].
275 2.1.1. Accept-Datetime, Memento-Datetime
277 The "Accept-Datetime" request header is trasnmitted by a user agent
278 to indicate it wants to access a past state of an Original Resource.
279 To that end, the "Accept-Datetime" header is conveyed in an HTTP
280 request issued against a TimeGate for an Original Resource, and its
281 value indicates the datetime of the desired past state of the
282 Original Resource.
284 Example of an "Accept-Datetime" request header:
286 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
463 Figure 2 provides a schematic overview of a successful request/
464 response chain that involves datetime negotiation. Dashed lines
465 depict HTTP transactions between user agent and server. The
466 interactions are for a scenario where the Original Resource resides
467 on one server, whereas both its TimeGate and Mementos reside on
468 another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also
469 exist in which all these resources are on the same server (for
470 example, content management systems) or all are on different servers
471 (for example, an aggregator of TimeGates).
473 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R
474 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
475 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G
476 4: UA <-- HTTP 302; Location: URI-M; Vary; Link:
477 URI-R,URI-T ------------------------------------------> URI-G
478 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M
479 6: UA <-- HTTP 200; Memento-Datetime: T; Link:
480 URI-R,URI-T,URI-G ------------------------------------- URI-M
482 Figure 2: A datetime negotiation request/response chain
484 o Step 1: The user agent that wants to access a prior state of the
485 Original Resource issues an HTTP HEAD/GET against URI-R that has
486 an "Accept-Datetime" HTTP header with a value of the datetime of
487 the desired state.
489 o Step 2: The response from URI-R includes an HTTP "Link" header
490 with a Relation Type of "timegate" pointing at a TimeGate (URI-G)
491 for the Original Resource.
493 o Step 3: The user agent starts the datetime negotiation process
494 with the TimeGate by issuing an HTTP GET request against URI-G
495 that has an "Accept-Datetime" HTTP header with a value of the
496 datetime of the desired prior state of the Original Resource.
498 o Step 4: The response from URI-G includes a "Location" header
499 pointing at a Memento (URI-M) for the Original Resource. In
500 addition, the response contains an HTTP "Link" header with a
501 Relation Type of "original" pointing at the Original Resource
502 (URI-R), and an HTTP "Link" header with a Relation Type of
503 "timemap" pointing at a TimeMap (URI-T).
505 o Step 5: The user agent issues an HTTP GET request against URI-M.
507 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP
508 header with a value of the archival datetime of the Memento. It
509 also contains an HTTP "Link" header with a Relation Type of
510 "original" pointing at the Original Resource (URI-R), with a
511 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the
512 Original Resource, and with a Relation Type of "timemap" pointing
513 at a TimeMap (URI-T) for the Original Resource. The state that is
514 expressed by the response is the state the Original Resource had
515 at the archival datetime expressed in the "Memento-Datetime"
516 header.
518 In order to respond to a datetime negotiation request, the server
519 uses an internal algorithm to select the Memento that best meets the
520 user agent's datetime preference. The exact nature of the selection
521 algorithm is at the server's discretion but is intented to be
522 consistent, for example, always selecting the Memento that is nearest
523 in time relative to the requested datetime, always selecting the
524 Memento that is nearest in the past relative to the requested
525 datetime, etc.
527 Due to the sparseness of Mementos in most systems, the value of the
528 "Memento-Datetime" header returned by a server may differ
529 (significantly) from the value conveyed by the user agent in "Accept-
530 Datetime".
532 Although a Memento encapsulates a prior state of an Original
533 Resource, the entity-body returned in response to an HTTP GET request
534 issued against a Memento may very well not be byte-to-byte the same
535 as an entity-body that was previously returned by that Original
536 Resource. Various reasons exist why there are significant chances
537 these would be different yet do convey substantially the same
538 information. These include format migrations as part of a digital
539 preservation strategy, URI-rewriting as applied by some web archives,
540 and the addition of banners as a means to brand web archives.
542 When negotiating in the datetime dimension, the regular content
543 negotiation dimensions (media type, character encoding, language, and
544 compression) remain available. It is the TimeGate server's
545 responsibility to honor (or not) such content negotiation, and in
546 doing so it MUST always first select a Memento that meets the user
547 agent's datetime preference, and then consider honoring regular
548 content negotiation for it. As a result of this approach, the
549 returned Memento will not necessarily meet the user agent's regular
550 content negotiation preferences. Therefore, it is RECOMMENDED that
551 the server provides "memento" links in the HTTP "Link" header
552 pointing at Mementos that do meet the user agent's regular content
553 negotiation requests and that have a value for the "Memento-Datetime"
554 header in the temporal vicinity of the user agent's preferred
555 datetime value.
557 A user agent that engages in datetime negotiation with a resource
558 typically starts by issuing an HTTP HEAD, not GET, request with an
559 "Accept-Datetime" header in order to determine how to proceed. This
560 strategy is related to the existence of various server implementation
561 patterns as will become clear in the below.
563 Details about the HTTP interactions involved in datetime negotation
564 are provided in Section 4.
566 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
1081 Figure 15: Response from URI-G<>URI-R for Pattern 2.2
1083 In a subsequent request, which is the same as Figure 11 but with HTTP
1084 GET instead of HEAD, the user agent can obtain the representation of
1085 the selected Memento. It will be provided as the entity-body of a
1086 response that has the same Memento headers as Figure 15.
1088 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct
1089 URI-M for Mementos
1091 In case the TimeGate uses a 200 negotiation style, but Mementos have
1092 no distinct URIs, the response to the user agent's request of Figure
1093 11 has a "200 OK" HTTP status code, and it does not contain a
1094 "Content-Location" nor "Location" header as there is no URI-M of the
1095 selected Memento to convey. The use of Memento response headers and
1096 links in the response from URI-G is as follows:
1098 o The "Vary" header MUST be provided and it MUST include the
1099 "accept-datetime" value.
1101 o The response MUST include a "Memento-Datetime" header. Its value
1102 expresses the archival datetime of the Memento.
1104 o The "Link" header MUST be provided and it MUST contain at least a
1105 link with the "original" Relation Type that has the URI-R of the
1106 Original Resource as Target IRI. The provision of other links is
1107 encouraged and is subject to the considerations described in
1108 Section 2.2.
1110 The server's response to the request of Figure 11 is shown in Figure
1111 16.
1113 HTTP/1.1 200 OK
1114 Date: Thu, 21 Jan 2010 00:09:40 GMT
1115 Server: Apache-Coyote/1.1
1116 Vary: accept-datetime
1117 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1118 Link: ; rel="original",
1119
1120 ; rel="timemap"; type="application/link-format",
1121
1122 ; rel="timegate"
1123 Content-Length: 23364
1124 Content-Type: text/html; charset=UTF-8
1125 Connection: close
1127 Figure 16: Response from URI-G<>URI-R for Pattern 2.3
1129 In a subsequent request, which is the same as Figure 11 but with HTTP
1130 GET instead of HEAD, the user agent can obtain the representation of
1131 the selected Memento. It will be provided as the entity-body of a
1132 response that has the same Memento headers as Figure 16.
1134 4.3. Pattern 3 - The Original Resource is a Fixed Resource
1136 This pattern does not involve datetime negotiation with a TimeGate
1137 but it can be implemented for Original Resources that never change
1138 state or do not change anymore past a certain point in their
1139 existence, meaning that URI-R and URI-M coincide either from the
1140 outset or starting at some point in time. This pattern is summarized
1141 in the below table. Examples are tweets or stable media resources on
1142 news sites.
1144 +-----------+--------------+------------+----------+----------------+
1145 | Pattern | Original | TimeGate | Memento | Negotiation |
1146 | | Resource | | | Style |
1147 +-----------+--------------+------------+----------+----------------+
1148 | Pattern 3 | URI-R | - | URI-R | - |
1149 +-----------+--------------+------------+----------+----------------+
1151 Table 3: Pattern 3
1153 Servers that host such resources can support the Memento framework by
1154 treating the stable resource (FixedResource as per
1155 [W3C.gen-ont-20090420]) as a Memento. The use of Memento response
1156 headers and links in responses from such a stable resource is as
1157 follows:
1159 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1160 be provided.
1162 o The response MUST include a "Memento-Datetime" header. Its value
1163 expresses the datetime at which the resource became stable.
1164 Providing this value includes a promise that the resource has not
1165 changed since this datetime and will not change anymore beyond it.
1167 o The "Link" header MUST be provided and MUST have a link with the
1168 "original" Relation Type that has the URI-R of the stable resource
1169 itself as Target IRI.
1171 Figure 17 shows a response to an HTTP HEAD request for the resource
1172 with URI-R http://a.example.org/ that has been stable since March
1173 20th 2009.
1175 HTTP/1.1 200 OK
1176 Date: Thu, 21 Jan 2010 00:09:40 GMT
1177 Server: Apache-Coyote/1.1
1178 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
1179 Link: ; rel="original"
1180 Content-Length: 0
1181 Content-Type: text/plain; charset=UTF-8
1182 Connection: close
1184 Figure 17: Response from URI-R=URI-M for Pattern 3
1186 4.4. Pattern 4 - Mementos without a TimeGate
1188 Cases may occur in which a server hosts Mementos but does not expose
1189 a TimeGate for them. This can, for example, be the case if the
1190 server's Mementos result from taking a snapshot of the state of a set
1191 of Original Resources from another server as it is being retired. As
1192 a result, only a single Memento per Original Resource is hosted,
1193 making the introduction of a TimeGate unnecessary. But it may also
1194 be the case for servers that host multiple Mementos for an Original
1195 Resource but consider exposing TimeGates too expensive. In this
1196 case, URI-R and URI-M are distinct, but a TimeGate is absent. This
1197 case is summarized in the below table.
1199 +-----------+--------------+------------+----------+----------------+
1200 | Pattern | Original | TimeGate | Memento | Negotiation |
1201 | | Resource | | | Style |
1202 +-----------+--------------+------------+----------+----------------+
1203 | Pattern 4 | URI-R | - | URI-M | - |
1204 +-----------+--------------+------------+----------+----------------+
1206 Table 4: Pattern 4
1208 Servers that host such Mementos without TimeGates can still support
1209 the Memento framework by providing the appropriate Memento headers
1210 and links. Their use is as follows for a response from URI-M:
1212 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1213 be provided.
1215 o The response MUST include a "Memento-Datetime" header. Its value
1216 expresses the archival datetime of the Memento.
1218 o The "Link" header MUST be provided and it MUST have a link with
1219 the "original" Relation Type that has the URI-R of the associated
1220 Original Resource as Target IRI. The provision of other links is
1221 encouraged and is subject to the considerations described in
1222 Section 2.2.
1224 Figure 18 shows a response to an HTTP HEAD request for the Memento
1225 with URI-M http://arxiv.example.net/web/20010911203610/http://
1226 a.example.org/. Note the use of links: three links have the URI-M of
1227 the Memento as Target IRI and have respective Relation Types
1228 "memento", "first", and "last". This combination indicates that this
1229 is the only Memento for the Original Resource with Target IRI
1230 provided by the "original" link (http://a.example.org/) that the
1231 server is aware of. Note also that such a response does not imply
1232 that there is no server whatsoever that exposes a TimeGate; it merely
1233 means that the responding server neither provides nor is aware of the
1234 location of a TimeGate.
1236 HTTP/1.1 200 OK
1237 Date: Thu, 21 Jan 2010 00:09:40 GMT
1238 Server: Apache-Coyote/1.1
1239 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1240 Link: ; rel="original",
1241
1242 ; rel="first last memento"
1243 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT"
1244 Content-Length: 0
1245 Content-Type: text/plain; charset=UTF-8
1246 Connection: close
1248 Figure 18: Response from URI-M<>URI-R for Pattern 4
1250 4.5. Special Cases
1252 4.5.1. Original Resource provides no "timegate" link
1254 Cases exist in which the response from the Original Resource does not
1255 contain a "timegate" link, including:
1257 o The Original Resource's server does not support the Memento
1258 framework;
1260 o The Original Resource no longer exists and the responding server
1261 is not aware of its prior existence;
1263 o The server that hosted the Original Resource no longer exists.
1265 In all these cases, the user agent should attempt to determine an
1266 appropriate TimeGate for the Original Resource, either automatically
1267 or interactively supported by the user.
1269 4.5.2. Server exists but Original Resource no longer does
1271 Cases exist in which the server knows that an Original Resource used
1272 to exist, but no longer provides a current representation. If there
1273 is a preferred TimeGate for such a discontinued Original Resource,
1274 then the server MUST include a "timegate" link in responses to
1275 requests for it. This may allow access to Mementos for the Original
1276 Resource even if it no longer exists. A server's response to a
1277 request for the discontinued resource http://a.example.org/pic is
1278 illustrated in Figure 19.
1280 HTTP/1.1 404 Not Found
1281 Date: Thu, 21 Jan 2010 00:02:12 GMT
1282 Server: Apache
1283 Link:
1284
1285 ; rel="timegate"
1286 Content-Length: 255
1287 Connection: close
1288 Content-Type: text/html; charset=iso-8909-1
1290 Figure 19: Response from an Original Resource that not longer exists
1292 4.5.3. Issues with Accept-Datetime
1294 The following special cases may occur regarding the "Accept-Datetime"
1295 header when a user agent issues a request against a TimeGate:
1297 o If the value of the "Accept-Datetime" is either earlier than the
1298 datetime of the first Memento or later than the datetime of the
1299 most recent Memento known to the TimeGate, the first or most
1300 recent Memento MUST be selected, respectively.
1302 o If the value of the "Accept-Datetime" does not conform to the
1303 rfc1123-date construction rule of the BNF in Figure 1, the
1304 response MUST have a "400 Bad Request" HTTP status code.
1306 o If a user agent issues a request against a TimeGate and fails to
1307 include an "Accept-Datetime" request header, the most recent
1308 Memento SHOULD be selected.
1310 In all cases, the use of headers and links in responses is as
1311 described for TimeGates in the respective scenarios.
1313 4.5.4. Memento of a 3XX response
1315 Cases exist in which HTTP responses with 3XX status codes are
1316 archived. For example, crawl-based web archives commonly archive
1317 responses with HTTP status codes "301 Moved Permanently" and "302
1318 Found" whereas Linked Data archives hold on to "303 See Other"
1319 responses.
1321 If the Memento requested by the user agent is an archived version of
1322 an HTTP response with a 3XX status code, the server's response MUST
1323 have the same 3XX HTTP status code. The use of other Memento headers
1324 is as described for Mementos in the respective scenarios.
1326 The user agent's handling of an HTTP response with a 3XX status code
1327 is not affected by the presence of a "Memento-Datetime" header. The
1328 user agent MUST behave in the same manner as it does with HTTP
1329 responses with a 3XX status code that do not have a "Memento-
1330 Datetime" header.
1332 However, the user agent MUST be aware that the URI that was selected
1333 from the "Location" header of an HTTP response with a 3XX status code
1334 might not be that of a Memento but rather of an Original Resource.
1335 In the latter case it SHOULD proceed by looking for a Memento of the
1336 selected Original Resource.
1338 For example, Figure 20 shows the response to an HTTP GET request for
1339 http://a.example.org issued on April 11 2008. This response is
1340 archived as a Memento of http://a.example.org that has as URI-M http:
1341 //arxiv.example.net/web/20080411000650/http://a.example.org. The
1342 response to an HTTP GET on this URI-M is shown in Figure 21. It is a
1343 replay of the original response with "Memento-Datetime" and "Link"
1344 headers added, to allow a user agent to understand the response is a
1345 Memento. In Figure 21, the value of the "Location" header is the
1346 same as in the original response; it identifies an Original Resource.
1347 The user agent proceeds with finding a Memento for this Original
1348 Resource. Web archives sometimes overwrite the value that was
1349 originally provided in the "Location" header in order to point at a
1350 Memento they hold of the resource to which the redirect originally
1351 led. This is shown in Figure 22. In this case, the user agent may
1352 decide it found an appropriate Memento.
1354 HTTP/1.1 301 Moved Permanently
1355 Date: Fri, 11 Apr 2008 00:06:50 GMT
1356 Server: Apache
1357 Location: http://b.example.org
1358 Content-Length: 0
1359 Content-Type: text/plain; charset=UTF-8
1360 Connection: close
1362 Figure 20: Response is a redirect
1364 HTTP/1.1 301 Moved Permanently
1365 Date: Thu, 21 Jan 2010 00:09:40 GMT
1366 Server: Apache-Coyote/1.1
1367 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1368 Location: http://b.example.org
1369 Link: ; rel="original",
1370
1371 ; rel="timemap"; type="application/link-format",
1372
1373 ; rel="timegate"
1374 Content-Length: 0
1375 Content-Type: text/plain; charset=UTF-8
1376 Connection: close
1378 Figure 21: Response is a Memento of a redirect; leads to an Original
1379 Resource
1381 HTTP/1.1 301 Moved Permanently
1382 Date: Thu, 21 Jan 2010 00:09:40 GMT
1383 Server: Apache-Coyote/1.1
1384 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1385 Location:
1386 http://arxiv.example.net/web/20080411000655/http://b.example.org
1387 Link: ; rel="original",
1388
1389 ; rel="timemap"; type="application/link-format",
1390
1391 ; rel="timegate"
1392 Content-Length: 0
1393 Content-Type: text/plain; charset=UTF-8
1394 Connection: close
1396 Figure 22: Response is a Memento of a redirect; leads to a Memento
1398 4.5.5. Memento of responses with 4XX or 5XX HTTP status codes
1400 Cases exist in which responses with 4XX and 5XX HTTP status codes are
1401 archived. If the Memento requested by the user agent is an archived
1402 version of such an HTTP response, the server's response MUST have the
1403 same 4XX or 5XX HTTP status code. The use of headers and links in
1404 responses is as described for Mementos in the respective scenarios.
1406 For example, Figure 23 shows the 404 response to an HTTP GET request
1407 for http://a.example.org issued on April 11 2008. This response is
1408 archived as a Memento of http://a.example.org, that has as URI-M
1409 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1410 The response to an HTTP HEAD on this URI-M is shown in Figure 24. It
1411 is a replay of the original response with "Memento-Datetime" and
1412 "Link" headers added, to allow a user agent to understand the
1413 response is a Memento.
1415 HTTP/1.1 404 Not Found
1416 Date: Fri, 11 Apr 2008 00:06:50 GMT
1417 Server: Apache
1418 Content-Length: 0
1419 Content-Type: text/plain; charset=UTF-8
1420 Connection: close
1422 Figure 23: Response is a 404
1424 HTTP/1.1 404 Not Found
1425 Date: Thu, 21 Jan 2010 00:09:40 GMT
1426 Server: Apache-Coyote/1.1
1427 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1428 Link: ; rel="original",
1429
1430 ; rel="timemap"; type="application/link-format",
1431
1432 ; rel="timegate"
1433 Content-Length: 0
1434 Content-Type: text/plain; charset=UTF-8
1435 Connection: close
1437 Figure 24: Response is a Memento of a 404
1439 4.5.6. Sticky "Memento-Datetime" and "original" link for Mementos
1441 A response to an HTTP HEAD/GET request issued against a Memento:
1443 o Includes a "Memento-Datetime" header that entails a promise that
1444 the response is archived, frozen in time. The value of the header
1445 expresses the archival datetime of the Memento.
1447 o Includes a link in the HTTP Link header with an "original"
1448 relation type that unambiguously points to the Original Resource
1449 associated with the Memento. The Target IRI of the link is the
1450 URI-R of that Original Resource.
1452 Both the "Memento-Datetime" header and the "original" link MUST be
1453 "sticky" in the following ways:
1455 o The server that originally assigns them MUST retain them in all
1456 responses to HTTP requests (with or without "Accept-Datetime"
1457 request header) that occur against the Memento after the time of
1458 their original assignment and the server MUST NOT change the value
1459 of the "Memento-Datetime" header nor the Target IRI of the
1460 "original" link.
1462 o Applications that mirror Mementos at a different URI MUST retain
1463 them and MUST NOT change them unless mirroring involves a
1464 meaningful state change. This allows, among others, duplicating a
1465 web archive at a new location while preserving the value of the
1466 "Memento-Datetime" header and the link with the "original"
1467 relation type for the archived resources. For example, when
1468 mirroring, the "Last-Modified" header will be updated to reflect
1469 the time of mirroring at the new URI, whereas the value for
1470 "Memento-Datetime" will be maintained.
1472 4.5.7. Intermediate Resources
1474 An intermediate resource is a resource that issues a redirect to a
1475 TimeGate, to a Memento, or to another intermediate resource, and thus
1476 plays an active role in the Memento infrastructure. Intermediate
1477 resources commonly exist in web archives on the path from a TimeGate
1478 to an appropriate Memento.
1480 A response of an intermediate resource has an HTTP status code
1481 indicative of HTTP redirection (e.g. 302) and uses Memento headers
1482 and links that allow to recognize that the resource plays a role in
1483 the Memento framework:
1485 o A "Vary" header that includes an "accept-datetime" value MUST NOT
1486 be provided.
1488 o The response MUST NOT include a "Memento-Datetime" header.
1490 o The "Link" header MUST be provided and it MUST have a link with
1491 the "original" Relation Type that has the URI-R of the associated
1492 Original Resource as Target IRI. Links with "timegate",
1493 "timemap", and "memento" Relation Types are OPTIONAL and, if
1494 provided, MUST pertain to the Original Resource for which the user
1495 agent is trying to obtain a Memento.
1497 A user agent MUST follow a redirection provided by an intermediate
1498 resource; multiple such redirections can be chained.
1500 Consider the case where a user agent follows the "timegate" link
1501 provided in Figure 10 and engages in datetime negotiation with the
1502 assumed TimeGate in the manner shown in Figure 11. But instead of
1503 receiving a response as shown in Figure 12, it receives the one shown
1504 below in Figure 25. Such a response is umabiguosuly recognizable as
1505 coming from an intermediate resource.
1507 HTTP/1.1 302 Found
1508 Date: Thu, 21 Jan 2010 00:06:50 GMT
1509 Server: Apache
1510 Location:
1511 http://arxiv.example.net/new-timegate/http://a.example.org/
1512 Link: ; rel="original"
1513 Content-Length: 0
1514 Content-Type: text/plain; charset=UTF-8
1515 Connection: close
1517 Figure 25: Redirecting Resource redirects to a TimeGate
1519 4.5.8. Resources excluded from datetime negotiation
1521 When delivering a Memento to a user agent, a web archive commonly
1522 enhances that Memento's archived content, for example, by including a
1523 banner that provides branding and highlights the archival status of
1524 the Memento. The resources that are involved in providing such
1525 system-specific functionality, many times Javascript or images, must
1526 be used in their current state.
1528 A server that generally supports datetime negotiation should make
1529 resources that need to be excluded from datetime negotiation
1530 recognizable. Doing so allows a user agent to refrain from
1531 attempting to access a Memento for them. In order to achieve this,
1532 the server SHOULD include a special-purpose link in the HTTP "Link"
1533 header when responding to a HTTP HEAD/GET request to a resource
1534 excluded from datetime negotiation. This link has "http://
1535 mementoweb.org/terms/donotnegotiate" as Target IRI and "type",
1536 defined in [RFC6903], as the value of the rel attribute. Other
1537 Memento headers as defined in Section 2.1. SHOULD NOT be provided.
1539 Figure 26 shows the response to a HTTP HEAD request from a resource
1540 excluded from datetime negotiation.
1542 HTTP/1.1 200 OK
1543 Date: Thu, 21 Jan 2010 00:09:40 GMT
1544 Server: Apache-Coyote/1.1
1545 Link: ; rel="type"
1546 Content-Length: 238
1547 Content-Type: application/javascript; charset=UTF-8
1548 Connection: close
1550 Figure 26: Response to a HTTP HEAD request from a resource excluded
1551 from datetime negotiation
1553 5. TimeMaps: Content and Serialization
1555 A TimeMap is introduced to support retrieving a comprehensive list of
1556 all Mementos for a specific Original Resource known to a server. The
1557 entity-body of a response to an HTTP GET request issued against a
1558 TimeMap's URI-T:
1560 o MUST list the URI-R of the Original Resource that the TimeMap is
1561 about;
1563 o MUST list the URI-M and archival datetime of each Memento for the
1564 Original Resource known to the server, preferably in a single
1565 document, or, alternatively in multiple documents that can be
1566 gathered by following contained links with a "timemap" Relation
1567 Type;
1569 o SHOULD list the URI-G of one or more TimeGates for the Original
1570 Resource known to the responding server;
1572 o SHOULD, for self-containment, list the URI-T of the TimeMap
1573 itself;
1575 o MUST unambiguously type listed resources as being Original
1576 Resource, TimeGate, Memento, or TimeMap.
1578 The entity-body of a response from a TimeMap MAY be serialized in
1579 various ways, but the link-value format serialization described here
1580 MUST be supported. In this serialization, the entity-body MUST be
1581 formatted in the same way as the value of an HTTP "Link" header, and
1582 hence MUST comply to the "link-value" construction rule of
1583 "Section 5. The Link Header Field" of [RFC5988], and the media type
1584 of the entity-body MUST be "application/link-format" as introduced in
1585 [RFC6690]. Links contained in the entity-body MUST be interpreted as
1586 follows:
1588 o The Context IRI is set to the anchor parameter, when specified;
1590 o The Context IRI of links with the "self" Relation Types is the
1591 URI-T of the TimeMap, i.e. the URI of the resource from which the
1592 TimeMap was requested;
1594 o The Context IRI of all other links is the URI-R of the Original
1595 Resource, which is provided as the Target IRI of the link with an
1596 "original" Relation Type.
1598 In order to retrieve the link-value serialization of a TimeMap, a
1599 user agent uses an "Accept" request header with a value set to
1600 "application/link-format". This is shown in Figure 27.
1602 GET /timemap/http://a.example.org/ HTTP/1.1
1603 Host: arxiv.example.net
1604 Accept: application/link-format;q=1.0
1605 Connection: close
1607 Figure 27: Request for a TimeMap
1609 If the TimeMap requested by the user agent exists, the server's
1610 response has a "200 OK" HTTP status code and the list of Mementos is
1611 provided in the entity-body of the response. Such a response is
1612 shown in Figure 28
1614 HTTP/1.1 200 OK
1615 Date: Thu, 21 Jan 2010 00:06:50 GMT
1616 Server: Apache
1617 Content-Length: 4883
1618 Content-Type: application/link-format
1619 Connection: close
1621 ;rel="original",
1622
1623 ; rel="self";type="application/link-format"
1624 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1625 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1626
1627 ; rel="timegate",
1628
1629 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
1630 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1631
1632 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
1633 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1634
1635 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
1636 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1637
1638 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
1639 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1640 ...
1642 Figure 28: Response from a TimeMap
1644 5.1. Special Cases
1646 5.1.1. Index and Paging TimeMaps
1648 Cases exist in which a TimeMap points at one or more other TimeMaps:
1650 o Index Timemap - A TimeMap can merely point at other TimeMaps and
1651 not list any Mementos itself. This can happen when Mementos are
1652 spread across several archives that share a front-end. An example
1653 is shown in Figure 29.
1655 o Paging Timemap - The number of available Mementos can require
1656 introducing multiple TimeMaps that can be paged. An example is
1657 shown in Figure 30. Note that a Paging TimeMap contains links to
1658 other TimeMaps but actually also lists Mementos.
1660 In both cases, including the "from" and "until" attributes for
1661 "timemap" links is RECOMMENDED as a means to express the temporal
1662 span of Mementos listed in each TimeMap. Note that TimeMaps obtained
1663 by following a "timemap" link can contain links to further TimeMaps.
1665 ;rel="original",
1666
1667 ; rel="timegate",
1668
1669 ; rel="self";type="application/link-format",
1670
1671 ; rel="timemap";type="application/link-format"
1672 ; from="Wed, 21 Jun 2000 04:41:56 GMT"
1673 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1674
1675 ; rel="timemap";type="application/link-format"
1676 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1677 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1678
1679 ; rel="timemap";type="application/link-format"
1680 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1682 Figure 29: Index TimeMap
1684 ;rel="original",
1685
1686 ; rel="timegate",
1687
1688 ; rel="self";type="application/link-format"
1689 ; from="Tue, 20 Jun 2000 18:02:59 GMT"
1690 ; until="Wed, 09 Apr 2008 20:30:51 GMT",
1691
1692 ; rel="timemap";type="application/link-format"
1693 ; from="Thu, 10 Apr 2008 20:30:51 GMT"
1694 ; until="Tue, 27 Oct 2009 20:49:54 GMT",
1695
1696 ; rel="timemap";type="application/link-format"
1697 ; from="Thu, 29 Oct 2009 20:30:51 GMT"
1698 ; until="Fri, 31 Aug 2012 12:22:34 GMT"
1699
1700 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1701
1702 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1703
1704 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1706 ...
1708 Figure 30: Paging TimeMap
1710 5.1.2. Mementos for TimeMaps
1712 A TimeMap can itself act as an Original Resource for which a TimeGate
1713 and Mementos may exist. Hence, the response from a TimeMap could
1714 include a "timegate" link to a TimeGate via which prior TimeMap
1715 versions are available. And, in cases where URI-T=URI-R=URI-G (a
1716 TimeMap is an Original Resource that acts as its own TimeGate), an
1717 "original" link pointing at the TimeMap URI-T would be included.
1719 Therefore, caution is required in cases where a TimeMap for an
1720 Original Resource wants to explicitly express in a Link header for
1721 which Original Resource it is a TimeMap. It can do so by including a
1722 "timemap" link that has the URI-R of the Original Resource as Context
1723 IRI and the URI-T of the TimeMap as Target IRI.
1725 Figure 31 shows the response to an HTTP HEAD request against a
1726 TimeMap that has http://arxiv.example.net/timemap/http://
1727 a.example.org as URI-T. This TimeMap provides information about
1728 Mementos for the Original Resource that has http://a.example.org as
1729 URI-R. The response includes an "original" link pointing to the
1730 Original Resource that this TimeMap is about. Note the use of the
1731 "anchor" attribute in this link to convey the URI-R of that Original
1732 Resource.
1734 HTTP/1.1 200 OK
1735 Date: Thu, 21 Jan 2010 00:06:50 GMT
1736 Server: Apache
1737 Link:
1738 ; anchor="http://a.example.org"; rel="timemap"
1739 ; type="application/link-format"
1740 Content-Length: 0
1741 Content-Type: application/link-format; charset=UTF-8
1742 Connection: close
1744 Figure 31: TimeMap links to the Original Resource it is about
1746 6. IANA Considerations
1748 6.1. HTTP Headers
1750 This memo requires IANA to register the Accept-Datetime and Memento-
1751 Datetime HTTP headers defined in Section 2.1.1 in the Permanent
1752 Message Header Field Names registry:
1754 o Header field name: Accept-Datetime
1756 o Applicable protocol: "http" (RFC 2616)
1758 o Status: Informational
1760 o Author/Change controller: Herbert Van de Sompel, Los Alamos
1761 National Laboratory, hvdsomp@gmail.com
1763 o Specification document(s): this document
1765 o Header field name: Memento-Datetime
1767 o Applicable protocol: "http" (RFC 2616)
1769 o Status: Informational
1771 o Author/Change controller: Herbert Van de Sompel, Los Alamos
1772 National Laboratory, hvdsomp@gmail.com
1774 o Specification document(s): this document
1776 6.2. Link Relation Types
1778 This memo requires IANA to register the Relation Types "original",
1779 "timegate", "timemap", and "memento" defined in Section 2.2 in the
1780 Link Relation Types registry.
1782 o Relation Name: original
1784 o Description: The Target IRI points to an Original Resource.
1786 o Reference: this document
1788 o Notes: An Original Resource is a resource that exists or used to
1789 exist, and for which access to one of its prior states may be
1790 required.
1792 o Relation Name: timegate
1794 o Description: The Target IRI points to a TimeGate for an Original
1795 Resource.
1797 o Reference: this document
1799 o Notes: A TimeGate for an Original Resource is a resource that is
1800 capable of datetime negotiation to support access to prior states
1801 of the Original Resource.
1803 o Relation Name: timemap
1805 o Description: The Target IRI points to a TimeMap for an Original
1806 Resource.
1808 o Reference: this document
1810 o Notes: A TimeMap for an Original Resource is a resource from which
1811 a list of URIs of Mementos of the Original Resource is available.
1813 o Relation Name: memento
1815 o Description: The Target IRI points to a Memento, a fixed resource
1816 that will not change state anymore.
1818 o Reference: this document
1820 o Notes: A Memento for an Original Resource is a resource that
1821 encapsulates a prior state of the Original Resource.
1823 7. Security Considerations
1825 Provision of a "timegate" HTTP "Link" header in responses to requests
1826 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1827 response codes) is OPTIONAL. The inclusion of this Link when
1828 requesting authentication is at the server's discretion; cases may
1829 exist in which a server protects the current state of a resource, but
1830 supports open access to prior states and thus chooses to supply a
1831 "timegate" HTTP "Link" header. Conversely, the server may choose to
1832 not advertise the TimeGate URIs (e.g., they exist in an intranet
1833 archive) for unauthenticated requests.
1835 The veracity of archives and the relationships between Original
1836 Resources and Mementos is beyond the scope of this document. Even in
1837 the absence of malice, it is possible for separate archives to have
1838 different Mementos for the same Original Resource at the same
1839 datetime if the state of the Original Resource was dependent on the
1840 requesting archive's user agent IP address, specific HTTP request
1841 headers, and possibly other factors.
1843 Further authentication, encryption and other security related issues
1844 are otherwise orthogonal to Memento.
1846 8. Changelog
1848 v11 2013-10-10 HVDS MLN RS draft-vandesompel-memento-11
1850 o Expressed the definitions of link relation types in IANA
1851 Considerations in terms of Target IRI.
1853 v10 2013-10-01 HVDS MLN RS draft-vandesompel-memento-10
1855 o Provided detailed information in the IANA Considerations section.
1857 v09 2013-09-09 HVDS MLN RS draft-vandesompel-memento-09
1859 o Added timemap link to the example for Pattern 1.2.
1861 o Clarified that both Memento-Datetime value and the "original" link
1862 must be sticky.
1864 v08 2013-07-08 HVDS MLN RS draft-vandesompel-memento-08
1866 o Added the Special Case where a server that generally supports
1867 datetime negotiation indicates that a given resource is not
1868 subject to datetime negotiation.
1870 v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07
1872 o Introduced "Overview" section to make the existence of two
1873 components (datetime negotiation and TimeMaps) more explicit.
1875 o Replaced the hard-to-interpret summary table detailing the use of
1876 headers (introduced in version 06 ) with an explicit version in
1877 the appendix.
1879 o Revised the abstract.
1881 o Added TimeMaps to the enumeration of core components in the
1882 Purpose section.
1884 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06
1886 o Major overhaul of the presentation of the specification.
1888 o Specification of patterns whereby URI-R=URI-G and with both 200
1889 and 302 negotation style.
1891 o Removal of Discovery section to increase focus on datetime
1892 negotation aspects.
1894 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05
1896 o Clarified the section on Memento Relation Types.
1898 o Re-introduced "license" attribute for "memento" Relation Type as
1899 it will become essential for IIPC.
1901 o Introduced from and until attributes for "timemap" links to
1902 accomodate paged TimeMap cases.
1904 o Introduced the notion of Redirecting Resource and inserted related
1905 information in various sections.
1907 o Added discovery of Mementos via host-meta.
1909 o Corrected ambiguous uses of the term "representation".
1911 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
1913 o Removed the possibility to use an interval indicator in an Accept-
1914 Datetime header as no one is implementing it.
1916 o Corrected typo in Other Relation Types table.
1918 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap
1919 paging.
1921 o Changed Discovery component from using robots.txt with Memento-
1922 specific add-ons to well-known URI and host-meta.
1924 o Removed "embargo" and "license" attributes for links with a
1925 "memento" Relation Type because no one is using them.
1927 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1929 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1930 5XX status code.
1932 o Clarified that a TimeGate must not use the "Memento-Datetime"
1933 header.
1935 o Added wording to warn for possible cache problems with Memento
1936 implementations that choose to have an Original Resource and and
1937 its TimeGate coincide.
1939 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1941 o Added scenario in which a TimeGate redirects to another TimeGate.
1943 o Reorganized TimeGate section to better reflect the difference
1944 between requests with and without interval indicator.
1946 o Added recommendation to provide "memento" links to Mementos in the
1947 vicinity of the preferred interval provided by the user agent, in
1948 case of a 406 response.
1950 o Removed TimeMap Feed material from the Discovery section as a
1951 result of discussions regarding (lack of) scalability of the
1952 approach with representatives of the International Internet
1953 Preservation Consortium. An alternative approach to support batch
1954 discovery of Mementos will be specified.
1956 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1958 o Introduced wording and reference to indicate a Memento is a
1959 FixedResource.
1961 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1962 about retaining "Memento-Datetime" headers and values when a
1963 Memento is mirrored at different URI.
1965 o Introduced section about handling both datetime and regular
1966 negotiation.
1968 o Introduced section about Mementos Without TimeGate.
1970 o Made various changes in the section Relation Type "memento",
1971 including addition of "license" and "embargo" attributes, and
1972 clarification of rules regarding the use of "memento" links.
1974 o Moved section about TimeMaps inside the Datetime Negotiation
1975 section, and updated it.
1977 o Restarted the Discovery section from scratch.
1979 v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel-
1980 memento-00
1982 v00 2010-10-19 HVDS MLN RS Limited circulation version
1984 2010-07-22 HVDS MLN First internal version
1986 9. Acknowledgements
1988 The Memento effort is funded by the Library of Congress. Many thanks
1989 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1990 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers,
1991 James Anderson, Tim Starling, Martin Klein, Mark Nottingham for
1992 feedback. Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla
1993 Balakireva, Frank McCown, Harihar Shankar, Brad Tofel, Andrew
1994 Jackson, Ahmed Alsum, Mat Kelly, Ilya Kreymer for implementations
1995 that informed the specification.
1997 10. References
1999 10.1. Normative References
2001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2002 Requirement Levels", BCP 14, RFC 2119, March 1997.
2004 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2005 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2006 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2008 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
2009 4151, October 2005.
2011 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
2012 Syndication Format", RFC 4287, December 2005.
2014 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
2015 Uniform Resource Identifiers (URIs)", RFC 5785, April
2016 2010.
2018 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
2019 for Simple Version Navigation between Web Resources", RFC
2020 5829, April 2010.
2022 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
2024 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC
2025 6415, October 2011.
2027 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
2028 Format", RFC 6690, August 2012.
2030 [RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903,
2031 March 2013.
2033 10.2. Informative References
2035 [Fitch] Fitch, ., "Web site archiving - an approach to recording
2036 every materially different response produced by a
2037 website", July 2003,
2038 .
2040 [I-D.masinter-dated-uri]
2041 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
2042 dated URIs", draft-masinter-dated-uri-10 (work in
2043 progress), January 2012.
2045 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2046 and Support", STD 3, RFC 1123, October 1989.
2048 [W3C.REC-aww-20041215]
2049 Jacobs, . and . Walsh, "Architecture of the World Wide
2050 Web", December 2004, .
2052 [W3C.gen-ont-20090420]
2053 Berners-Lee, ., "Architecture of the World Wide Web",
2054 April 2009, .
2056 Appendix A. Appendix: Use of Headers and Relation Types per Pattern
2058 +--------------------+--------------+----------+----------+---------+
2059 | Response Header | Pattern | Original | TimeGate | Memento |
2060 | | | Resource | | |
2061 +--------------------+--------------+----------+----------+---------+
2062 | Vary: accept- | Pattern 1.1 | 1 | 1 | 0 |
2063 | datetime | (Section | | | |
2064 | | 4.1.1) ; | | | |
2065 | | Pattern 1.2 | | | |
2066 | | (Section | | | |
2067 | | 4.1.2) | | | |
2068 | | Pattern 1.3 | 1 | 1 | 1 |
2069 | | (Section | | | |
2070 | | 4.1.3) | | | |
2071 | | Pattern 2.1 | 0 | 1 | 0 |
2072 | | (Section | | | |
2073 | | 4.2.1) ; | | | |
2074 | | Pattern 2.2 | | | |
2075 | | (Section | | | |
2076 | | 4.2.2) | | | |
2077 | | Pattern 2.3 | 0 | 1 | 1 |
2078 | | (Section | | | |
2079 | | 4.2.3) | | | |
2080 | | Pattern 3 | 1 | NA | 1 |
2081 | | (Section | | | |
2082 | | 4.3) | | | |
2083 | | Pattern 4 | 0 | NA | 1 |
2084 | | (Section | | | |
2085 | | 4.4) | | | |
2086 | Memento-Datetime | Pattern 1.1 | 0 | 0 | 1 |
2087 | | (Section | | | |
2088 | | 4.1.1) ; | | | |
2089 | | Pattern 1.2 | | | |
2090 | | (Section | | | |
2091 | | 4.1.1) | | | |
2092 | | Pattern 1.3 | 1 | 1 | 1 |
2093 | | (Section | | | |
2094 | | 4.1.3) | | | |
2095 | | Pattern 2.1 | 0 | 0 | 1 |
2096 | | (Section | | | |
2097 | | 4.2.1) ; | | | |
2098 | | Pattern 2.2 | | | |
2099 | | (Section | | | |
2100 | | 4.2.2) | | | |
2101 | | Pattern 2.3 | 0 | 1 | 1 |
2102 | | (Section | | | |
2103 | | 4.2.3) | | | |
2104 | | Pattern 3 | 1 | NA | 1 |
2105 | | (Section | | | |
2106 | | 4.3) | | | |
2107 | | Pattern 4 | 0 | NA | 1 |
2108 | | (Section | | | |
2109 | | 4.4) | | | |
2110 | Link | | | | |
2111 | rel="original" | Pattern 1.1 | 0 | 1 | 1 |
2112 | | (Section | | | |
2113 | | 4.1.1) ; | | | |
2114 | | Pattern 1.2 | | | |
2115 | | (Section | | | |
2116 | | 4.1.1) | | | |
2117 | | Pattern 1.3 | 1 | 1 | 1 |
2118 | | (Section | | | |
2119 | | 4.1.3) | | | |
2120 | | Pattern 2.1 | 0 | 1 | 1 |
2121 | | (Section | | | |
2122 | | 4.2.1) ; | | | |
2123 | | Pattern 2.2 | | | |
2124 | | (Section | | | |
2125 | | 4.2.2) | | | |
2126 | | Pattern 2.3 | 0 | 1 | 1 |
2127 | | (Section | | | |
2128 | | 4.2.3) | | | |
2129 | | Pattern 3 | 1 | NA | 1 |
2130 | | (Section | | | |
2131 | | 4.3) | | | |
2132 | | Pattern 4 | 0 | NA | 1 |
2133 | | (Section | | | |
2134 | | 4.4) | | | |
2135 | rel="timegate" | Pattern 1.1 | >=0 | >=0 | >=0 |
2136 | | (Section | | | |
2137 | | 4.1.1) ; | | | |
2138 | | Pattern 1.2 | | | |
2139 | | (Section | | | |
2140 | | 4.1.1) | | | |
2141 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2142 | | (Section | | | |
2143 | | 4.1.3) | | | |
2144 | | Pattern 2.1 | >=0 | 0 | >=0 |
2145 | | (Section | | | |
2146 | | 4.2.1) ; | | | |
2147 | | Pattern 2.2 | | | |
2148 | | (Section | | | |
2149 | | 4.2.2) | | | |
2150 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2151 | | (Section | | | |
2152 | | 4.2.3) | | | |
2153 | | Pattern 3 | NA | NA | NA |
2154 | | (Section | | | |
2155 | | 4.3) | | | |
2156 | | Pattern 4 | NA | NA | NA |
2157 | | (Section | | | |
2158 | | 4.4) | | | |
2159 | rel="timemap" | Pattern 1.1 | >=0 | >=0 | >=0 |
2160 | | (Section | | | |
2161 | | 4.1.1) ; | | | |
2162 | | Pattern 1.2 | | | |
2163 | | (Section | | | |
2164 | | 4.1.1) | | | |
2165 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2166 | | (Section | | | |
2167 | | 4.1.3) | | | |
2168 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2169 | | (Section | | | |
2170 | | 4.2.1) ; | | | |
2171 | | Pattern 2.2 | | | |
2172 | | (Section | | | |
2173 | | 4.2.2) | | | |
2174 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2175 | | (Section | | | |
2176 | | 4.2.3) | | | |
2177 | | Pattern 3 | >=0 | NA | >=0 |
2178 | | (Section | | | |
2179 | | 4.3) | | | |
2180 | | Pattern 4 | >=0 | NA | >=0 |
2181 | | (Section | | | |
2182 | | 4.4) | | | |
2183 | rel="memento" | Pattern 1.1 | >=0 | >=0 | >=0 |
2184 | | (Section | | | |
2185 | | 4.1.1) ; | | | |
2186 | | Pattern 1.2 | | | |
2187 | | (Section | | | |
2188 | | 4.1.1) | | | |
2189 | | Pattern 1.3 | >=0 | >=0 | >=0 |
2190 | | (Section | | | |
2191 | | 4.1.3) | | | |
2192 | | Pattern 2.1 | >=0 | >=0 | >=0 |
2193 | | (Section | | | |
2194 | | 4.2.1) ; | | | |
2195 | | Pattern 2.2 | | | |
2196 | | (Section | | | |
2197 | | 4.2.2) | | | |
2198 | | Pattern 2.3 | >=0 | >=0 | >=0 |
2199 | | (Section | | | |
2200 | | 4.2.3) | | | |
2201 | | Pattern 3 | >=0 | NA | >=0 |
2202 | | (Section | | | |
2203 | | 4.3) | | | |
2204 | | Pattern 4 | >=0 | NA | >=0 |
2205 | | (Section | | | |
2206 | | 4.4) | | | |
2207 +--------------------+--------------+----------+----------+---------+
2209 Table 5: Memento Headers
2211 Authors' Addresses
2213 Herbert Van de Sompel
2214 Los Alamos National Laboratory
2215 PO Box 1663
2216 Los Alamos, New Mexico 87545
2217 USA
2219 Phone: +1 505 667 1267
2220 Email: hvdsomp@gmail.com
2221 URI: http://public.lanl.gov/herbertv/
2222 Michael Nelson
2223 Old Dominion University
2224 Norfolk, Virginia 23529
2225 USA
2227 Phone: +1 757 683 6393
2228 Email: mln@cs.odu.edu
2229 URI: http://www.cs.odu.edu/~mln/
2231 Robert Sanderson
2232 Los Alamos National Laboratory
2233 PO Box 1663
2234 Los Alamos, New Mexico 87545
2235 USA
2237 Phone: +1 505 665 5804
2238 Email: azaroth42@gmail.com
2239 URI: http://public.lanl.gov/rsanderson/