idnits 2.17.1 draft-vandesompel-memento-08.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 (July 09, 2013) is 3944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4151' is defined on line 1917, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 1920, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 1923, but no explicit reference was found in the text == Unused Reference: 'RFC6415' is defined on line 1933, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. VandeSompel 3 Internet-Draft Los Alamos National Laboratory 4 Intended status: Informational M. Nelson 5 Expires: January 10, 2014 Old Dominion University 6 R. Sanderson 7 Los Alamos National Laboratory 8 July 09, 2013 10 HTTP framework for time-based access to resource states -- Memento 11 draft-vandesompel-memento-08 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 January 10, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 62 1.3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. HTTP headers, Link Relation Types . . . . . . . . . . . . . . 6 64 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 6 66 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.1.3. Link . . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.2. Link Relation Types . . . . . . . . . . . . . . . . . . . 8 69 2.2.1. Link Relation Type "original" . . . . . . . . . . . . 8 70 2.2.2. Link Relation Type "timegate" . . . . . . . . . . . . 8 71 2.2.3. Link Relation Type "timemap" . . . . . . . . . . . . 9 72 2.2.4. Link Relation Type "memento" . . . . . . . . . . . . 9 73 3. Overview of the Memento Framework . . . . . . . . . . . . . . 10 74 3.1. Datetime Negotiation . . . . . . . . . . . . . . . . . . 10 75 3.2. TimeMaps . . . . . . . . . . . . . . . . . . . . . . . . 13 76 4. Datetime Negotiation: HTTP Interactions . . . . . . . . . . . 14 77 4.1. Pattern 1 - The Original Resource acts as its own 78 TimeGate . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; 80 distinct URI-M for Mementos . . . . . . . . . . . . . 15 81 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; 82 distinct URI-M for Mementos . . . . . . . . . . . . . 17 83 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; 84 no distinct URI-M for Mementos . . . . . . . . . . . 18 85 4.2. Pattern 2 - A remote resource acts as a TimeGate for the 86 Original Resource . . . . . . . . . . . . . . . . . . . . 19 87 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; 88 distinct URI-M for Mementos . . . . . . . . . . . . . 21 89 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; 90 distinct URI-M for Mementos . . . . . . . . . . . . . 23 91 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; 92 no distinct URI-M for Mementos . . . . . . . . . . . 24 93 4.3. Pattern 3 - The Original Resource is a Fixed Resource . . 25 94 4.4. Pattern 4 - Mementos without a TimeGate . . . . . . . . . 26 95 4.5. Special Cases . . . . . . . . . . . . . . . . . . . . . . 27 96 4.5.1. Original Resource provides no "timegate" link . . . . 27 97 4.5.2. Server exists but Original Resource no longer does . 27 98 4.5.3. Issues with Accept-Datetime . . . . . . . . . . . . . 28 99 4.5.4. Memento of a 3XX response . . . . . . . . . . . . . . 28 100 4.5.5. Memento of responses with 4XX or 5XX HTTP status 101 codes . . . . . . . . . . . . . . . . . . . . . . . . 30 102 4.5.6. Sticky "Memento-Datetime" value for Mementos . . . . 31 103 4.5.7. Intermediate Resources . . . . . . . . . . . . . . . 31 104 4.5.8. Resources excluded from datetime negotiation . . . . 32 105 5. TimeMaps: Content and Serialization . . . . . . . . . . . . . 33 106 5.1. Special Cases . . . . . . . . . . . . . . . . . . . . . . 35 107 5.1.1. Index and Paging TimeMaps . . . . . . . . . . . . . . 35 108 5.1.2. Mementos for TimeMaps . . . . . . . . . . . . . . . . 36 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 111 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38 112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 115 10.2. Informative References . . . . . . . . . . . . . . . . . 42 116 Appendix A. Appendix: Use of Headers and Relation Types per 117 Pattern . . . . . . . . . . . . . . . . . . . . . . 42 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 120 1. Introduction 122 1.1. Terminology 124 This specification uses the terms "resource", "request", "response", 125 "entity-body", "content negotiation", "user agent", "server" as 126 described in [RFC2616], and it uses the terms "representation" and 127 "resource state" as described in [W3C.REC-aww-20041215]. 129 In addition, the following terms specific to the Memento framework 130 are introduced: 132 o Original Resource: An Original Resource is a resource that exists 133 or used to exist, and for which access to one of its prior states 134 may be required. 136 o Memento: A Memento for an Original Resource is a resource that 137 encapsulates a prior state of the Original Resource. A Memento 138 for an Original Resource as it existed at time T is a resource 139 that encapsulates the state the Original Resource had at time T. 141 o TimeGate: A TimeGate for an Original Resource is a resource that 142 is capable of datetime negotiation to support access to prior 143 states of the Original Resource. 145 o TimeMap: A TimeMap for an Original Resource is a resource from 146 which a list of URIs of Mementos of the Original Resource is 147 available. 149 1.2. Notational Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 When needed for extra clarity, the following conventions are used: 157 o URI-R is used to denote the URI of an Original Resource. 159 o URI-G is used to denote the URI of a TimeGate. 161 o URI-M is used to denote the URI of a Memento. 163 o URI-T is used to denote the URI of a TimeMap. 165 1.3. Purpose 167 The state of an Original Resource may change over time. 168 Dereferencing its URI at any specific moment yields a response that 169 reflects the resource's state at that moment: a representation of the 170 resource's state (e.g. "200 OK" HTTP status code), an indication of 171 its non-existence (e.g. "404 Not Found" HTTP status code), a relation 172 to another resource (e.g. "302 Found" HTTP status code), etc. 173 However, responses may also exist that reflect prior states of an 174 Original Resource: a representation of a prior state of the Original 175 Resource, an indication that the Original Resource did not exist at 176 some time in the past, a relation that the Original Resource had to 177 another resource at some time in the past, etc. Mementos that 178 provide such responses exist in web archives, content management 179 systems, or revision control systems, among others. For any given 180 Original Resource several Mementos may exist, each one reflecting a 181 frozen prior state of the Original Resource. 183 Examples are: 185 Mementos for Original Resource http://www.ietf.org/ : 187 o http://web.archive.org/web/19970107171109/http://www.ietf.org/ 189 o http://webarchive.nationalarchives.gov.uk/20080906200044/http:// 190 www.ietf.org/ 192 Mementos for Original Resource http://en.wikipedia.org/wiki/ 193 Hypertext_Transfer_Protocol : 195 o http://en.wikipedia.org/w/ 196 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574 198 o http://en.wikipedia.org/w/ 199 index.php?title=Hypertext_Transfer_Protocol&oldid=33912 201 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/ 202 wiki/Hypertext_Transfer_Protocol 204 Mementos for Original Resource http://www.w3.org/TR/webarch/ : 206 o http://www.w3.org/TR/2004/PR-webarch-20041105/ 208 o http://www.w3.org/TR/2002/WD-webarch-20020830/ 210 o http://webarchive.nationalarchives.gov.uk/20100304163140/http:// 211 www.w3.org/TR/webarch/ 213 In the abstract, the Memento framework introduces a mechanism to 214 access versions of web resources that: 216 o Is fully distributed in the sense that resource versions may 217 reside on multiple servers, and that any such server is likely 218 only aware of the versions it holds; 220 o Uses the global notion of datetime as a resource version indicator 221 and access key; 223 o Leverages the following primitives of [W3C.REC-aww-20041215]: 224 resource, resource state, representation, content negotiation, and 225 link. 227 The core components of Memento's mechanism to access resource 228 versions are: 230 1. The abstract notion of the state of an Original Resource (URI-R) 231 as it existed at datetime T. Note the relationship with the ability 232 to identify the state of a resource at datetime T by means of a URI 233 as intended by the proposed Dated URI scheme 234 [I-D.masinter-dated-uri]. 236 2. A "bridge" from the present to the past, consisting of: 238 o The existence of a TimeGate (URI-G), which is aware of (at least 239 part of the) version history of the Original Resource (URI-R); 241 o The ability to negotiate in the datetime dimension with that 242 TimeGate (URI-G), as a means to access the state that the Original 243 Resource (URI-R) had at datetime T. 245 3. A "bridge" from the past to the present, consisting of an 246 appropriately typed link from a Memento (URI-M), which encapsulates 247 the state the Original Resource (URI-R) had at datetime T, to the 248 Original Resource (URI-R). 250 4. The existence of a TimeMap (URI-T) from which a list of all 251 Mementos that encapsulate a prior state of the Original Resource 252 (URI-R) can be obtained. 254 This document is concerned with specifying an instantiation of these 255 abstractions for resources that are identified by HTTP(S) URIs. 257 2. HTTP headers, Link Relation Types 259 The Memento framework is concerned with HEAD and GET interactions 260 with Original Resources, TimeGates, Mementos, and TimeMaps that are 261 identified by HTTP or HTTPS URIs. Details are only provided for 262 resources identified by HTTP URIs but apply similarly to those with 263 HTTPS URIs. 265 2.1. HTTP Headers 267 The Memento framework operates at the level of HTTP request and 268 response headers. It introduces two new headers ("Accept-Datetime", 269 "Memento-Datetime") and introduces new values for two existing 270 headers ("Vary", "Link"). Other HTTP headers are present or absent 271 in Memento response/request cycles as specified by [RFC2616]. 273 2.1.1. Accept-Datetime, Memento-Datetime 275 The "Accept-Datetime" request header is trasnmitted by a user agent 276 to indicate it wants to access a past state of an Original Resource. 277 To that end, the "Accept-Datetime" header is conveyed in an HTTP 278 request issued against a TimeGate for an Original Resource, and its 279 value indicates the datetime of the desired past state of the 280 Original Resource. 282 Example of an "Accept-Datetime" request header: 284 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 286 The "Memento-Datetime" response header is used by a server to 287 indicate that a response reflects a prior state of an Original 288 Resource. Its value expresses the datetime of that state. The URI 289 of the Original Resource for which the response reflects a prior 290 state is provided as the Target IRI of a link provided in the HTTP 291 "Link" header that has a Relation Type of "original" (see 292 Section 2.2). 294 The presence of a "Memento-Datetime" header and associated value for 295 a given response constitutes a promise that the resource state 296 reflected in the response will no longer change (see Section 4.5.6). 298 Example of a "Memento-Datetime" response header: 300 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT 302 Values for the "Accept-Datetime" and "Memento-Datetime" headers 303 consist of a MANDATORY datetime expressed according to the [RFC1123] 304 format, which is formalized by the rfc1123-date construction rule of 305 the BNF in Figure 1. The datetime is case-sensitive with names for 306 days and months exactly as shown in the wkday and month construction 307 rules of the BNF, respectively. The datetime MUST be represented in 308 Greenwich Mean Time (GMT). 310 accept-dt-value = rfc1123-date 311 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 312 date1 = 2DIGIT SP month SP 4DIGIT 313 ; day month year (e.g., 20 Mar 1957) 314 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 315 ; 00:00:00 - 23:59:59 (e.g., 14:33:22) 316 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | 317 "Sun" 318 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | 319 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 321 Figure 1: BNF for the datetime format 323 2.1.2. Vary 325 Generally, the "Vary" header is used in HTTP responses to indicate 326 the dimensions in which content negotiation is possible. In the 327 Memento framework, a TimeGate uses the "Vary" header with a value 328 that includes "accept-datetime" to convey that datetime negotation is 329 possible. 331 For example, this use of the "Vary" header indicates that datetime is 332 the only dimension in which negotiation is possible: 334 Vary: accept-datetime 336 The use of the "Vary" header in this example shows that both datetime 337 negotiation, and media type content negotiation are possible: 339 Vary: accept-datetime, accept 341 2.1.3. Link 343 The Memento framework defines the "original", "timegate", "timemap", 344 and "memento" Relation Types to convey typed links among Original 345 Resources, TimeGates, Mementos, and TimeMaps. The are defined in 346 Section 2.2, below. In addition, existing Relation Types may be 347 used, for example, to support navigating among Mementos. Examples 348 are "first", "last", "prev", "next", "predecessor-version", 349 "successor-version" as detailed in [RFC5988] and [RFC5829]. 351 2.2. Link Relation Types 353 This section introduces the Relation Types used in the Memento 354 framework. They are defined in a general way and their use in HTTP 355 "Link" Headers [RFC5988] is described in detail. The use of these 356 Relation Types in TimeMaps is described in Section 5. 358 2.2.1. Link Relation Type "original" 360 "original" -- A link with an "original" Relation Type is used to 361 point from a TimeGate or a Memento to its associated Original 362 Resource. 364 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests 365 issued against a TimeGate or a Memento MUST include exactly one link 366 with an "original" Relation Type in their HTTP "Link" header. 368 2.2.2. Link Relation Type "timegate" 370 "timegate" -- A link with a "timegate" Relation Type is used to point 371 from the Original Resource, as well as from a Memento associated with 372 the Original Resource, to a TimeGate for the Original Resource. 374 Use in HTTP "Link" headers: If there is a TimeGate associated with an 375 Original Resource or Memento that is preferred for use, then 376 responses to HTTP HEAD/GET requests issued against these latter 377 resources MUST include a link with a "timegate" Relation Type in 378 their HTTP "Link" header. Since multiple TimeGates can exist for any 379 Original Resource, multiple "timegate" links MAY occur, each with a 380 distinct Target IRI. 382 2.2.3. Link Relation Type "timemap" 384 "timemap" -- A link with a "timemap" Relation Type is used to point 385 from a TimeGate or a Memento associated with an Original Resource, as 386 well as from the Original Resource itself, to a TimeMap for the 387 Original Resource. 389 Attributes: A link with a "timemap" Relation Type SHOULD use the 390 "type" attribute to convey the mime type of the TimeMap 391 serialization. The "from" and "until" attributes may be used to 392 express the start and end of the temporal interval covered by 393 Mementos listed in the TimeMap. That is, the linked TimeMap will not 394 contain Mementos with archival datetimes outside of the expressed 395 temporal interval. Attempts SHOULD be made to convey this interval 396 as accurately as possible. The value for the these attributes MUST 397 be a datetime expressed according to the rfc1123-date construction 398 rule of the BNF in Figure 1 and it MUST be represented in Greenwich 399 Mean Time (GMT). 401 Use in HTTP "Link" headers: If there is a TimeMap associated with an 402 Original Resource, a TimeGate or a Memento that is preferred for use, 403 then responses to HTTP HEAD/GET requests issued against these latter 404 resources MUST include a link with a "timemap" Relation Type in their 405 HTTP "Link" header. Multiple such links, each with a distinct Target 406 IRI, MAY be expressed as a means to point to different TimeMaps or to 407 different serializations of the same TimeMap. In all cases, use of 408 the "from" and "until" attributes is OPTIONAL. 410 2.2.4. Link Relation Type "memento" 412 "memento" -- A link with a "memento" Relation Type is used to point 413 from a TimeGate or a Memento for an Original Resource, as well as 414 from the Original Resource itself, to a Memento for the Original 415 Resource. 417 Attributes: A link with a "memento" Relation Type MUST include a 418 "datetime" attribute with a value that matches the "Memento-Datetime" 419 of the Memento that is the target of the link; that is, the value of 420 the "Memento-Datetime" header that is returned when the URI of the 421 linked Memento is dereferenced. The value for the "datetime" 422 attribute MUST be a datetime expressed according to the rfc1123-date 423 construction rule of the BNF in Figure 1 and it MUST be represented 424 in Greenwich Mean Time (GMT). This link MAY include a "license" 425 attribute to associate a license with the Memento; the value for the 426 "license" attribute MUST be a URI. 428 Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests 429 issued against an Original Resource, a TimeGate and a Memento MAY 430 include links in their HTTP "Link" headers with a "memento" Relation 431 Type. For responses in which a Memento is selected, the provision of 432 navigational links that lead to Mementos other than the selected one 433 can be beneficial to the user agent. Of special importance are links 434 that lead to the temporally first and last Memento known to the 435 responding server, as well as links leading to Mementos that are 436 temporally adjacent to the selected one. 438 3. Overview of the Memento Framework 440 The Memento framework defines two complementary approaches to support 441 obtaining representations of prior states of an Original Resource: 443 o Datetime Negotiation: Datetime negotiation is a variation on 444 content negotiation by which a user agent expresses a datetime 445 preference pertaining to the representation of an Original 446 Resource, instead of, for example, a media type preference. Based 447 on the responding server's knowledge of the past of the Original 448 Resource, it selects a Memento of the Original Resource that best 449 meets the user agent's datetime preference. An overview is 450 provided in Section 3.1; details are in Section 4. 452 o TimeMaps: A TimeMap is a resource from which a list can be 453 obtained that provides a comprehensive overview of the past of an 454 Original Resource. A server makes a TimeMap available that 455 enumerates all Mementos that the server is aware of, along with 456 their archival datetime. A user agent can obtain the TimeMap and 457 select Mementos from it. An overview is provided in Section 3.2; 458 details are in Section 5. 460 3.1. Datetime Negotiation 461 Figure 2 provides a schematic overview of a successful request/ 462 response chain that involves datetime negotiation. Dashed lines 463 depict HTTP transactions between user agent and server. The 464 interactions are for a scenario where the Original Resource resides 465 on one server, whereas both its TimeGate and Mementos reside on 466 another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also 467 exist in which all these resources are on the same server (for 468 example, content management systems) or all are on different servers 469 (for example, an aggregator of TimeGates). 471 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R 472 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R 473 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G 474 4: UA <-- HTTP 302; Location: URI-M; Vary; Link: 475 URI-R,URI-T ------------------------------------------> URI-G 476 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M 477 6: UA <-- HTTP 200; Memento-Datetime: T; Link: 478 URI-R,URI-T,URI-G ------------------------------------- URI-M 480 Figure 2: A datetime negotiation request/response chain 482 o Step 1: The user agent that wants to access a prior state of the 483 Original Resource issues an HTTP HEAD/GET against URI-R that has 484 an "Accept-Datetime" HTTP header with a value of the datetime of 485 the desired state. 487 o Step 2: The response from URI-R includes an HTTP "Link" header 488 with a Relation Type of "timegate" pointing at a TimeGate (URI-G) 489 for the Original Resource. 491 o Step 3: The user agent starts the datetime negotiation process 492 with the TimeGate by issuing an HTTP GET request against URI-G 493 that has an "Accept-Datetime" HTTP header with a value of the 494 datetime of the desired prior state of the Original Resource. 496 o Step 4: The response from URI-G includes a "Location" header 497 pointing at a Memento (URI-M) for the Original Resource. In 498 addition, the response contains an HTTP "Link" header with a 499 Relation Type of "original" pointing at the Original Resource 500 (URI-R), and an HTTP "Link" header with a Relation Type of 501 "timemap" pointing at a TimeMap (URI-T). 503 o Step 5: The user agent issues an HTTP GET request against URI-M. 505 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP 506 header with a value of the archival datetime of the Memento. It 507 also contains an HTTP "Link" header with a Relation Type of 508 "original" pointing at the Original Resource (URI-R), with a 509 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the 510 Original Resource, and with a Relation Type of "timemap" pointing 511 at a TimeMap (URI-T) for the Original Resource. The state that is 512 expressed by the response is the state the Original Resource had 513 at the archival datetime expressed in the "Memento-Datetime" 514 header. 516 In order to respond to a datetime negotiation request, the server 517 uses an internal algorithm to select the Memento that best meets the 518 user agent's datetime preference. The exact nature of the selection 519 algorithm is at the server's discretion but is intented to be 520 consistent, for example, always selecting the Memento that is nearest 521 in time relative to the requested datetime, always selecting the 522 Memento that is nearest in the past relative to the requested 523 datetime, etc. 525 Due to the sparseness of Mementos in most systems, the value of the 526 "Memento-Datetime" header returned by a server may differ 527 (significantly) from the value conveyed by the user agent in "Accept- 528 Datetime". 530 Although a Memento encapsulates a prior state of an Original 531 Resource, the entity-body returned in response to an HTTP GET request 532 issued against a Memento may very well not be byte-to-byte the same 533 as an entity-body that was previously returned by that Original 534 Resource. Various reasons exist why there are significant chances 535 these would be different yet do convey substantially the same 536 information. These include format migrations as part of a digital 537 preservation strategy, URI-rewriting as applied by some web archives, 538 and the addition of banners as a means to brand web archives. 540 When negotiating in the datetime dimension, the regular content 541 negotiation dimensions (media type, character encoding, language, and 542 compression) remain available. It is the TimeGate server's 543 responsibility to honor (or not) such content negotiation, and in 544 doing so it MUST always first select a Memento that meets the user 545 agent's datetime preference, and then consider honoring regular 546 content negotiation for it. As a result of this approach, the 547 returned Memento will not necessarily meet the user agent's regular 548 content negotiation preferences. Therefore, it is RECOMMENDED that 549 the server provides "memento" links in the HTTP "Link" header 550 pointing at Mementos that do meet the user agent's regular content 551 negotiation requests and that have a value for the "Memento-Datetime" 552 header in the temporal vicinity of the user agent's preferred 553 datetime value. 555 A user agent that engages in datetime negotiation with a resource 556 typically starts by issuing an HTTP HEAD, not GET, request with an 557 "Accept-Datetime" header in order to determine how to proceed. This 558 strategy is related to the existence of various server implementation 559 patterns as will become clear in the below. 561 Details about the HTTP interactions involved in datetime negotation 562 are provided in Section 4. 564 3.2. TimeMaps 566 Figure 3 provides a schematic overview of a successful request/ 567 response chain that shows a user agent obtaining a TimeMap. The 568 pictoral conventions are the same as the ones used in Figure 2, as is 569 the scenario. Note that, in addition to a TimeGate, an Original 570 Resource and a Memento can also provide a link to a TimeMap. 572 1: UA --- HTTP HEAD/GET ------------------------------------> URI-R 573 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R 574 3: UA --- HTTP HEAD/GET ------------------------------------> URI-G 575 4: UA <-- HTTP 302; Location: URI-M; Vary; Link: 576 URI-R,URI-T ------------------------------------------> URI-G 577 5: UA --- HTTP GET URI-T -----------------------------------> URI-T 578 6: UA <-- HTTP 200 ------------------------------------------ URI-T 580 Figure 3: A request/response chain to obtain a TimeMap 582 o Step 1: The user agent that wants to access a TimeMap for the 583 Original Resource issues an HTTP HEAD/GET against URI-R. This can 584 be done with or without an "Accept-Datetime" HTTP header. 586 o Step 2: Irrespective of the use of an "Accept-Datetime" HTTP 587 header in Step 1, the response from URI-R includes an HTTP "Link" 588 header with a Relation Type of "timegate" pointing at a TimeGate 589 (URI-G) for the Original Resource. 591 o Step 3: The user agent issues an HTTP GET request against URI-G. 592 This can be done with or without an "Accept-Datetime" HTTP header. 594 o Step 4: Irrespective of the use of an "Accept-Datetime" HTTP 595 header in Step 1, the response contains an HTTP "Link" header with 596 a Relation Type of "timemap" pointing at a TimeMap (URI-T). 598 o Step 5: The user agent issues an HTTP GET request against URI-T. 600 o Step 6: The response from URI-T has an entity-body that lists all 601 Mementos for the Original Resource known to the responding server, 602 as well as their archival datetimes. 604 Details about the content and serialization of TimeMaps are provided 605 in Section 5. 607 4. Datetime Negotiation: HTTP Interactions 609 Figure 2 depicts a specific pattern to implement the Memento 610 framework. Multiple patterns exist and they can be grouped as 611 follows: 613 o Pattern 1 (Section 4.1) - The Original Resource acts as its own 614 TimeGate 616 o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for 617 the Original Resource 619 o Pattern 3 (Section 4.3) - The Original Resource is a Fixed 620 Resource 622 o Pattern 4 (Section 4.4) - Mementos without a TimeGate 624 Details of the HTTP interactions for common cases for each of those 625 patterns are provided in Section 4.1 through Section 4.4. Appendix A 626 summarizes the use of the "Vary", "Memento-Datetime", and "Link" 627 headers in responses from Original Resources, TimeGates, and Mementos 628 for the various patterns. Special cases are described in 629 Section 4.5. Note that in the following sections, the HTTP status 630 code of the responses with an entity-body is shown as "200 OK", but a 631 series of "206 Partial Content" responses could be substituted. 633 Figure 4 shows a user agent that attemtps to datetime negotiate with 634 the Original Resource http://a.example.org/ by including an "Accept- 635 Datetime" header in its HTTP HEAD request. This initiating request 636 is the same for Pattern 1 (Section 4.1) through Pattern 3 637 (Section 4.3). 639 HEAD / HTTP/1.1 640 Host: a.example.org 641 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 642 Connection: close 644 Figure 4: User Agent Attempts Datetime Negotiation With Original 645 Resource 647 4.1. Pattern 1 - The Original Resource acts as its own TimeGate 649 In this implementation pattern, the Original Resource acts as its own 650 TimeGate, which means that URI-R and URI-G coincide. Content 651 management systems and revision control systems can support datetime 652 negotiation in this way as they are commonly aware of the version 653 history of their own resources. 655 The response to this request when datetime negotiation for this 656 resource is supported depends on the negotiation style it uses 657 (200-style or 302-style) and on the existence or absence of a URI-M 658 for Mementos that is distinct from the URI-R of the associated 659 Original Resource. The various cases are summarized in the below 660 table and the server responses for each are detailed in the remainder 661 of this section. 663 +--------------+------------+------------+----------+---------------+ 664 | Pattern | Original | TimeGate | Memento | Negotiation | 665 | | Resource | | | Style | 666 +--------------+------------+------------+----------+---------------+ 667 | Pattern 1.1 | URI-R | URI-R | URI-M | 302 | 668 | (Section | | | | | 669 | 4.1.1) | | | | | 670 | Pattern 1.2 | URI-R | URI-R | URI-M | 200 | 671 | (Section | | | | | 672 | 4.1.2) | | | | | 673 | Pattern 1.3 | URI-R | URI-R | URI-R | 200 | 674 | (Section | | | | | 675 | 4.1.3) | | | | | 676 +--------------+------------+------------+----------+---------------+ 678 Table 1: Pattern 1 680 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; distinct 681 URI-M for Mementos 683 In this case, the response to the user agent's request of Figure 4 684 has a "302 Found" HTTP status code, and the "Location" header conveys 685 the URI-M of the selected Memento. The use of Memento response 686 headers and links in the response from URI-R=URI-G is as follows: 688 o The "Vary" header MUST be provided and it MUST include the 689 "accept-datetime" value. 691 o The response MUST NOT contain a "Memento-Datetime" header. 693 o The "Link" header MUST be provided and it MUST contain at least a 694 link with the "original" Relation Type that has the URI-R of the 695 Original Resource as Target IRI. The provision of other links is 696 encouraged and is subject to the considerations described in 697 Section 2.2. 699 The server's response to the request of Figure 4 is shown in Figure 700 5. Note the inclusion of the recommended link to the TimeGate that, 701 in this case, has a Target IRI that is the URI-R of the Original 702 Resource. 704 HTTP/1.1 302 Found 705 Date: Thu, 21 Jan 2010 00:06:50 GMT 706 Server: Apache 707 Vary: accept-datetime 708 Location: 709 http://a.example.org/?version=20010911203610 710 Link: ; rel="original timegate" 711 Content-Length: 0 712 Content-Type: text/plain; charset=UTF-8 713 Connection: close 715 Figure 5: Response from URI-R=URI-G for Pattern 1.1 717 In a subsequent request, shown in Figure 6, the user agent can obtain 718 the selected Memento by issuing an HTTP GET request against the URI-M 719 that was provided in the "Location" header. The inclusion of the 720 "Accept-Datetime" header in this request is not needed but will 721 typically occur as the user agent is in datetime negotiation mode. 723 GET /?version=20010911203610 HTTP/1.1 724 Host: a.example.org 725 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 726 Connection: close 728 Figure 6: User Agent Requests Selected Memento 730 The response has a "200 OK" HTTP status code and the entity-body of 731 the response contains the representation of the selected Memento. 732 The use of Memento response headers and links in the response from 733 URI-M is as follows: 735 o A "Vary" header that includes an "accept-datetime" value MUST NOT 736 be provided. 738 o The response MUST include a "Memento-Datetime" header. Its value 739 expresses the archival datetime of the Memento. 741 o The "Link" header MUST be provided and it MUST contain at least a 742 link with the "original" Relation Type that has the URI-R of the 743 Original Resource as Target IRI. The provision of other links is 744 encouraged and is subject to the considerations described in 745 Section 2.2. 747 The server's response to the request of Figure 6 is shown in Figure 748 7. Note the provision of the required "original", and the 749 recommended "timegate" and "timemap" links. The former two point to 750 the Original Resource, which acts as its own TimeGate. The latter 751 has "from" and "until" attributes to indicate the temporal interval 752 covered by Mementos listed in the linked TimeMap. 754 HTTP/1.1 200 OK 755 Date: Thu, 21 Jan 2010 00:06:51 GMT 756 Server: Apache-Coyote/1.1 757 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 758 Link: ; rel="original timegate", 759 760 ; rel="timemap"; type="application/link-format" 761 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 762 ; until="Wed, 20 Jan 2010 09:34:33 GMT" 763 Content-Length: 23364 764 Content-Type: text/html;charset=utf-8 765 Connection: close 767 Figure 7: Response from URI-M for Pattern 1.1 769 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; distinct 770 URI-M for Mementos 772 In this case, the response to the user agent's request of Figure 4 773 has a "200 OK" HTTP status code, and the "Content-Location" header 774 conveys the URI-M of the selected Memento. The use of Memento 775 response headers and links in the response from URI-R=URI-G is as 776 follows: 778 o The "Vary" header MUST be provided and it MUST include the 779 "accept-datetime" value. 781 o The response MUST include a "Memento-Datetime" header. Its value 782 expresses the archival datetime of the selected Memento. 784 o The "Link" header MUST be provided and it MUST contain at least a 785 link with the "original" Relation Type that has the URI-R of the 786 Original Resource as Target IRI. The provision of other links is 787 encouraged and is subject to the considerations described in 788 Section 2.2. 790 The server's response to the request of Figure 4 is shown in Figure 791 8. Note the provision of optional "memento" links pointing at the 792 oldest and most recent Memento for the Original Resource known to the 793 responding server. 795 HTTP/1.1 200 OK 796 Date: Thu, 21 Jan 2010 00:06:50 GMT 797 Server: Apache 798 Vary: accept-datetime 799 Content-Location: 800 http://a.example.org/?version=20010911203610 801 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 802 Link: ; rel="original timegate", 803 804 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 805 806 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT" 807 Content-Length: 2312 808 Content-Type: text/html; charset=UTF-8 809 Connection: close 811 Figure 8: Response from URI-R=URI-G for Pattern 1.2 813 In a subsequent request, which is the same as Figure 4 but with HTTP 814 GET instead of HEAD, the user agent can obtain the representation of 815 the selected Memento. It will be provided as the entity-body of a 816 response that has the same Memento headers as in Figure 8. 818 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; no distinct 819 URI-M for Mementos 821 In this case, the response to the user agent's request of Figure 4 822 has a "200 OK" HTTP status code, and it does not contain a "Content- 823 Location" nor "Location" header as there is no URI-M of the selected 824 Memento to convey. The use of Memento response headers and links in 825 the response from URI-R=URI-G is as follows: 827 o The "Vary" header MUST be provided and it MUST include the 828 "accept-datetime" value. 830 o The response MUST include a "Memento-Datetime" header. Its value 831 expresses the archival datetime of the selected Memento. 833 o The "Link" header MUST be provided and it MUST contain at least a 834 link with the "original" Relation Type that has the URI-R of the 835 Original Resource as Target IRI. The provision of other links is 836 encouraged and is subject to the considerations described in 837 Section 2.2. 839 The server's response to the request of Figure 4 is shown in Figure 840 9. The recommended "timemap" and "timegate" links are included in 841 addition to the mandatory "original" link. 843 HTTP/1.1 200 OK 844 Date: Thu, 21 Jan 2010 00:06:50 GMT 845 Server: Apache 846 Vary: accept-datetime 847 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 848 Link: ; rel="original timegate", 849 850 ; rel="timemap"; type="application/link-format" 851 Content-Length: 0 852 Content-Type: text/plain; charset=UTF-8 853 Connection: close 855 Figure 9: Response from URI-R=URI-G for Pattern 1.3 857 In a subsequent request, which is the same as Figure 4 but with HTTP 858 GET instead of HEAD, the user agent can obtain the representation of 859 the selected Memento. It will be provided as the entity-body of a 860 response that has the same Memento headers as in Figure 9. 862 4.2. Pattern 2 - A remote resource acts as a TimeGate for the Original 863 Resource 865 In this implementation pattern, the Original Resource does not act as 866 its own TimeGate, which means that URI-R and URI-G are different. 867 This pattern is typically implemented by servers for which the 868 history of their resources is recorded in remote systems such as web 869 archives and transactional archives [Fitch]. But servers that 870 maintain their own history, such as content management systems and 871 Version Control Systems, may also implement this pattern, for 872 example, to distribute the load involved in responding to requests 873 for current and prior representations of resources between different 874 servers. 876 This pattern is summarized in the below table and is detailed in the 877 remainder of this section. Three cases exist that differ regarding 878 the negotiation style that is used by the remote TimeGate and 879 regarding the existence of a URI-M for Mementos that is distinct from 880 the URI-G of the TimeGate. 882 +--------------+------------+------------+----------+---------------+ 883 | Pattern | Original | TimeGate | Memento | Negotiation | 884 | | Resource | | | Style | 885 +--------------+------------+------------+----------+---------------+ 886 | Pattern 2.1 | URI-R | URI-G | URI-M | 302 | 887 | (Section | | | | | 888 | 4.2.1) | | | | | 889 | Pattern 2.2 | URI-R | URI-G | URI-M | 200 | 890 | (Section | | | | | 891 | 4.2.2) | | | | | 892 | Pattern 2.3 | URI-R | URI-G | URI-G | 200 | 893 | (Section | | | | | 894 | 4.2.3) | | | | | 895 +--------------+------------+------------+----------+---------------+ 897 Table 2: Pattern 2 899 The response by the Original Resource to the request shown in Figure 900 4 is the same for all three cases. The use of headers and links in 901 the response from URI-R is as follows: 903 o A "Vary" header that includes an "accept-datetime" value MUST NOT 904 be provided. 906 o The response MUST NOT contain a "Memento-Datetime" header. 908 o The "Link" header SHOULD be provided. It MUST NOT include a link 909 with an "original" Relation Type. If a preferred TimeGate is 910 associated with the Original Resource, then it MUST include a link 911 with a "timegate" Relation Type that has the URI-G of the TimeGate 912 as Target IRI. If a preferred TimeMap is associated with the 913 Original Resource, then it SHOULD include a link with a "timemap" 914 Relation Type that has the URI-T of the TimeGate as Target IRI. 915 Multiple "timegate" and "timemap" links can be provided to 916 accommodate situations in which the server is aware of multiple 917 TimeGates or Timemaps for the Original Resource. 919 Figure 10 shows such a response. Note the absence of an "original" 920 link as the responding resource is neither a TimeGate or a Memento. 922 HTTP/1.1 200 OK 923 Date: Thu, 21 Jan 2010 00:02:12 GMT 924 Server: Apache 925 Link: 926 ; rel="timegate" 927 Content-Length: 255 928 Connection: close 929 Content-Type: text/html; charset=iso-8859-1 931 Figure 10: Response from URI-R<>URI-G for Pattern 2 933 Once a user agent has obtained the URI-G of a remote TimeGate for the 934 Original Resource it can engage in datetime negotation with that 935 TimeGate. Figure 11 shows the request issued against the TimeGate 936 whereas Section 4.2.1 through Section 4.2.3 detail the responses for 937 various TimeGate implementation patterns. 939 HEAD /timegate/http://a.example.org/ HTTP/1.1 940 Host: arxiv.example.net 941 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 942 Connection: close 944 Figure 11: User Agent Engages in Datetime Negotiation With Remote 945 TimeGate 947 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; distinct 948 URI-M for Mementos 950 In case the TimeGate uses a 302 negotiation style, the response to 951 the user agent's request of Figure 11 has a "302 Found" HTTP status 952 code, and the "Location" header conveys the URI-M of the selected 953 Memento. The use of Memento response headers and links in the 954 response from URI-G is as follows: 956 o The "Vary" header MUST be provided and it MUST include the 957 "accept-datetime" value. 959 o The response MUST NOT contain a "Memento-Datetime" header. 961 o The "Link" header MUST be provided and it MUST contain at least a 962 link with the "original" Relation Type that has the URI-R of the 963 Original Resource as Target IRI. The provision of other links is 964 encouraged and is subject to the considerations described in 965 Section 2.2. 967 The server's response to the request of Figure 11 is shown in Figure 968 12. It contains the mandatory "original" link that points back to 969 the Original Resource associated with this TimeGate and it shows the 970 recommended "timemap" link that includes "from" and "until" 971 attributes. 973 HTTP/1.1 302 Found 974 Date: Thu, 21 Jan 2010 00:02:14 GMT 975 Server: Apache 976 Vary: accept-datetime 977 Location: 978 http://arxiv.example.net/web/20010911203610/http://a.example.org/ 979 Link: ; rel="original", 980 981 ; rel="timemap"; type="application/link-format" 982 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 983 ; until="Wed, 20 Jan 2010 09:34:33 GMT" 984 Content-Length: 0 985 Content-Type: text/plain; charset=UTF-8 986 Connection: close 988 Figure 12: Response from URI-G<>URI-R for Pattern 2.1 990 In a subsequent HTTP GET request, shown in Figure 13, the user agent 991 can obtain the selected Memento by issuing an HTTP GET request 992 against the URI-M that was provided in the "Location" header. The 993 inclusion of the "Accept-Datetime" header in this request is not 994 needed but will typically occur as the user agent is in datetime 995 negotiation mode. 997 GET /web/20010911203610/http://a.example.org/ HTTP/1.1 998 Host: arxiv.example.net/ 999 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 1000 Connection: close 1002 Figure 13: User Agent Requests Selected Memento 1004 The response has a "200 OK" HTTP status code. The use of Memento 1005 response headers and links in the response from URI-M is as follows: 1007 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1008 be provided. 1010 o The response MUST include a "Memento-Datetime" header. Its value 1011 expresses the archival datetime of the Memento. 1013 o The "Link" header MUST be provided and it MUST contain at least a 1014 link with the "original" Relation Type that has the URI-R of the 1015 Original Resource as Target IRI. The provision of other links is 1016 encouraged and is subject to the considerations described in 1017 Section 2.2. 1019 The server's response to the request of Figure 13 is shown in Figure 1020 14. Note the provision of the recommended "timegate" and "timemap" 1021 links. 1023 HTTP/1.1 200 OK 1024 Date: Thu, 21 Jan 2010 00:02:15 GMT 1025 Server: Apache-Coyote/1.1 1026 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1027 Link: ; rel="original", 1028 1029 ; rel="timemap"; type="application/link-format", 1030 1031 ; rel="timegate" 1032 Content-Length: 23364 1033 Content-Type: text/html;charset=utf-8 1034 Connection: close 1036 Figure 14: Response from URI-M for Pattern 2.1 1038 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; distinct 1039 URI-M for Mementos 1041 In case the TimeGate uses a 200 negotiation style, and each Memento 1042 has a distinct URI-M, the response to the user agent's request of 1043 Figure 11 has a "200 OK" HTTP status code, and the "Content-Location" 1044 header conveys the URI-M of the selected Memento. The use of Memento 1045 response headers and links in the response from URI-G is as follows: 1047 o The "Vary" header MUST be provided and it MUST include the 1048 "accept-datetime" value. 1050 o The response MUST include a "Memento-Datetime" header. Its value 1051 expresses the archival datetime of the Memento. 1053 o The "Link" header MUST be provided and it MUST contain at least a 1054 link with the "original" Relation Type that has the URI-R of the 1055 Original Resource as Target IRI. The provision of other links is 1056 encouraged and is subject to the considerations described in 1057 Section 2.2. 1059 The server's response to the request of Figure 11 is shown in Figure 1060 15. 1062 HTTP/1.1 200 OK 1063 Date: Thu, 21 Jan 2010 00:09:40 GMT 1064 Server: Apache-Coyote/1.1 1065 Vary: accept-datetime 1066 Content-Location: 1067 http://arxiv.example.net/web/20010911203610/http://a.example.org/ 1068 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1069 Link: ; rel="original", 1070 1071 ; rel="timemap"; type="application/link-format", 1072 1073 ; rel="timegate" 1074 Content-Length: 23364 1075 Content-Type: text/html; charset=UTF-8 1076 Connection: close 1078 Figure 15: Response from URI-G<>URI-R for Pattern 2.2 1080 In a subsequent request, which is the same as Figure 11 but with HTTP 1081 GET instead of HEAD, the user agent can obtain the representation of 1082 the selected Memento. It will be provided as the entity-body of a 1083 response that has the same Memento headers as Figure 15. 1085 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct 1086 URI-M for Mementos 1088 In case the TimeGate uses a 200 negotiation style, but Mementos have 1089 no distinct URIs, the response to the user agent's request of Figure 1090 11 has a "200 OK" HTTP status code, and it does not contain a 1091 "Content-Location" nor "Location" header as there is no URI-M of the 1092 selected Memento to convey. The use of Memento response headers and 1093 links in the response from URI-G is as follows: 1095 o The "Vary" header MUST be provided and it MUST include the 1096 "accept-datetime" value. 1098 o The response MUST include a "Memento-Datetime" header. Its value 1099 expresses the archival datetime of the Memento. 1101 o The "Link" header MUST be provided and it MUST contain at least a 1102 link with the "original" Relation Type that has the URI-R of the 1103 Original Resource as Target IRI. The provision of other links is 1104 encouraged and is subject to the considerations described in 1105 Section 2.2. 1107 The server's response to the request of Figure 11 is shown in Figure 1108 16. 1110 HTTP/1.1 200 OK 1111 Date: Thu, 21 Jan 2010 00:09:40 GMT 1112 Server: Apache-Coyote/1.1 1113 Vary: accept-datetime 1114 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1115 Link: ; rel="original", 1116 1117 ; rel="timemap"; type="application/link-format", 1118 1119 ; rel="timegate" 1120 Content-Length: 23364 1121 Content-Type: text/html; charset=UTF-8 1122 Connection: close 1124 Figure 16: Response from URI-G<>URI-R for Pattern 2.3 1126 In a subsequent request, which is the same as Figure 11 but with HTTP 1127 GET instead of HEAD, the user agent can obtain the representation of 1128 the selected Memento. It will be provided as the entity-body of a 1129 response that has the same Memento headers as Figure 16. 1131 4.3. Pattern 3 - The Original Resource is a Fixed Resource 1133 This pattern does not involve datetime negotiation with a TimeGate 1134 but it can be implemented for Original Resources that never change 1135 state or do not change anymore past a certain point in their 1136 existence, meaning that URI-R and URI-M coincide either from the 1137 outset or starting at some point in time. This pattern is summarized 1138 in the below table. Examples are tweets or stable media resources on 1139 news sites. 1141 +-----------+--------------+------------+----------+----------------+ 1142 | Pattern | Original | TimeGate | Memento | Negotiation | 1143 | | Resource | | | Style | 1144 +-----------+--------------+------------+----------+----------------+ 1145 | Pattern 3 | URI-R | - | URI-R | - | 1146 +-----------+--------------+------------+----------+----------------+ 1148 Table 3: Pattern 3 1150 Servers that host such resources can support the Memento framework by 1151 treating the stable resource (FixedResource as per 1152 [W3C.gen-ont-20090420]) as a Memento. The use of Memento response 1153 headers and links in responses from such a stable resource is as 1154 follows: 1156 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1157 be provided. 1159 o The response MUST include a "Memento-Datetime" header. Its value 1160 expresses the datetime at which the resource became stable. 1161 Providing this value includes a promise that the resource has not 1162 changed since this datetime and will not change anymore beyond it. 1164 o The "Link" header MUST be provided and MUST have a link with the 1165 "original" Relation Type that has the URI-R of the stable resource 1166 itself as Target IRI. 1168 Figure 17 shows a response to an HTTP HEAD request for the resource 1169 with URI-R http://a.example.org/ that has been stable since March 1170 20th 2009. 1172 HTTP/1.1 200 OK 1173 Date: Thu, 21 Jan 2010 00:09:40 GMT 1174 Server: Apache-Coyote/1.1 1175 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT 1176 Link: ; rel="original" 1177 Content-Length: 0 1178 Content-Type: text/plain; charset=UTF-8 1179 Connection: close 1181 Figure 17: Response from URI-R=URI-M for Pattern 3 1183 4.4. Pattern 4 - Mementos without a TimeGate 1185 Cases may occur in which a server hosts Mementos but does not expose 1186 a TimeGate for them. This can, for example, be the case if the 1187 server's Mementos result from taking a snapshot of the state of a set 1188 of Original Resources from another server as it is being retired. As 1189 a result, only a single Memento per Original Resource is hosted, 1190 making the introduction of a TimeGate unnecessary. But it may also 1191 be the case for servers that host multiple Mementos for an Original 1192 Resource but consider exposing TimeGates too expensive. In this 1193 case, URI-R and URI-M are distinct, but a TimeGate is absent. This 1194 case is summarized in the below table. 1196 +-----------+--------------+------------+----------+----------------+ 1197 | Pattern | Original | TimeGate | Memento | Negotiation | 1198 | | Resource | | | Style | 1199 +-----------+--------------+------------+----------+----------------+ 1200 | Pattern 4 | URI-R | - | URI-M | - | 1201 +-----------+--------------+------------+----------+----------------+ 1203 Table 4: Pattern 4 1205 Servers that host such Mementos without TimeGates can still support 1206 the Memento framework by providing the appropriate Memento headers 1207 and links. Their use is as follows for a response from URI-M: 1209 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1210 be provided. 1212 o The response MUST include a "Memento-Datetime" header. Its value 1213 expresses the archival datetime of the Memento. 1215 o The "Link" header MUST be provided and it MUST have a link with 1216 the "original" Relation Type that has the URI-R of the associated 1217 Original Resource as Target IRI. The provision of other links is 1218 encouraged and is subject to the considerations described in 1219 Section 2.2. 1221 Figure 18 shows a response to an HTTP HEAD request for the Memento 1222 with URI-M http://arxiv.example.net/web/20010911203610/http:// 1223 a.example.org/. Note the use of links: three links have the URI-M of 1224 the Memento as Target IRI and have respective Relation Types 1225 "memento", "first", and "last". This combination indicates that this 1226 is the only Memento for the Original Resource with Target IRI 1227 provided by the "original" link (http://a.example.org/) that the 1228 server is aware of. Note also that such a response does not imply 1229 that there is no server whatsoever that exposes a TimeGate; it merely 1230 means that the responding server neither provides nor is aware of the 1231 location of a TimeGate. 1233 HTTP/1.1 200 OK 1234 Date: Thu, 21 Jan 2010 00:09:40 GMT 1235 Server: Apache-Coyote/1.1 1236 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1237 Link: ; rel="original", 1238 1239 ; rel="first last memento" 1240 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT" 1241 Content-Length: 0 1242 Content-Type: text/plain; charset=UTF-8 1243 Connection: close 1245 Figure 18: Response from URI-M<>URI-R for Pattern 4 1247 4.5. Special Cases 1249 4.5.1. Original Resource provides no "timegate" link 1251 Cases exist in which the response from the Original Resource does not 1252 contain a "timegate" link, including: 1254 o The Original Resource's server does not support the Memento 1255 framework; 1257 o The Original Resource no longer exists and the responding server 1258 is not aware of its prior existence; 1260 o The server that hosted the Original Resource no longer exists. 1262 In all these cases, the user agent should attempt to determine an 1263 appropriate TimeGate for the Original Resource, either automatically 1264 or interactively supported by the user. 1266 4.5.2. Server exists but Original Resource no longer does 1268 Cases exist in which the server knows that an Original Resource used 1269 to exist, but no longer provides a current representation. If there 1270 is a preferred TimeGate for such a discontinued Original Resource, 1271 then the server MUST include a "timegate" link in responses to 1272 requests for it. This may allow access to Mementos for the Original 1273 Resource even if it no longer exists. A server's response to a 1274 request for the discontinued resource http://a.example.org/pic is 1275 illustrated in Figure 19. 1277 HTTP/1.1 404 Not Found 1278 Date: Thu, 21 Jan 2010 00:02:12 GMT 1279 Server: Apache 1280 Link: 1281 1282 ; rel="timegate" 1283 Content-Length: 255 1284 Connection: close 1285 Content-Type: text/html; charset=iso-8909-1 1287 Figure 19: Response from an Original Resource that not longer exists 1289 4.5.3. Issues with Accept-Datetime 1291 The following special cases may occur regarding the "Accept-Datetime" 1292 header when a user agent issues a request against a TimeGate: 1294 o If the value of the "Accept-Datetime" is either earlier than the 1295 datetime of the first Memento or later than the datetime of the 1296 most recent Memento known to the TimeGate, the first or most 1297 recent Memento MUST be selected, respectively. 1299 o If the value of the "Accept-Datetime" does not conform to the 1300 rfc1123-date construction rule of the BNF in Figure 1, the 1301 response MUST have a "400 Bad Request" HTTP status code. 1303 o If a user agent issues a request against a TimeGate and fails to 1304 include an "Accept-Datetime" request header, the most recent 1305 Memento SHOULD be selected. 1307 In all cases, the use of headers and links in responses is as 1308 described for TimeGates in the respective scenarios. 1310 4.5.4. Memento of a 3XX response 1312 Cases exist in which HTTP responses with 3XX status codes are 1313 archived. For example, crawl-based web archives commonly archive 1314 responses with HTTP status codes "301 Moved Permanently" and "302 1315 Found" whereas Linked Data archives hold on to "303 See Other" 1316 responses. 1318 If the Memento requested by the user agent is an archived version of 1319 an HTTP response with a 3XX status code, the server's response MUST 1320 have the same 3XX HTTP status code. The use of other Memento headers 1321 is as described for Mementos in the respective scenarios. 1323 The user agent's handling of an HTTP response with a 3XX status code 1324 is not affected by the presence of a "Memento-Datetime" header. The 1325 user agent MUST behave in the same manner as it does with HTTP 1326 responses with a 3XX status code that do not have a "Memento- 1327 Datetime" header. 1329 However, the user agent MUST be aware that the URI that was selected 1330 from the "Location" header of an HTTP response with a 3XX status code 1331 might not be that of a Memento but rather of an Original Resource. 1332 In the latter case it SHOULD proceed by looking for a Memento of the 1333 selected Original Resource. 1335 For example, Figure 20 shows the response to an HTTP GET request for 1336 http://a.example.org issued on April 11 2008. This response is 1337 archived as a Memento of http://a.example.org that has as URI-M http: 1338 //arxiv.example.net/web/20080411000650/http://a.example.org. The 1339 response to an HTTP GET on this URI-M is shown in Figure 21. It is a 1340 replay of the original response with "Memento-Datetime" and "Link" 1341 headers added, to allow a user agent to understand the response is a 1342 Memento. In Figure 21, the value of the "Location" header is the 1343 same as in the original response; it identifies an Original Resource. 1344 The user agent proceeds with finding a Memento for this Original 1345 Resource. Web archives sometimes overwrite the value that was 1346 originally provided in the "Location" header in order to point at a 1347 Memento they hold of the resource to which the redirect originally 1348 led. This is shown in Figure 22. In this case, the user agent may 1349 decide it found an appropriate Memento. 1351 HTTP/1.1 301 Moved Permanently 1352 Date: Fri, 11 Apr 2008 00:06:50 GMT 1353 Server: Apache 1354 Location: http://b.example.org 1355 Content-Length: 0 1356 Content-Type: text/plain; charset=UTF-8 1357 Connection: close 1359 Figure 20: Response is a redirect 1361 HTTP/1.1 301 Moved Permanently 1362 Date: Thu, 21 Jan 2010 00:09:40 GMT 1363 Server: Apache-Coyote/1.1 1364 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1365 Location: http://b.example.org 1366 Link: ; rel="original", 1367 1368 ; rel="timemap"; type="application/link-format", 1369 1370 ; rel="timegate" 1371 Content-Length: 0 1372 Content-Type: text/plain; charset=UTF-8 1373 Connection: close 1375 Figure 21: Response is a Memento of a redirect; leads to an Original 1376 Resource 1378 HTTP/1.1 301 Moved Permanently 1379 Date: Thu, 21 Jan 2010 00:09:40 GMT 1380 Server: Apache-Coyote/1.1 1381 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1382 Location: 1383 http://arxiv.example.net/web/20080411000655/http://b.example.org 1384 Link: ; rel="original", 1385 1386 ; rel="timemap"; type="application/link-format", 1387 1388 ; rel="timegate" 1389 Content-Length: 0 1390 Content-Type: text/plain; charset=UTF-8 1391 Connection: close 1393 Figure 22: Response is a Memento of a redirect; leads to a Memento 1395 4.5.5. Memento of responses with 4XX or 5XX HTTP status codes 1397 Cases exist in which responses with 4XX and 5XX HTTP status codes are 1398 archived. If the Memento requested by the user agent is an archived 1399 version of such an HTTP response, the server's response MUST have the 1400 same 4XX or 5XX HTTP status code. The use of headers and links in 1401 responses is as described for Mementos in the respective scenarios. 1403 For example, Figure 23 shows the 404 response to an HTTP GET request 1404 for http://a.example.org issued on April 11 2008. This response is 1405 archived as a Memento of http://a.example.org, that has as URI-M 1406 http://arxiv.example.net/web/20080411000650/http://a.example.org. 1407 The response to an HTTP HEAD on this URI-M is shown in Figure 24. It 1408 is a replay of the original response with "Memento-Datetime" and 1409 "Link" headers added, to allow a user agent to understand the 1410 response is a Memento. 1412 HTTP/1.1 404 Not Found 1413 Date: Fri, 11 Apr 2008 00:06:50 GMT 1414 Server: Apache 1415 Content-Length: 0 1416 Content-Type: text/plain; charset=UTF-8 1417 Connection: close 1419 Figure 23: Response is a 404 1421 HTTP/1.1 404 Not Found 1422 Date: Thu, 21 Jan 2010 00:09:40 GMT 1423 Server: Apache-Coyote/1.1 1424 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1425 Link: ; rel="original", 1426 1427 ; rel="timemap"; type="application/link-format", 1428 1429 ; rel="timegate" 1430 Content-Length: 0 1431 Content-Type: text/plain; charset=UTF-8 1432 Connection: close 1434 Figure 24: Response is a Memento of a 404 1436 4.5.6. Sticky "Memento-Datetime" value for Mementos 1438 The provision of a "Memento-Datetime" in a response entails a promise 1439 that the response is frozen in time. As a consequence, the "Memento- 1440 Datetime" header associated with a Memento MUST be "sticky" in the 1441 following ways: 1443 o The server that originally assigns the "Memento-Datetime" header 1444 and value to a specific response MUST retain that header in all 1445 future responses to HTTP requests (with or without "Accept- 1446 Datetime" header) that occur against the Memento after the time of 1447 the original assignment of the header, and it MUST NOT change its 1448 associated value. 1450 o Applications that mirror Mementos at a different URI MUST retain 1451 the "Memento-Datetime" header and MUST NOT change its value unless 1452 mirroring involves a meaningful state change. This allows, for 1453 example, duplicating a web archive at a new location while 1454 preserving the value of the "Memento-Datetime" header of the 1455 archived resources. In this example, the "Last-Modified" header 1456 will be updated to reflect the time of mirroring at the new URI, 1457 whereas the value for "Memento-Datetime" will be maintained. 1459 4.5.7. Intermediate Resources 1460 An intermediate resource is a resource that issues a redirect to a 1461 TimeGate, to a Memento, or to another intermediate resource, and thus 1462 plays an active role in the Memento infrastructure. Intermediate 1463 resources commonly exist in web archives on the path from a TimeGate 1464 to an appropriate Memento. 1466 A response of an intermediate resource has an HTTP status code 1467 indicative of HTTP redirection (e.g. 302) and uses Memento headers 1468 and links that allow to recognize that the resource plays a role in 1469 the Memento framework: 1471 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1472 be provided. 1474 o The response MUST NOT include a "Memento-Datetime" header. 1476 o The "Link" header MUST be provided and it MUST have a link with 1477 the "original" Relation Type that has the URI-R of the associated 1478 Original Resource as Target IRI. Links with "timegate", 1479 "timemap", and "memento" Relation Types are OPTIONAL and, if 1480 provided, MUST pertain to the Original Resource for which the user 1481 agent is trying to obtain a Memento. 1483 A user agent MUST follow a redirection provided by an intermediate 1484 resource; multiple such redirections can be chained. 1486 Consider the case where a user agent follows the "timegate" link 1487 provided in Figure 10 and engages in datetime negotiation with the 1488 assumed TimeGate in the manner shown in Figure 11. But instead of 1489 receiving a response as shown in Figure 12, it receives the one shown 1490 below in Figure 25. Such a response is umabiguosuly recognizable as 1491 coming from an intermediate resource. 1493 HTTP/1.1 302 Found 1494 Date: Thu, 21 Jan 2010 00:06:50 GMT 1495 Server: Apache 1496 Location: 1497 http://arxiv.example.net/new-timegate/http://a.example.org/ 1498 Link: ; rel="original" 1499 Content-Length: 0 1500 Content-Type: text/plain; charset=UTF-8 1501 Connection: close 1503 Figure 25: Redirecting Resource redirects to a TimeGate 1505 4.5.8. Resources excluded from datetime negotiation 1506 When delivering a Memento to a user agent, a web archive commonly 1507 enhances that Memento's archived content, for example, by including a 1508 banner that provides branding and highlights the archival status of 1509 the Memento. The resources that are involved in providing such 1510 system-specific functionality, many times Javascript or images, must 1511 be used in their current state. 1513 A server that generally supports datetime negotiation should make 1514 resources that need to be excluded from datetime negotiation 1515 recognizable. Doing so allows a user agent to refrain from 1516 attempting to access a Memento for them. In order to achieve this, 1517 the server SHOULD include a special-purpose link in the HTTP "Link" 1518 header when responding to a HTTP HEAD/GET request to a resource 1519 excluded from datetime negotiation. This link has "http:// 1520 mementoweb.org/terms/donotnegotiate" as Target IRI and "type", 1521 defined in [RFC6903], as the value of the rel attribute. Other 1522 Memento headers as defined in Section 2.1. SHOULD NOT be provided. 1524 Figure 26 shows the response to a HTTP HEAD request from a resource 1525 excluded from datetime negotiation. 1527 HTTP/1.1 200 OK 1528 Date: Thu, 21 Jan 2010 00:09:40 GMT 1529 Server: Apache-Coyote/1.1 1530 Link: ; rel="type" 1531 Content-Length: 238 1532 Content-Type: application/javascript; charset=UTF-8 1533 Connection: close 1535 Figure 26: Response to a HTTP HEAD request from a resource excluded 1536 from datetime negotiation 1538 5. TimeMaps: Content and Serialization 1540 A TimeMap is introduced to support retrieving a comprehensive list of 1541 all Mementos for a specific Original Resource known to a server. The 1542 entity-body of a response to an HTTP GET request issued against a 1543 TimeMap's URI-T: 1545 o MUST list the URI-R of the Original Resource that the TimeMap is 1546 about; 1548 o MUST list the URI-M and archival datetime of each Memento for the 1549 Original Resource known to the server, preferably in a single 1550 document, or, alternatively in multiple documents that can be 1551 gathered by following contained links with a "timemap" Relation 1552 Type; 1554 o SHOULD list the URI-G of one or more TimeGates for the Original 1555 Resource known to the responding server; 1557 o SHOULD, for self-containment, list the URI-T of the TimeMap 1558 itself; 1560 o MUST unambiguously type listed resources as being Original 1561 Resource, TimeGate, Memento, or TimeMap. 1563 The entity-body of a response from a TimeMap MAY be serialized in 1564 various ways, but the link-value format serialization described here 1565 MUST be supported. In this serialization, the entity-body MUST be 1566 formatted in the same way as the value of an HTTP "Link" header, and 1567 hence MUST comply to the "link-value" construction rule of 1568 "Section 5. The Link Header Field" of [RFC5988], and the media type 1569 of the entity-body MUST be "application/link-format" as introduced in 1570 [RFC6690]. Links contained in the entity-body MUST be interpreted as 1571 follows: 1573 o The Context IRI is set to the anchor parameter, when specified; 1575 o The Context IRI of links with the "self" Relation Types is the 1576 URI-T of the TimeMap, i.e. the URI of the resource from which the 1577 TimeMap was requested; 1579 o The Context IRI of all other links is the URI-R of the Original 1580 Resource, which is provided as the Target IRI of the link with an 1581 "original" Relation Type. 1583 In order to retrieve the link-value serialization of a TimeMap, a 1584 user agent uses an "Accept" request header with a value set to 1585 "application/link-format". This is shown in Figure 27. 1587 GET /timemap/http://a.example.org/ HTTP/1.1 1588 Host: arxiv.example.net 1589 Accept: application/link-format;q=1.0 1590 Connection: close 1592 Figure 27: Request for a TimeMap 1594 If the TimeMap requested by the user agent exists, the server's 1595 response has a "200 OK" HTTP status code and the list of Mementos is 1596 provided in the entity-body of the response. Such a response is 1597 shown in Figure 28 1599 HTTP/1.1 200 OK 1600 Date: Thu, 21 Jan 2010 00:06:50 GMT 1601 Server: Apache 1602 Content-Length: 4883 1603 Content-Type: application/link-format 1604 Connection: close 1606 ;rel="original", 1607 1608 ; rel="self";type="application/link-format" 1609 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1610 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1611 1612 ; rel="timegate", 1613 1614 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" 1615 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1616 1617 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" 1618 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1619 1620 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" 1621 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1622 1623 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT" 1624 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1625 ... 1627 Figure 28: Response from a TimeMap 1629 5.1. Special Cases 1631 5.1.1. Index and Paging TimeMaps 1633 Cases exist in which a TimeMap points at one or more other TimeMaps: 1635 o Index Timemap - A TimeMap can merely point at other TimeMaps and 1636 not list any Mementos itself. This can happen when Mementos are 1637 spread across several archives that share a front-end. An example 1638 is shown in Figure 29. 1640 o Paging Timemap - The number of available Mementos can require 1641 introducing multiple TimeMaps that can be paged. An example is 1642 shown in Figure 30. Note that a Paging TimeMap contains links to 1643 other TimeMaps but actually also lists Mementos. 1645 In both cases, including the "from" and "until" attributes for 1646 "timemap" links is RECOMMENDED as a means to express the temporal 1647 span of Mementos listed in each TimeMap. Note that TimeMaps obtained 1648 by following a "timemap" link can contain links to further TimeMaps. 1650 ;rel="original", 1651 1652 ; rel="timegate", 1653 1654 ; rel="self";type="application/link-format", 1655 1656 ; rel="timemap";type="application/link-format" 1657 ; from="Wed, 21 Jun 2000 04:41:56 GMT" 1658 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1659 1660 ; rel="timemap";type="application/link-format" 1661 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1662 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1663 1664 ; rel="timemap";type="application/link-format" 1665 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1667 Figure 29: Index TimeMap 1669 ;rel="original", 1670 1671 ; rel="timegate", 1672 1673 ; rel="self";type="application/link-format" 1674 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1675 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1676 1677 ; rel="timemap";type="application/link-format" 1678 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1679 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1680 1681 ; rel="timemap";type="application/link-format" 1682 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1683 ; until="Fri, 31 Aug 2012 12:22:34 GMT" 1684 1685 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", 1686 1687 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT", 1688 1689 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT", 1690 ... 1692 Figure 30: Paging TimeMap 1694 5.1.2. Mementos for TimeMaps 1696 A TimeMap can itself act as an Original Resource for which a TimeGate 1697 and Mementos may exist. Hence, the response from a TimeMap could 1698 include a "timegate" link to a TimeGate via which prior TimeMap 1699 versions are available. And, in cases where URI-T=URI-R=URI-G (a 1700 TimeMap is an Original Resource that acts as its own TimeGate), an 1701 "original" link pointing at the TimeMap URI-T would be included. 1703 Therefore, caution is required in cases where a TimeMap for an 1704 Original Resource wants to explicitly express in a Link header for 1705 which Original Resource it is a TimeMap. It can do so by including a 1706 "timemap" link that has the URI-R of the Original Resource as Context 1707 IRI and the URI-T of the TimeMap as Target IRI. 1709 Figure 31 shows the response to an HTTP HEAD request against a 1710 TimeMap that has http://arxiv.example.net/timemap/http:// 1711 a.example.org as URI-T. This TimeMap provides information about 1712 Mementos for the Original Resource that has http://a.example.org as 1713 URI-R. The response includes an "original" link pointing to the 1714 Original Resource that this TimeMap is about. Note the use of the 1715 "anchor" attribute in this link to convey the URI-R of that Original 1716 Resource. 1718 HTTP/1.1 200 OK 1719 Date: Thu, 21 Jan 2010 00:06:50 GMT 1720 Server: Apache 1721 Link: 1722 ; anchor="http://a.example.org"; rel="timemap" 1723 ; type="application/link-format" 1724 Content-Length: 0 1725 Content-Type: application/link-format; charset=UTF-8 1726 Connection: close 1728 Figure 31: TimeMap links to the Original Resource it is about 1730 6. IANA Considerations 1732 This memo requires IANA to register the Accept-Datetime and Memento- 1733 Datetime HTTP headers defined in Section 2.1.1 in the appropriate 1734 IANA registry. 1736 This memo requires IANA to register the Relation Types "original", 1737 "timegate", "timemap", and "memento" defined in Section 2.2 in the 1738 appropriate IANA registry. 1740 This memo requires IANA to register the "datetime" and "license" 1741 attributes for the "memento" Relation Type, as defined in 1742 Section 2.2.4, in the appropriate IANA registry. 1744 This memo requires IANA to register the "from" and "until" attributes 1745 for the "timemap" Relation Type, as defined in Section 2.2.4, in the 1746 appropriate IANA registry. 1748 7. Security Considerations 1750 Provision of a "timegate" HTTP "Link" header in responses to requests 1751 for an Original Resource that is protected (e.g., 401 or 403 HTTP 1752 response codes) is OPTIONAL. The inclusion of this Link when 1753 requesting authentication is at the server's discretion; cases may 1754 exist in which a server protects the current state of a resource, but 1755 supports open access to prior states and thus chooses to supply a 1756 "timegate" HTTP "Link" header. Conversely, the server may choose to 1757 not advertise the TimeGate URIs (e.g., they exist in an intranet 1758 archive) for unauthenticated requests. 1760 The veracity of archives and the relationships between Original 1761 Resources and Mementos is beyond the scope of this document. Even in 1762 the absence of malice, it is possible for separate archives to have 1763 different Mementos for the same Original Resource at the same 1764 datetime if the state of the Original Resource was dependent on the 1765 requesting archive's user agent IP address, specific HTTP request 1766 headers, and possibly other factors. 1768 Further authentication, encryption and other security related issues 1769 are otherwise orthogonal to Memento. 1771 8. Changelog 1773 v07 2013-07-08 HVDS MLN RS draft-vandesompel-memento-08 1775 o Added the Special Case where a server that generally supports 1776 datetime negotiation indicates that a given resource is not 1777 subject to datetime negotiation. 1779 v07 2013-03-28 HVDS MLN RS draft-vandesompel-memento-07 1781 o Introduced "Overview" section to make the existence of two 1782 components (datetime negotiation and TimeMaps) more explicit. 1784 o Replaced the hard-to-interpret summary table detailing the use of 1785 headers (introduced in version 06 ) with an explicit version in 1786 the appendix. 1788 o Revised the abstract. 1790 o Added TimeMaps to the enumeration of core components in the 1791 Purpose section. 1793 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06 1795 o Major overhaul of the presentation of the specification. 1797 o Specification of patterns whereby URI-R=URI-G and with both 200 1798 and 302 negotation style. 1800 o Removal of Discovery section to increase focus on datetime 1801 negotation aspects. 1803 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05 1805 o Clarified the section on Memento Relation Types. 1807 o Re-introduced "license" attribute for "memento" Relation Type as 1808 it will become essential for IIPC. 1810 o Introduced from and until attributes for "timemap" links to 1811 accomodate paged TimeMap cases. 1813 o Introduced the notion of Redirecting Resource and inserted related 1814 information in various sections. 1816 o Added discovery of Mementos via host-meta. 1818 o Corrected ambiguous uses of the term "representation". 1820 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04 1822 o Removed the possibility to use an interval indicator in an Accept- 1823 Datetime header as no one is implementing it. 1825 o Corrected typo in Other Relation Types table. 1827 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap 1828 paging. 1830 o Changed Discovery component from using robots.txt with Memento- 1831 specific add-ons to well-known URI and host-meta. 1833 o Removed "embargo" and "license" attributes for links with a 1834 "memento" Relation Type because no one is using them. 1836 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03 1838 o Added description of Mementos of HTTP responses with 3XX, 4XX and 1839 5XX status code. 1841 o Clarified that a TimeGate must not use the "Memento-Datetime" 1842 header. 1844 o Added wording to warn for possible cache problems with Memento 1845 implementations that choose to have an Original Resource and and 1846 its TimeGate coincide. 1848 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02 1850 o Added scenario in which a TimeGate redirects to another TimeGate. 1852 o Reorganized TimeGate section to better reflect the difference 1853 between requests with and without interval indicator. 1855 o Added recommendation to provide "memento" links to Mementos in the 1856 vicinity of the preferred interval provided by the user agent, in 1857 case of a 406 response. 1859 o Removed TimeMap Feed material from the Discovery section as a 1860 result of discussions regarding (lack of) scalability of the 1861 approach with representatives of the International Internet 1862 Preservation Consortium. An alternative approach to support batch 1863 discovery of Mementos will be specified. 1865 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01 1867 o Introduced wording and reference to indicate a Memento is a 1868 FixedResource. 1870 o Introduced "Sticky Memento-Datetime" notion and clarified wording 1871 about retaining "Memento-Datetime" headers and values when a 1872 Memento is mirrored at different URI. 1874 o Introduced section about handling both datetime and regular 1875 negotiation. 1877 o Introduced section about Mementos Without TimeGate. 1879 o Made various changes in the section Relation Type "memento", 1880 including addition of "license" and "embargo" attributes, and 1881 clarification of rules regarding the use of "memento" links. 1883 o Moved section about TimeMaps inside the Datetime Negotiation 1884 section, and updated it. 1886 o Restarted the Discovery section from scratch. 1888 v01 2010-11-11 HVDS MLN RS First public version draft-vandesompel- 1889 memento-00 1891 v00 2010-10-19 HVDS MLN RS Limited circulation version 1893 2010-07-22 HVDS MLN First internal version 1895 9. Acknowledgements 1897 The Memento effort is funded by the Library of Congress. Many thanks 1898 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry 1899 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers, 1900 James Anderson, Tim Starling, Martin Klein, Mark Nottingham for 1901 feedback. Many thanks to Samuel Adams, Scott Ainsworth, Lyudmilla 1902 Balakireva, Frank McCown, Harihar Shankar, Brad Tofel, Andrew 1903 Jackson, Ahmed Alsum, Mat Kelly, Ilya Kreymer for implementations 1904 that informed the specification. 1906 10. References 1908 10.1. Normative References 1910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1911 Requirement Levels", BCP 14, RFC 2119, March 1997. 1913 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1914 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1915 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1917 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 1918 4151, October 2005. 1920 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1921 Syndication Format", RFC 4287, December 2005. 1923 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1924 Uniform Resource Identifiers (URIs)", RFC 5785, April 1925 2010. 1927 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types 1928 for Simple Version Navigation between Web Resources", RFC 1929 5829, April 2010. 1931 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1933 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 1934 6415, October 2011. 1936 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1937 Format", RFC 6690, August 2012. 1939 [RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903, 1940 March 2013. 1942 10.2. Informative References 1944 [Fitch] Fitch, ., "Web site archiving - an approach to recording 1945 every materially different response produced by a 1946 website", July 2003, 1947 . 1949 [I-D.masinter-dated-uri] 1950 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on 1951 dated URIs", draft-masinter-dated-uri-10 (work in 1952 progress), January 2012. 1954 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1955 and Support", STD 3, RFC 1123, October 1989. 1957 [W3C.REC-aww-20041215] 1958 Jacobs, . and . Walsh, "Architecture of the World Wide 1959 Web", December 2004, . 1961 [W3C.gen-ont-20090420] 1962 Berners-Lee, ., "Architecture of the World Wide Web", 1963 April 2009, . 1965 Appendix A. Appendix: Use of Headers and Relation Types per Pattern 1967 +--------------------+--------------+----------+----------+---------+ 1968 | Response Header | Pattern | Original | TimeGate | Memento | 1969 | | | Resource | | | 1970 +--------------------+--------------+----------+----------+---------+ 1971 | Vary: accept- | Pattern 1.1 | 1 | 1 | 0 | 1972 | datetime | (Section | | | | 1973 | | 4.1.1) ; | | | | 1974 | | Pattern 1.2 | | | | 1975 | | (Section | | | | 1976 | | 4.1.2) | | | | 1977 | | Pattern 1.3 | 1 | 1 | 1 | 1978 | | (Section | | | | 1979 | | 4.1.3) | | | | 1980 | | Pattern 2.1 | 0 | 1 | 0 | 1981 | | (Section | | | | 1982 | | 4.2.1) ; | | | | 1983 | | Pattern 2.2 | | | | 1984 | | (Section | | | | 1985 | | 4.2.2) | | | | 1986 | | Pattern 2.3 | 0 | 1 | 1 | 1987 | | (Section | | | | 1988 | | 4.2.3) | | | | 1989 | | Pattern 3 | 1 | NA | 1 | 1990 | | (Section | | | | 1991 | | 4.3) | | | | 1992 | | Pattern 4 | 0 | NA | 1 | 1993 | | (Section | | | | 1994 | | 4.4) | | | | 1995 | Memento-Datetime | Pattern 1.1 | 0 | 0 | 1 | 1996 | | (Section | | | | 1997 | | 4.1.1) ; | | | | 1998 | | Pattern 1.2 | | | | 1999 | | (Section | | | | 2000 | | 4.1.1) | | | | 2001 | | Pattern 1.3 | 1 | 1 | 1 | 2002 | | (Section | | | | 2003 | | 4.1.3) | | | | 2004 | | Pattern 2.1 | 0 | 0 | 1 | 2005 | | (Section | | | | 2006 | | 4.2.1) ; | | | | 2007 | | Pattern 2.2 | | | | 2008 | | (Section | | | | 2009 | | 4.2.2) | | | | 2010 | | Pattern 2.3 | 0 | 1 | 1 | 2011 | | (Section | | | | 2012 | | 4.2.3) | | | | 2013 | | Pattern 3 | 1 | NA | 1 | 2014 | | (Section | | | | 2015 | | 4.3) | | | | 2016 | | Pattern 4 | 0 | NA | 1 | 2017 | | (Section | | | | 2018 | | 4.4) | | | | 2019 | Link | | | | | 2020 | rel="original" | Pattern 1.1 | 0 | 1 | 1 | 2021 | | (Section | | | | 2022 | | 4.1.1) ; | | | | 2023 | | Pattern 1.2 | | | | 2024 | | (Section | | | | 2025 | | 4.1.1) | | | | 2026 | | Pattern 1.3 | 1 | 1 | 1 | 2027 | | (Section | | | | 2028 | | 4.1.3) | | | | 2029 | | Pattern 2.1 | 0 | 1 | 1 | 2030 | | (Section | | | | 2031 | | 4.2.1) ; | | | | 2032 | | Pattern 2.2 | | | | 2033 | | (Section | | | | 2034 | | 4.2.2) | | | | 2035 | | Pattern 2.3 | 0 | 1 | 1 | 2036 | | (Section | | | | 2037 | | 4.2.3) | | | | 2038 | | Pattern 3 | 1 | NA | 1 | 2039 | | (Section | | | | 2040 | | 4.3) | | | | 2041 | | Pattern 4 | 0 | NA | 1 | 2042 | | (Section | | | | 2043 | | 4.4) | | | | 2044 | rel="timegate" | Pattern 1.1 | >=0 | >=0 | >=0 | 2045 | | (Section | | | | 2046 | | 4.1.1) ; | | | | 2047 | | Pattern 1.2 | | | | 2048 | | (Section | | | | 2049 | | 4.1.1) | | | | 2050 | | Pattern 1.3 | >=0 | >=0 | >=0 | 2051 | | (Section | | | | 2052 | | 4.1.3) | | | | 2053 | | Pattern 2.1 | >=0 | 0 | >=0 | 2054 | | (Section | | | | 2055 | | 4.2.1) ; | | | | 2056 | | Pattern 2.2 | | | | 2057 | | (Section | | | | 2058 | | 4.2.2) | | | | 2059 | | Pattern 2.3 | >=0 | >=0 | >=0 | 2060 | | (Section | | | | 2061 | | 4.2.3) | | | | 2062 | | Pattern 3 | NA | NA | NA | 2063 | | (Section | | | | 2064 | | 4.3) | | | | 2065 | | Pattern 4 | NA | NA | NA | 2066 | | (Section | | | | 2067 | | 4.4) | | | | 2068 | rel="timemap" | Pattern 1.1 | >=0 | >=0 | >=0 | 2069 | | (Section | | | | 2070 | | 4.1.1) ; | | | | 2071 | | Pattern 1.2 | | | | 2072 | | (Section | | | | 2073 | | 4.1.1) | | | | 2074 | | Pattern 1.3 | >=0 | >=0 | >=0 | 2075 | | (Section | | | | 2076 | | 4.1.3) | | | | 2077 | | Pattern 2.1 | >=0 | >=0 | >=0 | 2078 | | (Section | | | | 2079 | | 4.2.1) ; | | | | 2080 | | Pattern 2.2 | | | | 2081 | | (Section | | | | 2082 | | 4.2.2) | | | | 2083 | | Pattern 2.3 | >=0 | >=0 | >=0 | 2084 | | (Section | | | | 2085 | | 4.2.3) | | | | 2086 | | Pattern 3 | >=0 | NA | >=0 | 2087 | | (Section | | | | 2088 | | 4.3) | | | | 2089 | | Pattern 4 | >=0 | NA | >=0 | 2090 | | (Section | | | | 2091 | | 4.4) | | | | 2092 | rel="memento" | Pattern 1.1 | >=0 | >=0 | >=0 | 2093 | | (Section | | | | 2094 | | 4.1.1) ; | | | | 2095 | | Pattern 1.2 | | | | 2096 | | (Section | | | | 2097 | | 4.1.1) | | | | 2098 | | Pattern 1.3 | >=0 | >=0 | >=0 | 2099 | | (Section | | | | 2100 | | 4.1.3) | | | | 2101 | | Pattern 2.1 | >=0 | >=0 | >=0 | 2102 | | (Section | | | | 2103 | | 4.2.1) ; | | | | 2104 | | Pattern 2.2 | | | | 2105 | | (Section | | | | 2106 | | 4.2.2) | | | | 2107 | | Pattern 2.3 | >=0 | >=0 | >=0 | 2108 | | (Section | | | | 2109 | | 4.2.3) | | | | 2110 | | Pattern 3 | >=0 | NA | >=0 | 2111 | | (Section | | | | 2112 | | 4.3) | | | | 2113 | | Pattern 4 | >=0 | NA | >=0 | 2114 | | (Section | | | | 2115 | | 4.4) | | | | 2116 +--------------------+--------------+----------+----------+---------+ 2118 Table 5: Memento Headers 2120 Authors' Addresses 2121 Herbert VandeSompel 2122 Los Alamos National Laboratory 2123 PO Box 1663 2124 Los Alamos, New Mexico 87545 2125 USA 2127 Phone: +1 505 667 1267 2128 Email: hvdsomp@gmail.com 2129 URI: http://public.lanl.gov/herbertv/ 2131 Michael Nelson 2132 Old Dominion University 2133 Norfolk, Virginia 23529 2134 USA 2136 Phone: +1 757 683 6393 2137 Email: mln@cs.odu.edu 2138 URI: http://www.cs.odu.edu/~mln/ 2140 Robert Sanderson 2141 Los Alamos National Laboratory 2142 PO Box 1663 2143 Los Alamos, New Mexico 87545 2144 USA 2146 Phone: +1 505 665 5804 2147 Email: azaroth42@gmail.com 2148 URI: http://public.lanl.gov/rsanderson/