idnits 2.17.1 draft-vandesompel-memento-06.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 (February 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4151' is defined on line 1832, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 1835, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 1838, but no explicit reference was found in the text == Unused Reference: 'RFC6415' is defined on line 1848, 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: August 29, 2013 Old Dominion University 6 R. Sanderson 7 Los Alamos National Laboratory 8 February 25, 2013 10 HTTP framework for time-based access to resource states -- Memento 11 draft-vandesompel-memento-06 13 Abstract 15 The HTTP-based Memento framework bridges the present and past Web. It 16 facilitates obtaining representations of prior states of a resource 17 by leveraging the resource's URI and a preferred datetime. To this 18 end, the framework introduces datetime negotiation, a variation on 19 content negotiation. It also facilitates recongizing a resource that 20 encapsulates a frozen prior state of another resource by expressing 21 that state's datetime and by providing an appropriately typed link to 22 that other resource. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 29, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4 61 1.3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. HTTP headers, Relation Types . . . . . . . . . . . . . . . . . 6 63 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 7 65 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.1.3. Link . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.2. Relation Types . . . . . . . . . . . . . . . . . . . . . . 8 68 2.2.1. Relation Type "original" . . . . . . . . . . . . . . . 9 69 2.2.2. Relation Type "timegate" . . . . . . . . . . . . . . . 9 70 2.2.3. Relation Type "timemap" . . . . . . . . . . . . . . . 9 71 2.2.4. Relation Type "memento" . . . . . . . . . . . . . . . 10 72 2.3. Memento response headers: Summary . . . . . . . . . . . . 10 73 3. General considerations regarding Datetime Negotiation . . . . 11 74 4. HTTP Interactions for Datetime Negotiation . . . . . . . . . . 12 75 4.1. Pattern 1 - The Original Resource acts as its own 76 TimeGate . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation 78 ; distinct URI-M for Mementos . . . . . . . . . . . . 15 79 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation 80 ; distinct URI-M for Mementos . . . . . . . . . . . . 17 81 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation 82 ; no distinct URI-M for Mementos . . . . . . . . . . . 18 83 4.2. Pattern 2 - A remote resource acts as a TimeGate for 84 the Original Resource . . . . . . . . . . . . . . . . . . 19 85 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation 86 ; distinct URI-M for Mementos . . . . . . . . . . . . 21 87 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation 88 ; distinct URI-M for Mementos . . . . . . . . . . . . 23 89 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation 90 ; no distinct URI-M for Mementos . . . . . . . . . . . 24 91 4.3. Pattern 3 - The Original Resource is a Fixed Resource . . 25 92 4.4. Pattern 4 - Mementos without a TimeGate . . . . . . . . . 26 93 4.5. Special Cases . . . . . . . . . . . . . . . . . . . . . . 28 94 4.5.1. Original Resource provides no "timegate" link . . . . 28 95 4.5.2. Server exists but Original Resource no longer does . . 28 96 4.5.3. Issues with Accept-Datetime . . . . . . . . . . . . . 28 97 4.5.4. Memento of a 3XX response . . . . . . . . . . . . . . 29 98 4.5.5. Memento of responses with 4XX or 5XX HTTP status 99 codes . . . . . . . . . . . . . . . . . . . . . . . . 31 100 4.5.6. Sticky "Memento-Datetime" value for Mementos . . . . . 32 101 4.5.7. Intermediate Resources . . . . . . . . . . . . . . . . 32 102 5. TimeMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 103 5.1. Index and Paging TimeMaps . . . . . . . . . . . . . . . . 35 104 5.2. Mementos for TimeMaps . . . . . . . . . . . . . . . . . . 37 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 107 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 41 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 114 1. Introduction 116 1.1. Terminology 118 This specification uses the terms "resource", "request", "response", 119 "entity-body", "content negotiation", "user agent", "server" as 120 described in [RFC2616], and it uses the terms "representation" and 121 "resource state" as described in [W3C.REC-aww-20041215]. 123 In addition, the following terms specific to the Memento framework 124 are introduced: 126 o Original Resource: An Original Resource is a resource that exists 127 or used to exist, and for which access to one of its prior states 128 may be required. 130 o Memento: A Memento for an Original Resource is a resource that 131 encapsulates a prior state of the Original Resource. A Memento 132 for an Original Resource as it existed at time T is a resource 133 that encapsulates the state the Original Resource had at time T. 135 o TimeGate: A TimeGate for an Original Resource is a resource that 136 is capable of datetime negotiation to support access to prior 137 states of the Original Resource. 139 o TimeMap: A TimeMap for an Original Resource is a resource from 140 which a list of URIs of Mementos of the Original Resource is 141 available. 143 1.2. Notational Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 When needed for extra clarity, the following conventions are used: 151 o URI-R is used to denote the URI of an Original Resource. 153 o URI-G is used to denote the URI of a TimeGate. 155 o URI-M is used to denote the URI of a Memento. 157 o URI-T is used to denote the URI of a TimeMap. 159 1.3. Purpose 161 The state of an Original Resource may change over time. 162 Dereferencing its URI at any specific moment yields a response that 163 reflects the resource's state at that moment: a representation of the 164 resource's state (e.g. "200 OK" HTTP status code), an indication of 165 its non-existence (e.g. "404 Not Found" HTTP status code), a relation 166 to another resource (e.g. "302 Found" HTTP status code), etc. 167 However, responses may also exist that reflect prior states of an 168 Original Resource: a representation of a prior state of the Original 169 Resource, an indication that the Original Resource did not exist at 170 some time in the past, a relation that the Original Resource had to 171 another resource at some time in the past, etc. Mementos that 172 provide such responses exist in web archives, content management 173 systems, or revision control systems, among others. For any given 174 Original Resource several Mementos may exist, each one reflecting a 175 frozen prior state of the Original Resource. 177 Examples are: 179 Mementos for Original Resource http://www.ietf.org/ : 181 o http://web.archive.org/web/19970107171109/http://www.ietf.org/ 183 o http://webarchive.nationalarchives.gov.uk/20080906200044/http:// 184 www.ietf.org/ 186 Mementos for Original Resource 187 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol : 189 o http://en.wikipedia.org/w/ 190 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574 192 o http://en.wikipedia.org/w/ 193 index.php?title=Hypertext_Transfer_Protocol&oldid=33912 195 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/ 196 wiki/Hypertext_Transfer_Protocol 198 Mementos for Original Resource http://www.w3.org/TR/webarch/ : 200 o http://www.w3.org/TR/2004/PR-webarch-20041105/ 202 o http://www.w3.org/TR/2002/WD-webarch-20020830/ 204 o http://webarchive.nationalarchives.gov.uk/20100304163140/http:// 205 www.w3.org/TR/webarch/ 207 In the abstract, the Memento framework introduces a mechanism to 208 access versions of web resources that: 210 o Is fully distributed in the sense that resource versions may 211 reside on multiple servers, and that any such server is likely 212 only aware of the versions it holds; 214 o Uses the global notion of datetime as a resource version indicator 215 and access key; 217 o Leverages the following primitives of [W3C.REC-aww-20041215]: 218 resource, resource state, representation, content negotiation, and 219 link. 221 The core components of Memento's mechanism to access resource 222 versions are: 224 1. The abstract notion of the state of an Original Resource (URI-R) 225 as it existed at datetime T. Note the relationship with the ability 226 to identify the state of a resource at datetime T by means of a URI 227 as intended by the proposed Dated URI scheme 228 [I-D.masinter-dated-uri]. 230 2. A "bridge" from the present to the past, consisting of: 232 o The existence of a TimeGate (URI-G), which is aware of (at least 233 part of the) version history of the Original Resource (URI-R); 235 o The ability to negotiate in the datetime dimension with that 236 TimeGate (URI-G), as a means to access the state that the Original 237 Resource (URI-R) had at datetime T. 239 3. A "bridge" from the past to the present, consisting of an 240 appropriately typed link from a Memento (URI-M), which encapsulates 241 the state the Original Resource (URI-R) had at datetime T, to the 242 Original Resource (URI-R). 244 This document is concerned with specifying an instantiation of these 245 abstractions for resources that are identified by HTTP(S) URIs. 247 2. HTTP headers, Relation Types 249 The Memento framework is concerned with HEAD and GET interactions 250 with Original Resources, TimeGates, Mementos, and TimeMaps that are 251 identified by HTTP or HTTPS URIs. Details are only provided for 252 resources identified by HTTP URIs but apply similarly to those with 253 HTTPS URIs. 255 2.1. HTTP Headers 257 The Memento framework operates at the level of HTTP request and 258 response headers. It introduces two new headers ("Accept-Datetime", 259 "Memento-Datetime") and introduces new values for two existing 260 headers ("Vary", "Link"). Other HTTP headers are present or absent 261 in Memento response/request cycles as specified by [RFC2616]. 263 2.1.1. Accept-Datetime, Memento-Datetime 265 The "Accept-Datetime" request header is trasnmitted by a user agent 266 to indicate it wants to access a past state of an Original Resource. 267 To that end, the "Accept-Datetime" header is conveyed in an HTTP 268 request issued against a TimeGate for an Original Resource, and its 269 value indicates the datetime of the desired past state of the 270 Original Resource. 272 Example of an "Accept-Datetime" request header: 274 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 276 The "Memento-Datetime" response header is used by a server to 277 indicate that a response reflects a prior state of an Original 278 Resource. Its value expresses the datetime of that state. The URI 279 of the Original Resource for which the response reflects a prior 280 state is provided as the Target IRI of a link provided in the HTTP 281 "Link" header that has a Relation Type of "original" (see 282 Section 2.2). 284 The presence of a "Memento-Datetime" header and associated value for 285 a given response constitutes a promise that the resource state 286 reflected in the response will no longer change (see Section 4.5.6). 288 Example of a "Memento-Datetime" response header: 290 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT 292 Values for the "Accept-Datetime" and "Memento-Datetime" headers 293 consist of a MANDATORY datetime expressed according to the [RFC1123] 294 format, which is formalized by the rfc1123-date construction rule of 295 the BNF in Figure 1. The datetime MUST be represented in Greenwich 296 Mean Time (GMT). 298 accept-dt-value = rfc1123-date *SP 299 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 300 date1 = 2DIGIT SP month SP 4DIGIT 301 ; day month year (e.g., 20 Mar 1957) 302 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 303 ; 00:00:00 - 23:59:59 (e.g., 14:33:22) 304 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | 305 "Sun" 306 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | 307 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 309 Figure 1: BNF for the datetime format 311 2.1.2. Vary 313 Generally, the "Vary" header is used in HTTP responses to indicate 314 the dimensions in which content negotiation is possible. In the 315 Memento framework, a TimeGate uses the "Vary" header with a value 316 that includes "accept-datetime" to convey that datetime negotation is 317 possible. 319 For example, this use of the "Vary" header indicates that datetime is 320 the only dimension in which negotiation is possible: 322 Vary: accept-datetime 324 The use of the "Vary" header in this example shows that both datetime 325 negotiation, and media type content negotiation are possible: 327 Vary: accept-datetime, accept 329 2.1.3. Link 331 The Memento framework defines the "original", "timegate", "timemap", 332 and "memento" Relation Types to convey typed links among Original 333 Resources, TimeGates, Mementos, and TimeMaps. The are defined in 334 Section 2.2, below. In addition, existing Relation Types may be 335 used, for example, to support navigating among Mementos. Examples 336 are "first", "last", "prev", "next", "predecessor-version", 337 "successor-version" as detailed in [RFC5988] and [RFC5829]. 339 2.2. Relation Types 341 This section introduces the Relation Types used in the Memento 342 framework. They are defined in a general way and their use in HTTP 343 "Link" Headers [RFC5988] is described in detail. The use of these 344 Relation Types in TimeMaps is described in Section 5. 346 2.2.1. Relation Type "original" 348 "original" -- A link with an "original" Relation Type is used to 349 point from a TimeGate or a Memento to its associated Original 350 Resource. 352 Use in HTTP "Link" headers: A TimeGate and a Memento MUST include 353 exactly one link with an "original" Relation Type in their HTTP 354 "Link" header. 356 2.2.2. Relation Type "timegate" 358 "timegate" -- A link with a "timegate" Relation Type is used to point 359 from the Original Resource, as well as from a Memento associated with 360 the Original Resource, to a TimeGate for the Original Resource. 362 Use in HTTP "Link" headers: An Original Resource and a Memento SHOULD 363 include a link with a "timegate" Relation Type in their HTTP "Link" 364 header. Since multiple TimeGates can exist for any Original 365 Resource, multiple "timegate" links MAY occur, each with a distinct 366 Target IRI. 368 2.2.3. Relation Type "timemap" 370 "timemap" -- A link with a "timemap" Relation Type is used to point 371 from a TimeGate or a Memento associated with an Original Resource, as 372 well as from the Original Resource itself, to a TimeMap for the 373 Original Resource. 375 Attributes: A link with a "timemap" Relation Type SHOULD use the 376 "type" attribute to convey the mime type of the TimeMap 377 serialization. The "from" and "until" attributes may be used to 378 express the start and end of the temporal interval covered by 379 Mementos listed in the TimeMap. That is, the linked TimeMap will not 380 contain Mementos with archival datetimes outside of the expressed 381 temporal interval. Attempts SHOULD be made to convey this interval 382 as accurately as possible. The value for the these attributes MUST 383 be a datetime expressed according to the rfc1123-date construction 384 rule of the BNF in Figure 1 and it MUST be represented in Greenwich 385 Mean Time (GMT). 387 Use in HTTP "Link" headers: An Original Resource, a TimeGate and a 388 Memento SHOULD include a link with a "timemap" Relation Type in their 389 HTTP "Link" header. Multiple such links, each with a distinct Target 390 IRI, MAY be expressed as a means to point to different TimeMaps or to 391 different serializations of the same TimeMap. In all cases, use of 392 the "from" and "until" attributes is OPTIONAL. 394 2.2.4. Relation Type "memento" 396 "memento" -- A link with a "memento" Relation Type is used to point 397 from a TimeGate or a Memento for an Original Resource, as well as 398 from the Original Resource itself, to a Memento for the Original 399 Resource. 401 Attributes: A link with a "memento" Relation Type MUST include a 402 "datetime" attribute with a value that matches the "Memento-Datetime" 403 of the Memento that is the target of the link; that is, the value of 404 the "Memento-Datetime" header that is returned when the URI of the 405 linked Memento is dereferenced. The value for the "datetime" 406 attribute MUST be a datetime expressed according to the rfc1123-date 407 construction rule of the BNF in Figure 1 and it MUST be represented 408 in Greenwich Mean Time (GMT). This link MAY include a "license" 409 attribute to associate a license with the Memento; the value for the 410 "license" attribute SHOULD be a URI. 412 Use in HTTP "Link" headers: An Original Resource, a TimeGate and a 413 Memento MAY include links in their HTTP "Link" headers with a 414 "memento" Relation Type. For responses in which a Memento is 415 selected, the provision of navigational links that lead to Mementos 416 other than the selected one can be beneficial to the user agent. Of 417 special importance are links that lead to the temporally first and 418 last Memento known to the responding server, as well as links leading 419 to Mementos that are temporally adjacent to the selected one. 421 2.3. Memento response headers: Summary 423 The below table summarizes the use of the Vary, Memento-Datetime, and 424 Link headers in responses from Original Resources, TimeGates, and 425 Mementos. The value of the Vary header MUST contain the "accept- 426 datetime" value, whereas the value of the Memento-Datetime header 427 MUST convey the datetime of the state of the Original Resource that 428 is encapsulated in the Memento selected by the response. From now 429 on, this datetime will be referred to as the archival datetime of the 430 Memento. 432 The Link header can contain links with the "original", "timegate", 433 "timemap", and "memento" Relation Types and their use for the various 434 resource types is also detailed in the table. 436 The inclusion of Memento headers and links in responses from the 437 respective resources is as shown in the table irrespective of whether 438 an HTTP HEAD/GET request against their URI includes an "Accept- 439 Datetime" request header: requests with and without an "Accept- 440 Datetime" header yield the inclusion of the same response headers. 441 Values for those response headers depend on the request. 443 The use of response headers and links for specific scenarios can be 444 derived from this table. For example: 446 o URI-R<>URI-G<>URI-M - If the TimeGate is distinct from the 447 associated Original Resource and Memento, then their use is as 448 shown in the respective columns. 450 o URI-R=URI-G - If the TimeGate coincides with the Original 451 Resource, then their use is obtained by taking the union of the 452 headers for a TimeGate and for an Original Resource and by 453 selecting REQUIRED over RECOMMENDED and REQUIRED over PROHIBITED. 454 For example, this case must have a "Vary" header that includes an 455 "accept-datetime" value. 457 o URI-R=URI-M - If the Original Resource and its Memento coincide 458 (the Original Resource is a FixedResource as per 459 [W3C.gen-ont-20090420]), their use is obtained by taking the union 460 of the headers for an Original Resource and for a Memento and by 461 selecting REQUIRED over RECOMMENDED and REQUIRED over PROHIBITED. 462 For example, this case must have a "Memento-Datetime" header. 464 +------------------+---------------+---------------+----------------+ 465 | Response Header | Original | TimeGate | Memento | 466 | | Resource | | | 467 +------------------+---------------+---------------+----------------+ 468 | Vary: | PROHIBITED | REQUIRED, 1 | PROHIBITED | 469 | accept-datetime | | | | 470 | Memento-Datetime | PROHIBITED | PROHIBITED | REQUIRED, 1 | 471 | Link | RECOMMENDED, | REQUIRED, 1 | REQUIRED, 1 | 472 | | 0 or 1 | | | 473 | "original" link | NA | REQUIRED, 1 | REQUIRED, 1 | 474 | "timegate" link | RECOMMENDED, | NA | RECOMMENDED, 0 | 475 | | 0 or more | | or more | 476 | "timemap" link | RECOMMENDED, | RECOMMENDED, | RECOMMENDED, 0 | 477 | | 0 or more | 0 or more | or more | 478 | "memento" link | OPTIONAL, 0 | OPTIONAL, 0 | OPTIONAL, 0 or | 479 | | or more | or more | more | 480 +------------------+---------------+---------------+----------------+ 482 Table 1: Memento Headers 484 3. General considerations regarding Datetime Negotiation 486 In order to respond to a datetime negotiation request, the server 487 uses an internal algorithm to select the Memento that best meets the 488 user agent's datetime preference. The exact nature of the selection 489 algorithm is at the server's discretion but SHOULD be consistent, for 490 example, always selecting the Memento that is nearest in time 491 relative to the requested datetime, always selecting the Memento that 492 is nearest in the past relative to the requested datetime, etc. 494 Due to the sparseness of Mementos in most systems, the value of the 495 "Memento-Datetime" header returned by a server may differ 496 (significantly) from the value conveyed by the user agent in "Accept- 497 Datetime". 499 Although a Memento encapsulates a prior state of an Original 500 Resource, the entity-body returned in response to an HTTP GET request 501 issued against a Memento may very well not be byte-to-byte the same 502 as an entity-body that was previously returned by that Original 503 Resource. Various reasons exist why there are significant chances 504 these would be different yet do convey substantially the same 505 information. These include format migrations as part of a digital 506 preservation strategy, URI-rewriting as applied by some web archives, 507 and the addition of banners as a means to brand web archives. 509 When negotiating in the datetime dimension, the regular content 510 negotiation dimensions (media type, character encoding, language, and 511 compression) remain available. It is the TimeGate server's 512 responsibility to honor (or not) such content negotiation, and in 513 doing so it MUST always first select a Memento that meets the user 514 agent's datetime preference, and then consider honoring regular 515 content negotiation for it. As a result of this approach, the 516 returned Memento will not necessarily meet the user agent's regular 517 content negotiation preferences. Therefore, it is RECOMMENDED that 518 the server provides "memento" links in the HTTP "Link" header 519 pointing at Mementos that do meet the user agent's regular content 520 negotiation requests and that have a value for the "Memento-Datetime" 521 header in the temporal vicinity of the user agent's preferred 522 datetime value. 524 A user agent that engages in datetime negotiation with a resource 525 typically starts by issuing an HTTP HEAD, not GET, request with an 526 "Accept-Datetime" header in order to determine how to proceed. This 527 strategy is related to the existence of various server implementation 528 patterns as will become clear in the below. 530 In the following sections, the HTTP status code of the responses with 531 an entity-body is shown as "200 OK", but a series of "206 Partial 532 Content" responses could be substituted. 534 4. HTTP Interactions for Datetime Negotiation 536 This section describes the HTTP interactions of the Memento framework 537 for a variety of scenarios. First, Figure 2 provides a schematic 538 overview of a successful request/response chain that involves 539 datetime negotiation. Dashed lines depict HTTP transactions between 540 user agent and server. The interactions are for a scenario where the 541 Original Resource resides on one server, whereas both its TimeGate 542 and Mementos reside on another. Scenarios also exist in which all 543 these resources are on the same server (for example, content 544 management systems) or all are on different servers (for example, an 545 aggregator of TimeGates). 547 1: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-R 548 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R 549 3: UA --- HTTP HEAD/GET; Accept-Datetime: T ----------------> URI-G 550 4: UA <-- HTTP 302; Location: URI-M; Vary; Link: 551 URI-R,URI-T ------------------------------------------> URI-G 552 5: UA --- HTTP GET URI-M; Accept-Datetime: T ---------------> URI-M 553 6: UA <-- HTTP 200; Memento-Datetime: T; Link: 554 URI-R,URI-T,URI-G ------------------------------------- URI-M 556 Figure 2: A datetime negotiation request/response chain 558 o Step 1: The user agent that wants to access a prior state of the 559 Original Resource issues an HTTP HEAD/GET against URI-R that has 560 an "Accept-Datetime" HTTP header with a value of the datetime of 561 the desired state. 563 o Step 2: The response from URI-R includes an HTTP "Link" header 564 with a Relation Type of "timegate" pointing at a TimeGate (URI-G) 565 for the Original Resource. 567 o Step 3: The user agent starts the datetime negotiation process 568 with the TimeGate by issuing an HTTP GET request against URI-G 569 that has an "Accept-Datetime" HTTP header with a value of the 570 datetime of the desired prior state of the Original Resource. 572 o Step 4: The response from URI-G includes a "Location" header 573 pointing at a Memento (URI-M) for the Original Resource. In 574 addition, the response contains an HTTP "Link" header with a 575 Relation Type of "original" pointing at the Original Resource 576 (URI-R), and an HTTP "Link" header with a Relation Type of 577 "timemap" pointing at a TimeMap (URI-T). 579 o Step 5: The user agent issues an HTTP GET request against URI-M. 581 o Step 6: The response from URI-M includes a "Memento-Datetime" HTTP 582 header with a value of the archival datetime of the Memento. It 583 also contains an HTTP "Link" header with a Relation Type of 584 "original" pointing at the Original Resource (URI-R), with a 585 Relation Type of "timegate" pointing at a TimeGate (URI-G) for the 586 Original Resource, and with a Relation Type of "timemap" pointing 587 at a TimeMap (URI-T) for the Original Resource. The state that is 588 expressed by the response is the state the Original Resource had 589 at the archival datetime expressed in the "Memento-Datetime" 590 header. 592 Figure 2 depicts a specific pattern to implement the Memento 593 framework. Multiple patterns exist and they can be grouped as 594 follows: 596 o Pattern 1 (Section 4.1) - The Original Resource acts as its own 597 TimeGate 599 o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for 600 the Original Resource 602 o Pattern 3 (Section 4.3) - The Original Resource is a Fixed 603 Resource 605 o Pattern 4 (Section 4.4) - Mementos without a TimeGate 607 Details of the HTTP interactions for common cases for each of those 608 patterns are provided in Section 4.1 through Section 4.4. Special 609 cases are described in Section 4.5. 611 Figure 3 shows a user agent that attemtps to datetime negotiate with 612 the Original Resource http://a.example.org/ by including an "Accept- 613 Datetime" header in its HTTP HEAD request. This initiating request 614 is the same for Pattern 1 (Section 4.1) through Pattern 3 615 (Section 4.3). 617 HEAD / HTTP/1.1 618 Host: a.example.org 619 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 620 Connection: close 622 Figure 3: User Agent Attempts Datetime Negotiation With Original 623 Resource 625 4.1. Pattern 1 - The Original Resource acts as its own TimeGate 627 In this implementation pattern, the Original Resource acts as its own 628 TimeGate, which means that URI-R and URI-G coincide. Content 629 management systems and revision control systems can support datetime 630 negotiation in this way as they are commonly aware of the version 631 history of their own resources. 633 The response to this request when datetime negotiation for this 634 resource is supported depends on the negotiation style it uses (200- 635 style or 302-style) and on the existence or absence of a URI-M for 636 Mementos that is distinct from the URI-R of the associated Original 637 Resource. The various cases are summarized in the below table and 638 the server responses for each are detailed in the remainder of this 639 section. 641 +-------------------+------------+----------+---------+-------------+ 642 | Pattern | Original | TimeGate | Memento | Negotiation | 643 | | Resource | | | Style | 644 +-------------------+------------+----------+---------+-------------+ 645 | Pattern 1.1 | URI-R | URI-R | URI-M | 302 | 646 | (Section 4.1.1) | | | | | 647 | Pattern 1.2 | URI-R | URI-R | URI-M | 200 | 648 | (Section 4.1.2) | | | | | 649 | Pattern 1.3 | URI-R | URI-R | URI-R | 200 | 650 | (Section 4.1.3) | | | | | 651 +-------------------+------------+----------+---------+-------------+ 653 Table 2: Pattern 1 655 4.1.1. Pattern 1.1 - URI-R=URI-G ; 302-style negotiation ; distinct 656 URI-M for Mementos 658 In this case, the response to the user agent's request of Figure 3 659 has a "302 Found" HTTP status code, and the "Location" header conveys 660 the URI-M of the selected Memento. As per Section 2.3, the use of 661 Memento response headers and links in the response from URI-R=URI-G 662 is as follows: 664 o The "Vary" header MUST be provided and it MUST include the 665 "accept-datetime" value. 667 o The response MUST NOT contain a "Memento-Datetime" header. 669 o The "Link" header MUST be provided and it MUST contain at least a 670 link with the "original" Relation Type that has the URI-R of the 671 Original Resource as Target IRI. The provision of other links is 672 encouraged and is subject to the considerations described in 673 Section 2.2. 675 The server's response to the request of Figure 3 is shown in 676 Figure 4. Note the inclusion of the recommended link to the TimeGate 677 that, in this case, has a Target IRI that is the URI-R of the 678 Original Resource. 680 HTTP/1.1 302 Found 681 Date: Thu, 21 Jan 2010 00:06:50 GMT 682 Server: Apache 683 Vary: accept-datetime 684 Location: 685 http://a.example.org/?version=20010911203610 686 Link: ; rel="original timegate" 687 Content-Length: 0 688 Content-Type: text/plain; charset=UTF-8 689 Connection: close 691 Figure 4: Response from URI-R=URI-G for Pattern 1.1 693 In a subsequent request, shown in Figure 5, the user agent can obtain 694 the selected Memento by issuing an HTTP GET request against the URI-M 695 that was provided in the "Location" header. The inclusion of the 696 "Accept-Datetime" header in this request is not needed but will 697 typically occur as the user agent is in datetime negotiation mode. 699 GET /?version=20010911203610 HTTP/1.1 700 Host: a.example.org 701 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 702 Connection: close 704 Figure 5: User Agent Requests Selected Memento 706 The response has a "200 OK" HTTP status code and the entity-body of 707 the response contains the representation of the selected Memento. As 708 per Section 2.3, the use of Memento response headers and links in the 709 response from URI-M is as follows: 711 o A "Vary" header that includes an "accept-datetime" value MUST NOT 712 be provided. 714 o The response MUST include a "Memento-Datetime" header. Its value 715 expresses the archival datetime of the Memento. 717 o The "Link" header MUST be provided and it MUST contain at least a 718 link with the "original" Relation Type that has the URI-R of the 719 Original Resource as Target IRI. The provision of other links is 720 encouraged and is subject to the considerations described in 721 Section 2.2. 723 The server's response to the request of Figure 5 is shown in 724 Figure 6. Note the provision of the required "original", and the 725 recommended "timegate" and "timemap" links. The former two point to 726 the Original Resource, which acts as its own TimeGate. The latter 727 has "from" and "until" attributes to indicate the temporal interval 728 covered by Mementos listed in the linked TimeMap. 730 HTTP/1.1 200 OK 731 Date: Thu, 21 Jan 2010 00:06:51 GMT 732 Server: Apache-Coyote/1.1 733 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 734 Link: ; rel="original timegate", 735 736 ; rel="timemap"; type="application/link-format" 737 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 738 ; until="Wed, 20 Jan 2010 09:34:33 GMT" 739 Content-Length: 23364 740 Content-Type: text/html;charset=utf-8 741 Connection: close 743 Figure 6: Response from URI-M for Pattern 1.1 745 4.1.2. Pattern 1.2 - URI-R=URI-G ; 200-style negotiation ; distinct 746 URI-M for Mementos 748 In this case, the response to the user agent's request of Figure 3 749 has a "200 OK" HTTP status code, and the "Content-Location" header 750 conveys the URI-M of the selected Memento. As per Section 2.3, the 751 use of Memento response headers and links in the response from URI- 752 R=URI-G is as follows: 754 o The "Vary" header MUST be provided and it MUST include the 755 "accept-datetime" value. 757 o The response MUST include a "Memento-Datetime" header. Its value 758 expresses the archival datetime of the selected Memento. 760 o The "Link" header MUST be provided and it MUST contain at least a 761 link with the "original" Relation Type that has the URI-R of the 762 Original Resource as Target IRI. The provision of other links is 763 encouraged and is subject to the considerations described in 764 Section 2.2. 766 The server's response to the request of Figure 3 is shown in 767 Figure 7. Note the provision of optional "memento" links pointing at 768 the oldest and most recent Memento for the Original Resource known to 769 the responding server. 771 HTTP/1.1 200 OK 772 Date: Thu, 21 Jan 2010 00:06:50 GMT 773 Server: Apache 774 Vary: accept-datetime 775 Content-Location: 776 http://a.example.org/?version=20010911203610 777 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 778 Link: ; rel="original timegate", 779 780 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 781 782 ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT" 783 Content-Length: 2312 784 Content-Type: text/html; charset=UTF-8 785 Connection: close 787 Figure 7: Response from URI-R=URI-G for Pattern 1.2 789 In a subsequent request, which is the same as Figure 3 but with HTTP 790 GET instead of HEAD, the user agent can obtain the representation of 791 the selected Memento. It will be provided as the entity-body of a 792 response that has the same Memento headers as in Figure 7. 794 4.1.3. Pattern 1.3 - URI-R=URI-G ; 200-style negotiation ; no distinct 795 URI-M for Mementos 797 In this case, the response to the user agent's request of Figure 3 798 has a "200 OK" HTTP status code, and it does not contain a "Content- 799 Location" nor "Location" header as there is no URI-M of the selected 800 Memento to convey. As per Section 2.3, the use of Memento response 801 headers and links in the response from URI-R=URI-G is as follows: 803 o The "Vary" header MUST be provided and it MUST include the 804 "accept-datetime" value. 806 o The response MUST include a "Memento-Datetime" header. Its value 807 expresses the archival datetime of the selected Memento. 809 o The "Link" header MUST be provided and it MUST contain at least a 810 link with the "original" Relation Type that has the URI-R of the 811 Original Resource as Target IRI. The provision of other links is 812 encouraged and is subject to the considerations described in 813 Section 2.2. 815 The server's response to the request of Figure 3 is shown in 816 Figure 8. The recommended "timemap" and "timegate" links are 817 included in addition to the mandatory "original" link. 819 HTTP/1.1 200 OK 820 Date: Thu, 21 Jan 2010 00:06:50 GMT 821 Server: Apache 822 Vary: accept-datetime 823 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 824 Link: ; rel="original timegate", 825 826 ; rel="timemap"; type="application/link-format" 827 Content-Length: 0 828 Content-Type: text/plain; charset=UTF-8 829 Connection: close 831 Figure 8: Response from URI-R=URI-G for Pattern 1.3 833 In a subsequent request, which is the same as Figure 3 but with HTTP 834 GET instead of HEAD, the user agent can obtain the representation of 835 the selected Memento. It will be provided as the entity-body of a 836 response that has the same Memento headers as in Figure 8. 838 4.2. Pattern 2 - A remote resource acts as a TimeGate for the Original 839 Resource 841 In this implementation pattern, the Original Resource does not act as 842 its own TimeGate, which means that URI-R and URI-G are different. 843 This pattern is typically implemented by servers for which the 844 history of their resources is recorded in remote systems such as web 845 archives and transactional archives [Fitch]. But servers that 846 maintain their own history, such as content management systems and 847 Version Control Systems, may also implement this pattern, for 848 example, to distribute the load involved in responding to requests 849 for current and prior representations of resources between different 850 servers. 852 This pattern is summarized in the below table and is detailed in the 853 remainder of this section. Three cases exist that differ regarding 854 the negotiation style that is used by the remote TimeGate and 855 regarding the existence of a URI-M for Mementos that is distinct from 856 the URI-G of the TimeGate. 858 +-------------------+------------+----------+---------+-------------+ 859 | Pattern | Original | TimeGate | Memento | Negotiation | 860 | | Resource | | | Style | 861 +-------------------+------------+----------+---------+-------------+ 862 | Pattern 2.1 | URI-R | URI-G | URI-M | 302 | 863 | (Section 4.2.1) | | | | | 864 | Pattern 2.2 | URI-R | URI-G | URI-M | 200 | 865 | (Section 4.2.2) | | | | | 866 | Pattern 2.3 | URI-R | URI-G | URI-G | 200 | 867 | (Section 4.2.3) | | | | | 868 +-------------------+------------+----------+---------+-------------+ 870 Table 3: Pattern 2 872 The response by the Original Resource to the request shown in 873 Figure 3 is the same for all three cases. As per Section 2.3, the 874 use of headers and links in the response from URI-R is as follows: 876 o A "Vary" header that includes an "accept-datetime" value MUST NOT 877 be provided. 879 o The response MUST NOT contain a "Memento-Datetime" header. 881 o The "Link" header SHOULD be provided. It MUST NOT include a link 882 with an "original" Relation Type. It SHOULD include a link with a 883 "timegate" Relation Type that has the URI-G of the TimeGate as 884 Target IRI. It SHOULD include a link with a "timemap" Relation 885 Type that has the URI-T of the TimeGate as Target IRI. Multiple 886 "timegate" and "timemap" links can be provided to accommodate 887 situations in which the server is aware of multiple TimeGates or 888 Timemaps for the Original Resource. 890 Figure 9 shows such a response. Note the absence of an "original" 891 link as the responding resource is neither a TimeGate or a Memento. 893 HTTP/1.1 200 OK 894 Date: Thu, 21 Jan 2010 00:02:12 GMT 895 Server: Apache 896 Link: 897 ; rel="timegate" 898 Content-Length: 255 899 Connection: close 900 Content-Type: text/html; charset=iso-8859-1 902 Figure 9: Response from URI-R<>URI-G for Pattern 2 904 Once a user agent has obtained the URI-G of a remote TimeGate for the 905 Original Resource it can engage in datetime negotation with that 906 TimeGate. Figure 10 shows the request issued against the TimeGate 907 whereas Section 4.2.1 through Section 4.2.3 detail the responses for 908 various TimeGate implementation patterns. 910 HEAD /timegate/http://a.example.org/ HTTP/1.1 911 Host: arxiv.example.net 912 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 913 Connection: close 915 Figure 10: User Agent Engages in Datetime Negotiation With Remote 916 TimeGate 918 4.2.1. Pattern 2.1 - URI-R<>URI-G ; 302-style negotiation ; distinct 919 URI-M for Mementos 921 In case the TimeGate uses a 302 negotiation style, the response to 922 the user agent's request of Figure 10 has a "302 Found" HTTP status 923 code, and the "Location" header conveys the URI-M of the selected 924 Memento. As per Section 2.3, the use of Memento response headers and 925 links in the response from URI-G is as follows: 927 o The "Vary" header MUST be provided and it MUST include the 928 "accept-datetime" value. 930 o The response MUST NOT contain a "Memento-Datetime" header. 932 o The "Link" header MUST be provided and it MUST contain at least a 933 link with the "original" Relation Type that has the URI-R of the 934 Original Resource as Target IRI. The provision of other links is 935 encouraged and is subject to the considerations described in 936 Section 2.2. 938 The server's response to the request of Figure 10 is shown in 939 Figure 11. It contains the mandatory "original" link that points 940 back to the Original Resource associated with this TimeGate and it 941 shows the recommended "timemap" link that includes "from" and "until" 942 attributes. 944 HTTP/1.1 302 Found 945 Date: Thu, 21 Jan 2010 00:02:14 GMT 946 Server: Apache 947 Vary: accept-datetime 948 Location: 949 http://arxiv.example.net/web/20010911203610/http://a.example.org/ 950 Link: ; rel="original", 951 952 ; rel="timemap"; type="application/link-format" 953 ; from="Tue, 15 Sep 2000 11:28:26 GMT" 954 ; until="Wed, 20 Jan 2010 09:34:33 GMT" 955 Content-Length: 0 956 Content-Type: text/plain; charset=UTF-8 957 Connection: close 959 Figure 11: Response from URI-G<>URI-R for Pattern 2.1 961 In a subsequent HTTP GET request, shown in Figure 12, the user agent 962 can obtain the selected Memento by issuing an HTTP GET request 963 against the URI-M that was provided in the "Location" header. The 964 inclusion of the "Accept-Datetime" header in this request is not 965 needed but will typically occur as the user agent is in datetime 966 negotiation mode. 968 GET /web/20010911203610/http://a.example.org/ HTTP/1.1 969 Host: arxiv.example.net/ 970 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT 971 Connection: close 973 Figure 12: User Agent Requests Selected Memento 975 The response has a "200 OK" HTTP status code. As per Section 2.3, 976 the use of Memento response headers and links in the response from 977 URI-M is as follows: 979 o A "Vary" header that includes an "accept-datetime" value MUST NOT 980 be provided. 982 o The response MUST include a "Memento-Datetime" header. Its value 983 expresses the archival datetime of the Memento. 985 o The "Link" header MUST be provided and it MUST contain at least a 986 link with the "original" Relation Type that has the URI-R of the 987 Original Resource as Target IRI. The provision of other links is 988 encouraged and is subject to the considerations described in 989 Section 2.2. 991 The server's response to the request of Figure 12 is shown in 992 Figure 13. Note the provision of the recommended "timegate" and 993 "timemap" links. 995 HTTP/1.1 200 OK 996 Date: Thu, 21 Jan 2010 00:02:15 GMT 997 Server: Apache-Coyote/1.1 998 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 999 Link: ; rel="original", 1000 1001 ; rel="timemap"; type="application/link-format", 1002 1003 ; rel="timegate" 1004 Content-Length: 23364 1005 Content-Type: text/html;charset=utf-8 1006 Connection: close 1008 Figure 13: Response from URI-M for Pattern 2.1 1010 4.2.2. Pattern 2.2 - URI-R<>URI-G ; 200-style negotiation ; distinct 1011 URI-M for Mementos 1013 In case the TimeGate uses a 200 negotiation style, and each Memento 1014 has a distinct URI-M, the response to the user agent's request of 1015 Figure 10 has a "200 OK" HTTP status code, and the "Content-Location" 1016 header conveys the URI-M of the selected Memento. As per 1017 Section 2.3, the use of Memento response headers and links in the 1018 response from URI-G is as follows: 1020 o The "Vary" header MUST be provided and it MUST include the 1021 "accept-datetime" value. 1023 o The response MUST include a "Memento-Datetime" header. Its value 1024 expresses the archival datetime of the Memento. 1026 o The "Link" header MUST be provided and it MUST contain at least a 1027 link with the "original" Relation Type that has the URI-R of the 1028 Original Resource as Target IRI. The provision of other links is 1029 encouraged and is subject to the considerations described in 1030 Section 2.2. 1032 The server's response to the request of Figure 10 is shown in 1033 Figure 14. 1035 HTTP/1.1 200 OK 1036 Date: Thu, 21 Jan 2010 00:09:40 GMT 1037 Server: Apache-Coyote/1.1 1038 Vary: accept-datetime 1039 Content-Location: 1040 http://arxiv.example.net/web/20010911203610/http://a.example.org/ 1041 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1042 Link: ; rel="original", 1043 1044 ; rel="timemap"; type="application/link-format", 1045 1046 ; rel="timegate" 1047 Content-Length: 23364 1048 Content-Type: text/html; charset=UTF-8 1049 Connection: close 1051 Figure 14: Response from URI-G<>URI-R for Pattern 2.2 1053 In a subsequent request, which is the same as Figure 10 but with HTTP 1054 GET instead of HEAD, the user agent can obtain the representation of 1055 the selected Memento. It will be provided as the entity-body of a 1056 response that has the same Memento headers as Figure 14. 1058 4.2.3. Pattern 2.3 - URI-R<>URI-G ; 200-style negotiation ; no distinct 1059 URI-M for Mementos 1061 In case the TimeGate uses a 200 negotiation style, but Mementos have 1062 no distinct URIs, the response to the user agent's request of 1063 Figure 10 has a "200 OK" HTTP status code, and it does not contain a 1064 "Content-Location" nor "Location" header as there is no URI-M of the 1065 selected Memento to convey. As per Section 2.3, the use of Memento 1066 response headers and links in the response from URI-G is as follows: 1068 o The "Vary" header MUST be provided and it MUST include the 1069 "accept-datetime" value. 1071 o The response MUST include a "Memento-Datetime" header. Its value 1072 expresses the archival datetime of the Memento. 1074 o The "Link" header MUST be provided and it MUST contain at least a 1075 link with the "original" Relation Type that has the URI-R of the 1076 Original Resource as Target IRI. The provision of other links is 1077 encouraged and is subject to the considerations described in 1078 Section 2.2. 1080 The server's response to the request of Figure 10 is shown in 1081 Figure 15. 1083 HTTP/1.1 200 OK 1084 Date: Thu, 21 Jan 2010 00:09:40 GMT 1085 Server: Apache-Coyote/1.1 1086 Vary: accept-datetime 1087 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1088 Link: ; rel="original", 1089 1090 ; rel="timemap"; type="application/link-format", 1091 1092 ; rel="timegate" 1093 Content-Length: 23364 1094 Content-Type: text/html; charset=UTF-8 1095 Connection: close 1097 Figure 15: Response from URI-G<>URI-R for Pattern 2.3 1099 In a subsequent request, which is the same as Figure 10 but with HTTP 1100 GET instead of HEAD, the user agent can obtain the representation of 1101 the selected Memento. It will be provided as the entity-body of a 1102 response that has the same Memento headers as Figure 15. 1104 4.3. Pattern 3 - The Original Resource is a Fixed Resource 1106 This pattern does not involve datetime negotiation with a TimeGate 1107 but it can be implemented for Original Resources that never change 1108 state or do not change anymore past a certain point in their 1109 existence, meaning that URI-R and URI-M coincide either from the 1110 outset or starting at some point in time. This pattern is summarized 1111 in the below table. Examples are tweets or stable media resources on 1112 news sites. 1114 +----------+----------------+----------+---------+------------------+ 1115 | Pattern | Original | TimeGate | Memento | Negotiation | 1116 | | Resource | | | Style | 1117 +----------+----------------+----------+---------+------------------+ 1118 | Pattern | URI-R | - | URI-R | - | 1119 | 3 | | | | | 1120 +----------+----------------+----------+---------+------------------+ 1122 Table 4: Pattern 3 1124 Servers that host such resources can support the Memento framework by 1125 treating the stable resource (FixedResource as per 1126 [W3C.gen-ont-20090420]) as a Memento. As per Section 2.3, the use of 1127 Memento response headers and links in responses from such a stable 1128 resource is as follows: 1130 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1131 be provided. 1133 o The response MUST include a "Memento-Datetime" header. Its value 1134 expresses the datetime at which the resource became stable. 1135 Providing this value includes a promise that the resource has not 1136 changed since this datetime and will not change anymore beyond it. 1138 o The "Link" header MUST be provided and MUST have a link with the 1139 "original" Relation Type that has the URI-R of the stable resource 1140 itself as Target IRI. 1142 Figure 16 shows a response to an HTTP HEAD request for the resource 1143 with URI-R http://a.example.org/ that has been stable since March 1144 20th 2009. 1146 HTTP/1.1 200 OK 1147 Date: Thu, 21 Jan 2010 00:09:40 GMT 1148 Server: Apache-Coyote/1.1 1149 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT 1150 Link: ; rel="original" 1151 Content-Length: 0 1152 Content-Type: text/plain; charset=UTF-8 1153 Connection: close 1155 Figure 16: Response from URI-R=URI-M for Pattern 3 1157 4.4. Pattern 4 - Mementos without a TimeGate 1159 Cases may occur in which a server hosts Mementos but does not expose 1160 a TimeGate for them. This can, for example, be the case if the 1161 server's Mementos result from taking a snapshot of the state of a set 1162 of Original Resources from another server as it is being retired. As 1163 a result, only a single Memento per Original Resource is hosted, 1164 making the introduction of a TimeGate unnecessary. But it may also 1165 be the case for servers that host multiple Mementos for an Original 1166 Resource but consider exposing TimeGates too expensive. In this 1167 case, URI-R and URI-M are distinct, but a TimeGate is absent. This 1168 case is summarized in the below table. 1170 +----------+----------------+----------+---------+------------------+ 1171 | Pattern | Original | TimeGate | Memento | Negotiation | 1172 | | Resource | | | Style | 1173 +----------+----------------+----------+---------+------------------+ 1174 | Pattern | URI-R | - | URI-M | - | 1175 | 4 | | | | | 1176 +----------+----------------+----------+---------+------------------+ 1177 Table 5: Pattern 4 1179 Servers that host such Mementos without TimeGates can still support 1180 the Memento framework by providing the appropriate Memento headers 1181 and links. As per Section 2.3, these are as follows for a response 1182 from URI-M: 1184 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1185 be provided. 1187 o The response MUST include a "Memento-Datetime" header. Its value 1188 expresses the archival datetime of the Memento. 1190 o The "Link" header MUST be provided and it MUST have a link with 1191 the "original" Relation Type that has the URI-R of the associated 1192 Original Resource as Target IRI. The provision of other links is 1193 encouraged and is subject to the considerations described in 1194 Section 2.2. 1196 Figure 17 shows a response to an HTTP HEAD request for the Memento 1197 with URI-M 1198 http://arxiv.example.net/web/20010911203610/http://a.example.org/. 1199 Note the use of links: three links have the URI-M of the Memento as 1200 Target IRI and have respective Relation Types "memento", "first", and 1201 "last". This combination indicates that this is the only Memento for 1202 the Original Resource with Target IRI provided by the "original" link 1203 (http://a.example.org/) that the server is aware of. Note also that 1204 such a response does not imply that there is no server whatsoever 1205 that exposes a TimeGate; it merely means that the responding server 1206 neither provides nor is aware of the location of a TimeGate. 1208 HTTP/1.1 200 OK 1209 Date: Thu, 21 Jan 2010 00:09:40 GMT 1210 Server: Apache-Coyote/1.1 1211 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT 1212 Link: ; rel="original", 1213 1214 ; rel="first last memento" 1215 ; datetime="Tue, 11 Sep 2001 20:36:10 GMT" 1216 Content-Length: 0 1217 Content-Type: text/plain; charset=UTF-8 1218 Connection: close 1220 Figure 17: Response from URI-M<>URI-R for Pattern 4 1222 4.5. Special Cases 1224 4.5.1. Original Resource provides no "timegate" link 1226 Cases exist in which the response from the Original Resource does not 1227 contain a "timegate" link, including: 1229 o The Original Resource's server does not support the Memento 1230 framework; 1232 o The Original Resource no longer exists and the responding server 1233 is not aware of its prior existence; 1235 o The server that hosted the Original Resource no longer exists. 1237 In all these cases, the user agent SHOULD attempt to determine an 1238 appropriate TimeGate for the Original Resource, either automatically 1239 or interactively supported by the user. 1241 4.5.2. Server exists but Original Resource no longer does 1243 If possible, a server SHOULD also provide a "timegate" link in 1244 responses to requests for an Original Resource that the server knows 1245 used to exist, but no longer provides a current representation. This 1246 may allow access to Mementos for the Original Resource even if it no 1247 longer exists. A server's response to a request for the discontinued 1248 resource http://a.example.org/pic is illustrated in Figure 18. 1250 HTTP/1.1 404 Not Found 1251 Date: Thu, 21 Jan 2010 00:02:12 GMT 1252 Server: Apache 1253 Link: 1254 1255 ; rel="timegate" 1256 Content-Length: 255 1257 Connection: close 1258 Content-Type: text/html; charset=iso-8909-1 1260 Figure 18: Response from an Original Resource that not longer exists 1262 4.5.3. Issues with Accept-Datetime 1264 The following special cases may occur regarding the "Accept-Datetime" 1265 header when a user agent issues a request against a TimeGate: 1267 o If the value of the "Accept-Datetime" is either earlier than the 1268 datetime of the first Memento or later than the datetime of the 1269 most recent Memento known to the TimeGate, the first or most 1270 recent Memento SHOULD be selected, respectively. 1272 o If the value of the "Accept-Datetime" does not conform to the 1273 rfc1123-date construction rule of the BNF in Figure 1, the 1274 response MUST have a "400 Bad Request" HTTP status code. The use 1275 of Memento headers is as per Section 2.3. 1277 o If a user agent issues a request against a TimeGate and fails to 1278 include an "Accept-Datetime" request header, the most recent 1279 Memento SHOULD be selected. 1281 4.5.4. Memento of a 3XX response 1283 Cases exist in which HTTP responses with 3XX status codes are 1284 archived. For example, crawl-based web archives commonly archive 1285 responses with HTTP status codes "301 Moved Permanently" and "302 1286 Found" whereas Linked Data archives hold on to "303 See Other" 1287 responses. 1289 If the Memento requested by the user agent is an archived version of 1290 an HTTP response with a 3XX status code, the server's response MUST 1291 have the same 3XX HTTP status code. The use of other Memento headers 1292 is as described in the Memento column of Section 2.3. 1294 The user agent's handling of an HTTP response with a 3XX status code 1295 is not affected by the presence of a "Memento-Datetime" header. The 1296 user agent SHOULD behave in the same manner as it does with HTTP 1297 responses with a 3XX status code that do not have a "Memento- 1298 Datetime" header. 1300 However, the user agent MUST be aware that the URI that was selected 1301 from the "Location" header of an HTTP response with a 3XX status code 1302 might not be that of a Memento but rather of an Original Resource. 1303 In the latter case it SHOULD proceed by looking for a Memento of the 1304 selected Original Resource. 1306 For example, Figure 19 shows the response to an HTTP GET request for 1307 http://a.example.org issued on April 11 2008. This response is 1308 archived as a Memento of http://a.example.org that has as URI-M 1309 http://arxiv.example.net/web/20080411000650/http://a.example.org. 1310 The response to an HTTP GET on this URI-M is shown in Figure 20. It 1311 is a replay of the original response with "Memento-Datetime" and 1312 "Link" headers added, to allow a user agent to understand the 1313 response is a Memento. In Figure 20, the value of the "Location" 1314 header is the same as in the original response; it identifies an 1315 Original Resource. The user agent proceeds with finding a Memento 1316 for this Original Resource. Web archives sometimes overwrite the 1317 value that was originally provided in the "Location" header in order 1318 to point at a Memento they hold of the resource to which the redirect 1319 originally led. This is shown in Figure 21. In this case, the user 1320 agent may decide it found an appropriate Memento. 1322 HTTP/1.1 301 Moved Permanently 1323 Date: Fri, 11 Apr 2008 00:06:50 GMT 1324 Server: Apache 1325 Location: http://b.example.org 1326 Content-Length: 0 1327 Content-Type: text/plain; charset=UTF-8 1328 Connection: close 1330 Figure 19: Response is a redirect 1332 HTTP/1.1 301 Moved Permanently 1333 Date: Thu, 21 Jan 2010 00:09:40 GMT 1334 Server: Apache-Coyote/1.1 1335 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1336 Location: http://b.example.org 1337 Link: ; rel="original", 1338 1339 ; rel="timemap"; type="application/link-format", 1340 1341 ; rel="timegate" 1342 Content-Length: 0 1343 Content-Type: text/plain; charset=UTF-8 1344 Connection: close 1346 Figure 20: Response is a Memento of a redirect; leads to an Original 1347 Resource 1349 HTTP/1.1 301 Moved Permanently 1350 Date: Thu, 21 Jan 2010 00:09:40 GMT 1351 Server: Apache-Coyote/1.1 1352 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1353 Location: 1354 http://arxiv.example.net/web/20080411000655/http://b.example.org 1355 Link: ; rel="original", 1356 1357 ; rel="timemap"; type="application/link-format", 1358 1359 ; rel="timegate" 1360 Content-Length: 0 1361 Content-Type: text/plain; charset=UTF-8 1362 Connection: close 1364 Figure 21: Response is a Memento of a redirect; leads to a Memento 1366 4.5.5. Memento of responses with 4XX or 5XX HTTP status codes 1368 Cases exist in which responses with 4XX and 5XX HTTP status codes are 1369 archived. If the Memento requested by the user agent is an archived 1370 version of such an HTTP response, the server's response MUST have the 1371 same 4XX or 5XX HTTP status code. The use of other Memento headers 1372 is as described in the Memento column of Section 2.3. 1374 For example, Figure 22 shows the 404 response to an HTTP GET request 1375 for http://a.example.org issued on April 11 2008. This response is 1376 archived as a Memento of http://a.example.org, that has as URI-M 1377 http://arxiv.example.net/web/20080411000650/http://a.example.org. 1378 The response to an HTTP HEAD on this URI-M is shown in Figure 23. It 1379 is a replay of the original response with "Memento-Datetime" and 1380 "Link" headers added, to allow a user agent to understand the 1381 response is a Memento. 1383 HTTP/1.1 404 Not Found 1384 Date: Fri, 11 Apr 2008 00:06:50 GMT 1385 Server: Apache 1386 Content-Length: 0 1387 Content-Type: text/plain; charset=UTF-8 1388 Connection: close 1390 Figure 22: Response is a 404 1392 HTTP/1.1 404 Not Found 1393 Date: Thu, 21 Jan 2010 00:09:40 GMT 1394 Server: Apache-Coyote/1.1 1395 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 1396 Link: ; rel="original", 1397 1398 ; rel="timemap"; type="application/link-format", 1399 1400 ; rel="timegate" 1401 Content-Length: 0 1402 Content-Type: text/plain; charset=UTF-8 1403 Connection: close 1405 Figure 23: Response is a Memento of a 404 1407 4.5.6. Sticky "Memento-Datetime" value for Mementos 1409 The provision of a "Memento-Datetime" in a response entails a promise 1410 that the response is frozen in time. As a consequence, the "Memento- 1411 Datetime" header associated with a Memento MUST be "sticky" in the 1412 following ways: 1414 o The server that originally assigns the "Memento-Datetime" header 1415 and value to a specific response MUST retain that header in all 1416 future responses to HTTP requests (with or without "Accept- 1417 Datetime" header) that occur against the Memento after the time of 1418 the original assignment of the header, and it MUST NOT change its 1419 associated value. 1421 o Applications that mirror Mementos at a different URI MUST retain 1422 the "Memento-Datetime" header and MUST NOT change its value unless 1423 mirroring involves a meaningful state change. This allows, for 1424 example, duplicating a web archive at a new location while 1425 preserving the value of the "Memento-Datetime" header of the 1426 archived resources. In this example, the "Last-Modified" header 1427 will be updated to reflect the time of mirroring at the new URI, 1428 whereas the value for "Memento-Datetime" will be maintained. 1430 4.5.7. Intermediate Resources 1432 An intermediate resource is a resource that issues a redirect to a 1433 TimeGate, to a Memento, or to another intermediate resource, and thus 1434 plays an active role in the Memento infrastructure. Intermediate 1435 resources commonly exist in web archives on the path from a TimeGate 1436 to an appropriate Memento. 1438 A response of an intermediate resource has an HTTP status code 1439 indicative of HTTP redirection (e.g. 302) and uses Memento headers 1440 and links that allow to recognize that the resource plays a role in 1441 the Memento framework: 1443 o A "Vary" header that includes an "accept-datetime" value MUST NOT 1444 be provided. 1446 o The response MUST NOT include a "Memento-Datetime" header. 1448 o The "Link" header MUST be provided and it MUST have a link with 1449 the "original" Relation Type that has the URI-R of the associated 1450 Original Resource as Target IRI. Links with "timegate", 1451 "timemap", and "memento" Relation Types are OPTIONAL and, if 1452 provided, MUST pertain to the Original Resource for which the user 1453 agent is trying to obtain a Memento. 1455 A user agent SHOULD follow a redirection provided by an intermediate 1456 resource; multiple such redirections can be chained. 1458 Consider the case where a user agent follows the "timegate" link 1459 provided in Figure 9 and engages in datetime negotiation with the 1460 assumed TimeGate in the manner shown in Figure 10. But instead of 1461 receiving a response as shown in Figure 11, it receives the one shown 1462 below in Figure 24. Such a response is umabiguosuly recognizable as 1463 coming from an intermediate resource. 1465 HTTP/1.1 302 Found 1466 Date: Thu, 21 Jan 2010 00:06:50 GMT 1467 Server: Apache 1468 Location: 1469 http://arxiv.example.net/new-timegate/http://a.example.org/ 1470 Link: ; rel="original" 1471 Content-Length: 0 1472 Content-Type: text/plain; charset=UTF-8 1473 Connection: close 1475 Figure 24: Redirecting Resource redirects to a TimeGate 1477 5. TimeMaps 1479 A TimeMap is introduced to support retrieving a comprehensive list of 1480 all Mementos for a specific Original Resource known to a server. The 1481 entity-body of a response to an HTTP GET request issued against a 1482 TimeMap's URI-T: 1484 o MUST list the URI-R of the Original Resource that the TimeMap is 1485 about; 1487 o MUST list the URI-M and archival datetime of each Memento for the 1488 Original Resource known to the server, preferably in a single 1489 document, or, alternatively in multiple documents that can be 1490 gathered by following contained links with a "timemap" Relation 1491 Type; 1493 o SHOULD list the URI-G of one or more TimeGates for the Original 1494 Resource known to the responding server; 1496 o SHOULD, for self-containment, list the URI-T of the TimeMap 1497 itself; 1499 o MUST unambiguously type listed resources as being Original 1500 Resource, TimeGate, Memento, or TimeMap. 1502 The entity-body of a response from a TimeMap MAY be serialized in 1503 various ways, but the link-value format serialization described here 1504 MUST be supported. In this serialization, the entity-body MUST be 1505 formatted in the same way as the value of an HTTP "Link" header, and 1506 hence MUST comply to the "link-value" construction rule of "Section 1507 5. The Link Header Field" of [RFC5988], and the media type of the 1508 entity-body MUST be "application/link-format" as introduced in 1509 [RFC6690]. Links contained in the entity-body MUST be interpreted as 1510 follows: 1512 o The Context IRI is set to the anchor parameter, when specified; 1514 o The Context IRI of links with the "self" Relation Types is the 1515 URI-T of the TimeMap, i.e. the URI of the resource from which the 1516 TimeMap was requested; 1518 o The Context IRI of all other links is the URI-R of the Original 1519 Resource, which is provided as the Target IRI of the link with an 1520 "original" Relation Type. 1522 In order to retrieve the link-value serialization of a TimeMap, a 1523 user agent SHOULD use an "Accept" request header with a value set to 1524 "application/link-format". This is shown in Figure 25. 1526 GET /timemap/http://a.example.org/ HTTP/1.1 1527 Host: arxiv.example.net 1528 Accept: application/link-format;q=1.0 1529 Connection: close 1531 Figure 25: Request for a TimeMap 1533 If the TimeMap requested by the user agent exists, the server's 1534 response has a "200 OK" HTTP status code and the list of Mementos is 1535 provided in the entity-body of the response. Such a response is 1536 shown in Figure 26 1538 HTTP/1.1 200 OK 1539 Date: Thu, 21 Jan 2010 00:06:50 GMT 1540 Server: Apache 1541 Content-Length: 4883 1542 Content-Type: application/link-format 1543 Connection: close 1545 ;rel="original", 1546 1547 ; rel="self";type="application/link-format" 1548 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1549 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1550 1551 ; rel="timegate", 1552 1553 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" 1554 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1555 1556 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" 1557 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1558 1559 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" 1560 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1561 1562 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT" 1563 ; license="http://creativecommons.org/publicdomain/zero/1.0/", 1564 ... 1566 Figure 26: Response from a TimeMap 1568 5.1. Index and Paging TimeMaps 1570 Cases exist in which a TimeMap points at one or more other TimeMaps: 1572 o Index Timemap - A TimeMap can merely point at other TimeMaps and 1573 not list any Mementos itself. This can happen when Mementos are 1574 spread across several archives that share a front-end. An example 1575 is shown in Figure 27. 1577 o Paging Timemap - The number of available Mementos can require 1578 introducing multiple TimeMaps that can be paged. An example is 1579 shown in Figure 28. Note that a Paging TimeMap contains links to 1580 other TimeMaps but actually also lists Mementos. 1582 In both cases, including the "from" and "until" attributes for 1583 "timemap" links is RECOMMENDED as a means to express the temporal 1584 span of Mementos listed in each TimeMap. Note that TimeMaps obtained 1585 by following a "timemap" link can contain links to further TimeMaps. 1587 ;rel="original", 1588 1589 ; rel="timegate", 1590 1591 ; rel="self";type="application/link-format", 1592 1593 ; rel="timemap";type="application/link-format" 1594 ; from="Wed, 21 Jun 2000 04:41:56 GMT" 1595 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1596 1597 ; rel="timemap";type="application/link-format" 1598 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1599 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1600 1601 ; rel="timemap";type="application/link-format" 1602 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1604 Figure 27: Index TimeMap 1606 ;rel="original", 1607 1608 ; rel="timegate", 1609 1610 ; rel="self";type="application/link-format" 1611 ; from="Tue, 20 Jun 2000 18:02:59 GMT" 1612 ; until="Wed, 09 Apr 2008 20:30:51 GMT", 1613 1614 ; rel="timemap";type="application/link-format" 1615 ; from="Thu, 10 Apr 2008 20:30:51 GMT" 1616 ; until="Tue, 27 Oct 2009 20:49:54 GMT", 1617 1618 ; rel="timemap";type="application/link-format" 1619 ; from="Thu, 29 Oct 2009 20:30:51 GMT" 1620 ; until="Fri, 31 Aug 2012 12:22:34 GMT" 1621 1622 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", 1623 1624 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT", 1625 1626 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT", 1627 ... 1629 Figure 28: Paging TimeMap 1631 5.2. Mementos for TimeMaps 1633 A TimeMap can itself act as an Original Resource for which a TimeGate 1634 and Mementos may exist. Hence, as per Section 2.3, the response from 1635 a TimeMap could include a "timegate" link to a TimeGate via which 1636 prior TimeMap versions are available. And, in cases where URI-T=URI- 1637 R=URI-G (a TimeMap is an Original Resource that acts as its own 1638 TimeGate), an "original" link pointing at the TimeMap URI-T would be 1639 included. 1641 Therefore, caution is required in cases where a TimeMap for an 1642 Original Resource wants to explicitly express in a Link header for 1643 which Original Resource it is a TimeMap. It can do so by including a 1644 "timemap" link that has the URI-R of the Original Resource as Context 1645 IRI and the URI-T of the TimeMap as Target IRI. 1647 Figure 29 shows the response to an HTTP HEAD request against a 1648 TimeMap that has 1649 http://arxiv.example.net/timemap/http://a.example.org as URI-T. This 1650 TimeMap provides information about Mementos for the Original Resource 1651 that has http://a.example.org as URI-R. The response includes an 1652 "original" link pointing to the Original Resource that this TimeMap 1653 is about. Note the use of the "anchor" attribute in this link to 1654 convey the URI-R of that Original Resource. 1656 HTTP/1.1 200 OK 1657 Date: Thu, 21 Jan 2010 00:06:50 GMT 1658 Server: Apache 1659 Link: 1660 ; anchor="http://a.example.org"; rel="timemap" 1661 ; type="application/link-format" 1662 Content-Length: 0 1663 Content-Type: application/link-format; charset=UTF-8 1664 Connection: close 1666 Figure 29: TimeMap links to the Original Resource it is about 1668 6. IANA Considerations 1670 This memo requires IANA to register the Accept-Datetime and Memento- 1671 Datetime HTTP headers defined in Section 2.1.1 in the appropriate 1672 IANA registry. 1674 This memo requires IANA to register the Relation Types "original", 1675 "timegate", "timemap", and "memento" defined in Section 2.2 in the 1676 appropriate IANA registry. 1678 This memo requires IANA to register the "datetime" and "license" 1679 attributes for the "memento" Relation Type, as defined in 1680 Section 2.2.4, in the appropriate IANA registry. 1682 This memo requires IANA to register the "from" and "until" attributes 1683 for the "timemap" Relation Type, as defined in Section 2.2.4, in the 1684 appropriate IANA registry. 1686 7. Security Considerations 1688 Provision of a "timegate" HTTP "Link" header in responses to requests 1689 for an Original Resource that is protected (e.g., 401 or 403 HTTP 1690 response codes) is OPTIONAL. The inclusion of this Link when 1691 requesting authentication is at the server's discretion; cases may 1692 exist in which a server protects the current state of a resource, but 1693 supports open access to prior states and thus chooses to supply a 1694 "timegate" HTTP "Link" header. Conversely, the server may choose to 1695 not advertise the TimeGate URIs (e.g., they exist in an intranet 1696 archive) for unauthenticated requests. 1698 The veracity of archives and the relationships between Original 1699 Resources and Mementos is beyond the scope of this document. Even in 1700 the absence of malice, it is possible for separate archives to have 1701 different Mementos for the same Original Resource at the same 1702 datetime if the state of the Original Resource was dependent on the 1703 requesting archive's user agent IP address, specific HTTP request 1704 headers, and possibly other factors. 1706 Further authentication, encryption and other security related issues 1707 are otherwise orthogonal to Memento. 1709 8. Changelog 1711 v06 2013-02-14 HVDS MLN RS draft-vandesompel-memento-06 1713 o Major overhaul of the presentation of the specification. 1715 o Specification of patterns whereby URI-R=URI-G and with both 200 1716 and 302 negotation style. 1718 o Removal of Discovery section to increase focus on datetime 1719 negotation aspects. 1721 v05 2012-09-01 HVDS MLN RS draft-vandesompel-memento-05 1722 o Clarified the section on Memento Relation Types. 1724 o Re-introduced "license" attribute for "memento" Relation Type as 1725 it will become essential for IIPC. 1727 o Introduced from and until attributes for "timemap" links to 1728 accomodate paged TimeMap cases. 1730 o Introduced the notion of Redirecting Resource and inserted related 1731 information in various sections. 1733 o Added discovery of Mementos via host-meta. 1735 o Corrected ambiguous uses of the term "representation". 1737 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04 1739 o Removed the possibility to use an interval indicator in an Accept- 1740 Datetime header as no one is implementing it. 1742 o Corrected typo in Other Relation Types table. 1744 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap 1745 paging. 1747 o Changed Discovery component from using robots.txt with Memento- 1748 specific add-ons to well-known URI and host-meta. 1750 o Removed "embargo" and "license" attributes for links with a 1751 "memento" Relation Type because no one is using them. 1753 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03 1755 o Added description of Mementos of HTTP responses with 3XX, 4XX and 1756 5XX status code. 1758 o Clarified that a TimeGate must not use the "Memento-Datetime" 1759 header. 1761 o Added wording to warn for possible cache problems with Memento 1762 implementations that choose to have an Original Resource and and 1763 its TimeGate coincide. 1765 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02 1767 o Added scenario in which a TimeGate redirects to another TimeGate. 1769 o Reorganized TimeGate section to better reflect the difference 1770 between requests with and without interval indicator. 1772 o Added recommendation to provide "memento" links to Mementos in the 1773 vicinity of the preferred interval provided by the user agent, in 1774 case of a 406 response. 1776 o Removed TimeMap Feed material from the Discovery section as a 1777 result of discussions regarding (lack of) scalability of the 1778 approach with representatives of the International Internet 1779 Preservation Consortium. An alternative approach to support batch 1780 discovery of Mementos will be specified. 1782 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01 1784 o Introduced wording and reference to indicate a Memento is a 1785 FixedResource. 1787 o Introduced "Sticky Memento-Datetime" notion and clarified wording 1788 about retaining "Memento-Datetime" headers and values when a 1789 Memento is mirrored at different URI. 1791 o Introduced section about handling both datetime and regular 1792 negotiation. 1794 o Introduced section about Mementos Without TimeGate. 1796 o Made various changes in the section Relation Type "memento", 1797 including addition of "license" and "embargo" attributes, and 1798 clarification of rules regarding the use of "memento" links. 1800 o Moved section about TimeMaps inside the Datetime Negotiation 1801 section, and updated it. 1803 o Restarted the Discovery section from scratch. 1805 v01 2010-11-11 HVDS MLN RS First public version 1806 draft-vandesompel-memento-00 1808 v00 2010-10-19 HVDS MLN RS Limited circulation version 1810 2010-07-22 HVDS MLN First internal version 1812 9. Acknowledgements 1814 The Memento effort is funded by the Library of Congress. Many thanks 1815 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry 1816 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers, 1817 James Anderson, Tim Starling, Martin Klein for feedback. Many thanks 1818 to Samuel Adams, Scott Ainsworth, Lyudmilla Balakireva, Frank McCown, 1819 Harihar Shankar, Brad Tofel for early implementations. 1821 10. References 1823 10.1. Normative References 1825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1826 Requirement Levels", BCP 14, RFC 2119, March 1997. 1828 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1829 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1830 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1832 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 1833 RFC 4151, October 2005. 1835 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1836 Syndication Format", RFC 4287, December 2005. 1838 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1839 Uniform Resource Identifiers (URIs)", RFC 5785, 1840 April 2010. 1842 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types 1843 for Simple Version Navigation between Web Resources", 1844 RFC 5829, April 2010. 1846 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1848 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", 1849 RFC 6415, October 2011. 1851 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1852 Format", RFC 6690, August 2012. 1854 10.2. Informative References 1856 [Fitch] Fitch, "Web site archiving - an approach to recording 1857 every materially different response produced by a 1858 website", July 2003, 1859 . 1861 [I-D.masinter-dated-uri] 1862 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on 1863 dated URIs", draft-masinter-dated-uri-10 (work in 1864 progress), January 2012. 1866 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1867 and Support", STD 3, RFC 1123, October 1989. 1869 [W3C.REC-aww-20041215] 1870 Jacobs and Walsh, "Architecture of the World Wide Web", 1871 December 2004, . 1873 [W3C.gen-ont-20090420] 1874 Berners-Lee, "Architecture of the World Wide Web", 1875 April 2009, . 1877 Authors' Addresses 1879 Herbert VandeSompel 1880 Los Alamos National Laboratory 1881 PO Box 1663 1882 Los Alamos, New Mexico 87545 1883 USA 1885 Phone: +1 505 667 1267 1886 Email: hvdsomp@gmail.com 1887 URI: http://public.lanl.gov/herbertv/ 1889 Michael Nelson 1890 Old Dominion University 1891 Norfolk, Virginia 23529 1892 USA 1894 Phone: +1 757 683 6393 1895 Email: mln@cs.odu.edu 1896 URI: http://www.cs.odu.edu/~mln/ 1898 Robert Sanderson 1899 Los Alamos National Laboratory 1900 PO Box 1663 1901 Los Alamos, New Mexico 87545 1902 USA 1904 Phone: +1 505 665 5804 1905 Email: azaroth42@gmail.com 1906 URI: http://public.lanl.gov/rsanderson/