idnits 2.17.1
draft-vandesompel-memento-04.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 (May 24, 2012) is 4355 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 1992, but no explicit
reference was found in the text
== Outdated reference: A later version (-14) exists of
draft-ietf-core-link-format-12
** 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: November 25, 2012 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 May 24, 2012
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-04
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 obtaining representations of prior states of a
18 resource, available from archival resources in Web archives or
19 version resources in content management systems, by leveraging the
20 resource's URI and a preferred datetime. To this end, the framework
21 introduces datetime negotiation (a variation on content negotiation),
22 and new Relation Types for the HTTP "Link" header aimed at
23 interlinking resources with their archival/version resources. It
24 also introduces various discovery mechanisms that further support
25 bridging the present and past Web.
27 Status of this Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on November 25, 2012.
44 Copyright Notice
46 Copyright (c) 2012 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
63 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 6
65 2. The Memento Framework, Datetime Negotiation component:
66 HTTP headers, HTTP Link Relation Types . . . . . . . . . . . . 7
67 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 7
68 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 7
69 2.1.1.1. Values for Accept-Datetime . . . . . . . . . . . . 8
70 2.1.1.2. Values for Memento-Datetime . . . . . . . . . . . 9
71 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 9
72 2.1.3. Location . . . . . . . . . . . . . . . . . . . . . . . 9
73 2.1.4. Link . . . . . . . . . . . . . . . . . . . . . . . . . 9
74 2.2. Link Header Relation Types . . . . . . . . . . . . . . . . 9
75 2.2.1. Memento Framework Relation Types . . . . . . . . . . . 10
76 2.2.1.1. Relation Type "original" . . . . . . . . . . . . . 10
77 2.2.1.2. Relation Type "timegate" . . . . . . . . . . . . . 11
78 2.2.1.3. Relation Type "timemap" . . . . . . . . . . . . . 11
79 2.2.1.4. Relation Type "memento" . . . . . . . . . . . . . 12
80 2.2.2. Other Relation Types . . . . . . . . . . . . . . . . . 13
81 3. The Memento Framework, Datetime Negotiation component:
82 HTTP Interactions . . . . . . . . . . . . . . . . . . . . . . 14
83 3.1. Interactions with an Original Resource . . . . . . . . . . 16
84 3.1.1. Step 1: User Agent Requests an Original Resource . . . 16
85 3.1.2. Step 2: Server Responds to a Request for an
86 Original Resource . . . . . . . . . . . . . . . . . . 16
87 3.1.2.1. Original Resource is an Appropriate Memento . . . 17
88 3.1.2.2. Server Exists and Original Resource Used to
89 Exist . . . . . . . . . . . . . . . . . . . . . . 19
90 3.1.2.3. Missing or Inadequate "timegate" Link in
91 Original Server's Response . . . . . . . . . . . . 19
92 3.2. Interactions with a TimeGate . . . . . . . . . . . . . . . 20
93 3.2.1. Step 3: User Agent Negotiates with a TimeGate . . . . 20
94 3.2.2. Step 4: Server Responds to Negotiation with
95 TimeGate . . . . . . . . . . . . . . . . . . . . . . . 20
97 3.2.2.1. Successful Scenario . . . . . . . . . . . . . . . 20
98 3.2.2.2. Multiple Matching Mementos . . . . . . . . . . . . 22
99 3.2.2.3. TimeGate Redirects to another TimeGate . . . . . . 23
100 3.2.2.4. Accept-Datetime and other Accept Headers
101 Provided . . . . . . . . . . . . . . . . . . . . . 24
102 3.2.2.5. Accept-Datetime Unparseable . . . . . . . . . . . 25
103 3.2.2.6. Accept-Datetime Not Provided . . . . . . . . . . . 25
104 3.2.2.7. TimeGate Does Not Exist . . . . . . . . . . . . . 25
105 3.2.2.8. HTTP Methods other than HEAD/GET . . . . . . . . . 25
106 3.2.3. Recognizing a TimeGate . . . . . . . . . . . . . . . . 26
107 3.3. Interactions with a Memento . . . . . . . . . . . . . . . 27
108 3.3.1. Step 5: User Agent Requests a Memento . . . . . . . . 27
109 3.3.2. Step 6: Server Responds to a Request for a Memento . . 27
110 3.3.2.1. Common Scenario . . . . . . . . . . . . . . . . . 27
111 3.3.2.2. Memento of a 3XX Response . . . . . . . . . . . . 29
112 3.3.2.3. Memento of Responses with Other HTTP Status
113 Codes . . . . . . . . . . . . . . . . . . . . . . 31
114 3.3.2.4. Mementos Without a TimeGate . . . . . . . . . . . 32
115 3.3.2.5. Memento Does not Exist . . . . . . . . . . . . . . 33
116 3.3.3. Recognizing a Memento . . . . . . . . . . . . . . . . 34
117 3.4. Interactions with a TimeMap . . . . . . . . . . . . . . . 34
118 3.4.1. User Agent Requests a TimeMap . . . . . . . . . . . . 35
119 3.4.2. Server Responds to a Request for a TimeMap . . . . . . 35
120 4. The Memento Framework, Discovery of TimeGates and TimeMaps . . 38
121 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
122 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
123 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 41
124 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
125 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
126 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
127 9.2. Informative References . . . . . . . . . . . . . . . . . . 44
128 Appendix A. Appendix B: A Sample, Successful Memento
129 Request/Response cycle . . . . . . . . . . . . . . . 44
130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
132 1. Introduction
134 1.1. Terminology
136 This specification uses the terms "resource", "request", "response",
137 "entity", "entity-body", "entity-header", "content negotiation",
138 "client", "user agent", "server" as described in [RFC2616], and it
139 uses the terms "representation" and "resource state" as described in
140 [W3C.REC-aww-20041215].
142 In addition, the following terms specific to the Memento framework
143 are introduced:
145 o Original Resource: An Original Resource is a resource that exists
146 or used to exist, and for which access to one of its prior states
147 is desired.
149 o Memento: A Memento for an Original Resource is a resource that
150 encapsulates a prior state of the Original Resource. A Memento
151 for an Original Resource as it existed at time Tj is a resource
152 that encapsulates the state that the Original Resource had at time
153 Tj.
155 o TimeGate: A TimeGate for an Original Resource is a resource that
156 is capable of negotiation to allow selective, datetime-based,
157 access to prior states of the Original Resource.
159 o TimeMap: A TimeMap for an Original Resource is a resource from
160 which a list of URIs of Mementos of the Original Resource is
161 available.
163 1.2. Purpose
165 The state of an Original Resource may change over time.
166 Dereferencing its URI at any specific moment in time during its
167 existence yields a representation of its then current state.
168 Dereferencing its URI at any time past its existence no longer yields
169 a meaningful representation, if any. Still, in both cases, resources
170 may exist that encapsulate prior states of the Original Resource.
171 Each such resource, named a Memento, has its own URI that, when
172 dereferenced, returns a representation of a prior state of the
173 Original Resource. Mementos may, for example, exist in Web archives,
174 Content Management Systems, or Revision Control Systems.
176 Examples are:
178 Mementos for Original Resource http://www.ietf.org/ :
180 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
182 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
183 www.ietf.org/
185 Mementos for Original Resource
186 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol :
188 o http://en.wikipedia.org/w/
189 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
191 o http://en.wikipedia.org/w/
192 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
194 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
195 wiki/Hypertext_Transfer_Protocol
197 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
199 o http://www.w3.org/TR/2004/PR-webarch-20041105/
201 o http://www.w3.org/TR/2002/WD-webarch-20020830/
203 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
204 www.w3.org/TR/webarch/
206 In the abstract, Memento introduces a mechanism to access versions of
207 Web resources that:
209 o Is fully distributed in the sense that resource versions may
210 reside on multiple hosts, and that any such host is likely only
211 aware of the versions it holds;
213 o Uses the global notion of datetime as a resource version indicator
214 and access key;
216 o Leverages the following primitives of W3C.REC-aww-20041215
217 [W3C.REC-aww-20041215]: resource, resource state, representation,
218 content negotiation, and link.
220 The core components of Memento's mechanism to access resource
221 versions are:
223 1. The abstract notion of the state of a resource identified by
224 URI-R as it existed at some time Tj. Note the relationship with the
225 ability to identify a the state of a resource at some datetime Tj by
226 means of a URI as intended by the proposed Dated URI scheme
227 [I-D.masinter-dated-uri].
229 2. A bridge from the present to the past, consisting of:
231 o An appropriately typed link from a resource identified by URI-R to
232 an associated TimeGate identified by URI-G, which is aware of (at
233 least part of the) version history of the resource identified by
234 URI-R;
236 o The ability to content negotiate in the datetime dimension with
237 the TimeGate identified by URI-G, as a means to obtain a
238 representation of the state that the resource identified by URI-R
239 had at some datetime Tj.
241 3. A bridge from the past to the present, consisting of an
242 appropriately typed link from a resource identified by URI-M, which
243 encapsulates the state a resource identified by URI-R had at some
244 datetime Tj, to the resource identified by URI-R.
246 Section 2 and Section 3 of this document are concerned with
247 specifying an instantiation of these abstractions for resources that
248 are identified by HTTP(S) URIs, whereas Section 4 details an approach
249 to support batch discovery of TimeGates and TimeMaps that is based on
250 well-known URI [RFC5785] and host-meta [RFC6415].
252 1.3. Notational Conventions
254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
256 document are to be interpreted as described in [RFC2119].
258 When needed for extra clarity, the following conventions are used:
260 o URI-R is used to denote the URI of an Original Resource.
262 o URI-G is used to denote the URI of a TimeGate.
264 o URI-M is used to denote the URI of a Memento.
266 o URI-T is used to denote the URI of a TimeMap.
268 o When scenarios are described that involve multiple Mementos,
269 URI-M0 denotes the URI of the first Memento known to the
270 responding server, URI-Mn denotes the URI of the most recent known
271 Memento, URI-Mj denotes the URI of the selected Memento, URI-Mi
272 denotes the URI of the Memento that is temporally previous to the
273 selected Memento, and URI-Mk denotes the URI of the Memento that
274 is temporally after the selected Memento. The respective
275 datetimes for these Mementos are T0, Tn, Tj, Ti, and Tk; it holds
276 that T0 <= Ti <= Tj <= Tk <= Tn.
278 2. The Memento Framework, Datetime Negotiation component: HTTP headers,
279 HTTP Link Relation Types
281 The Memento framework is concerned with Original Resources,
282 TimeGates, Mementos, and TimeMaps that are identified by HTTP or
283 HTTPS URIs. Details are only provided for resources identified by
284 HTTP URIs but apply similarly to those with HTTPS URIs.
286 2.1. HTTP Headers
288 The Memento framework operates at the level of HTTP request and
289 response headers. It introduces two new headers ("Accept-Datetime",
290 "Memento-Datetime"), introduces new values for two existing headers
291 ("Vary", "Link"), and uses an existing header ("Location") without
292 modification. All these headers are described below. Other HTTP
293 headers are present or absent in Memento response/request cycles as
294 specified by [RFC2616].
296 2.1.1. Accept-Datetime, Memento-Datetime
298 The "Accept-Datetime" request header is used by a user agent to
299 indicate it wants to retrieve a representation of a Memento that
300 encapsulates a past state of an Original Resource. To that end, the
301 "Accept-Datetime" header is conveyed in an HTTP GET/HEAD request
302 issued against a TimeGate for an Original Resource, and its value
303 indicates the datetime of the desired past state of the Original
304 Resource. The "Accept-Datetime" request header has no defined
305 meaning for HTTP methods other than HEAD and GET.
307 The "Memento-Datetime" response header is used by a server to
308 indicate that the response contains a representation of a Memento,
309 and its value expresses the datetime of the state of an Original
310 Resource that is encapsulated in that Memento. The URI of that
311 Original Resource is provided in the response, as the Target IRI (see
312 [RFC5988]) of a link provided in the HTTP "Link" header that has a
313 Relation Type of "original" (see Section 2.2).
315 The presence of a "Memento-Datetime" header and associated value for
316 a given resource constitutes a promise that the resource is stable
317 and that its state will no longer change. This means that, in terms
318 of the Ontology for Relating Generic and Specific Information
319 Resources (see W3C.gen-ont-20090420 [W3C.gen-ont-20090420]), a
320 Memento is a FixedResource.
322 As a consequence, "Memento-Datetime" headers associated with a
323 Memento MUST be "sticky" in the following ways:
325 o The server that originally assigns the "Memento-Datetime" header
326 and value MUST retain that header in all responses to HTTP HEAD/
327 GET requests (with or without "Accept-Datetime" header) that occur
328 against the Memento after the time of the original assignment of
329 the header, and it MUST NOT change its associated value.
331 o Applications that mirror Mementos at a different URI MUST NOT
332 change the "Memento-Datetime" header and value of those Mementos
333 unless mirroring involves a meaningful state change. This allows,
334 for example, duplicating a Web archive at a new location while
335 preserving the value of the "Memento-Datetime" header of the
336 archived resources. In this example, the "Last-Modified" header
337 will be updated to reflect the time of mirroring at the new URI,
338 whereas the value for "Memento-Datetime" will be sticky.
340 2.1.1.1. Values for Accept-Datetime
342 Values for the "Accept-Datetime" header consist of a MANDATORY
343 datetime expressed according to the [RFC1123] format, which is
344 formalized by the rfc1123-date construction rule of the BNF in
345 Figure 1. The datetime MUST be represented in Greenwich Mean Time
346 (GMT).
348 Example of an "Accept-Datetime" request header:
350 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
352 The user agent uses the MANDATORY datetime value to convey its
353 preferred datetime for a Memento.
355 accept-dt-value = rfc1123-date *SP
356 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
357 date1 = 2DIGIT SP month SP 4DIGIT
358 ; day month year (e.g., 20 Mar 1957)
359 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
360 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
361 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
362 "Sun"
363 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
364 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
366 Figure 1: BNF for the datetime format
368 2.1.1.2. Values for Memento-Datetime
370 Values for the "Memento-Datetime" headers MUST be datetimes expressed
371 according to the rfc1123-date construction rule of the BNF in
372 Figure 1; they MUST be represented in Greenwich Mean Time (GMT).
374 An example "Memento-Datetime" response header:
376 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
378 2.1.2. Vary
380 The "Vary" response header is used in responses to indicate the
381 dimensions in which content negotiation was successfully applied.
382 This header is used in the Memento framework to indicate both whether
383 datetime negotiation was applied or is supported by the responding
384 server.
386 For example, this use of the "Vary" header indicates that datetime is
387 the only dimension in which negotiation was applied:
389 Vary: negotiate, accept-datetime
391 The use of the "Vary" header in this example shows that both datetime
392 negotiation, and media type content negotiation were applied:
394 Vary: negotiate, accept-datetime, accept
396 2.1.3. Location
398 The "Location" header is used as defined in [RFC2616]. Examples are
399 given in Section 3 below.
401 2.1.4. Link
403 The "Link" response header is specified in [RFC5988]. The Memento
404 framework introduces new Relation Types to convey typed links among
405 Original Resources, TimeGates, Mementos, and TimeMaps. Already
406 existing Relation Types, among others, aimed at supporting navigation
407 among a series of ordered resources may also be used in the Memento
408 framework. This is detailed in Link Header Relation Types
409 (Section 2.2), below.
411 2.2. Link Header Relation Types
413 The "Link" header specified in [RFC5988] is semantically equivalent
414 to the "" element in HTML, as well as the "atom:link" feed-
415 level element in Atom [RFC4287]. By default, the origin of a link
416 expressed by an entry in a "Link" header (named Context IRI in
417 [RFC5988]) is the IRI of the requested resource. This default can be
418 overwritten using the "anchor" attribute in the entry.
420 2.2.1. Memento Framework Relation Types
422 The Relation Types used in the Memento framework are listed in the
423 remainder of this section, and their use is summarized in the below
424 table. Appendix A shows a Memento request/response cycle that uses
425 all the Relation Types that are introduced here.
427 +----------+-------------------+---------------------+--------------+
428 | Relation | Original Resource | TimeGate | Memento |
429 | Type | | | |
430 +----------+-------------------+---------------------+--------------+
431 | original | NA, except see | REQUIRED, 1 | REQUIRED, 1 |
432 | | Section 3.1.2.1 | | |
433 | timegate | RECOMMENDED, 0 or | REQUIRED, 1 in case | RECOMMENDED, |
434 | | more | of Section 3.2.2.3 | 0 or more |
435 | timemap | NA | RECOMMENDED, 0 or | RECOMMENDED, |
436 | | | more | 0 or more |
437 | memento | NA, except see | REQUIRED, 1 or more | REQUIRED, 1 |
438 | | Section 3.1.2.1 | | or more |
439 +----------+-------------------+---------------------+--------------+
441 Table 1: The use of Relation Types
443 2.2.1.1. Relation Type "original"
445 "original" -- A "Link" header entry with a Relation Type of
446 "original" is used to point from a TimeGate or a Memento to their
447 associated Original Resource. In both cases, an entry with the
448 "original" Relation Type MUST occur exactly once in a "Link" header.
449 Details for the entry are as follows:
451 o Context IRI: URI-G, URI-M
453 o Target IRI: URI-R
455 o Relation Type: "original"
457 o Use: REQUIRED
459 o Cardinality: 1
461 2.2.1.2. Relation Type "timegate"
463 "timegate" -- A "Link" header entry with a Relation Type of
464 "timegate" is used to point both from an Original Resource or a
465 Memento to a TimeGate for the Original Resource. In both cases, the
466 use of an entry with the "timegate" Relation Type is RECOMMENDED.
467 Since more than one TimeGate can exist for any Original Resource,
468 multiple entries with a "timegate" Relation Type MAY occur, each with
469 a distinct Target IRI. Since a TimeGate has no mime type, the "type"
470 attribute MUST NOT be used on Links with a "timegate" Relation Type.
471 Details for the entry are as follows:
473 o Context IRI: URI-R or URI-Mj
475 o Target IRI: URI-G
477 o Relation Type: "timegate"
479 o Use: RECOMMENDED
481 o Cardinality: 0 or more
483 In the special case (see Section 3.2.2.3) where a TimeGate redirects
484 to another TimeGate for the Original Resource, a "Link" header entry
485 with a Relation Type of "timegate" MUST be used to point from the
486 former to the latter.
488 2.2.1.3. Relation Type "timemap"
490 "timemap" -- A "Link" header entry with a Relation Type of "timemap"
491 is used to point from both a TimeGate or a Memento to a TimeMap
492 resource from which a list of Mementos known to the responding server
493 is available. Use of an entry with the "timemap" Relation Type is
494 RECOMMENDED, and, since multiple serializations of a TimeMap are
495 possible, multiple entries with a "timemap" Relation Type MAY occur,
496 each with a distinct Target IRI, and each with a MANDATORY "type"
497 attribute to convey the mime type of the TimeMap serialization.
498 Details for the entry are as follows:
500 o Context IRI: URI-G or URI-Mi
502 o Target IRI: URI-T
504 o Relation Type: "timemap"
506 o Target Attribute: "type"
507 o Use: RECOMMENDED
509 o Cardinality: 0 or more
511 Further details about TimeMap serializations are provided in
512 Section 3.4.
514 2.2.1.4. Relation Type "memento"
516 "memento" -- A "Link" header entry with a Relation Type of "memento"
517 is used to point from both a TimeGate and a Memento to various
518 Mementos for an Original Resource. This link MUST include a
519 "datetime" attribute with a value that matches the "Memento-Datetime"
520 of the Memento that is the target of the link; that is, the value of
521 the "Memento-Datetime" header that is returned when the URI of the
522 linked Memento is dereferenced. The value for the "datetime"
523 attribute MUST be a datetime expressed according to the rfc1123-date
524 construction rule of the BNF in Figure 1 and it MUST be represented
525 in Greenwich Mean Time (GMT). The link SHOULD also include a "type"
526 attribute to convey the mime type of the Memento that is the target
527 of the link. Use of entries with the "memento" Relation Type is
528 REQUIRED and it MUST be as follows:
530 For all responses to HTTP HEAD/GET requests issued against a TimeGate
531 or a Memento in which a Memento is selected or served by the
532 responding server:
534 o One "memento" link MUST be included that has as Target IRI the URI
535 of the Memento that was selected or served;
537 o One "memento" link MUST be included that has as Target IRI the URI
538 of the temporally first Memento known to the responding server;
540 o One "memento" link MUST be included that has as Target IRI the URI
541 of the temporally most recent Memento known to the responding
542 server.
544 o One "memento" link SHOULD be included that has as Target IRI the
545 URI of the Memento that is previous to the selected Memento in the
546 temporal series of all Mementos (sorted by ascending "Memento-
547 Datetime" values) known to the server;
549 o One "memento" link SHOULD be included that has as Target IRI the
550 URI the Memento that is next to the selected Memento in the
551 temporal series of all Mementos (sorted by ascending "Memento-
552 Datetime" values) known to the server.
554 o Other "memento" links MAY only be included if both the
555 aforementioned previous and next links are provided. Each of
556 these OPTIONAL "memento" links MUST have as Target IRI the URI of
557 a Memento other than the ones listed above.
559 For all responses to HTTP HEAD/GET requests issued against an
560 existing TimeGate or Memento in which no Memento is selected or
561 served by the responding server:
563 o One "memento" link MUST be included that has as Target IRI the URI
564 of the temporally first Memento known to the responding server;
566 o One "memento" link MUST be included that has as Target IRI the URI
567 of the temporally most recent Memento known to the responding
568 server.
570 o Other "memento" links MAY be included, and each of these OPTIONAL
571 links MUST have as Target IRI the URI of a Memento other than the
572 two listed above.
574 Note that the Target IRI of some of these links may coincide. For
575 example, if the selected Memento actually is the first Memento known
576 to the server, only three distinct "memento" links may result. The
577 value for the "datetime" attribute of these links would be the
578 datetimes of the first (equal to selected), next, and most recent
579 Memento known to the responding server.
581 The summary is as follows:
583 o Context IRI: URI-G, URI-Mj
585 o Target IRI: URI-M
587 o Relation Type: "memento"
589 o Target Attributes: "datetime"
591 o Use: REQUIRED
593 o Cardinality: 1 or more
595 2.2.2. Other Relation Types
597 Web Linking [RFC5988] allows for the inclusion of links with
598 different Relation Types but the same Target IRI, and hence the
599 Relation Types introduced by the Memento framework MAY be combined
600 with others as deemed necessary. As the "memento" Relation Type
601 focuses on conveying the datetime of a linked Memento, Relation Types
602 that allow navigating among the temporally ordered series of Mementos
603 known to a server are of particular importance. With this regard,
604 the Relation Types listed in the below table SHOULD be considered for
605 combination with the "memento" Relation Type. A distinction is made
606 between responding servers that can be categorized as systems that
607 are the focus of [RFC5829] (such as version control systems) and
608 others that can not (such as Web archives). Note that, in terms of
609 [RFC5829], the last Memento (URI-Mn) is the version prior to the
610 latest (i.e. current) version.
612 +-----------------------------+---------------------+---------------+
613 | Memento Type | RFC5829 system | non RFC5829 |
614 | | | system |
615 +-----------------------------+---------------------+---------------+
616 | First Memento (URI-M0) | first | first |
617 | Last Memento (URI-Mn) | last | last |
618 | Selected Memento (URI-Mj) | NA | NA |
619 | Memento prior to selected | predecessor-version | prev |
620 | Memento (URI-Mi) | | |
621 | Memento next to selected | successor-version | next |
622 | Memento (URI-Mk) | | |
623 +-----------------------------+---------------------+---------------+
625 Table 2: The use of Relation Types
627 3. The Memento Framework, Datetime Negotiation component: HTTP
628 Interactions
630 This section describes the HTTP interactions of the Memento framework
631 for a variety of scenarios. First, Figure 2 provides a schematic
632 overview of a successful request/response chain that involves
633 datetime negotiation. Dashed lines depict HTTP transactions between
634 user agent and server. Appendix A shows these HTTP interactions in
635 detail for the case where the Original Resource resides on one
636 server, whereas both the TimeGate and the Mementos reside on another.
637 Scenarios also exist in which all these resources are on the same
638 server (for example, Content Management Systems) or on different
639 servers (for example, an aggregator of TimeGates). Note that, in
640 Step 2 and Step 6, the HTTP status code of the response is shown as
641 "200 OK", but a series of "206 Partial Content" responses could be
642 substituted without loss of generality.
644 1: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-R
645 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
646 3: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-G
647 4: UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
648 URI-R,URI-T,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -------- URI-G
649 5: UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------------> URI-Mj
650 6: UA <-- HTTP 200; Memento-Datetime: Tj; Link:
651 URI-R,URI-T,URI-G,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -- URI-Mj
653 Figure 2: Typical Memento request/response chain
655 o Step 1: In order to determine what the URI is of a TimeGate for an
656 Original Resource, the user agent issues an HTTP HEAD/GET request
657 against the URI of the Original Resource (URI-R).
659 o Step 2: The entity-header of the response from URI-R includes an
660 HTTP "Link" header with a Relation Type of "timegate" pointing at
661 a TimeGate (URI-G) for the Original Resource.
663 o Step 3: The user agent starts the datetime negotiation process
664 with the TimeGate by issuing an HTTP GET request against its URI-G
665 thereby including an "Accept-Datetime" HTTP header with a value of
666 the datetime of the desired prior state of the Original Resource.
668 o Step 4: The entity-header of the response from URI-G includes a
669 "Location" header pointing at the URI of a Memento (URI-Mj) for
670 the Original Resource. In addition, the entity-header contains an
671 HTTP "Link" header with a Relation Type of "original" pointing at
672 the Original Resource, and an HTTP "Link" header with a Relation
673 Type of "timemap" pointing at a TimeMap (URI-T). Also HTTP Links
674 pointing at various Mementos are provided using the "memento"
675 Relation Type, as specified in Section 2.2.1.4.
677 o Step 5: The user agent issues an HTTP GET request against the
678 URI-Mj of a Memento, obtained in Step 4.
680 o Step 6: The entity-header of the response from URI-Mj includes a
681 "Memento-Datetime" HTTP header with a value of the datetime of the
682 Memento. It also contains an HTTP "Link" header with a Relation
683 Type of "original" pointing at the Original Resource, with a
684 Relation Type of "timegate" pointing at a TimeGate associated with
685 the Original Resource, and with a Relation Type of "timemap"
686 pointing at a TimeMap. The state that is expressed by the
687 representation provided in the response is the state the Original
688 Resource had at the datetime expressed in the "Memento-Datetime"
689 header. This response also includes HTTP Links with a "memento"
690 Relation Type pointing at various Mementos, as specified in
691 Section 2.2.1.4.
693 The following sections detail the specifics of HTTP interactions with
694 Original Resources, TimeGates, Mementos, and TimeMaps under various
695 conditions.
697 3.1. Interactions with an Original Resource
699 This section details HTTP GET/HEAD requests targeted at an Original
700 Resource (URI-R).
702 3.1.1. Step 1: User Agent Requests an Original Resource
704 In order to try and discover a TimeGate for the Original Resource,
705 the user agent SHOULD issue an HTTP HEAD or GET request against the
706 Original Resource's URI. Use of the "Accept-Datetime" header in the
707 HTTP HEAD/GET request is OPTIONAL.
709 Figure 3 shows the use of HTTP HEAD indicating the user agent is not
710 interested in retrieving a representation of the Original Resource,
711 but only in determining a TimeGate for it. It also shows the use of
712 the "Accept-Datetime" header anticipating that the user agent will
713 set it for the entire duration of a Memento request/response cycle.
715 HEAD / HTTP/1.1
716 Host: a.example.org
717 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
718 Connection: close
720 Figure 3: User Agent Requests Original Resource
722 3.1.2. Step 2: Server Responds to a Request for an Original Resource
724 The response of the Original Resource's server to the user agent's
725 HTTP HEAD/GET request of Step 1, for the case where the Original
726 Resource exists, is as it would be in a regular HTTP request/response
727 cycle, but in addition MAY include a HTTP "Link" header with a
728 Relation Type of "timegate" that conveys the URI of the Original
729 Resource's TimeGate as the Target IRI of the Link. Multiple HTTP
730 Links with a relation type of "timegate" MAY be provided to
731 accommodate situations in which the server is aware of multiple
732 TimeGates for an Original Resource. The actual Target IRI provided
733 in the "timegate" Link may depend on several factors including the
734 datetime provided in the "Accept-Datetime" header, and the IP address
735 of the user agent. A response for this case is illustrated in
736 Figure 4.
738 HTTP/1.1 200 OK
739 Date: Thu, 21 Jan 2010 00:02:12 GMT
740 Server: Apache
741 Link:
742 ; rel="timegate"
743 Content-Length: 255
744 Connection: close
745 Content-Type: text/html; charset=iso-8859-1
747 Figure 4: Server of Original Resource Responds
749 Servers that actively maintain archives of their resources SHOULD
750 include the "timegate" HTTP "Link" header because this link is an
751 important way for a user agent to discover TimeGates for those
752 resources. This includes servers such as Content Management Systems,
753 Control Version Systems, and Web servers with associated
754 transactional archives Fitch [Fitch]. Servers that do not actively
755 maintain archives of their resources MAY include the "timegate" HTTP
756 "Link" header as a way to convey a preference for TimeGates for their
757 resources exposed by a third party archive. This includes servers
758 that rely on Web archives such as the Internet Archive to archive
759 their resources.
761 The server of the Original Resource MUST treat requests with and
762 without an "Accept-Datetime" header in the same way:
764 o The response MUST either always or never include a HTTP "Link"
765 header with an entry that has a "timegate" Relation Type and the
766 URI of a TimeGate as the Target IRI.
768 o The entity-body of the response MUST be the same, for user agent
769 requests with or without a "Accept-Datetime" header.
771 3.1.2.1. Original Resource is an Appropriate Memento
773 The "Memento-Datetime" header MAY be applied to an Original Resource
774 directly to indicate it is a FixedResource (see W3C.gen-ont-20090420
775 [W3C.gen-ont-20090420]), meaning that the state of the Original
776 Resource has not changed since the datetime conveyed in the "Memento-
777 Datetime" header, and as a promise that it will not change anymore
778 beyond it. This may occur, for example, for certain stable media
779 resources on news sites. In case the user agent's preferred datetime
780 is equal to or more recent than the datetime conveyed as the value of
781 "Memento-Datetime" in the server's response in Step 2, the user agent
782 SHOULD conclude it has located an appropriate Memento, and it SHOULD
783 NOT continue to Step 3.
785 Figure 5 illustrates such a response to a request for the resource
786 with URI http://a.example.org/pic that has been stable since it was
787 created. Note the use of both the "memento" and "original" Relation
788 Types for links that have as Target IRI the URI of the Original
789 Resource.
791 HTTP/1.1 200 OK
792 Date: Thu, 21 Jan 2010 00:02:12 GMT
793 Server: Apache
794 Link:
795
796 ; rel="original memento"
797 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT"
798 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
799 Content-Length: 255
800 Connection: close
801 Content-Type: text/html; charset=iso-8909-1
803 Figure 5: Response to a request for an Original Resource that was
804 created as a FixedResource
806 Cases may also exist in which a resource becomes stable at a certain
807 point in its existence, but changed previously. In such cases, the
808 Original Resource may know about a TimeGate that is aware of its
809 prior history and hence MAY also include a link with a "timegate"
810 Relation Type. This is illustrated in Figure 6, where the "memento"
811 and "original" Relation Types are used as in Figure 5, and the
812 existence of a TimeGate to negotiate for Mementos with datetimes
813 prior to Fri, 20 Mar 2009 11:00:00 GMT is indicated.
815 HTTP/1.1 200 OK
816 Date: Thu, 21 Jan 2010 00:02:12 GMT
817 Server: Apache
818 Link:
819
820 ; rel="original memento"
821 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT",
822
823 ; rel="timegate"
824 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
825 Content-Length: 255
826 Connection: close
827 Content-Type: text/html; charset=iso-8909-1
829 Figure 6: Response to a request for an Original Resource that became
830 a FixedResource
832 3.1.2.2. Server Exists and Original Resource Used to Exist
834 Servers SHOULD also provide a "timegate" HTTP "Link" header in
835 responses to requests for an Original Resource that the server knows
836 used to exist, but no longer does. This allows the use of an
837 Original Resource's URI as an entry point to representations of its
838 prior states even if the resource itself no longer exists. A
839 server's response for this case is illustrated in Figure 7.
841 HTTP/1.1 404 Not Found
842 Date: Thu, 21 Jan 2010 00:02:12 GMT
843 Server: Apache
844 Link:
845
846 ; rel="timegate"
847 Content-Length: 255
848 Connection: close
849 Content-Type: text/html; charset=iso-8909-1
851 Figure 7: Response to a request for an Original Resource that not
852 longer exists
854 In case the server is not aware of the prior existence of the
855 Original Resource, its response SHOULD NOT include a "timegate" HTTP
856 Link. Section 3.1.2.3 details what the user agent's behavior should
857 be in such cases.
859 3.1.2.3. Missing or Inadequate "timegate" Link in Original Server's
860 Response
862 A user agent MAY ignore the TimeGate returned in Step 2. However,
863 when engaging in a Memento request/response cycle, a user agent
864 SHOULD NOT proceed immediately to Step 3 by using a TimeGate of its
865 own preference but rather SHOULD always start the cycle by issuing an
866 HTTP GET/HEAD against the Original Resource (Step 1, Figure 3) as it
867 is an important way to learn about dedicated or preferred TimeGates
868 for the Original Resource. Also, cases exist in which the response
869 in Step 2 will not provide a "timegate" link, including:
871 o The Original Resource's server does not support the Memento
872 framework;
874 o The Original Resource no longer exists and the responding server
875 is not aware of its prior existence;
877 o The server that hosted the Original Resource no longer exists;
878 In all these cases, the user agent SHOULD attempt to determine an
879 appropriate TimeGate for the Original Resource, either automatically
880 or interactively supported by the user. The discovery mechanisms
881 described in Section 4 can support the user agent with this regard.
883 3.2. Interactions with a TimeGate
885 This section details HTTP GET/HEAD requests targeted at a TimeGate
886 (URI-G).
888 3.2.1. Step 3: User Agent Negotiates with a TimeGate
890 In order to negotiate with a TimeGate, the user agent MUST issue a
891 HTTP HEAD or GET against its URI, its request MUST include the
892 "Accept-Datetime" header to express its datetime preference, and the
893 use of that header MUST be as described in Section 2.1.1.1. The URI
894 of the TimeGate may have been provided as the Target IRI of a
895 "timegate" HTTP "Link" header in the response from the Original
896 Resource (Step 2, Figure 4), or may have resulted from another
897 discovery mechanism (see Section 4) or user interaction. Such a
898 request is illustrated in Figure 8.
900 GET /timegate/http://a.example.org HTTP/1.1
901 Host: arxiv.example.net
902 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
903 Connection: close
905 Figure 8: User agent negotiates with TimeGate
907 3.2.2. Step 4: Server Responds to Negotiation with TimeGate
909 In order to respond to a datetime negotiation request (Step 3,
910 Section 3.2.1), the server uses an internal algorithm to select the
911 Memento that best meets the user agent's datetime preference, and
912 redirects to it. The exact nature of the selection algorithm is at
913 the server's discretion but SHOULD be consistent. A variety of
914 approaches can be used including selecting the Memento that is
915 nearest in time (either past or future) or nearest in the past
916 relative to the requested datetime. The commons scenario for
917 datetime negotiation with a TimeGate is described in Section 3.2.2.1
918 but special cases exist, and they are addressed in Section 3.2.2.2
919 through Section 3.2.2.8.
921 3.2.2.1. Successful Scenario
923 In cases where the TimeGate exists, and the datetime provided in the
924 user agent's "Accept-Datetime" header can be parsed, the server
925 selects a Memento based on the user agent's datetime preference. The
926 response MUST have a "302 Found" HTTP status code, and the "Location"
927 header MUST be used to convey the URI of the selected Memento. The
928 "Vary" header MUST be provided and it MUST include the "negotiate"
929 and "accept-datetime" values to indicate that datetime negotiation
930 has taken place. The "Link" header MUST be provided and contain
931 links with Relation Types subject to the considerations described in
932 Section 2.2. The response MUST NOT contain a "Memento-Datetime"
933 header. Such a response is illustrated in Figure 9.
935 HTTP/1.1 302 Found
936 Date: Thu, 21 Jan 2010 00:06:50 GMT
937 Server: Apache
938 Vary: negotiate, accept-datetime
939 Location:
940 http://arxiv.example.net/web/20010911203610/http://a.example.org
941 Link: ; rel="original",
942
943 ; rel="timemap"; type="application/link-format",
944
945 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
946
947 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
948
949 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
950
951 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
952
953 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
954 Content-Length: 0
955 Content-Type: text/plain; charset=UTF-8
956 Connection: close
958 Figure 9: Server of TimeGate responds
960 If a user agent's "Accept-Datetime" header conveys a datetime that is
961 either earlier than the datetime of the first Memento or later than
962 the datetime of the most recent Memento known to the server, the
963 server's response is as just described yet entails the selection of
964 the first or most recent Memento, respectively.
966 This is illustrated in Figure 10 that shows the response from a
967 TimeGate exposed by a MediaWiki server to a request by a user agent
968 that has an "Accept-Datetime: Mon, 31 May 1999 00:00:00 GMT" header.
969 Note that a link is provided with a "successor-version" Relation Type
970 but not with a "predecessor-version" Relation Type.
972 HTTP/1.1 302 Found
973 Server: Apache
974 Content-Length: 709
975 Content-Type: text/html; charset=utf-8
976 Date: Thu, 21 Jan 2010 00:09:40 GMT
977 Location:
978 http://a.example.org/w/index.php?title=Clock&oldid=1493688
979 Vary: negotiate, accept-datetime
980 Link: ; rel="original",
981
982 ; rel="timemap",
983
984 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
985
986 ; rel="successor-version memento"
987 ; datetime="Tue, 30 Sep 2003 14:28:00 GMT",
988
989 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT"
990 Connection: close
992 Figure 10: A TimeGate's response to a request for a Memento with a
993 datetime earlier than that of the first Memento
995 3.2.2.2. Multiple Matching Mementos
997 Because the finest datetime granularity expressible using the
998 [RFC1123] format used in HTTP is seconds level, cases may occur in
999 which a TimeGate server is aware of multiple Mementos that meet the
1000 user agent's datetime preference. This may occur in Content
1001 Management Systems with very high update rates. The response in this
1002 case MUST be handled as in Section 3.2.2.1, with the selection of one
1003 of the matching Mementos.
1005 As an example, Figure 11 shows a hypothetical response from a
1006 TimeGate on a MediaWiki server to a request for a Memento for the
1007 Original Resource http://a.example.org/w/Clock for which two Mementos
1008 exist for the user agent's preferred datetime.
1010 HTTP/1.1 302 Found
1011 Server: Apache
1012 Content-Length: 705
1013 Content-Type: text/html; charset=utf-8
1014 Date: Thu, 21 Jan 2010 00:09:40 GMT
1015 Vary: negotiate, accept-datetime
1016 Location:
1017 http://a.example.org/w/index.php?title=Clock&oldid=322586071
1018 Link: ; rel="original",
1019
1020 ; rel="timemap";type="application/link-format",
1021
1022 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
1023
1024 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT",
1025
1026 ; rel="memento"; datetime="Sun, 31 May 2009 15:43:00 GMT",
1027
1028 ; rel="memento successor-version"
1029 ; datetime="Sun, 31 May 2009 15:43:00 GMT"
1030
1031 ; rel="memento predecessor-version"
1032 ; datetime="Sun, 31 May 2009 15:41:24 GMT"
1033 Connection: close
1035 Figure 11: A TimeGate's response to a request that has multiple
1036 Mementos with a matching datetime
1038 3.2.2.3. TimeGate Redirects to another TimeGate
1040 Cases may exist in which a TimeGate's response entails a redirects to
1041 another TimeGate, for example, because the responding TimeGate is
1042 aware that the other TimeGate is able to more precisely respond to a
1043 client's datetime preference. In such cases, the TimeGate's response
1044 MUST have a "302 Found" HTTP status code, and the "Location" header
1045 MUST be used to convey the URI of the other TimeGate. The "Vary"
1046 header MUST be provided and it MUST include the "negotiate" and
1047 "accept-datetime" values to indicate that, although datetime
1048 negotiation has not taken place, the responding TimeGate is capable
1049 of it. The "Link" header MUST be provided and contain links with
1050 Relation Types subject to the considerations described in
1051 Section 2.2. Specifically, the use of links with a "memento"
1052 Relation Type MUST follow the rules for the case where no Memento is
1053 selected by the responding server (Section 2.2.1.4). Also, a link
1054 with a "timegate" Relation Type MUST be provided that has as Target
1055 IRI the URI of the TimeGate to which the current TimeGate is
1056 redirecting the client. The response MUST NOT contain a "Memento-
1057 Datetime" header.
1059 A response in which the client is redirected by TimeGate
1060 http://arxiv.example.net/timegate/http://a.example.org to TimeGate
1061 http://otherarxiv.example.com/timegate/http://a.example.org for the
1062 Original Resource http://a.example.org is illustrated in Figure 12.
1063 Note the URI of the latter TimeGate in both the "Location" and "Link"
1064 header, in the latter case as the Target IRI of a "timegate" link.
1065 Note also that the "memento" and "timemap" links in this response
1066 reflect the knowledge of the responding TimeGate, not of the remote
1067 TimeGate.
1069 HTTP/1.1 302 Found
1070 Date: Thu, 21 Jan 2010 00:06:50 GMT
1071 Server: Apache
1072 Vary: negotiate, accept-datetime
1073 Location:
1074 http://otherarxiv.example.com/timegate/http://a.example.org
1075 Link: ; rel="original",
1076
1077 ; rel="timemap"; type="application/link-format",
1078
1079 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1080
1081 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1082
1083 ; rel="timegate"
1084 Content-Length: 0
1085 Content-Type: text/plain; charset=UTF-8
1086 Connection: close
1088 Figure 12: TimeGate redirects to another TimeGate
1090 3.2.2.4. Accept-Datetime and other Accept Headers Provided
1092 When interacting with a TimeGate, the regular content negotiation
1093 dimensions (media type, character encoding, language, and
1094 compression) remain available. It is the TimeGate server's
1095 responsibility to honor (or not) such content negotiation, and in
1096 doing so it MUST always first select a Memento that meets the user
1097 agent's datetime preference, and then consider honoring regular
1098 content negotiation for it. As a result of this approach, the
1099 returned Memento will not necessarily meet the user agent's regular
1100 content negotiation preferences. Therefore, it is RECOMMENDED that
1101 the server provides HTTP Links with a "memento" Relation Type
1102 pointing at Mementos that do meet the user agent's regular content
1103 negotiation requests and that have a value for the "Memento-Datetime"
1104 header in the temporal vicinity of the user agent's preferred
1105 datetime value.
1107 3.2.2.5. Accept-Datetime Unparseable
1109 In case, in Step 3, a user agent conveys a value for the "Accept-
1110 Datetime" request header that does not conform to the accept-dt-value
1111 construction rule of the BNF in Figure 1, the TimeGate server's
1112 response MUST have a "400 Bad Request" HTTP status code. The use of
1113 the "Vary" header MUST be as described in Section 3.2.2.1. The use
1114 of the "Link" header MUST be as described in Section 2.2.
1115 Specifically, the use of links with a "memento" Relation Type MUST
1116 follow the rules for the case where no Memento is selected by the
1117 responding server, i.e. only "memento" links to the first and most
1118 recent Mementos MUST be provided (Section 2.2.1.4).
1120 3.2.2.6. Accept-Datetime Not Provided
1122 In case, in Step 3, a user agent issues a request to a TimeGate and
1123 fails to include an "Accept-Datetime" request header, the response
1124 MUST be handled as in Section 3.2.2.1, with a selection of the most
1125 recent Memento known to the responding server.
1127 3.2.2.7. TimeGate Does Not Exist
1129 Cases may occur in which a user agent issues a request against a
1130 TimeGate that does not exist. This may, for example, occur when a
1131 user agent uses internal knowledge to construct the URI of an
1132 assumed, yet non-existent TimeGate. In these cases, the response
1133 from the target server MUST have a "404 Not Found" HTTP status code,
1134 and SHOULD include a "Vary" header that includes the "negotiate" and
1135 "accept-datetime" values as an indication that, generally, the server
1136 is capable of datetime negotiation. The response MUST NOT include a
1137 "Link" header with any of the Relation Types introduced in
1138 Section 2.2.1, and it MUST NOT contain a "Memento-Datetime" header.
1140 3.2.2.8. HTTP Methods other than HEAD/GET
1142 In the above, the safe HTTP methods GET and HEAD are described for
1143 TimeGates. TimeGates MAY support the safe HTTP methods OPTIONS and
1144 TRACE in the way described in [RFC2616]. Unsafe HTTP methods (i.e.
1145 PUT, POST, DELETE) MUST NOT be supported by a TimeGate. Such
1146 requests MUST yield a response with a "405 Method Not Allowed" HTTP
1147 status code, and MUST include an "Allow" header to convey that only
1148 the HEAD and GET (and OPTIONALLY the OPTIONS and TRACE) methods are
1149 supported. In addition, the response MUST have a "Vary" header that
1150 includes the "negotiate" and "accept-datetime" values to indicate the
1151 TimeGate supports datetime negotiation. Figure 13 shows such a
1152 response.
1154 HTTP/1.1 405 Method Not Allowed
1155 Date: Thu, 21 Jan 2010 00:02:12 GMT
1156 Server: Apache
1157 Vary: negotiate, accept-datetime
1158 Allow: HEAD, GET
1159 Content-Length: 255
1160 Connection: close
1161 Content-Type: text/html; charset=iso-8909-1
1163 Figure 13: Response from a TimeGate accessed with HTTP method other
1164 than HEAD/GET
1166 3.2.3. Recognizing a TimeGate
1168 When a user agent issues a HTTP HEAD/GET request against an assumed
1169 TimeGate URI (e.g. URI is Target IRI of a link with a "timegate"
1170 Relation Type, URI is discovered as described in Section 4, etc.), it
1171 SHOULD NOT conclude that the targeted resource effectively is a
1172 TimeGate and hence will behave as described in Section 3.2.2.
1174 A user agent MUST decide it has reached a TimeGate if the response to
1175 a HTTP HEAD/GET request against the resource's URI contains a "Vary"
1176 header that includes the "negotiate" and "accept-datetime" values.
1177 If the response does not, the user agent MUST decide it has not
1178 reached a TimeGate and proceed as follows:
1180 o If the response contains a redirection, the user agent SHOULD
1181 follow it. Note that a chain of redirections is possible, e.g.
1182 URI-R -> URI-1 -> URI-2 -> ... -> URI-G
1184 o If the response does not contain a redirection, or if the
1185 redirection (chain) does not lead to a TimeGate, the user agent
1186 SHOULD attempt to determine an appropriate TimeGate for the
1187 Original Resource, either automatically or interactively supported
1188 by the user. The discovery mechanisms described in Section 4 can
1189 support the user agent with this regard.
1191 Resources that are not TimeGates (i.e. do not behave as described in
1192 Section 3.2.2) MUST NOT use a "Vary" header that includes the
1193 "accept-datetime" value.
1195 In certain cases, it is possible to implement Memento support in such
1196 a manner that an Original Resource coincides with its TimeGate, i.e.
1197 URI-R and URI-G are the same. This implementation pattern is NOT
1198 RECOMMENDED. It can make determining whether a resource is a
1199 TimeGate more challenging, and, more importantly, it may cause
1200 problems with caches. Observed caching problems, which
1201 implementations must take care to avoid, include:
1203 o Cache invalidation when switching between a request for the
1204 Original Resource and a negotiation with the TimeGate.
1206 o Delivering a (cached) Original Resource response when a TimeGate
1207 response was requested, and vice versa.
1209 3.3. Interactions with a Memento
1211 This section details HTTP GET/HEAD requests targeted at a Memento
1212 (URI-M).
1214 3.3.1. Step 5: User Agent Requests a Memento
1216 In Step 5, the user agent issues a HTTP GET request against the URI
1217 of a Memento. The user agent MAY include an "Accept-Datetime" header
1218 in this request, but the existence or absence of this header MUST NOT
1219 affect the server's response. The URI of the Memento may have
1220 resulted from a response in Step 4, or the user agent may simply have
1221 happened upon it. Such a request is illustrated in Figure 14.
1223 GET /web/20010911203610/http://a.example.org HTTP/1.1
1224 Host: arxiv.example.net
1225 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1226 Connection: close
1228 Figure 14: User agent requests Memento
1230 3.3.2. Step 6: Server Responds to a Request for a Memento
1232 This section describes possible responses to a request for a Memento.
1233 Section 3.3.2.1 discusses the common scenario, whereas
1234 Section 3.3.2.2 and Section 3.3.2.3 detail special cases whereby
1235 Mementos are archived copies of HTTP responses with 3xx, 4xx and 5xx
1236 status codes.
1238 3.3.2.1. Common Scenario
1240 If the Memento requested by the user agent in Step 5 exists, and is
1241 not a special Memento as described in Section 3.3.2.2 and
1242 Section 3.3.2.2, the server's response MUST have a "200 OK" HTTP
1243 status code or, where appropriate "206 Partial Content", and it MUST
1244 include a "Memento-Datetime" header with a value equal to the
1245 archival datetime of the Memento, that is, the datetime of the state
1246 of the Original Resource that is encapsulated in the Memento. The
1247 "Link" header MUST be provided and contain links subject to the
1248 considerations described in Section 2.2. The Target IRI and, when
1249 applicable, the datetime values in the "Link" header associated with
1250 the "memento" Relation Type SHOULD be the same as conveyed in Step 4,
1251 in case the TimeGate and the selected Memento reside on the same
1252 server. However, they MAY be different in case the TimeGate and the
1253 selected Memento reside on different servers.
1255 Figure 15 illustrates the server's response to the request issued
1256 against a Memento in Step 5 (Figure 14).
1258 HTTP/1.1 200 OK
1259 Date: Thu, 21 Jan 2010 00:09:40 GMT
1260 Server: Apache-Coyote/1.1
1261 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1262 Link: ; rel="original",
1263
1264 ; rel="timemap"; type="application/link-format",
1265
1266 ; rel="timegate",
1267
1268 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1269
1270 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1271
1272 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
1273
1274 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
1275
1276 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
1277 Content-Length: 23364
1278 Content-Type: text/html;charset=utf-8
1279 Connection: close
1281 Figure 15: Server of Memento responds
1283 The server's response MUST include the "Memento-Datetime" header
1284 regardless whether the user agent's request contained an "Accept-
1285 Datetime" header or not. This is the way by which resources make
1286 explicit that they are Mementos. Due to the sparseness of Mementos
1287 in most archives, the value of the "Memento-Datetime" header returned
1288 by a server may differ (significantly) from the value conveyed by the
1289 user agent in "Accept-Datetime".
1291 Although a Memento encapsulates a prior state of an Original
1292 Resource, the entity-body returned in response to an HTTP GET request
1293 issued against a Memento may very well not be byte-to-byte the same
1294 as an entity-body that was previously returned by that Original
1295 Resource. Various reasons exist why there are significant chances
1296 these would be different yet do convey substantially the same
1297 information. These include format migrations as part of a digital
1298 preservation strategy, URI-rewriting as applied by some Web archives,
1299 and the addition of banners as a means to brand Web archives.
1301 3.3.2.2. Memento of a 3XX Response
1303 Cases exist in which HTTP responses with 3XX status codes are
1304 archived. For example, crawl-based web archives commonly archive
1305 responses with HTTP status codes "301 Moved Permanently" and "302
1306 Found" whereas Linked Data archives hold on to "303 See Other"
1307 responses. But also other 3XX responses may be archived.
1309 If the Memento requested by the user agent is an archived version of
1310 an HTTP response with a 3XX status code, the server's response MUST
1311 have the same 3XX HTTP status code, and it MUST include a "Memento-
1312 Datetime" header with a value equal to the archival datetime of the
1313 original 3XX response. All other considerations, e.g. pertaining to
1314 the use of "Link" header, expressed in Section 3.3.2.1 apply.
1316 The client's handling of a HTTP response with a 3XX status code is
1317 not affected by the presence of a "Memento-Datetime" header. The
1318 client SHOULD behave in the same manner as it does with HTTP
1319 responses with a 3XX status code that do not have a "Memento-
1320 Datetime" header. For example:
1322 o For a response from a Memento that has a 3XX status code and
1323 contains a "Location" header, the client SHOULD continue on to the
1324 URI specified in that header.
1326 o For a response from a Memento that has a "300 Multiple Choices"
1327 status code, the response body SHOULD be presented to the user to
1328 allow selection of a URI.
1330 However, the client MUST be aware that the URI that was selected from
1331 the HTTP response with a 3XX status code might not be that of a
1332 Memento but rather of an Original Resource. In that case it SHOULD
1333 proceed by looking for a Memento of the selected Original Resource.
1335 For example, on April 11 2008 Figure 16 is the response to an HTTP
1336 GET request for http://a.example.org. This response is archived as a
1337 Memento of http://a.example.org, and this Memento's URI is
1338 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1339 The response to a HTTP HEAD/GET on this Memento is shown in
1340 Figure 17. In essence, it is a replay of the original response with
1341 "Memento-Datetime" and "Link" headers added, to allow a client to
1342 understand the response is a Memento. In Figure 17, the value of the
1343 "Location" header is the same as in the original response; it
1344 identifies an Original Resource. The client proceeds with finding a
1345 Memento for this Original Resource. Web archives sometimes overwrite
1346 the value that was originally provided in the "Location" header in
1347 order to point at a Memento they hold of the resource to which the
1348 redirect originally led. This is shown in Figure 18. In this case,
1349 the client may decide it found an appropriate Memento.
1351 HTTP/1.1 301 Moved Permanently
1352 Date: Fri, 11 Apr 2008 00:06:50 GMT
1353 Server: Apache
1354 Location: http://b.example.org
1355 Content-Length: 0
1356 Content-Type: text/plain; charset=UTF-8
1357 Connection: close
1359 Figure 16: Response to the User Agent Request is a Redirect
1361 HTTP/1.1 301 Moved Permanently
1362 Date: Thu, 21 Jan 2010 00:09:40 GMT
1363 Server: Apache-Coyote/1.1
1364 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1365 Location: http://b.example.org
1366 Link: ; rel="original",
1367
1368 ; rel="timemap"; type="application/link-format",
1369
1370 ; rel="timegate",
1371
1372 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1373
1374 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1375
1376 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1377
1378 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1379
1380 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1381 Content-Length: 0
1382 Content-Type: text/plain; charset=UTF-8
1383 Connection: close
1385 Figure 17: Response to a User Agent Request for a Memento of a
1386 Redirect; leads to an Original Resource
1388 HTTP/1.1 301 Moved Permanently
1389 Date: Thu, 21 Jan 2010 00:09:40 GMT
1390 Server: Apache-Coyote/1.1
1391 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1392 Location:
1393 http://arxiv.example.net/web/20080411000655/http://b.example.org
1394 Link: ; rel="original",
1395
1396 ; rel="timemap"; type="application/link-format",
1397
1398 ; rel="timegate",
1399
1400 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1401
1402 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1403
1404 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1405
1406 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1407
1408 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1409 Content-Length: 0
1410 Content-Type: text/plain; charset=UTF-8
1411 Connection: close
1413 Figure 18: Response to a User Agent Request for a Memento of a
1414 Redirect; leads to a Memento
1416 3.3.2.3. Memento of Responses with Other HTTP Status Codes
1418 Cases exist in which responses with 4xx and 5xx HTTP status codes are
1419 archived. If the Memento requested by the user agent is an archived
1420 version of such an HTTP response, the server's response MUST have the
1421 same 4xx or 5xx HTTP status code, and it MUST include a "Memento-
1422 Datetime" header with a value equal to the archival datetime of the
1423 original response. All other considerations, e.g. pertaining to the
1424 use of "Link" header, expressed in Section 3.3.2.1 apply.
1426 For example, on April 11 2008, Figure 19 is the 404 response to an
1427 HTTP GET request for http://a.example.org. This response is archived
1428 as a Memento of http://a.example.org, and this Memento's URI is
1429 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1430 The response to a HTTP HEAD/GET on this Memento is shown in
1431 Figure 20. It is a replay of the original response with "Memento-
1432 Datetime" and "Link" headers added, to allow a client to understand
1433 the response is a Memento.
1435 HTTP/1.1 404 Not Found
1436 Date: Fri, 11 Apr 2008 00:06:50 GMT
1437 Server: Apache
1438 Content-Length: 0
1439 Content-Type: text/plain; charset=UTF-8
1440 Connection: close
1442 Figure 19: Response to the User Agent Request is a 404
1444 HTTP/1.1 404 Not Found
1445 Date: Thu, 21 Jan 2010 00:09:40 GMT
1446 Server: Apache-Coyote/1.1
1447 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1448 Link: ; rel="original",
1449
1450 ; rel="timemap"; type="application/link-format",
1451
1452 ; rel="timegate",
1453
1454 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1455
1456 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1457
1458 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1459
1460 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1461
1462 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1463 Content-Length: 0
1464 Content-Type: text/plain; charset=UTF-8
1465 Connection: close
1467 Figure 20: Response to a User Agent Request for a Memento of a 404
1468 Response
1470 3.3.2.4. Mementos Without a TimeGate
1472 Cases may occur in which a server that hosts Mementos does not expose
1473 a TimeGate for those Mementos. This can, for example, be the case if
1474 the server's Mementos result from taking a snapshot of the state of a
1475 set of Original Resources from another server at the time this other
1476 server is being retired. As a result, only a single Memento per
1477 Original Resource is hosted, making the introduction of a TimeGate
1478 unnecessary. But it may also be the case for servers that hosts
1479 multiple Mementos for an Original Resource but consider exposing
1480 TimeGates too expensive.
1482 In cases of Mementos without associated TimeGates, responses to a
1483 request for a Memento by a user agent MUST be as described in
1484 Section 3.3.2 with the exception that it will not contain a HTTP
1485 "Link" with a "timegate" Relation Type pointing at a TimeGate exposed
1486 by the responding server. It MAY still contain such a Link pointing
1487 at a TimeGate exposed elsewhere. Depending on whether one or more
1488 Mementos are hosted for an Original Resource, the response may or may
1489 not have a HTTP Link with a "timemap" Relation Type. However, the
1490 response MUST still contain a "Memento-Datetime" response header with
1491 a value that corresponds to archival datetime of the Memento.
1493 Figure 21 illustrates the server's response to the request issued
1494 against a Memento in Step 5 (Figure 14) for the case that Memento has
1495 no associated TimeGate. In this example, it is also assumed there is
1496 only one Memento for the Original Resource, and hence the Links with
1497 Relation Types "memento", "first", "last" all point at the same -
1498 responding - Memento.
1500 HTTP/1.1 200 OK
1501 Date: Thu, 21 Jan 2010 00:09:40 GMT
1502 Server: Apache-Coyote/1.1
1503 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1504 Link: ; rel="original",
1505
1506 ; rel="first last memento"
1507 ; datetime="Tue, 15 Sep 2000 11:28:26 GMT"
1508 Content-Length: 23364
1509 Content-Type: text/html;charset=utf-8
1510 Connection: close
1512 Figure 21: Server of Memento without TimeGate responds
1514 Note that a server issuing a response similar to that of Figure 21
1515 does not imply that there is no server whatsoever that exposes a
1516 TimeGate; it merely means that the responding server neither provides
1517 nor is aware of the location of a TimeGate.
1519 3.3.2.5. Memento Does not Exist
1521 Cases may occur in which a TimeGate's response (Step 4) points at a
1522 Memento that actually does not exist, resulting in a user agent's
1523 request (Step 5) for a non-existent Memento. In this case, the
1524 server's response MUST have the expected "404 Not Found" HTTP Status
1525 Code and it MUST NOT contain a "Memento-Datetime" header. Note that
1526 the absence of a Memento in an archive is distinct from the case of
1527 an archived response with a "404 Not Found" HTTP status code as is
1528 described in Section 3.3.2.3
1530 3.3.3. Recognizing a Memento
1532 When following the redirection provided by a confirmed TimeGate (see
1533 Section 3.2.3), a user agent SHOULD NOT assume that the targeted
1534 resource effectively is a Memento and hence will behave as described
1535 in Section 3.3.2.
1537 A user agent MUST decide it has reached a Memento if the response to
1538 a HTTP HEAD/GET request against the resource's URI contains a
1539 "Memento-Datetime" header with a legitimate value. If the response
1540 does not, the following applies:
1542 o If the response contains a redirection, the user agent SHOULD
1543 follow it. Even a chain of redirections is possible, e.g. URI-G
1544 -> URI-X -> URI-Y -> ... -> URI-M.
1546 o If the response by a confirmed TimeGate does not contain a
1547 redirection, or if the redirection (chain) that started at a
1548 confirmed TimeGate does not lead to a resource that provides a
1549 "Memento-Datetime" header, the user agent MAY still conclude that
1550 it has likely arrived at a Memento. That is because cases exist
1551 in which Web archives and CMS are made compliant with the Memento
1552 framework "by proxy". In these cases TimeGates will redirect to
1553 Mementos in such systems, but the responses from these Mementos
1554 will not (yet) include a "Memento-Datetime" header.
1556 3.4. Interactions with a TimeMap
1558 A TimeMap is introduced to support retrieving a comprehensive list of
1559 all Mementos for a specific Original Resource, known to a responding
1560 server. The entity-body of a response to an HTTP GET request issued
1561 against a TimeMap's URI:
1563 o MUST list the URI of the Original Resource that the TimeMap is
1564 about;
1566 o MUST preferably list the URI and datetime of each Memento for the
1567 Original Resource known to the responding server, or,
1568 alternatively support assembling such a list by following links
1569 with a "timemap" Relation Type provided in the TimeMap;
1571 o MUST list the URI of one or more TimeGates for the Original
1572 Resource known to the responding server;
1574 o SHOULD, for self-containment, list the URI of the TimeMap itself;
1576 o MUST unambiguously type listed resources as being Original
1577 Resource, TimeGate, Memento, or TimeMap.
1579 The entity-body of a response from a TimeMap MAY be serialized in
1580 various ways, but the link-value format serialization MUST be
1581 supported. In this serialization, the entity-body MUST be formatted
1582 in the same way as the value of a HTTP "Link" header, and hence MUST
1583 comply to the "link-value" construction rule of "Section 5. The Link
1584 Header Field" of [RFC5988], and the media type of the entity-body
1585 MUST be "application/link-format" as introduced in
1586 [I-D.ietf-core-link-format]. All links conveyed in this
1587 serialization MUST be interpreted as having the URI of the Original
1588 Resource as their Context IRI. The URI of the Original Resource is
1589 provided in the entity-body as the Target IRI of the link with an
1590 "original" Relation Type.
1592 3.4.1. User Agent Requests a TimeMap
1594 In order to retrieve the link-value serialization of a TimeMap, a
1595 user agent SHOULD use an "Accept" request header with a value set to
1596 "application/link-format". This is shown in Figure 22.
1598 GET /timemap/http://a.example.org HTTP/1.1
1599 Host: arxiv.example.net
1600 Accept: application/link-format;q=1.0
1601 Connection: close
1603 Figure 22: Request for a TimeMap
1605 3.4.2. Server Responds to a Request for a TimeMap
1607 If the TimeMap requested by the user agent exists, the server's
1608 response MUST have a "200 OK" HTTP status code (or "206 Partial
1609 Content", where appropriate). Note that a TimeMap is itself an
1610 Original Resource for which Mementos may exist. For example, a
1611 response from a TimeMap could provide a "timegate" Link to a TimeGate
1612 via which prior TimeMap versions are available. In this case, the
1613 use of the "Link" header is subject to all considerations described
1614 in Section 2.2, with the TimeMap acting as the Original Resource.
1616 However, in case a TimeMap wants to explicitly indicate in its
1617 response headers for which Original Resource it is a TimeMap, it MUST
1618 do so by including a HTTP "Link" header with the following
1619 characteristics:
1621 o The Context IRI for the HTTP Link is the URI of the Original
1622 Resource;
1624 o The Relation Type is "timemap";
1625 o The Target IRI for the HTTP Link is the URI of the TimeMap.
1627 Because the Context IRI of this HTTP Link is not the URI of the
1628 TimeMap, as per [RFC5988], the default Context IRI must be
1629 overwritten by using the "anchor" attribute with a value of the URI
1630 of the Original Resource.
1632 The response from the TimeMap to the request of Figure 22 is shown in
1633 Figure 23. The response header shows the TimeMap explicitly
1634 conveying the URI of the Original Resource for which it is a TimeMap;
1635 for practical reasons the entity-body in the example has been
1636 abbreviated. Notice also the use of the "self" Relation Type on the
1637 "timemap" link in the TimeMap.
1639 HTTP/1.1 200 OK
1640 Date: Thu, 21 Jan 2010 00:06:50 GMT
1641 Server: Apache
1642 Link:
1643 ; anchor="http://a.example.org"; rel="timemap"
1644 ; type="application/link-format"
1645 Content-Length: 4883
1646 Content-Type: application/link-format
1647 Connection: close
1649 ;rel="original",
1650
1651 ; rel="timemap self";type="application/link-format",
1652
1653 ; rel="timegate",
1654
1655 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1656
1657 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT",
1658
1659 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1660
1661 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1662 ...
1664 Figure 23: Response from a TimeMap
1666 Cases exist in which a TimeMap points at several other TimeMaps. In
1667 one such case, a TimeMap could merely point at other TimeMaps and not
1668 list any Mementos itself. This can happen when Mementos are spread
1669 across several archives that share a front-end. Such a TimeMap can
1670 be considered an index of TimeMaps and is shown in Figure 24. Note
1671 the use of the Relation Types "self" and index" when pointing to the
1672 index TimeMap itself, and "first" and "last" to point at remote
1673 TimeMaps that contain information on the earliest and most recent
1674 Mementos, respectively. Another case is when the number of available
1675 Mementos requires introducing multiple TimeMaps that can be paged.
1676 Such a TimeMap is shown in Figure 25; Note the use of the "self"
1677 Relation Type when pointing at the current TimeMap itself, and the
1678 use of "first", "last", "prev", and "next" to point at others. Note
1679 that this TimeMap also lists actual Mementos.
1681 ;rel="original",
1682
1683 ; rel="timegate",
1684
1685 ; rel="timemap self index";type="application/link-format",
1686
1687 ; rel="timemap first";type="application/link-format",
1688
1689 ; rel="timemap";type="application/link-format"
1690
1691 ; rel="timemap last";type="application/link-format"
1693 Figure 24: An index TimeMap
1695 ;rel="original",
1696
1697 ; rel="timegate",
1698
1699 ; rel="timemap self";type="application/link-format",
1700
1701 ; rel="timemap first";type="application/link-format",
1702
1703 ; rel="timemap last";type="application/link-format",
1704
1705 ; rel="timemap prev";type="application/link-format",
1706
1707 ; rel="timemap next";type="application/link-format",
1708
1709 ; rel="timemap";type="application/link-format",
1710
1711 ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1712
1713 ; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT",
1714
1715 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1716
1717 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1718 ...
1720 Figure 25: TimeMap Paging
1722 4. The Memento Framework, Discovery of TimeGates and TimeMaps
1724 Section 3 describes how TimeGates, Mementos, Original Resources, and
1725 TimeMaps can be discovered by following HTTP Links with Relation
1726 Types "timegate", "memento", "original", and "timemap", respectively.
1728 Naturally, some of these links can also be included in
1729 representations of resources that have a media type that allows
1730 embedding typed links. For example, an Original Resource that has an
1731 HTML representation can include a "timegate" link by using HTML's
1732 LINK element, e.g. . The use of such embedded links is also subject to
1735 the considerations of Section 2.2.
1737 In this section an additional approach is introduced to support batch
1738 discovery of TimeGates and TimeMaps. The approach leverages the
1739 well-known URI [RFC5785] and host-meta [RFC6415] specifications. It
1740 can be used in cases where the URI of a TimeGate or TimeMap has as
1741 part of its path-component the URI of the associated Original
1742 Resource. This is commonly the case for web archives and CMS that
1743 support the Memento protocol. The approach uses the following
1744 variables for URI templates used in host-meta files:
1746 o The "uri" variable, as reserved by [RFC6415], which stands for any
1747 URI in the server's document scope.
1749 o The "anyuri" variable, introduced here, which stands for any URI,
1750 i.e. not just URIs in the server's document scope.
1752 o The "path" variable, introduced here, which stands for any path
1753 and/or query component that can be added to the URI that precedes
1754 the variable in the URI template.
1756 A server SHOULD make TimeGates discoverable in the following way:
1758 o As per [RFC5785] and [RFC6415], the server publishes a document
1759 with the name "host-meta" in its /.well-known/ path.
1761 o As per [RFC6415], the host-meta document uses the XRD 1.0 document
1762 format.
1764 o The host-meta document includes one or more "Link" elements to
1765 support discovery of TimeGates for the server's Original
1766 Resources. Each such Link element has a value of "timegate" for
1767 its "rel" attribute, and it has a "template" attribute that has a
1768 URI template as its value. The URI template MAY either use the
1769 "uri", "anyuri", or "path" variable.
1771 o The URI template MUST be such that, when applying the URI of an
1772 Original Resource to the "uri" or "anyuri" variable, or when
1773 applying a path and/or query component of an Original Resource's
1774 URI to the "path" variable, the URI of a potential TimeGate for
1775 that Original Resource results.
1777 o Because Mementos do not exist for all possible URIs, there are no
1778 guarantees that these resulting TimeGates effectively exist. But
1779 URI templates should be created to try and maximize chances that
1780 the TimeGate effectively exists.
1782 The considerations described for TimeGate discovery also apply to
1783 TimeMap discovery. However, for TimeMaps, each Link element has a
1784 value of "timemap" for its "rel" attribute.
1786 Figure 26 and Figure 27 illustrate how a server makes TimeGates
1787 associated with its own Original Resources discoverable, whereas
1788 Figure 28 illustrates how a web archive that hosts Mementos for
1789 Original Resources originating from various domains makes its
1790 TimeGates and TimeMaps discoverable.
1792 Figure 26 shows a host-meta document published at
1793 http://a.example.org/.well-known/host-meta by a wiki that has
1794 http://a.example.org as its base URI. The document supports
1795 discovery of TimeGates that allow accessing prior versions of the
1796 wiki's Original Resources. The URI template uses the "uri" variable
1797 to stand for a document in the wiki's document range. Assuming
1798 http://a.example.org/w/Clock is the URI of an Original Resource on
1799 the wiki, applying the template to that URI yields
1800 http://a.example.org/Special:TimeGate/http://a.example.org/w/Clock as
1801 its corresponding TimeGate.
1803
1804
1806
1808
1809
1811 Figure 26: A host-meta Document Supporting TimeGate Discovery for a
1812 Wiki's Original Resources
1814 Figure 27 shows a host-meta document published at
1815 http://a.example.org/.well-known/host-meta by the server with base
1816 URI http://a.example.org to support discovery of TimeGates for its
1817 Original Resources. The example shows that the URI of TimeGates
1818 differs depending on the server path. Assuming
1819 http://a.example.org/b/Clock is the URI of an Original Resource on
1820 the wiki, applying that URI to the appropriate template yields
1821 http://a2.example.net/tg/http://a.example.org/b/Clock as its
1822 corresponding TimeGate.
1824
1825
1827
1829
1830
1832
1833
1835 Figure 27: A host-meta Document Supporting TimeGate Discovery for a
1836 Server's Original Resources
1838 Figure 28 shows a host-meta document published at
1839 http://arxiv.example.net/.well-known/host-meta by a web archive that
1840 has http://arxiv.example.net/ as its base URI. The document supports
1841 discovery of TimeGates and TimeMaps that the archive exposes, and
1842 that are associated with Original Resources for which the archive
1843 holds Mementos. The URI templates use the "anyuri" variable, which
1844 is an indication that the web archive holds Mementos for a wide
1845 variety of domains.
1847
1848
1850
1852
1853
1855
1856
1858 Figure 28: A host-meta Document Supporting Discovery of TimeGates and
1859 TimeMaps Exposed by a Web Archive
1861 5. IANA Considerations
1863 This memo requires IANA to register the Accept-Datetime and Memento-
1864 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1865 IANA registry.
1867 This memo requires IANA to register the "Link" header Relation Types
1868 "original", "timegate", "timemap", and "memento" defined in
1869 Section 2.2.1 in the appropriate IANA registry.
1871 This memo requires IANA to register the "datetime" attribute for
1872 "Link" headers with a "memento" Relation Type, as defined in
1873 Section 2.2.1.4 in the appropriate IANA registry.
1875 6. Security Considerations
1877 Provision of a "timegate" HTTP "Link" header in responses to requests
1878 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1879 response codes) is OPTIONAL. The inclusion of this Link when
1880 requesting authentication is at the server's discretion; cases may
1881 exist in which a server protects the current state of a resource, but
1882 supports open access to prior states and thus chooses to supply a
1883 "timegate" HTTP "Link" header. Conversely, the server may choose to
1884 not advertise the TimeGate URIs (e.g., they exist in an intranet
1885 archive) for unauthenticated requests.
1887 Authentication, encryption and other security related issues are
1888 otherwise orthogonal to Memento.
1890 7. Changelog
1892 v04 2012-05-18 HVDS MLN RS draft-vandesompel-memento-04
1894 o Removed the possibility to use an interval indicator in an Accept-
1895 Datetime header as no one is implementing it.
1897 o Corrected typo in Other Relation Types table.
1899 o Added TimeMap examples to illustrate index of TimeMaps and TimeMap
1900 paging.
1902 o Changed Discovery component from using robots.txt with Memento-
1903 specific add-ons to well-known URI and host-meta.
1905 o Removed "embargo" and "license" attributes for links with a
1906 "memento" Relation Type because no one is using them.
1908 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1910 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1911 5XX status code.
1913 o Clarified that a TimeGate must not use the "Memento-Datetime"
1914 header.
1916 o Added wording to warn for possible cache problems with Memento
1917 implementations that choose to have an Original Resource and and
1918 its TimeGate coincide.
1920 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1922 o Added scenario in which a TimeGate redirects to another TimeGate.
1924 o Reorganized TimeGate section to better reflect the difference
1925 between requests with and without interval indicator.
1927 o Added recommendation to provide "memento" links to Mementos in the
1928 vicinity of the preferred interval provided by the client, in case
1929 of a 406 response.
1931 o Removed TimeMap Feed material from the Discovery section as a
1932 result of discussions regarding (lack of) scalability of the
1933 approach with representatives of the International Internet
1934 Preservation Consortium. An alternative approach to support batch
1935 discovery of Mementos will be specified.
1937 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1939 o Introduced wording and reference to indicate a Memento is a
1940 FixedResource.
1942 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1943 about retaining "Memento-Datetime" headers and values when a
1944 Memento is mirrored at different URI.
1946 o Introduced section about handling both datetime and regular
1947 negotiation.
1949 o Introduced section about Mementos Without TimeGate.
1951 o Made various changes in the section Relation Type "memento",
1952 including addition of "license" and "embargo" attributes, and
1953 clarification of rules regarding the use of "memento" links.
1955 o Moved section about TimeMaps inside the Datetime Negotiation
1956 section, and updated it.
1958 o Restarted the Discovery section from scratch.
1960 v01 2010-11-11 HVDS MLN RS First public version
1961 draft-vandesompel-memento-00
1963 v00 2010-10-19 HVDS MLN RS Limited circulation version
1965 2010-07-22 HVDS MLN First internal version
1967 8. Acknowledgements
1969 The Memento effort is funded by the Library of Congress. Many thanks
1970 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1971 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers
1972 for early feedback. Many thanks to Samuel Adams, Scott Ainsworth,
1973 Lyudmilla Balakireva, Frank McCown, Harihar Shankar, Brad Tofel for
1974 early implementations.
1976 9. References
1978 9.1. Normative References
1980 [I-D.ietf-core-link-format]
1981 Shelby, Z., "CoRE Link Format",
1982 draft-ietf-core-link-format-12 (work in progress),
1983 May 2012.
1985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1986 Requirement Levels", BCP 14, RFC 2119, March 1997.
1988 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1989 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1990 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1992 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
1993 RFC 4151, October 2005.
1995 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1996 Syndication Format", RFC 4287, December 2005.
1998 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
1999 Uniform Resource Identifiers (URIs)", RFC 5785,
2000 April 2010.
2002 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
2003 for Simple Version Navigation between Web Resources",
2004 RFC 5829, April 2010.
2006 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
2008 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata",
2009 RFC 6415, October 2011.
2011 9.2. Informative References
2013 [Fitch] Fitch, "Web site archiving - an approach to recording
2014 every materially different response produced by a
2015 website", July 2003,
2016 .
2018 [I-D.masinter-dated-uri]
2019 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
2020 dated URIs", draft-masinter-dated-uri-10 (work in
2021 progress), January 2012.
2023 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2024 and Support", STD 3, RFC 1123, October 1989.
2026 [W3C.REC-aww-20041215]
2027 Jacobs and Walsh, "Architecture of the World Wide Web",
2028 December 2004, .
2030 [W3C.gen-ont-20090420]
2031 Berners-Lee, "Architecture of the World Wide Web",
2032 April 2009, .
2034 [robotstxt.org]
2035 "Robots Exclusion Protocol", August 2010,
2036 .
2038 Appendix A. Appendix B: A Sample, Successful Memento Request/Response
2039 cycle
2041 Step 1 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-R
2043 HEAD / HTTP/1.1
2044 Host: a.example.org
2045 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2046 Connection: close
2048 Step 2 : UA <-- HTTP 200; Link: URI-G ----------------------- URI-R
2049 HTTP/1.1 200 OK
2050 Date: Thu, 21 Jan 2010 00:02:12 GMT
2051 Server: Apache
2052 Link:
2053 ; rel="timegate"
2054 Content-Length: 255
2055 Connection: close
2056 Content-Type: text/html; charset=iso-8859-1
2058 Step 3 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-G
2060 GET /timegate/http://a.example.org
2061 HTTP/1.1
2062 Host: arxiv.example.net
2063 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2064 Connection: close
2066 Step 4 : UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
2067 URI-R, URI-T, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-G
2069 HTTP/1.1 302 Found
2070 Date: Thu, 21 Jan 2010 00:06:50 GMT
2071 Server: Apache
2072 Vary: negotiate, accept-datetime
2073 Location:
2074 http://arxiv.example.net/web/20010911203610/http://a.example.org
2075 Link: ; rel="original",
2076
2077 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
2078
2079 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
2080
2081 ; rel="timemap"; type="application/link-format",
2082
2083 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
2084
2085 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
2086
2087 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
2088 Content-Length: 0
2089 Content-Type: text/plain; charset=UTF-8
2090 Connection: close
2092 Step 5 : UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------> URI-Mj
2094 GET /web/20010911203610/http://a.example.org
2095 HTTP/1.1
2096 Host: arxiv.example.net
2097 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2098 Connection: close
2100 Step 6 : UA <-- HTTP 200; Memento-Datetime: Tj; Link: URI-R,
2101 URI-T, URI-G, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-Mj
2103 HTTP/1.1 200 OK
2104 Date: Thu, 21 Jan 2010 00:09:40 GMT
2105 Server: Apache-Coyote/1.1
2106 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
2107 Link: ; rel="original",
2108
2109 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
2110
2111 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
2112
2113 ; rel="timemap"; type="application/link-format",
2114
2115 ; rel="timegate",
2116
2117 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
2118
2119 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
2120
2121 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
2122 Content-Length: 23364
2123 Content-Type: text/html;charset=utf-8
2124 Connection: close
2126 A successful flow with TimeGate and Mementos on the same server
2128 Authors' Addresses
2130 Herbert VandeSompel
2131 Los Alamos National Laboratory
2132 PO Box 1663
2133 Los Alamos, New Mexico 87545
2134 USA
2136 Phone: +1 505 667 1267
2137 Email: hvdsomp@gmail.com
2138 URI: http://public.lanl.gov/herbertv/
2139 Michael Nelson
2140 Old Dominion University
2141 Norfolk, Virginia 23529
2142 USA
2144 Phone: +1 757 683 6393
2145 Email: mln@cs.odu.edu
2146 URI: http://www.cs.odu.edu/~mln/
2148 Robert Sanderson
2149 Los Alamos National Laboratory
2150 PO Box 1663
2151 Los Alamos, New Mexico 87545
2152 USA
2154 Phone: +1 505 665 5804
2155 Email: azaroth42@gmail.com