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