idnits 2.17.1 draft-vandesompel-memento-05.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 16, 2012) is 4179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4151' is defined on line 1842, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 1845, 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 (~~), 5 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: May 20, 2013 Old Dominion University 6 R. Sanderson 7 Los Alamos National Laboratory 8 November 16, 2012 10 HTTP framework for time-based access to resource states -- Memento 11 draft-vandesompel-memento-05 13 Abstract 15 The HTTP-based Memento framework bridges the present and past Web by 16 interlinking current resources with resources that encapsulate their 17 past. It facilitates accessing prior states of a resource, 18 encapsulated in archival resources in Web archives or version 19 resources in content management systems, by leveraging the resource's 20 URI and a preferred datetime. To this end, the framework introduces 21 datetime negotiation (a variation on content negotiation) and new 22 Relation Types. It also introduces discovery mechanisms to support 23 these capabilities. 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 May 20, 2013. 42 Copyright Notice 44 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 6 63 2. The Memento Framework, Datetime Negotiation component: 64 HTTP headers, HTTP Link Relation Types . . . . . . . . . . . . 7 65 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 7 67 2.1.1.1. Values for Accept-Datetime . . . . . . . . . . . . 8 68 2.1.1.2. Values for Memento-Datetime . . . . . . . . . . . 9 69 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.1.3. Location . . . . . . . . . . . . . . . . . . . . . . . 9 71 2.1.4. Link . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.2. Link Header Relation Types . . . . . . . . . . . . . . . . 10 73 2.2.1. Memento Framework Relation Types . . . . . . . . . . . 10 74 2.2.1.1. Relation Type "original" . . . . . . . . . . . . . 11 75 2.2.1.2. Relation Type "timegate" . . . . . . . . . . . . . 11 76 2.2.1.3. Relation Type "timemap" . . . . . . . . . . . . . 11 77 2.2.1.4. Relation Type "memento" . . . . . . . . . . . . . 12 78 2.2.2. Other Relation Types . . . . . . . . . . . . . . . . . 13 79 3. The Memento Framework, Datetime Negotiation component: 80 HTTP Interactions . . . . . . . . . . . . . . . . . . . . . . 14 81 3.1. Interactions with an Original Resource . . . . . . . . . . 15 82 3.1.1. Step 1: User Agent Requests an Original Resource . . . 15 83 3.1.2. Step 2: Server Responds to a Request for an 84 Original Resource . . . . . . . . . . . . . . . . . . 15 85 3.1.2.1. Original Resource is an Appropriate Memento . . . 16 86 3.1.2.2. Server Exists and Original Resource Used to 87 Exist . . . . . . . . . . . . . . . . . . . . . . 17 88 3.1.2.3. Missing "timegate" Link in Original Server's 89 Response . . . . . . . . . . . . . . . . . . . . . 18 90 3.2. Interactions with a TimeGate . . . . . . . . . . . . . . . 18 91 3.2.1. Step 3: User Agent Negotiates with a TimeGate . . . . 18 92 3.2.2. Step 4: Server Responds to Negotiation with 93 TimeGate . . . . . . . . . . . . . . . . . . . . . . . 19 94 3.2.2.1. Successful Scenario . . . . . . . . . . . . . . . 19 95 3.2.2.2. Multiple Matching Mementos . . . . . . . . . . . . 20 96 3.2.2.3. Accept-Datetime and other Accept Headers 97 Provided . . . . . . . . . . . . . . . . . . . . . 20 98 3.2.2.4. Accept-Datetime Not Provided . . . . . . . . . . . 21 99 3.2.2.5. Accept-Datetime Unparseable . . . . . . . . . . . 21 100 3.2.2.6. TimeGate Does Not Exist . . . . . . . . . . . . . 21 101 3.2.2.7. HTTP Methods other than HEAD/GET . . . . . . . . . 21 102 3.2.3. Recognizing a TimeGate . . . . . . . . . . . . . . . . 21 103 3.3. Interactions with a Memento . . . . . . . . . . . . . . . 22 104 3.3.1. Step 5: User Agent Requests a Memento . . . . . . . . 22 105 3.3.2. Step 6: Server Responds to a Request for a Memento . . 23 106 3.3.2.1. Common Scenario . . . . . . . . . . . . . . . . . 23 107 3.3.2.2. Memento of a 3XX Response . . . . . . . . . . . . 24 108 3.3.2.3. Memento of Responses with Other HTTP Status 109 Codes . . . . . . . . . . . . . . . . . . . . . . 27 110 3.3.2.4. Mementos Without a TimeGate . . . . . . . . . . . 28 111 3.3.2.5. Memento Does not Exist . . . . . . . . . . . . . . 29 112 3.3.3. Recognizing a Memento . . . . . . . . . . . . . . . . 29 113 3.4. Interactions with a Redirecting Resource . . . . . . . . . 30 114 3.5. Interactions with a TimeMap . . . . . . . . . . . . . . . 31 115 3.5.1. User Agent Requests a TimeMap . . . . . . . . . . . . 32 116 3.5.2. Server Responds to a Request for a TimeMap . . . . . . 32 117 4. The Memento Framework, Discovery of TimeGates, TimeMaps, 118 Mementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 119 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 120 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 121 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 39 122 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 123 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 124 9.1. Normative References . . . . . . . . . . . . . . . . . . . 41 125 9.2. Informative References . . . . . . . . . . . . . . . . . . 42 126 Appendix A. Appendix: A Sample, Successful Memento 127 Request/Response cycle . . . . . . . . . . . . . . . 42 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 130 1. Introduction 132 1.1. Terminology 134 This specification uses the terms "resource", "request", "response", 135 "entity-body", "content negotiation", "client", "user agent", 136 "server" as described in [RFC2616], and it uses the terms 137 "representation" and "resource state" as described in 138 [W3C.REC-aww-20041215]. 140 In addition, the following terms specific to the Memento framework 141 are introduced: 143 o Original Resource: An Original Resource is a resource that exists 144 or used to exist, and for which access to one of its prior states 145 may be required. 147 o Memento: A Memento for an Original Resource is a resource that 148 encapsulates a prior state of the Original Resource. A Memento 149 for an Original Resource as it existed at time Tj is a resource 150 that encapsulates the state the Original Resource had at time Tj. 152 o TimeGate: A TimeGate for an Original Resource is a resource that 153 is capable of datetime negotiation to support access to prior 154 states of the Original Resource. 156 o TimeMap: A TimeMap for an Original Resource is a resource from 157 which a list of URIs of Mementos of the Original Resource is 158 available. 160 o Redirecting Resource: A Redirecting Resource is a resource that 161 issues a redirect to a TimeGate, to a Memento, or to another 162 Redirecting Resource, and thus plays an active role in the Memento 163 infrastructure. 165 1.2. Purpose 167 The state of an Original Resource may change over time. 168 Dereferencing its URI at any specific moment in time yields a 169 response that reflects the resource's state at that moment: a 170 representation of the resource's state (e.g. "200 OK" HTTP status 171 code), an indication of its non-existence (e.g. "404 Not Found" HTTP 172 status code), a relation to another resource (e.g. "302 Found" HTTP 173 status code), etc. However, resources may also exist that 174 encapsulate prior states of an Original Resource. Each such 175 resource, named a Memento, has its own URI that, when dereferenced, 176 yields a response that reflects a prior state of the Original 177 Resource: a representation of a prior state of the Original Resource, 178 an indication that the Original Resource did not exist at some time 179 in the past, a relation that the Original Resource had to another 180 resource at some time in the past, etc. Mementos exist in Web 181 archives, Content Management Systems, or Revision Control Systems, 182 among others. For any given Original Resource several Mementos may 183 exist, each one reflecting a frozen prior state of the Original 184 Resource. In terms of the Ontology for Relating Generic and Specific 185 Information Resources [W3C.gen-ont-20090420]), a Memento is a 186 FixedResource. 188 Examples are: 190 Mementos for Original Resource http://www.ietf.org/ : 192 o http://web.archive.org/web/19970107171109/http://www.ietf.org/ 194 o http://webarchive.nationalarchives.gov.uk/20080906200044/http:// 195 www.ietf.org/ 197 Mementos for Original Resource 198 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol : 200 o http://en.wikipedia.org/w/ 201 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574 203 o http://en.wikipedia.org/w/ 204 index.php?title=Hypertext_Transfer_Protocol&oldid=33912 206 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/ 207 wiki/Hypertext_Transfer_Protocol 209 Mementos for Original Resource http://www.w3.org/TR/webarch/ : 211 o http://www.w3.org/TR/2004/PR-webarch-20041105/ 213 o http://www.w3.org/TR/2002/WD-webarch-20020830/ 215 o http://webarchive.nationalarchives.gov.uk/20100304163140/http:// 216 www.w3.org/TR/webarch/ 218 In the abstract, Memento introduces a mechanism to access versions of 219 Web resources that: 221 o Is fully distributed in the sense that resource versions may 222 reside on multiple hosts, and that any such host is likely only 223 aware of the versions it holds; 225 o Uses the global notion of datetime as a resource version indicator 226 and access key; 228 o Leverages the following primitives of [W3C.REC-aww-20041215]: 229 resource, resource state, representation, content negotiation, and 230 link. 232 The core components of Memento's mechanism to access resource 233 versions are: 235 1. The abstract notion of the state of a resource identified by 236 URI-R as it existed at some time Tj. Note the relationship with the 237 ability to identify a the state of a resource at some datetime Tj by 238 means of a URI as intended by the proposed Dated URI scheme 239 [I-D.masinter-dated-uri]. 241 2. A bridge from the present to the past, consisting of: 243 o An appropriately typed link from the resource identified by URI-R 244 to an associated TimeGate identified by URI-G, which is aware of 245 (at least part of the) version history of the resource identified 246 by URI-R; 248 o The ability to negotiate in the datetime dimension with the 249 TimeGate identified by URI-G, as a means to access the state that 250 the resource identified by URI-R had at some datetime Tj. 252 3. A bridge from the past to the present, consisting of an 253 appropriately typed link from a resource identified by URI-M, which 254 encapsulates the state a resource identified by URI-R had at some 255 datetime Tj, to the resource identified by URI-R. 257 Section 2 and Section 3 of this document are concerned with 258 specifying an instantiation of these abstractions for resources that 259 are identified by HTTP(S) URIs, whereas Section 4 details an approach 260 to support batch discovery of TimeGates and TimeMaps that is based on 261 well-known URI [RFC5785] and host-meta [RFC6415]. 263 1.3. Notational Conventions 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in [RFC2119]. 269 When needed for extra clarity, the following conventions are used: 271 o URI-R is used to denote the URI of an Original Resource. 273 o URI-G is used to denote the URI of a TimeGate. 275 o URI-M is used to denote the URI of a Memento. 277 o URI-T is used to denote the URI of a TimeMap. 279 o When scenarios are described that involve multiple Mementos, 280 URI-M0 denotes the URI of the first Memento known to the 281 responding server, URI-Mn denotes the URI of the most recent known 282 Memento, URI-Mj denotes the URI of the selected Memento, URI-Mi 283 denotes the URI of the Memento that is temporally previous to the 284 selected Memento, and URI-Mk denotes the URI of the Memento that 285 is temporally after the selected Memento. The respective 286 datetimes for these Mementos are T0, Tn, Tj, Ti, and Tk; it holds 287 that T0 <= Ti <= Tj <= Tk <= Tn. 289 2. The Memento Framework, Datetime Negotiation component: HTTP headers, 290 HTTP Link Relation Types 292 The Memento framework is concerned with Original Resources, 293 TimeGates, Mementos, and TimeMaps that are identified by HTTP or 294 HTTPS URIs. Details are only provided for resources identified by 295 HTTP URIs but apply similarly to those with HTTPS URIs. 297 2.1. HTTP Headers 299 The Memento framework operates at the level of HTTP request and 300 response headers. It introduces two new headers ("Accept-Datetime", 301 "Memento-Datetime"), introduces new values for two existing headers 302 ("Vary", "Link"), and uses an existing header ("Location") without 303 modification. All these headers are described below. Other HTTP 304 headers are present or absent in Memento response/request cycles as 305 specified by [RFC2616]. 307 2.1.1. Accept-Datetime, Memento-Datetime 309 The "Accept-Datetime" request header is used by a user agent to 310 indicate it wants to access a Memento that encapsulates a past state 311 of an Original Resource. To that end, the "Accept-Datetime" header 312 is conveyed in an HTTP request issued against a TimeGate for an 313 Original Resource, and its value indicates the datetime of the 314 desired past state of the Original Resource. 316 The "Memento-Datetime" response header is used by a server to 317 indicate that the response is a Memento, and its value expresses the 318 datetime of the state of an Original Resource that is encapsulated in 319 that Memento. The URI of that Original Resource is provided in the 320 response, as the Target IRI (see [RFC5988]) of a link provided in the 321 HTTP "Link" header that has a Relation Type of "original" (see 322 Section 2.2). 324 The presence of a "Memento-Datetime" header and associated value for 325 a given resource constitutes a promise that the resource is stable 326 and that its state will no longer change. This means that, in terms 327 of the Ontology for Relating Generic and Specific Information 328 Resources (see [W3C.gen-ont-20090420]), a Memento is a FixedResource. 330 As a consequence, "Memento-Datetime" headers associated with a 331 Memento MUST be "sticky" in the following ways: 333 o The server that originally assigns the "Memento-Datetime" header 334 and value MUST retain that header in all responses to HTTP 335 requests (with or without "Accept-Datetime" header) that occur 336 against the Memento after the time of the original assignment of 337 the header, and it MUST NOT change its associated value. 339 o Applications that mirror Mementos at a different URI MUST retain 340 the "Memento-Datetime" header and MUST NOT change its value unless 341 mirroring involves a meaningful state change. This allows, for 342 example, duplicating a Web archive at a new location while 343 preserving the value of the "Memento-Datetime" header of the 344 archived resources. In this example, the "Last-Modified" header 345 will be updated to reflect the time of mirroring at the new URI, 346 whereas the value for "Memento-Datetime" will be maintained. 348 2.1.1.1. Values for Accept-Datetime 350 Values for the "Accept-Datetime" header consist of a MANDATORY 351 datetime expressed according to the [RFC1123] format, which is 352 formalized by the rfc1123-date construction rule of the BNF in 353 Figure 1. The datetime MUST be represented in Greenwich Mean Time 354 (GMT). 356 Example of an "Accept-Datetime" request header: 358 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 360 The user agent uses the MANDATORY datetime value to convey its 361 preferred datetime for a Memento. 363 accept-dt-value = rfc1123-date *SP 364 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 365 date1 = 2DIGIT SP month SP 4DIGIT 366 ; day month year (e.g., 20 Mar 1957) 367 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 368 ; 00:00:00 - 23:59:59 (e.g., 14:33:22) 369 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | 370 "Sun" 371 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | 372 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 374 Figure 1: BNF for the datetime format 376 2.1.1.2. Values for Memento-Datetime 378 Values for the "Memento-Datetime" headers MUST be datetimes expressed 379 according to the rfc1123-date construction rule of the BNF in 380 Figure 1; they MUST be represented in Greenwich Mean Time (GMT). 382 An example "Memento-Datetime" response header: 384 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT 386 2.1.2. Vary 388 Generally, the "Vary" header is used in HTTP responses to indicate 389 the dimensions in which content negotiation is possible. In the 390 Memento framework, a TimeGate uses the "Vary" header with a value 391 that includes "negotiate" and "accept-datetime" to convey that 392 datetime negotation is possible. 394 For example, this use of the "Vary" header indicates that datetime is 395 the only dimension in which negotiation is possible: 397 Vary: negotiate, accept-datetime 399 The use of the "Vary" header in this example shows that both datetime 400 negotiation, and media type content negotiation are possible: 402 Vary: negotiate, accept-datetime, accept 404 2.1.3. Location 406 The "Location" header is used as defined in [RFC2616]. Examples are 407 given in Section 3 below. 409 2.1.4. Link 411 The "Link" response header is specified in [RFC5988]. The Memento 412 framework introduces new Relation Types to convey typed links among 413 Original Resources, TimeGates, Mementos, Redirecting Resources, and 414 TimeMaps. Existing Relation Types, among others, aimed at supporting 415 navigation among a series of ordered resources may also be used in 416 the Memento framework. This is detailed in the next section. 418 2.2. Link Header Relation Types 420 2.2.1. Memento Framework Relation Types 422 This section introduces the Relation Types used in the Memento 423 framework. They are defined in a general way and their use in HTTP 424 "Link" Headers is detailed. The use of these Relation Types in 425 TimeMaps and for the purpose of batch discovery is described in 426 Section 3.5 and Section 4, respectively. 428 The below table summarizes the use of Memento Relation Types in HTTP 429 "Link" headers by Original Resources, TimeGates, Mementos, and 430 Redirecting Resources. 432 Appendix A shows a Memento HTTP request/response cycle that uses all 433 the Memento Relation Types. 435 +--------+---------------+-------------+---------------+------------+ 436 | Relati | Original | TimeGate | Memento | Redirectin | 437 | on Typ | Resource | | | g Resource | 438 | e | | | | | 439 +--------+---------------+-------------+---------------+------------+ 440 | origin | NA, except | REQUIRED, 1 | REQUIRED, 1 | REQUIRED, | 441 | a l | see | | | 1 | 442 | | Section 3.1.2 | | | | 443 | | . 1 | | | | 444 | timega | RECOMMENDED, | NA | RECOMMENDED, | NA | 445 | t e | 0 or more | | 0 or more | | 446 | timema | OPTIONAL, 0 | RECOMMENDED | RECOMMENDED, | NA | 447 | p | or more | , 0 or more | 0 or more | | 448 | mement | OPTIONAL, 0 | REQUIRED, 1 | REQUIRED, 1 | NA | 449 | o | or more | or more | or more, | | 450 | | | | except see | | 451 | | | | Section 3.3.2 | | 452 | | | | . 4 | | 453 +--------+---------------+-------------+---------------+------------+ 455 Table 1: The use of Relation Types 457 2.2.1.1. Relation Type "original" 459 "original" -- A link with an "original" Relation Type is used to 460 point from a TimeGate, a Memento, or a Redirecting Resource to their 461 associated Original Resource. 463 Use in HTTP "Link" headers: A TimeGate, a Memento, and a Redirecting 464 Resource MUST include exactly one link with an "original" Relation 465 Type in their HTTP "Link" header. 467 2.2.1.2. Relation Type "timegate" 469 "timegate" -- A link with a "timegate" Relation Type is used to point 470 from the Original Resource itself, as well as from a Memento 471 associated with the Original Resource, to a TimeGate for the Original 472 Resource. 474 Use in HTTP "Link" headers: An Original Resource and a Memento SHOULD 475 include a link with a "timegate" Relation Type in their HTTP "Link" 476 header. Since multiple TimeGates can exist for any Original 477 Resource, multiple "timegate" links MAY occur, each with a distinct 478 Target IRI. 480 2.2.1.3. Relation Type "timemap" 482 "timemap" -- A link with a "timemap" Relation Type is used to point 483 from a TimeGate or a Memento associated with an Original Resource, as 484 well as from the Original Resource itself, to a TimeMap for the 485 Original Resource. 487 Attributes: A link with a "timemap" Relation Type SHOULD use the 488 "type" attribute to convey the mime type of the TimeMap 489 serialization. The "from" and "until" attributes may be used to 490 express the start and end of the temporal interval covered by 491 Mementos listed in the TimeMap. That is, the linked TimeMap will not 492 contain Mementos with archival datetimes outside of the expressed 493 temporal interval. Attemtps SHOULD be made to convey this interval 494 as accurately as possible. The value for the these attributes MUST 495 be a datetime expressed according to the rfc1123-date construction 496 rule of the BNF in Figure 1 and it MUST be represented in Greenwich 497 Mean Time (GMT). 499 Use in HTTP "Link" headers: A TimeGate and a Memento SHOULD include a 500 link with a "timemap" Relation Type in their HTTP "Link" header. 501 Multiple such links, each with a distinct Target IRI, MAY be 502 expressed as a means to point to different TimeMaps or to different 503 serializations of a same TimeMap. An Original Resource MAY include 504 one or more "timemap" link in its HTTP header. In all cases, use of 505 the "from" and "until" attributes is OPTIONAL. 507 2.2.1.4. Relation Type "memento" 509 "memento" -- A link with a "memento" Relation Type is used to point 510 from a TimeGate or a Memento for an Original Resource, as well as 511 from the Original Resource itself, to a Memento for the Original 512 Resource. 514 Attributes: A link with a "memento" Relation Type MUST include a 515 "datetime" attribute with a value that matches the "Memento-Datetime" 516 of the Memento that is the target of the link; that is, the value of 517 the "Memento-Datetime" header that is returned when the URI of the 518 linked Memento is dereferenced. The value for the "datetime" 519 attribute MUST be a datetime expressed according to the rfc1123-date 520 construction rule of the BNF in Figure 1 and it MUST be represented 521 in Greenwich Mean Time (GMT). This link MAY include a "license" 522 attribute to associate a license with the Memento; the value for the 523 "license" attribute SHOULD be a URI. 525 Use in HTTP "Link" headers: A TimeGate and a Memento MUST include 526 links in their HTTP "Link" headers with a "memento" Relation Type 527 and, for the most common case whereby a Memento is selected in a 528 response to an HTTP requests, the links MUST be as follows: 530 o One "memento" link MUST be included that has as Target IRI the URI 531 of the Memento that was selected or served; 533 o One "memento" link MUST be included that has as Target IRI the URI 534 of the temporally first Memento known to the responding server; 536 o One "memento" link MUST be included that has as Target IRI the URI 537 of the temporally most recent Memento known to the responding 538 server. 540 o One "memento" link SHOULD be included that has as Target IRI the 541 URI of the Memento that is previous to the selected Memento in the 542 temporal series of all Mementos (sorted by ascending "Memento- 543 Datetime" values) known to the server; 545 o One "memento" link SHOULD be included that has as Target IRI the 546 URI the Memento that is next to the selected Memento in the 547 temporal series of all Mementos (sorted by ascending "Memento- 548 Datetime" values) known to the server. 550 o Other "memento" links MAY only be included if both the 551 aforementioned previous and next links are provided. Each of 552 these OPTIONAL "memento" links MUST have as Target IRI the URI of 553 a Memento other than the ones listed above. 555 Note that the Target IRI of some of these links may coincide. For 556 example, if the selected Memento actually is the first Memento known 557 to the server, only three distinct "memento" links may result. The 558 value for the "datetime" attribute of these links would be the 559 datetimes of the first (equal to selected), next, and most recent 560 Memento known to the responding server. 562 The use of the "memento" Relation Types for special cases whereby no 563 Memento is selected is described in Section 3.2.2.5, Section 3.2.2.6, 564 Section 3.3.2.4, and Section 3.3.2.5. 566 2.2.2. Other Relation Types 568 Web Linking [RFC5988] allows for the inclusion of links with 569 different Relation Types but the same Target IRI, and hence the 570 Relation Types introduced by the Memento framework MAY be combined 571 with others as deemed necessary. As the "memento" Relation Type 572 focuses on conveying the datetime of a linked Memento, Relation Types 573 that allow navigating among the temporally ordered series of Mementos 574 known to a server are of particular importance. With this regard, 575 the Relation Types listed in the below table SHOULD be considered for 576 combination with the "memento" Relation Type. A distinction is made 577 between responding servers that can be categorized as systems that 578 are the focus of [RFC5829] (such as version control systems) and 579 others that can not (such as Web archives). Note that, in terms of 580 [RFC5829], the last Memento (URI-Mn) is the version prior to the 581 latest (i.e. current) version. 583 +-----------------------------+---------------------+---------------+ 584 | Memento Type | RFC5829 system | non RFC5829 | 585 | | | system | 586 +-----------------------------+---------------------+---------------+ 587 | First Memento (URI-M0) | first | first | 588 | Last Memento (URI-Mn) | last | last | 589 | Selected Memento (URI-Mj) | NA | NA | 590 | Memento prior to selected | predecessor-version | prev | 591 | Memento (URI-Mi) | | | 592 | Memento next to selected | successor-version | next | 593 | Memento (URI-Mk) | | | 594 +-----------------------------+---------------------+---------------+ 596 Table 2: The use of Relation Types 598 3. The Memento Framework, Datetime Negotiation component: HTTP 599 Interactions 601 This section describes the HTTP interactions of the Memento framework 602 for a variety of scenarios. First, Figure 2 provides a schematic 603 overview of a successful request/response chain that involves 604 datetime negotiation. Dashed lines depict HTTP transactions between 605 user agent and server. Appendix A shows these HTTP interactions in 606 detail for the case where the Original Resource resides on one 607 server, whereas both the TimeGate and the Mementos reside on another. 608 Scenarios also exist in which all these resources are on the same 609 server (for example, Content Management Systems) or on different 610 servers (for example, an aggregator of TimeGates). Note that, in 611 Step 2 and Step 6, the HTTP status code of the response is shown as 612 "200 OK", but a series of "206 Partial Content" responses could be 613 substituted without loss of generality. 615 1: UA --- HTTP HEAD/GET; Accept-Datetime: Tj ---------------> URI-R 616 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R 617 3: UA --- HTTP HEAD/GET; Accept-Datetime: Tj ---------------> URI-G 618 4: UA <-- HTTP 302; Location: URI-Mj; Vary; Link: 619 URI-R,URI-T,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -------- URI-G 620 5: UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------------> URI-Mj 621 6: UA <-- HTTP 200; Memento-Datetime: Tj; Link: 622 URI-R,URI-T,URI-G,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -- URI-Mj 624 Figure 2: Typical Memento request/response chain 626 o Step 1: In order to discover the URI of a TimeGate for an Original 627 Resource, the user agent issues an HTTP HEAD/GET request against 628 the URI of the Original Resource (URI-R). 630 o Step 2: The response from URI-R includes an HTTP "Link" header 631 with a Relation Type of "timegate" pointing at a TimeGate for the 632 Original Resource (URI-G). 634 o Step 3: The user agent starts the datetime negotiation process 635 with the TimeGate by issuing an HTTP GET request against its URI-G 636 thereby including an "Accept-Datetime" HTTP header with a value of 637 the datetime of the desired prior state of the Original Resource. 639 o Step 4: The response from URI-G includes a "Location" header 640 pointing at the URI of a Memento for the Original Resource 641 (URI-Mj). In addition, the response contains an HTTP "Link" 642 header with a Relation Type of "original" pointing at the Original 643 Resource, and an HTTP "Link" header with a Relation Type of 644 "timemap" pointing at a TimeMap (URI-T). Also HTTP Links pointing 645 at various Mementos are provided using the "memento" Relation 646 Type, as specified in Section 2.2.1.4. 648 o Step 5: The user agent issues an HTTP GET request against the URI 649 of the Memento obtained in Step 4 (URI-Mj). 651 o Step 6: The response from URI-Mj includes a "Memento-Datetime" 652 HTTP header with a value of the datetime of the Memento. It also 653 contains an HTTP "Link" header with a Relation Type of "original" 654 pointing at the Original Resource, with a Relation Type of 655 "timegate" pointing at a TimeGate associated with the Original 656 Resource, and with a Relation Type of "timemap" pointing at a 657 TimeMap. The state that is expressed by the response is the state 658 the Original Resource had at the datetime expressed in the 659 "Memento-Datetime" header. This response also includes HTTP Links 660 with a "memento" Relation Type pointing at various Mementos, as 661 specified in Section 2.2.1.4. 663 The following sections detail the specifics of HTTP interactions with 664 Original Resources, TimeGates, Mementos, and TimeMaps under various 665 conditions. 667 3.1. Interactions with an Original Resource 669 This section details HTTP HEAD/GET requests targeted at an Original 670 Resource (URI-R). 672 3.1.1. Step 1: User Agent Requests an Original Resource 674 In order to attempt to discover the recommended TimeGate for the 675 Original Resource, the user agent SHOULD issue an HTTP HEAD or GET 676 request against the Original Resource's URI. Use of the "Accept- 677 Datetime" header in the HTTP HEAD/GET request is OPTIONAL. 679 Figure 3 shows the use of HTTP HEAD to determine a TimeGate for the 680 Original Resource http://a.example.org. 682 HEAD / HTTP/1.1 683 Host: a.example.org 684 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 685 Connection: close 687 Figure 3: User Agent Requests Original Resource 689 3.1.2. Step 2: Server Responds to a Request for an Original Resource 691 The response of the Original Resource's server to the user agent's 692 HTTP HEAD/GET request of Step 1, for the case where the Original 693 Resource exists, is as it would be in a regular HTTP request/response 694 cycle, but in addition MAY include a "timegate" link in the HTTP 695 "Link" header that conveys the URI of the Original Resource's 696 TimeGate as the Target IRI of the link. Multiple "timegate" links 697 MAY be provided to accommodate situations in which the server is 698 aware of multiple TimeGates for an Original Resource. The presence 699 or abscence of an "Accept-Datetime" header in a user agent's HTTP 700 request MUST NOT influence the presence or abscence of a "timegate" 701 link in the HTTP "Link" header of the server's response. A response 702 for this case is illustrated in Figure 4. 704 HTTP/1.1 200 OK 705 Date: Thu, 21 Jan 2010 00:02:12 GMT 706 Server: Apache 707 Link: 708 ; rel="timegate" 709 Content-Length: 255 710 Connection: close 711 Content-Type: text/html; charset=iso-8859-1 713 Figure 4: Server of Original Resource Responds 715 Servers that actively maintain archives of their resources SHOULD 716 include the "timegate" HTTP "Link" header because this link is an 717 important way for a user agent to discover TimeGates for those 718 resources. This includes servers such as Content Management Systems, 719 Control Version Systems, and Web servers with associated 720 transactional archives [Fitch]. Servers that do not actively 721 maintain archives of their resources MAY include the "timegate" HTTP 722 "Link" header as a way to convey a preference for TimeGates for their 723 resources exposed by a third party archive. This includes servers 724 that rely on Web archives such as the Internet Archive to archive 725 their resources. 727 3.1.2.1. Original Resource is an Appropriate Memento 729 The "Memento-Datetime" header MAY be applied to an Original Resource 730 directly to indicate it is a FixedResource (see 731 [W3C.gen-ont-20090420]), meaning that the state of the Original 732 Resource has not changed since the datetime conveyed in the "Memento- 733 Datetime" header, and as a promise that it will not change anymore 734 beyond it. This may occur, for example, for certain stable media 735 resources on news sites. In case the user agent's preferred datetime 736 is equal to or more recent than the datetime conveyed as the value of 737 "Memento-Datetime" in the server's response in Step 2, the user agent 738 SHOULD conclude it has located an appropriate Memento, and it SHOULD 739 NOT continue to Step 3. 741 Figure 5 illustrates such a response to a request for the resource 742 with URI http://a.example.org/pic that has been stable since it was 743 created. Note the use of both the "memento" and "original" Relation 744 Types for links that have as Target IRI the URI of the Original 745 Resource. 747 HTTP/1.1 200 OK 748 Date: Thu, 21 Jan 2010 00:02:12 GMT 749 Server: Apache 750 Link: 751 752 ; rel="original memento" 753 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT" 754 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT 755 Content-Length: 255 756 Connection: close 757 Content-Type: text/html; charset=iso-8909-1 759 Figure 5: Response to a request for an Original Resource that was 760 created as a FixedResource 762 Cases may also exist in which a resource becomes stable at a certain 763 point in its existence, but changed previously. In such cases, the 764 Original Resource may know about a TimeGate that is aware of its 765 prior history and hence MAY also include a link with a "timegate" 766 Relation Type in addition to the previously mentioned links with 767 "original" and "memento" Relation Types. 769 3.1.2.2. Server Exists and Original Resource Used to Exist 771 Servers SHOULD also provide a "timegate" link in the HTTP "Link" 772 header in responses to requests for an Original Resource that the 773 server knows used to exist, but no longer does so. This allows the 774 use of an Original Resource's URI as an entry point to its prior 775 states even if the resource itself no longer exists. A server's 776 response for this case is illustrated in Figure 6. 778 HTTP/1.1 404 Not Found 779 Date: Thu, 21 Jan 2010 00:02:12 GMT 780 Server: Apache 781 Link: 782 783 ; rel="timegate" 784 Content-Length: 255 785 Connection: close 786 Content-Type: text/html; charset=iso-8909-1 787 Figure 6: Response to a request for an Original Resource that not 788 longer exists 790 In case the server is not aware of the prior existence of the 791 Original Resource, its response SHOULD NOT include a "timegate" link 792 in the HTTP "Link" header. Section 3.1.2.3 details what the user 793 agent's behavior should be in such cases. 795 3.1.2.3. Missing "timegate" Link in Original Server's Response 797 When engaging in a Memento request/response cycle, a user agent 798 SHOULD NOT proceed immediately to Step 3 by using a TimeGate of its 799 own preference but rather SHOULD always start the cycle by issuing an 800 HTTP HEAD/GET against the Original Resource (Step 1, Figure 3) as it 801 is an important way to learn about dedicated or preferred TimeGates 802 for the Original Resource. Also, cases exist in which the response 803 in Step 2 will not provide a "timegate" link in the HTTP "Link" 804 header, including: 806 o The Original Resource's server does not support the Memento 807 framework; 809 o The Original Resource no longer exists and the responding server 810 is not aware of its prior existence; 812 o The server that hosted the Original Resource no longer exists; 814 In all these cases, the user agent SHOULD attempt to determine an 815 appropriate TimeGate for the Original Resource, either automatically 816 or interactively supported by the user. The discovery mechanisms 817 described in Section 4 can support the user agent with this regard. 819 3.2. Interactions with a TimeGate 821 This section details HTTP HEAD/GET requests targeted at a TimeGate 822 (URI-G). 824 3.2.1. Step 3: User Agent Negotiates with a TimeGate 826 In order to negotiate in the datetime dimension with a TimeGate, the 827 user agent MUST issue an HTTP request with the "Accept-Datetime" 828 header, as described in Section 2.1.1.1. This is illustrated in 829 Figure 7. 831 GET /timegate/http://a.example.org HTTP/1.1 832 Host: arxiv.example.net 833 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 834 Connection: close 836 Figure 7: User agent negotiates with TimeGate 838 3.2.2. Step 4: Server Responds to Negotiation with TimeGate 840 In order to respond to a datetime negotiation request (Step 3, 841 Section 3.2.1), the server uses an internal algorithm to select the 842 Memento that best meets the user agent's datetime preference, and 843 redirects to it. The exact nature of the selection algorithm is at 844 the server's discretion but SHOULD be consistent. A variety of 845 approaches can be used including selecting the Memento that is 846 nearest in time (either past or future) or nearest in the past 847 relative to the requested datetime. The most common scenario for 848 datetime negotiation with a TimeGate is described in Section 3.2.2.1 849 but special cases exist, and they are addressed in Section 3.2.2.2 850 through Section 3.2.2.7. 852 It is NOT RECOMMENDED to implement TimeGates such that they coincide 853 with their associated Original Resource, i.e. URI-R and URI-G are 854 the same. Doing so may cause cache invalidation problems and confuse 855 Memento clients. 857 3.2.2.1. Successful Scenario 859 In cases where the TimeGate exists, and the datetime provided in the 860 user agent's "Accept-Datetime" header can be parsed, the server 861 selects a Memento based on the user agent's datetime preference. The 862 response MUST have a "302 Found" HTTP status code, and the "Location" 863 header MUST be used to convey the URI of the selected Memento. The 864 "Vary" header MUST be provided and it MUST include the "negotiate" 865 and "accept-datetime" values. The "Link" header MUST be provided and 866 contain links with Relation Types subject to the considerations 867 described in Section 2.2. The response MUST NOT contain a "Memento- 868 Datetime" header. Such a response is illustrated in Figure 8. 870 If a user agent's "Accept-Datetime" header conveys a datetime that is 871 either earlier than the datetime of the first Memento or later than 872 the datetime of the most recent Memento known to the server, the 873 server's response is as just described yet entails the selection of 874 the first or most recent Memento, respectively. 876 HTTP/1.1 302 Found 877 Date: Thu, 21 Jan 2010 00:06:50 GMT 878 Server: Apache 879 Vary: negotiate, accept-datetime 880 Location: 881 http://arxiv.example.net/web/20010911203610/http://a.example.org 882 Link: ; rel="original", 883 884 ; rel="timemap"; type="application/link-format" 885 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 886 ; until="Tue, 08 Jul 2008 09:34:33 GMT", 887 888 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 889 890 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 891 892 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT", 893 894 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT", 895 896 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT" 897 Content-Length: 0 898 Content-Type: text/plain; charset=UTF-8 899 Connection: close 901 Figure 8: Server of TimeGate responds 903 3.2.2.2. Multiple Matching Mementos 905 Because the finest datetime granularity expressible using the 906 [RFC1123] format used in HTTP is seconds level, cases may occur in 907 which a TimeGate server is aware of multiple Mementos that meet the 908 user agent's datetime preference. This may occur in Content 909 Management Systems with very high update rates. The response in this 910 case MUST be handled as in Section 3.2.2.1, with the selection of one 911 of the matching Mementos. 913 3.2.2.3. Accept-Datetime and other Accept Headers Provided 915 When interacting with a TimeGate, the regular content negotiation 916 dimensions (media type, character encoding, language, and 917 compression) remain available. It is the TimeGate server's 918 responsibility to honor (or not) such content negotiation, and in 919 doing so it MUST always first select a Memento that meets the user 920 agent's datetime preference, and then consider honoring regular 921 content negotiation for it. As a result of this approach, the 922 returned Memento will not necessarily meet the user agent's regular 923 content negotiation preferences. Therefore, it is RECOMMENDED that 924 the server provides "memento" links in the HTTP "Link" header 925 pointing at Mementos that do meet the user agent's regular content 926 negotiation requests and that have a value for the "Memento-Datetime" 927 header in the temporal vicinity of the user agent's preferred 928 datetime value. 930 3.2.2.4. Accept-Datetime Not Provided 932 In case, in Step 3, a user agent issues a request to a TimeGate and 933 fails to include an "Accept-Datetime" request header, the response 934 MUST be handled as in Section 3.2.2.1, with a selection of the most 935 recent Memento known to the responding server. 937 3.2.2.5. Accept-Datetime Unparseable 939 In case, in Step 3, a user agent conveys a value for the "Accept- 940 Datetime" request header that does not conform to the accept-dt-value 941 construction rule of the BNF in Figure 1, the TimeGate server's 942 response MUST have a "400 Bad Request" HTTP status code. The use of 943 the "Vary" header MUST be as described in Section 3.2.2.1. The use 944 of entries in the "Link" header with "original", "timegate", and 945 "timemap" Relation Types MUST be as described in Section 2.2. 946 Entries with the "memento" Relation Type MUST be provided to only 947 point to the first and most recent Mementos. 949 3.2.2.6. TimeGate Does Not Exist 951 Cases may occur in which a user agent issues a request against a 952 TimeGate that does not exist. This may, for example, occur when a 953 user agent uses internal knowledge to construct the URI of an 954 assumed, yet non-existent TimeGate. In these cases, the response 955 from the target server MUST have a "404 Not Found" HTTP status code. 956 The response MUST NOT include a "Link" header with any of the 957 Relation Types introduced in Section 2.2.1, and it MUST NOT contain a 958 "Memento-Datetime" header. 960 3.2.2.7. HTTP Methods other than HEAD/GET 962 It is intended that the safe HTTP methods GET and HEAD are used with 963 TimeGates, and other methods are currently undefined. A TimeGate 964 MUST respond to unsupported HTTP methods with a "405 Method Not 965 Allowed" HTTP status code. 967 3.2.3. Recognizing a TimeGate 969 When a user agent issues a HTTP HEAD/GET request against the URI of 970 an assumed TimeGate for an Original Resource (e.g. the URI is the 971 Target IRI of a "timegate" link), it SHOULD NOT conclude that the 972 targeted resource effectively is a TimeGate and hence will behave as 973 described in Section 3.2.2. 975 A user agent MUST decide it has reached a TimeGate if the response to 976 a HTTP HEAD/GET request against the resource's URI contains a "Vary" 977 header that includes the "negotiate" and "accept-datetime" values. 978 If the response does not, the user agent MUST decide it has not 979 reached a TimeGate and proceed as follows: 981 o If the response contains a redirection that includes an "original" 982 link in the HTTP "Link" header, the agent MUST conclude it has 983 reached a Redirecting Resource that is part of the Memento 984 infrastructure and SHOULD follow the redirect. Note that a chain 985 of such redirections is possible, e.g. URI-R -> URI-1 (with 986 rel="original") -> URI-2 (with rel="original") -> ... -> URI-G 988 o If the response does not contain a redirection, or if the 989 redirection does not have an "original" link in the HTTP "Link" 990 header, the user agent SHOULD attempt to determine an appropriate 991 TimeGate for the Original Resource, either automatically or 992 interactively supported by the user. The discovery mechanisms 993 described in Section 4 can support the user agent with this 994 regard. 996 3.3. Interactions with a Memento 998 This section details HTTP HEAD/GET requests targeted at a Memento 999 (URI-M). 1001 3.3.1. Step 5: User Agent Requests a Memento 1003 In Step 5, the user agent issues an HTTP GET request against the URI 1004 of a Memento. The user agent MAY include an "Accept-Datetime" header 1005 in this request, but the existence or absence of this header MUST NOT 1006 affect the server's response. The URI of the Memento may have 1007 resulted from a response in Step 4, or the user agent may simply have 1008 happened upon it. Such a request is illustrated in Figure 9. 1010 GET /web/20010911203610/http://a.example.org HTTP/1.1 1011 Host: arxiv.example.net 1012 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 1013 Connection: close 1015 Figure 9: User agent requests Memento 1017 3.3.2. Step 6: Server Responds to a Request for a Memento 1019 This section describes possible responses to a request for a Memento. 1020 Section 3.3.2.1 discusses the most common scenario. Section 3.3.2.2 1021 through Section 3.3.2.4 detail special cases whereby Mementos are 1022 archived copies of HTTP responses with 3xx, 4xx and 5xx status codes. 1024 3.3.2.1. Common Scenario 1026 If the Memento requested by the user agent in Step 5 exists, and is 1027 not a special Memento as described in Section 3.3.2.2 and 1028 Section 3.3.2.2, the server's response MUST have a "200 OK" HTTP 1029 status code or, where appropriate "206 Partial Content". It MUST 1030 include a "Memento-Datetime" header with a value equal to the 1031 archival datetime of the Memento, that is, the datetime of the state 1032 of the Original Resource that is encapsulated in the Memento. The 1033 "Link" header MUST be provided and contain links subject to the 1034 considerations described in Section 2.2. 1036 Figure 10 illustrates the server's response to the request issued 1037 against a Memento in Step 5 (Figure 9). 1039 HTTP/1.1 200 OK 1040 Date: Thu, 21 Jan 2010 00:09:40 GMT 1041 Server: Apache-Coyote/1.1 1042 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1043 Link: ; rel="original", 1044 1045 ; rel="timemap"; type="application/link-format" 1046 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 1047 ; until="Tue, 08 Jul 2008 09:34:33 GMT", 1048 1049 ; rel="timegate", 1050 1051 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1052 1053 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1054 1055 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT", 1056 1057 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT", 1058 1059 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT" 1060 Content-Length: 23364 1061 Content-Type: text/html;charset=utf-8 1062 Connection: close 1064 Figure 10: Server of Memento responds 1066 The server's response MUST include the "Memento-Datetime" header 1067 regardless whether the user agent's request contained an "Accept- 1068 Datetime" header or not. This is the way by which resources make 1069 explicit that they are Mementos. Due to the sparseness of Mementos 1070 in most archives, the value of the "Memento-Datetime" header returned 1071 by a server may differ (significantly) from the value conveyed by the 1072 user agent in "Accept-Datetime". 1074 Although a Memento encapsulates a prior state of an Original 1075 Resource, the entity-body returned in response to an HTTP GET request 1076 issued against a Memento may very well not be byte-to-byte the same 1077 as an entity-body that was previously returned by that Original 1078 Resource. Various reasons exist why there are significant chances 1079 these would be different yet do convey substantially the same 1080 information. These include format migrations as part of a digital 1081 preservation strategy, URI-rewriting as applied by some Web archives, 1082 and the addition of banners as a means to brand Web archives. 1084 3.3.2.2. Memento of a 3XX Response 1086 Cases exist in which HTTP responses with 3XX status codes are 1087 archived. For example, crawl-based web archives commonly archive 1088 responses with HTTP status codes "301 Moved Permanently" and "302 1089 Found" whereas Linked Data archives hold on to "303 See Other" 1090 responses. 1092 If the Memento requested by the user agent is an archived version of 1093 an HTTP response with a 3XX status code, the server's response MUST 1094 have the same 3XX HTTP status code, and it MUST include a "Memento- 1095 Datetime" header with a value equal to the archival datetime of the 1096 original 3XX response. All other considerations, e.g. pertaining to 1097 the use of "Link" header, expressed in Section 3.3.2.1 apply. 1099 The client's handling of an HTTP response with a 3XX status code is 1100 not affected by the presence of a "Memento-Datetime" header. The 1101 client SHOULD behave in the same manner as it does with HTTP 1102 responses with a 3XX status code that do not have a "Memento- 1103 Datetime" header. 1105 However, the client MUST be aware that the URI that was selected from 1106 the "location" header of an HTTP response with a 3XX status code 1107 might not be that of a Memento but rather of an Original Resource. 1108 In that case it SHOULD proceed by looking for a Memento of the 1109 selected Original Resource. 1111 For example, Figure 11 shows the response to an HTTP GET request for 1112 http://a.example.org issued on April 11 2008. This response is 1113 archived as a Memento of http://a.example.org, and this Memento's URI 1114 is http://arxiv.example.net/web/20080411000650/http://a.example.org. 1115 The response to an HTTP GET on this Memento is shown in Figure 12. 1116 In essence, it is a replay of the original response with "Memento- 1117 Datetime" and "Link" headers added, to allow a client to understand 1118 the response is a Memento. In Figure 12, the value of the "Location" 1119 header is the same as in the original response; it identifies an 1120 Original Resource. The client proceeds with finding a Memento for 1121 this Original Resource. Web archives sometimes overwrite the value 1122 that was originally provided in the "Location" header in order to 1123 point at a Memento they hold of the resource to which the redirect 1124 originally led. This is shown in Figure 13. In this case, the 1125 client may decide it found an appropriate Memento. 1127 HTTP/1.1 301 Moved Permanently 1128 Date: Fri, 11 Apr 2008 00:06:50 GMT 1129 Server: Apache 1130 Location: http://b.example.org 1131 Content-Length: 0 1132 Content-Type: text/plain; charset=UTF-8 1133 Connection: close 1135 Figure 11: Response to the User Agent Request is a Redirect 1137 HTTP/1.1 301 Moved Permanently 1138 Date: Thu, 21 Jan 2010 00:09:40 GMT 1139 Server: Apache-Coyote/1.1 1140 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1141 Location: http://b.example.org 1142 Link: ; rel="original", 1143 1144 ; rel="timemap"; type="application/link-format", 1145 1146 ; rel="timegate", 1147 1148 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1149 1150 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1151 1152 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT", 1153 1154 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT", 1155 1156 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT" 1157 Content-Length: 0 1158 Content-Type: text/plain; charset=UTF-8 1159 Connection: close 1161 Figure 12: Response to a User Agent Request for a Memento of a 1162 Redirect; leads to an Original Resource 1164 HTTP/1.1 301 Moved Permanently 1165 Date: Thu, 21 Jan 2010 00:09:40 GMT 1166 Server: Apache-Coyote/1.1 1167 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1168 Location: 1169 http://arxiv.example.net/web/20080411000655/http://b.example.org 1170 Link: ; rel="original", 1171 1172 ; rel="timemap"; type="application/link-format", 1173 1174 ; rel="timegate", 1175 1176 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1177 1178 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1179 1180 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT", 1181 1182 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT", 1183 1184 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT" 1185 Content-Length: 0 1186 Content-Type: text/plain; charset=UTF-8 1187 Connection: close 1189 Figure 13: Response to a User Agent Request for a Memento of a 1190 Redirect; leads to a Memento 1192 3.3.2.3. Memento of Responses with Other HTTP Status Codes 1194 Cases exist in which responses with 4xx and 5xx HTTP status codes are 1195 archived. If the Memento requested by the user agent is an archived 1196 version of such an HTTP response, the server's response MUST have the 1197 same 4xx or 5xx HTTP status code, and it MUST include a "Memento- 1198 Datetime" header with a value equal to the archival datetime of the 1199 original response. All other considerations, e.g. pertaining to the 1200 use of "Link" header, expressed in Section 3.3.2.1 apply. 1202 For example, Figure 14 shows the 404 response to an HTTP GET request 1203 for http://a.example.org issued on April 11 2008. This response is 1204 archived as a Memento of http://a.example.org, and this Memento's URI 1205 is http://arxiv.example.net/web/20080411000650/http://a.example.org. 1206 The response to an HTTP HEAD/GET on this Memento is shown in 1207 Figure 15. It is a replay of the original response with "Memento- 1208 Datetime" and "Link" headers added, to allow a client to understand 1209 the response is a Memento. 1211 HTTP/1.1 404 Not Found 1212 Date: Fri, 11 Apr 2008 00:06:50 GMT 1213 Server: Apache 1214 Content-Length: 0 1215 Content-Type: text/plain; charset=UTF-8 1216 Connection: close 1218 Figure 14: Response to the User Agent Request is a 404 1220 HTTP/1.1 404 Not Found 1221 Date: Thu, 21 Jan 2010 00:09:40 GMT 1222 Server: Apache-Coyote/1.1 1223 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1224 Link: ; rel="original", 1225 1226 ; rel="timemap"; type="application/link-format", 1227 1228 ; rel="timegate", 1229 1230 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1231 1232 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1233 1234 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT", 1235 1236 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT", 1237 1238 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT" 1239 Content-Length: 0 1240 Content-Type: text/plain; charset=UTF-8 1241 Connection: close 1243 Figure 15: Response to a User Agent Request for a Memento of a 404 1244 Response 1246 3.3.2.4. Mementos Without a TimeGate 1248 Cases may occur in which a server that hosts Mementos does not expose 1249 a TimeGate for those Mementos. This can, for example, be the case if 1250 the server's Mementos result from taking a snapshot of the state of a 1251 set of Original Resources from another server at the time this other 1252 server is being retired. As a result, only a single Memento per 1253 Original Resource is hosted, making the introduction of a TimeGate 1254 unnecessary. But it may also be the case for servers that hosts 1255 multiple Mementos for an Original Resource but consider exposing 1256 TimeGates too expensive. 1258 In cases of Mementos without associated TimeGates, responses to a 1259 request for a Memento by a user agent MUST contain a "Memento- 1260 Datetime" response header with a value that corresponds to archival 1261 datetime of the Memento. The use of an HTTP "Link" header to convey 1262 Memento Relation Types is OPTIONAL. 1264 Figure 16 illustrates the server's response to the request issued 1265 against a Memento in Step 5 (Figure 9) for the case that Memento has 1266 no associated TimeGate. In this example, it is also assumed there is 1267 only one Memento for the Original Resource, and hence the links with 1268 Relation Types "memento", "first", "last" all point at the same - 1269 responding - Memento. 1271 HTTP/1.1 200 OK 1272 Date: Thu, 21 Jan 2010 00:09:40 GMT 1273 Server: Apache-Coyote/1.1 1274 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1275 Link: ; rel="original", 1276 1277 ; rel="first last memento" 1278 ; datetime="Tue, 15 Sep 2000 11:28:26 GMT" 1279 Content-Length: 23364 1280 Content-Type: text/html;charset=utf-8 1281 Connection: close 1283 Figure 16: Server of Memento without TimeGate responds 1285 Note that a server issuing a response similar to that of Figure 16 1286 does not imply that there is no server whatsoever that exposes a 1287 TimeGate; it merely means that the responding server neither provides 1288 nor is aware of the location of a TimeGate. 1290 3.3.2.5. Memento Does not Exist 1292 Cases may occur in which a TimeGate's response (Step 4) points at a 1293 Memento that actually does not exist, resulting in a user agent's 1294 request (Step 5) for a non-existent Memento. In this case, the 1295 server's response MUST have the expected "404 Not Found" HTTP Status 1296 Code and it MUST NOT contain a "Memento-Datetime" header. Note that 1297 the absence of a Memento in an archive is distinct from the case of 1298 an archived response with a "404 Not Found" HTTP status code as is 1299 described in Section 3.3.2.3 1301 3.3.3. Recognizing a Memento 1303 When following the redirection provided by a confirmed TimeGate (see 1304 Section 3.2.3), a user agent SHOULD NOT assume that the targeted 1305 resource effectively is a Memento and hence will behave as described 1306 in Section 3.3.2. 1308 A user agent MUST decide it has reached a Memento if the response to 1309 an HTTP request against the targeted resource's URI contains a 1310 "Memento-Datetime" header with a legitimate value. If the response 1311 does not, the following applies: 1313 o If the response contains a redirection that includes an "original" 1314 link in the HTTP "Link" header, the user agent MUST conclude it 1315 has reached a Redirecting Resource that is part of the Memento 1316 infrastructure and SHOULD follow the redirect. Note that a chain 1317 of such redirections is possible, e.g. URI-G -> URI-1 (with 1318 rel="original") -> URI-2 (with rel="original") -> ... -> URI-M 1320 o If the response contains no redirection or if a redirection 1321 (chain) does not lead to a resource that provides a "Memento- 1322 Datetime" header, the user agent SHOULD attempt to determine an 1323 appropriate TimeGate for the Original Resource, either 1324 automatically or interactively supported by the user. The 1325 discovery mechanisms described in Section 4 can support the user 1326 agent with this regard. 1328 3.4. Interactions with a Redirecting Resource 1330 A Redirecting Resource is a resource that issues a redirect to a 1331 TimeGate, to a Memento, or to another Redirecting Resource, and thus 1332 plays an active role in the Memento infrastructure. An example of a 1333 Redirecting Resource is a resource that acts as a front-end to 1334 multiple TimeGates and redirects to an appropriate TimeGate based on 1335 the value of the user agent's "Accept-Datetime" header. 1337 A user agent MUST decide that it has reached a Redirecting Resource 1338 if the response to an HTTP GET issued against the resource's URI has 1339 an HTTP status code indicative of redirection, has an "original" link 1340 in the HTTP "Link" header, yet does not have a "Memento-Datetime" nor 1341 "Vary" header. A user agent SHOULD follow the redirection provided 1342 by a Redirecting Resource. 1344 If, for example, a user agent follows a link to an assumed TimeGate 1345 and attempts the datetime negotiation illustrated in Figure 7, it 1346 will expect a response from a TimeGate, which must include a "Vary" 1347 header. Instead, it receives the response shown in Figure 17. This 1348 response has an HTTP "302 Found" status code, neither a "Vary" nor 1349 "Memento-Datetime" header, yet it does have an "original" link in the 1350 HTTP "Link" header pointing at the Original Resource, indicating it 1351 is a Redirecting Resource. 1353 HTTP/1.1 302 Found 1354 Date: Thu, 21 Jan 2010 00:06:50 GMT 1355 Server: Apache 1356 Location: 1357 http://arxiv.example.net/new-timegate/http://a.example.org 1358 Link: ; rel="original" 1359 Content-Length: 0 1360 Content-Type: text/plain; charset=UTF-8 1361 Connection: close 1363 Figure 17: Redirecting Resource redirects to a TimeGate 1365 3.5. Interactions with a TimeMap 1367 A TimeMap is introduced to support retrieving a comprehensive list of 1368 all Mementos for a specific Original Resource known to a responding 1369 server. The entity-body of a response to an HTTP GET request issued 1370 against a TimeMap's URI: 1372 o MUST list the URI of the Original Resource that the TimeMap is 1373 about; 1375 o MUST preferably list the URI and datetime of each Memento for the 1376 Original Resource known to the responding server, or, 1377 alternatively support assembling such a list by following links 1378 with a "timemap" Relation Type provided in the TimeMap; 1380 o SHOULD list the URI of one or more TimeGates for the Original 1381 Resource known to the responding server; 1383 o SHOULD, for self-containment, list the URI of the TimeMap itself; 1385 o MUST unambiguously type listed resources as being Original 1386 Resource, TimeGate, Memento, or TimeMap. 1388 The entity-body of a response from a TimeMap MAY be serialized in 1389 various ways, but the link-value format serialization MUST be 1390 supported. In this serialization, the entity-body MUST be formatted 1391 in the same way as the value of an HTTP "Link" header, and hence MUST 1392 comply to the "link-value" construction rule of "Section 5. The Link 1393 Header Field" of [RFC5988], and the media type of the entity-body 1394 MUST be "application/link-format" as introduced in [RFC6690]. Links 1395 contained in the entity-body MUST be interpreted as follows: 1397 o The Context IRI is set to the anchor parameter, when specified; 1399 o The Context IRI of links with the "self" Relation Types is the URI 1400 of the TimeMap, i.e. the URI of the resource from which the 1401 TimeMap was requested; 1403 o The Context IRI of all other links is the URI of the Original 1404 Resource, which is provided as the Target IRI of the link with an 1405 "original" Relation Type. 1407 3.5.1. User Agent Requests a TimeMap 1409 In order to retrieve the link-value serialization of a TimeMap, a 1410 user agent SHOULD use an "Accept" request header with a value set to 1411 "application/link-format". This is shown in Figure 18. 1413 GET /timemap/http://a.example.org HTTP/1.1 1414 Host: arxiv.example.net 1415 Accept: application/link-format;q=1.0 1416 Connection: close 1418 Figure 18: Request for a TimeMap 1420 3.5.2. Server Responds to a Request for a TimeMap 1422 If the TimeMap requested by the user agent exists, the server's 1423 response MUST have a "200 OK" HTTP status code (or "206 Partial 1424 Content", where appropriate). Note that a TimeMap is itself an 1425 Original Resource for which Mementos may exist. For example, a 1426 response from a TimeMap could provide a "timegate" Link to a TimeGate 1427 via which prior TimeMap versions are available. In this case, the 1428 use of the "Link" header is subject to all considerations described 1429 in Section 2.2, with the TimeMap acting as the Original Resource. 1431 However, in case a TimeMap wants to explicitly indicate in its 1432 response headers for which Original Resource it is a TimeMap, it MUST 1433 do so by including an HTTP "Link" header with the following 1434 characteristics: 1436 o The Context IRI for the HTTP Link is the URI of the Original 1437 Resource; 1439 o The Relation Type is "timemap"; 1441 o The Target IRI for the HTTP Link is the URI of the TimeMap. 1443 Because the Context IRI of this HTTP Link is not the URI of the 1444 TimeMap, as per [RFC5988], the default Context IRI must be 1445 overwritten by using the "anchor" attribute with a value of the URI 1446 of the Original Resource. 1448 The response from the TimeMap to the request of Figure 18 is shown in 1449 Figure 19. The response header shows the TimeMap explicitly 1450 conveying the URI of the Original Resource for which it is a TimeMap; 1451 for practical reasons the entity-body in the example has been 1452 abbreviated. Note the use of the "self" Relation Type to express the 1453 URI of the TimeMap itself. Note also the use of the "from" and 1454 "until" attributes on that link to express the datetime of the 1455 earliest and most recent Memento listed in the TimeMap. And, note 1456 the use of the "license" attribute introduced in Section 2.2.1.4 on 1457 the "memento" links in the TimeMap. 1459 HTTP/1.1 200 OK 1460 Date: Thu, 21 Jan 2010 00:06:50 GMT 1461 Server: Apache 1462 Link: 1463 ; anchor="http://a.example.org"; rel="timemap" 1464 ; type="application/link-format" 1465 Content-Length: 4883 1466 Content-Type: application/link-format 1467 Connection: close 1469 ;rel="original", 1470 1471 ; rel="self";type="application/link-format" 1472 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1473 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1474 1475 ; rel="timegate", 1476 1477 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" 1478 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1479 1480 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" 1481 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1482 1483 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" 1484 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1485 1486 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT" 1487 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1488 ... 1490 Figure 19: Response from a TimeMap 1492 Cases exist in which a TimeMap points at several other TimeMaps. In 1493 one such case, a TimeMap could merely point at other TimeMaps and not 1494 list any Mementos itself. This can happen when Mementos are spread 1495 across several archives that share a front-end. Such a TimeMap can 1496 be considered an index of TimeMaps and is shown in Figure 20. 1498 Another case is when the number of available Mementos requires 1499 introducing multiple TimeMaps that can be paged. Such a TimeMap is 1500 shown in Figure 21. Note that this TimeMap contains links to other 1501 TimeMaps but actually also lists Mementos. In both examples, the 1502 "timemap" links have the "from" and "until" attributes to express the 1503 temporal span of listed Mementos. Since the index TimeMap does not 1504 list any Mementos, these attributes are not used on the link that 1505 points at the index TimeMap itself, i.e. the link with the "self" 1506 Relation Type. Note that TimeMaps obtained by following a "timemap" 1507 link can contain links to further TimeMaps. 1509 ;rel="original", 1510 1511 ; rel="timegate", 1512 1513 ; rel="self";type="application/link-format", 1514 1515 ; rel="timemap";type="application/link-format" 1516 ; from="Wed, 21 Jun 2000 04:41:56 GMT" 1517 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1518 1519 ; rel="timemap";type="application/link-format" 1520 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1521 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1522 1523 ; rel="timemap";type="application/link-format" 1524 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1526 Figure 20: An index TimeMap 1528 ;rel="original", 1529 1530 ; rel="timegate", 1531 1532 ; rel="self";type="application/link-format" 1533 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1534 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1535 1536 ; rel="timemap";type="application/link-format" 1537 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1538 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1539 1540 ; rel="timemap";type="application/link-format" 1541 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1542 ; until="Fri, 31 Aug 2012 12:22:34 GMT" 1543 1544 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", 1545 1546 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT", 1547 1548 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT", 1549 ... 1551 Figure 21: TimeMap Paging 1553 4. The Memento Framework, Discovery of TimeGates, TimeMaps, Mementos 1555 Section 3 describes how TimeGates, Mementos, Original Resources, and 1556 TimeMaps can be discovered by following HTTP Links with Relation 1557 Types "timegate", "memento", "original", and "timemap", respectively. 1559 Naturally, some of these links can also be included in 1560 representations of resources that have a media type that allows 1561 embedding typed links. For example, an Original Resource that has an 1562 HTML representation can include a "timegate" link by using HTML's 1563 LINK element, e.g. . The use of such embedded links is also subject to 1566 the considerations of Section 2.2. 1568 In this section an additional approach is introduced to support batch 1569 discovery of TimeGates, TimeMaps, and Mementos. The approach 1570 leverages the well-known URI [RFC5785] and host-meta [RFC6415] 1571 specifications. It can be used in cases where URIs of TimeGates, 1572 TimeMaps, or Mementos have as part of their path-component the URI of 1573 the associated Original Resource. The approach uses the following 1574 variables for URI templates used in host-meta files: 1576 o The "uri" variable, as reserved by [RFC6415], which stands for any 1577 URI in the server's document scope. 1579 o The "anyuri" variable, introduced here, which stands for any URI, 1580 i.e. not just URIs in the server's document scope. 1582 A server SHOULD make TimeGates discoverable in the following way: 1584 o As per [RFC5785] and [RFC6415], the server publishes a document 1585 with the name "host-meta" in its /.well-known/ path. 1587 o As per [RFC6415], the host-meta document uses the XRD 1.0 document 1588 format. 1590 o The host-meta document includes one or more "Link" elements to 1591 support discovery of TimeGates. Each such Link element has a 1592 value of "timegate" for its "rel" attribute, and it has a 1593 "template" attribute that has a URI template as its value. The 1594 URI template MAY either use the "uri" or "anyuri" variable. 1596 o The URI template MUST be such that, when applying the URI of an 1597 Original Resource to the "uri" or "anyuri" variable the URI of a 1598 potential TimeGate for that Original Resource results. 1600 There are no guarantees that these resulting TimeGates exist, but URI 1601 templates should be created to try and maximize chances they do. 1603 The considerations described for TimeGate discovery also apply to 1604 TimeMap discovery. However, for TimeMaps, each Link element has a 1605 value of "timemap" for its "rel" attribute. 1607 Figure 22 illustrates how a server makes TimeGates associated with 1608 its own Original Resources discoverable, whereas Figure 23 1609 illustrates how a web archive that hosts Mementos for Original 1610 Resources originating from various domains makes its TimeGates and 1611 TimeMaps discoverable. 1613 Figure 22 shows a host-meta document published at 1614 http://a.example.org/.well-known/host-meta by a wiki that has 1615 http://a.example.org as its base URI. The document supports 1616 discovery of TimeGates that allow accessing prior versions of the 1617 wiki's Original Resources. The URI template uses the "uri" variable 1618 to stand for a document in the wiki's document range. Assuming 1619 http://a.example.org/w/Clock is the URI of an Original Resource on 1620 the wiki, applying the template to that URI yields 1621 http://a.example.org/Special:TimeGate/http://a.example.org/w/Clock as 1622 its corresponding TimeGate. 1624 1625 1627 1629 1630 1632 Figure 22: A host-meta Document Supporting TimeGate Discovery for a 1633 Wiki's Original Resources 1635 Figure 23 shows a host-meta document published at 1636 http://arxiv.example.net/.well-known/host-meta by a web archive that 1637 has http://arxiv.example.net/ as its base URI. The document supports 1638 discovery of TimeGates and TimeMaps that the archive exposes, and 1639 that are associated with Original Resources for which the archive 1640 holds Mementos. The URI templates use the "anyuri" variable, which 1641 is an indication that the web archive holds Mementos for a wide 1642 variety of domains. Note the use of the "from" and "until" 1643 attributes to express the time range for which the archive has 1644 Mementos. 1646 1647 1649 1651 1652 1656 1657 1659 Figure 23: A host-meta Document Supporting Discovery of TimeGates and 1660 TimeMaps Exposed by a Web Archive 1662 In some cases, Mementos can be made discoverable via a host-meta 1663 document. Consider, for example, a server with base URI 1664 http://a.example.org/ that archives its own content once a year and 1665 makes the result available in a snapshot archive with base URI 1666 http://arxiv.example.net/. The server can publish a host-meta 1667 document at http://a.example.org/.well-known/host-meta that points to 1668 Mementos contained in the annual snapshots. This is shown in 1669 Figure 24. Note also the use of the "license" attribute that 1670 associates a Creative Commons license with the Mementos in the 1671 archive. 1673 1674 1676 1679 1680 1683 1684 1686 Figure 24: A Server Pointing to its Mementos in a Snapshot Archive 1688 5. IANA Considerations 1690 This memo requires IANA to register the Accept-Datetime and Memento- 1691 Datetime HTTP headers defined in Section 2.1.1 in the appropriate 1692 IANA registry. 1694 This memo requires IANA to register the Relation Types "original", 1695 "timegate", "timemap", and "memento" defined in Section 2.2.1 in the 1696 appropriate IANA registry. 1698 This memo requires IANA to register the "datetime" and "license" 1699 attributes for the "memento" Relation Type, as defined in 1700 Section 2.2.1.4, in the appropriate IANA registry. 1702 This memo requires IANA to register the "from" and "until" attributes 1703 for the "timemap" Relation Type, as defined in Section 2.2.1.4, in 1704 the appropriate IANA registry. 1706 6. Security Considerations 1708 Provision of a "timegate" HTTP "Link" header in responses to requests 1709 for an Original Resource that is protected (e.g., 401 or 403 HTTP 1710 response codes) is OPTIONAL. The inclusion of this Link when 1711 requesting authentication is at the server's discretion; cases may 1712 exist in which a server protects the current state of a resource, but 1713 supports open access to prior states and thus chooses to supply a 1714 "timegate" HTTP "Link" header. Conversely, the server may choose to 1715 not advertise the TimeGate URIs (e.g., they exist in an intranet 1716 archive) for unauthenticated requests. 1718 The veracity of archives and the relationships between Original 1719 Resources and Mementos is beyond the scope of this document. Even in 1720 the absence of malice, it is possible for separate archives to have 1721 different Mementos for the same Original Resource at the same 1722 datetime if the state of the Original Resource was dependent on the 1723 requesting archive's user agent IP address, specific HTTP request 1724 headers, and possibly other factors. 1726 Further authentication, encryption and other security related issues 1727 are otherwise orthogonal to Memento. 1729 7. Changelog 1731 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05 1733 o Clarified the section on Memento Relation Types. 1735 o Re-introduced "license" attribute for "memento" Relation Type as 1736 it will become essential for IIPC. 1738 o Introduced from and until attributes for "timemap" links to 1739 accomodate paged TimeMap cases. 1741 o Introduced the notion of Redirecting Resource and inserted related 1742 information in various sections. 1744 o Added discovery of Mementos via host-meta. 1746 o Corrected ambiguous uses of the term "representation". 1748 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04 1750 o Removed the possibility to use an interval indicator in an Accept- 1751 Datetime header as no one is implementing it. 1753 o Corrected typo in Other Relation Types table. 1755 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap 1756 paging. 1758 o Changed Discovery component from using robots.txt with Memento- 1759 specific add-ons to well-known URI and host-meta. 1761 o Removed "embargo" and "license" attributes for links with a 1762 "memento" Relation Type because no one is using them. 1764 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03 1765 o Added description of Mementos of HTTP responses with 3XX, 4XX and 1766 5XX status code. 1768 o Clarified that a TimeGate must not use the "Memento-Datetime" 1769 header. 1771 o Added wording to warn for possible cache problems with Memento 1772 implementations that choose to have an Original Resource and and 1773 its TimeGate coincide. 1775 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02 1777 o Added scenario in which a TimeGate redirects to another TimeGate. 1779 o Reorganized TimeGate section to better reflect the difference 1780 between requests with and without interval indicator. 1782 o Added recommendation to provide "memento" links to Mementos in the 1783 vicinity of the preferred interval provided by the client, in case 1784 of a 406 response. 1786 o Removed TimeMap Feed material from the Discovery section as a 1787 result of discussions regarding (lack of) scalability of the 1788 approach with representatives of the International Internet 1789 Preservation Consortium. An alternative approach to support batch 1790 discovery of Mementos will be specified. 1792 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01 1794 o Introduced wording and reference to indicate a Memento is a 1795 FixedResource. 1797 o Introduced "Sticky Memento-Datetime" notion and clarified wording 1798 about retaining "Memento-Datetime" headers and values when a 1799 Memento is mirrored at different URI. 1801 o Introduced section about handling both datetime and regular 1802 negotiation. 1804 o Introduced section about Mementos Without TimeGate. 1806 o Made various changes in the section Relation Type "memento", 1807 including addition of "license" and "embargo" attributes, and 1808 clarification of rules regarding the use of "memento" links. 1810 o Moved section about TimeMaps inside the Datetime Negotiation 1811 section, and updated it. 1813 o Restarted the Discovery section from scratch. 1815 v01 2010-11-11 HVDS MLN RS First public version 1816 draft-vandesompel-memento-00 1818 v00 2010-10-19 HVDS MLN RS Limited circulation version 1820 2010-07-22 HVDS MLN First internal version 1822 8. Acknowledgements 1824 The Memento effort is funded by the Library of Congress. Many thanks 1825 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry 1826 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers 1827 for early feedback. Many thanks to Samuel Adams, Scott Ainsworth, 1828 Lyudmilla Balakireva, Frank McCown, Harihar Shankar, Brad Tofel for 1829 early implementations. 1831 9. References 1833 9.1. Normative References 1835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1836 Requirement Levels", BCP 14, RFC 2119, March 1997. 1838 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1839 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1840 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1842 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 1843 RFC 4151, October 2005. 1845 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1846 Syndication Format", RFC 4287, December 2005. 1848 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1849 Uniform Resource Identifiers (URIs)", RFC 5785, 1850 April 2010. 1852 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types 1853 for Simple Version Navigation between Web Resources", 1854 RFC 5829, April 2010. 1856 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1858 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", 1859 RFC 6415, October 2011. 1861 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1862 Format", RFC 6690, August 2012. 1864 9.2. Informative References 1866 [Fitch] Fitch, "Web site archiving - an approach to recording 1867 every materially different response produced by a 1868 website", July 2003, 1869 . 1871 [I-D.masinter-dated-uri] 1872 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on 1873 dated URIs", draft-masinter-dated-uri-10 (work in 1874 progress), January 2012. 1876 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1877 and Support", STD 3, RFC 1123, October 1989. 1879 [W3C.REC-aww-20041215] 1880 Jacobs and Walsh, "Architecture of the World Wide Web", 1881 December 2004, . 1883 [W3C.gen-ont-20090420] 1884 Berners-Lee, "Architecture of the World Wide Web", 1885 April 2009, . 1887 Appendix A. Appendix: A Sample, Successful Memento Request/Response 1888 cycle 1890 Step 1 : UA --- HTTP HEAD/GET; Accept-Datetime: Tj ---------> URI-R 1892 HEAD / HTTP/1.1 1893 Host: a.example.org 1894 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 1895 Connection: close 1897 Step 2 : UA <-- HTTP 200; Link: URI-G ----------------------- URI-R 1899 HTTP/1.1 200 OK 1900 Date: Thu, 21 Jan 2010 00:02:12 GMT 1901 Server: Apache 1902 Link: 1903 ; rel="timegate" 1904 Content-Length: 255 1905 Connection: close 1906 Content-Type: text/html; charset=iso-8859-1 1908 Step 3 : UA --- HTTP HEAD/GET; Accept-Datetime: Tj ---------> URI-G 1910 GET /timegate/http://a.example.org 1911 HTTP/1.1 1912 Host: arxiv.example.net 1913 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 1914 Connection: close 1916 Step 4 : UA <-- HTTP 302; Location: URI-Mj; Vary; Link: 1917 URI-R, URI-T, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-G 1919 HTTP/1.1 302 Found 1920 Date: Thu, 21 Jan 2010 00:06:50 GMT 1921 Server: Apache 1922 Vary: negotiate, accept-datetime 1923 Location: 1924 http://arxiv.example.net/web/20010911203610/http://a.example.org 1925 Link: ; rel="original", 1926 1927 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1928 1929 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1930 1931 ; rel="timemap"; type="application/link-format", 1932 1933 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT", 1934 1935 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT", 1936 1937 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT" 1938 Content-Length: 0 1939 Content-Type: text/plain; charset=UTF-8 1940 Connection: close 1942 Step 5 : UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------> URI-Mj 1944 GET /web/20010911203610/http://a.example.org 1945 HTTP/1.1 1946 Host: arxiv.example.net 1947 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 1948 Connection: close 1950 Step 6 : UA <-- HTTP 200; Memento-Datetime: Tj; Link: URI-R, 1951 URI-T, URI-G, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-Mj 1953 HTTP/1.1 200 OK 1954 Date: Thu, 21 Jan 2010 00:09:40 GMT 1955 Server: Apache-Coyote/1.1 1956 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1957 Link: ; rel="original", 1958 1959 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 1960 1961 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT", 1962 1963 ; rel="timemap"; type="application/link-format", 1964 1965 ; rel="timegate", 1966 1967 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT", 1968 1969 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT", 1970 1971 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT" 1972 Content-Length: 23364 1973 Content-Type: text/html;charset=utf-8 1974 Connection: close 1976 A successful flow with TimeGate and Mementos on the same server 1978 Authors' Addresses 1980 Herbert VandeSompel 1981 Los Alamos National Laboratory 1982 PO Box 1663 1983 Los Alamos, New Mexico 87545 1984 USA 1986 Phone: +1 505 667 1267 1987 Email: hvdsomp@gmail.com 1988 URI: http://public.lanl.gov/herbertv/ 1990 Michael Nelson 1991 Old Dominion University 1992 Norfolk, Virginia 23529 1993 USA 1995 Phone: +1 757 683 6393 1996 Email: mln@cs.odu.edu 1997 URI: http://www.cs.odu.edu/~mln/ 1998 Robert Sanderson 1999 Los Alamos National Laboratory 2000 PO Box 1663 2001 Los Alamos, New Mexico 87545 2002 USA 2004 Phone: +1 505 665 5804 2005 Email: azaroth42@gmail.com 2006 URI: http://public.lanl.gov/rsanderson/