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