idnits 2.17.1
draft-vandesompel-memento-03.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
== Line 1891 has weird spacing: '...ts that respe...'
== 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 (December 20, 2011) is 4512 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4151' is defined on line 2009, but no explicit
reference was found in the text
== Outdated reference: A later version (-14) exists of
draft-ietf-core-link-format-09
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288)
== Outdated reference: A later version (-10) exists of
draft-masinter-dated-uri-08
Summary: 2 errors (**), 0 flaws (~~), 7 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: June 22, 2012 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 December 20, 2011
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-03
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 June 22, 2012.
44 Copyright Notice
46 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . 10
73 2.1.4. Link . . . . . . . . . . . . . . . . . . . . . . . . . 10
74 2.2. Link Header Relation Types . . . . . . . . . . . . . . . . 10
75 2.2.1. Memento Framework Relation Types . . . . . . . . . . . 10
76 2.2.1.1. Relation Type "original" . . . . . . . . . . . . . 11
77 2.2.1.2. Relation Type "timegate" . . . . . . . . . . . . . 11
78 2.2.1.3. Relation Type "timemap" . . . . . . . . . . . . . 12
79 2.2.1.4. Relation Type "memento" . . . . . . . . . . . . . 12
80 2.2.2. Other Relation Types . . . . . . . . . . . . . . . . . 14
81 3. The Memento Framework, Datetime Negotiation component:
82 HTTP Interactions . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 17
87 3.1.2.1. Original Resource is an Appropriate Memento . . . 18
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 . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . 21
97 3.2.2.1. Successful Scenario . . . . . . . . . . . . . . . 21
98 3.2.2.2. Accept-Datetime with Interval Indicator
99 Provided . . . . . . . . . . . . . . . . . . . . . 23
100 3.2.2.3. Multiple Matching Mementos . . . . . . . . . . . . 24
101 3.2.2.4. TimeGate Redirects to another TimeGate . . . . . . 25
102 3.2.2.5. Accept-Datetime and other Accept Headers
103 Provided . . . . . . . . . . . . . . . . . . . . . 26
104 3.2.2.6. Accept-Datetime Unparseable . . . . . . . . . . . 27
105 3.2.2.7. Accept-Datetime Not Provided . . . . . . . . . . . 27
106 3.2.2.8. TimeGate Does Not Exist . . . . . . . . . . . . . 27
107 3.2.2.9. HTTP Methods other than HEAD/GET . . . . . . . . . 27
108 3.2.3. Recognizing a TimeGate . . . . . . . . . . . . . . . . 28
109 3.3. Interactions with a Memento . . . . . . . . . . . . . . . 29
110 3.3.1. Step 5: User Agent Requests a Memento . . . . . . . . 29
111 3.3.2. Step 6: Server Responds to a Request for a Memento . . 29
112 3.3.2.1. Common Scenario . . . . . . . . . . . . . . . . . 29
113 3.3.2.2. Memento of a 3XX Response . . . . . . . . . . . . 31
114 3.3.2.3. Memento of Responses with Other HTTP Status
115 Codes . . . . . . . . . . . . . . . . . . . . . . 33
116 3.3.2.4. Mementos Without a TimeGate . . . . . . . . . . . 34
117 3.3.2.5. Memento Does not Exist . . . . . . . . . . . . . . 35
118 3.3.3. Recognizing a Memento . . . . . . . . . . . . . . . . 36
119 3.4. Interactions with a TimeMap . . . . . . . . . . . . . . . 36
120 3.4.1. User Agent Requests a TimeMap . . . . . . . . . . . . 37
121 3.4.2. Server Responds to a Request for a TimeMap . . . . . . 37
122 4. The Memento Framework, Discovery Component . . . . . . . . . . 39
123 4.1. Discovering TimeGates Via Robots Exclusion Protocol . . . 39
124 4.2. Discovering Mementos via Robots Exclusion Protocol . . . . 41
125 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
126 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
127 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 42
128 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
129 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
130 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
131 9.2. Informative References . . . . . . . . . . . . . . . . . . 44
132 Appendix A. Appendix B: A Sample, Successful Memento
133 Request/Response cycle . . . . . . . . . . . . . . . 44
134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
136 1. Introduction
138 1.1. Terminology
140 This specification uses the terms "resource", "request", "response",
141 "entity", "entity-body", "entity-header", "content negotiation",
142 "client", "user agent", "server" as described in RFC 2616 [RFC2616],
143 and it uses the terms "representation" and "resource state" as
144 described in W3C.REC-aww-20041215 [W3C.REC-aww-20041215].
146 In addition, the following terms specific to the Memento framework
147 are introduced:
149 o Original Resource: An Original Resource is a resource that exists
150 or used to exist, and for which access to one of its prior states
151 is desired.
153 o Memento: A Memento for an Original Resource is a resource that
154 encapsulates a prior state of the Original Resource. A Memento
155 for an Original Resource as it existed at time Tj is a resource
156 that encapsulates the state that the Original Resource had at time
157 Tj.
159 o TimeGate: A TimeGate for an Original Resource is a resource that
160 is capable of negotiation to allow selective, datetime-based,
161 access to prior states of the Original Resource.
163 o TimeMap: A TimeMap for an Original Resource is a resource from
164 which a list of URIs of Mementos of the Original Resource is
165 available.
167 1.2. Purpose
169 The state of an Original Resource may change over time.
170 Dereferencing its URI at any specific moment in time during its
171 existence yields a representation of its then current state.
172 Dereferencing its URI at any time past its existence no longer yields
173 a meaningful representation, if any. Still, in both cases, resources
174 may exist that encapsulate prior states of the Original Resource.
175 Each such resource, named a Memento, has its own URI that, when
176 dereferenced, returns a representation of a prior state of the
177 Original Resource. Mementos may, for example, exist in Web archives,
178 Content Management Systems, or Revision Control Systems.
180 Examples are:
182 Mementos for Original Resource http://www.ietf.org/ :
184 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
186 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
187 www.ietf.org/
189 Mementos for Original Resource
190 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol :
192 o http://en.wikipedia.org/w/
193 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
195 o http://en.wikipedia.org/w/
196 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
198 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
199 wiki/Hypertext_Transfer_Protocol
201 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
203 o http://www.w3.org/TR/2004/PR-webarch-20041105/
205 o http://www.w3.org/TR/2002/WD-webarch-20020830/
207 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
208 www.w3.org/TR/webarch/
210 In the abstract, Memento introduces a mechanism to access versions of
211 Web resources that:
213 o Is fully distributed in the sense that resource versions may
214 reside on multiple hosts, and that any such host is likely only
215 aware of the versions it holds;
217 o Uses the global notion of datetime as a resource version indicator
218 and access key;
220 o Leverages the following primitives of W3C.REC-aww-20041215
221 [W3C.REC-aww-20041215]: resource, resource state, representation,
222 content negotiation, and link.
224 The core components of Memento's mechanism to access resource
225 versions are:
227 1. The abstract notion of the state of a resource identified by
228 URI-R as it existed at some time Tj. Note the relationship with the
229 ability to identify a the state of a resource at some datetime Tj by
230 means of a URI as intended by the proposed Dated URI scheme
231 I-D.masinter-dated-uri [I-D.masinter-dated-uri].
233 2. A bridge from the present to the past, consisting of:
235 o An appropriately typed link from a resource identified by URI-R to
236 an associated TimeGate identified by URI-G, which is aware of (at
237 least part of the) version history of the resource identified by
238 URI-R;
240 o The ability to content negotiate in the datetime dimension with
241 the TimeGate identified by URI-G, as a means to obtain a
242 representation of the state that the resource identified by URI-R
243 had at some datetime Tj.
245 3. A bridge from the past to the present, consisting of an
246 appropriately typed link from a resource identified by URI-M, which
247 encapsulates the state a resource identified by URI-R had at some
248 datetime Tj, to the resource identified by URI-R.
250 Section 2 and Section 3 of this document are concerned with
251 specifying an instantiation of these abstractions for resources that
252 are identified by HTTP(S) URIs, whereas Section 4 details approaches
253 to discover TimeGates, TimeMaps, and Mementos on the HTTP(S) Web by
254 other means than typed links.
256 1.3. Notational Conventions
258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
260 document are to be interpreted as described in RFC 2119 [RFC2119].
262 When needed for extra clarity, the following conventions are used:
264 o URI-R is used to denote the URI of an Original Resource.
266 o URI-G is used to denote the URI of a TimeGate.
268 o URI-M is used to denote the URI of a Memento.
270 o URI-T is used to denote the URI of a TimeMap.
272 o When scenarios are described that involve multiple Mementos,
273 URI-M0 denotes the URI of the first Memento known to the
274 responding server, URI-Mn denotes the URI of the most recent known
275 Memento, URI-Mj denotes the URI of the selected Memento, URI-Mi
276 denotes the URI of the Memento that is temporally previous to the
277 selected Memento, and URI-Mk denotes the URI of the Memento that
278 is temporally after the selected Memento. The respective
279 datetimes for these Mementos are T0, Tn, Tj, Ti, and Tk; it holds
280 that T0 <= Ti <= Tj <= Tk <= Tn.
282 2. The Memento Framework, Datetime Negotiation component: HTTP headers,
283 HTTP Link Relation Types
285 The Memento framework is concerned with Original Resources,
286 TimeGates, Mementos, and TimeMaps that are identified by HTTP or
287 HTTPS URIs. Details are only provided for resources identified by
288 HTTP URIs but apply similarly to those with HTTPS URIs.
290 2.1. HTTP Headers
292 The Memento framework operates at the level of HTTP request and
293 response headers. It introduces two new headers ("Accept-Datetime",
294 "Memento-Datetime"), introduces new values for two existing headers
295 ("Vary", "Link"), and uses an existing header ("Location") without
296 modification. All these headers are described below. Other HTTP
297 headers are present or absent in Memento response/request cycles as
298 specified by RFC 2616 [RFC2616].
300 2.1.1. Accept-Datetime, Memento-Datetime
302 The "Accept-Datetime" request header is used by a user agent to
303 indicate it wants to retrieve a representation of a Memento that
304 encapsulates a past state of an Original Resource. To that end, the
305 "Accept-Datetime" header is conveyed in an HTTP GET/HEAD request
306 issued against a TimeGate for an Original Resource, and its value
307 indicates the datetime of the desired past state of the Original
308 Resource. The "Accept-Datetime" request header has no defined
309 meaning for HTTP methods other than HEAD and GET.
311 The "Memento-Datetime" response header is used by a server to
312 indicate that the response contains a representation of a Memento,
313 and its value expresses the datetime of the state of an Original
314 Resource that is encapsulated in that Memento. The URI of that
315 Original Resource is provided in the response, as the Target IRI (see
316 RFC5988 [RFC5988]) of a link provided in the HTTP "Link" header that
317 has a Relation Type of "original" (see Section 2.2).
319 The presence of a "Memento-Datetime" header and associated value for
320 a given resource constitutes a promise that the resource is stable
321 and that its state will no longer change. This means that, in terms
322 of the Ontology for Relating Generic and Specific Information
323 Resources (see W3C.gen-ont-20090420 [W3C.gen-ont-20090420]), a
324 Memento is a FixedResource.
326 As a consequence, "Memento-Datetime" headers associated with a
327 Memento MUST be "sticky" in the following ways:
329 o The server that originally assigns the "Memento-Datetime" header
330 and value MUST retain that header in all responses to HTTP HEAD/
331 GET requests (with or without "Accept-Datetime" header) that occur
332 against the Memento after the time of the original assignment of
333 the header, and it MUST NOT change its associated value.
335 o Applications that mirror Mementos at a different URI MUST NOT
336 change the "Memento-Datetime" header and value of those Mementos
337 unless mirroring involves a meaningful state change. This allows,
338 for example, duplicating a Web archive at a new location while
339 preserving the value of the "Memento-Datetime" header of the
340 archived resources. In this example, the "Last-Modified" header
341 will be updated to reflect the time of mirroring at the new URI,
342 whereas the value for "Memento-Datetime" will be sticky.
344 2.1.1.1. Values for Accept-Datetime
346 Values for the "Accept-Datetime" header consist of a MANDATORY
347 datetime expressed according to the RFC 1123 [RFC1123] format, which
348 is formalized by the rfc1123-date construction rule of the BNF in
349 Figure 1, and an OPTIONAL interval indicator expressed according to
350 the iso8601-interval rule of the BNF in Figure 1. The datetime MUST
351 be represented in Greenwich Mean Time (GMT).
353 Examples of "Accept-Datetime" request headers with and without an
354 interval indicator:
356 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
357 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT; -P3DT5H;+P2DT6H
359 The user agent uses the MANDATORY datetime value to convey its
360 preferred datetime for a Memento; it uses the OPTIONAL interval
361 indicator to convey it is interested in retrieving Mementos that
362 reside within this interval around the preferred datetime, and not
363 interested in Mementos that reside outside of it. Not using an
364 interval indicator is equivalent to expressing an infinite interval
365 around the preferred datetime.
367 The interval mechanism can be regarded as an implementation of the
368 functionality intended by the q-value approach that is used in
369 regular content negotiation. The q-value approach is not supported
370 for Memento's datetime negotiation because it is well-suited for
371 negotiation over a discrete space of mostly predictable values, not
372 for negotiation over a continuum of unpredictable datetime values.
374 accept-dt-value = rfc1123-date *SP [ iso8601-interval ]
375 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
376 date1 = 2DIGIT SP month SP 4DIGIT
377 ; day month year (e.g., 20 Mar 1957)
378 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
379 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
380 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
381 "Sun"
382 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
383 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
384 iso8601-interval = ";" *SP "-" duration *SP ";" *SP "+" duration
385 duration = "P" ( dur-date | dur-week )
386 dur-date = ( dur-day | dur-month | dur-year ) [ dur-time ]
387 dur-year = 1*DIGIT "Y" [ dur-month ] [ dur-day ]
388 dur-month = 1*DIGIT "M" [ dur-day ]
389 dur-day = 1*DIGIT "D"
390 dur-time = "T" ( dur-hour | dur-minute | dur-second )
391 dur-hour = 1*DIGIT "H" [ dur-minute ] [ dur-second ]
392 dur-minute = 1*DIGIT "M" [ dur-second ]
393 dur-second = 1*DIGIT "S"
394 dur-week = 1*DIGIT "W"
396 Figure 1: BNF for the datetime format
398 2.1.1.2. Values for Memento-Datetime
400 Values for the "Memento-Datetime" headers MUST be datetimes expressed
401 according to the rfc1123-date construction rule of the BNF in
402 Figure 1; they MUST be represented in Greenwich Mean Time (GMT).
404 An example "Memento-Datetime" response header:
406 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
408 2.1.2. Vary
410 The "Vary" response header is used in responses to indicate the
411 dimensions in which content negotiation was successfully applied.
412 This header is used in the Memento framework to indicate both whether
413 datetime negotiation was applied or is supported by the responding
414 server.
416 For example, this use of the "Vary" header indicates that datetime is
417 the only dimension in which negotiation was applied:
419 Vary: negotiate, accept-datetime
420 The use of the "Vary" header in this example shows that both datetime
421 negotiation, and media type content negotiation were applied:
423 Vary: negotiate, accept-datetime, accept
425 2.1.3. Location
427 The "Location" header is used as defined in RFC 2616 [RFC2616].
428 Examples are given in Section 3 below.
430 2.1.4. Link
432 The "Link" response header is specified in RFC5988 [RFC5988]. The
433 Memento framework introduces new Relation Types to convey typed links
434 among Original Resources, TimeGates, Mementos, and TimeMaps. Already
435 existing Relation Types, among others, aimed at supporting navigation
436 among a series of ordered resources may also be used in the Memento
437 framework. This is detailed in Link Header Relation Types
438 (Section 2.2), below.
440 2.2. Link Header Relation Types
442 The "Link" header specified in RFC5988 [RFC5988] is semantically
443 equivalent to the "" element in HTML, as well as the "atom:
444 link" feed-level element in Atom RFC 4287 [RFC4287]. By default, the
445 origin of a link expressed by an entry in a "Link" header (named
446 Context IRI in RFC5988 [RFC5988]) is the IRI of the requested
447 resource. This default can be overwritten using the "anchor"
448 attribute in the entry.
450 2.2.1. Memento Framework Relation Types
452 The Relation Types used in the Memento framework are listed in the
453 remainder of this section, and their use is summarized in the below
454 table. Appendix A shows a Memento request/response cycle that uses
455 all the Relation Types that are introduced here.
457 +----------+-------------------+---------------------+--------------+
458 | Relation | Original Resource | TimeGate | Memento |
459 | Type | | | |
460 +----------+-------------------+---------------------+--------------+
461 | original | NA, except see | REQUIRED, 1 | REQUIRED, 1 |
462 | | Section 3.1.2.1 | | |
463 | timegate | RECOMMENDED, 0 or | REQUIRED, 1 in case | RECOMMENDED, |
464 | | more | of Section 3.2.2.4 | 0 or more |
465 | timemap | NA | RECOMMENDED, 0 or | RECOMMENDED, |
466 | | | more | 0 or more |
467 | memento | NA, except see | REQUIRED, 1 or more | REQUIRED, 1 |
468 | | Section 3.1.2.1 | | or more |
469 +----------+-------------------+---------------------+--------------+
471 Table 1: The use of Relation Types
473 2.2.1.1. Relation Type "original"
475 "original" -- A "Link" header entry with a Relation Type of
476 "original" is used to point from a TimeGate or a Memento to their
477 associated Original Resource. In both cases, an entry with the
478 "original" Relation Type MUST occur exactly once in a "Link" header.
479 Details for the entry are as follows:
481 o Context IRI: URI-G, URI-M
483 o Target IRI: URI-R
485 o Relation Type: "original"
487 o Use: REQUIRED
489 o Cardinality: 1
491 2.2.1.2. Relation Type "timegate"
493 "timegate" -- A "Link" header entry with a Relation Type of
494 "timegate" is used to point both from an Original Resource or a
495 Memento to a TimeGate for the Original Resource. In both cases, the
496 use of an entry with the "timegate" Relation Type is RECOMMENDED.
497 Since more than one TimeGate can exist for any Original Resource,
498 multiple entries with a "timegate" Relation Type MAY occur, each with
499 a distinct Target IRI. Since a TimeGate has no mime type, the "type"
500 attribute MUST NOT be used on Links with a "timegate" Relation Type.
501 Details for the entry are as follows:
503 o Context IRI: URI-R or URI-Mj
505 o Target IRI: URI-G
507 o Relation Type: "timegate"
509 o Use: RECOMMENDED
511 o Cardinality: 0 or more
513 In the special case (see Section 3.2.2.4) where a TimeGate redirects
514 to another TimeGate for the Original Resource, a "Link" header entry
515 with a Relation Type of "timegate" MUST be used to point from the
516 former to the latter.
518 2.2.1.3. Relation Type "timemap"
520 "timemap" -- A "Link" header entry with a Relation Type of "timemap"
521 is used to point from both a TimeGate or a Memento to a TimeMap
522 resource from which a list of Mementos known to the responding server
523 is available. Use of an entry with the "timemap" Relation Type is
524 RECOMMENDED, and, since multiple serializations of a TimeMap are
525 possible, multiple entries with a "timemap" Relation Type MAY occur,
526 each with a distinct Target IRI, and each with a MANDATORY "type"
527 attribute to convey the mime type of the TimeMap serialization.
528 Details for the entry are as follows:
530 o Context IRI: URI-G or URI-Mi
532 o Target IRI: URI-T
534 o Relation Type: "timemap"
536 o Target Attribute: "type"
538 o Use: RECOMMENDED
540 o Cardinality: 0 or more
542 Further details about TimeMap serializations are provided in
543 Section 3.4.
545 2.2.1.4. Relation Type "memento"
547 "memento" -- A "Link" header entry with a Relation Type of "memento"
548 is used to point from both a TimeGate and a Memento to various
549 Mementos for an Original Resource. This link MUST include a
550 "datetime" attribute with a value that matches the "Memento-Datetime"
551 of the Memento that is the target of the link; that is, the value of
552 the "Memento-Datetime" header that is returned when the URI of the
553 linked Memento is dereferenced. In addition, the link MAY include an
554 "embargo" attribute to convey the datetime until which the Memento
555 will remain inaccessible. The value for both the "datetime" and
556 "embargo" attributes MUST be a datetime expressed according to the
557 rfc1123-date construction rule of the BNF in Figure 1 and it MUST be
558 represented in Greenwich Mean Time (GMT). This link MAY also include
559 a "license" attribute to associate a license with the Memento; the
560 value for the "license" attribute SHOULD be a URI. The link SHOULD
561 also include a "type" attribute to convey the mime type of the
562 Memento that is the target of the link. Use of entries with the
563 "memento" Relation Type is REQUIRED and it MUST be as follows:
565 For all responses to HTTP HEAD/GET requests issued against a TimeGate
566 or a Memento in which a Memento is selected or served by the
567 responding server:
569 o One "memento" link MUST be included that has as Target IRI the URI
570 of the Memento that was selected or served;
572 o One "memento" link MUST be included that has as Target IRI the URI
573 of the temporally first Memento known to the responding server;
575 o One "memento" link MUST be included that has as Target IRI the URI
576 of the temporally most recent Memento known to the responding
577 server.
579 o One "memento" link SHOULD be included that has as Target IRI the
580 URI of the Memento that is previous to the selected Memento in the
581 temporal series of all Mementos (sorted by ascending "Memento-
582 Datetime" values) known to the server;
584 o One "memento" link SHOULD be included that has as Target IRI the
585 URI the Memento that is next to the selected Memento in the
586 temporal series of all Mementos (sorted by ascending "Memento-
587 Datetime" values) known to the server.
589 o Other "memento" links MAY only be included if both the
590 aforementioned previous and next links are provided. Each of
591 these OPTIONAL "memento" links MUST have as Target IRI the URI of
592 a Memento other than the ones listed above.
594 For all responses to HTTP HEAD/GET requests issued against an
595 existing TimeGate or Memento in which no Memento is selected or
596 served by the responding server:
598 o One "memento" link MUST be included that has as Target IRI the URI
599 of the temporally first Memento known to the responding server;
601 o One "memento" link MUST be included that has as Target IRI the URI
602 of the temporally most recent Memento known to the responding
603 server.
605 o Other "memento" links MAY be included, and each of these OPTIONAL
606 links MUST have as Target IRI the URI of a Memento other than the
607 two listed above.
609 Note that the Target IRI of some of these links may coincide. For
610 example, if the selected Memento actually is the first Memento known
611 to the server, only three distinct "memento" links may result. The
612 value for the "datetime" attribute of these links would be the
613 datetimes of the first (equal to selected), next, and most recent
614 Memento known to the responding server.
616 The summary is as follows:
618 o Context IRI: URI-G, URI-Mj
620 o Target IRI: URI-M
622 o Relation Type: "memento"
624 o Target Attributes: "datetime", "embargo", "license"
626 o Use: REQUIRED
628 o Cardinality: 1 or more
630 2.2.2. Other Relation Types
632 Web Linking RFC5988 [RFC5988] allows for the inclusion of links with
633 different Relation Types but the same Target IRI, and hence the
634 Relation Types introduced by the Memento framework MAY be combined
635 with others as deemed necessary. As the "memento" Relation Type
636 focuses on conveying the datetime of a linked Memento, Relation Types
637 that allow navigating among the temporally ordered series of Mementos
638 known to a server are of particular importance. With this regard,
639 the Relation Types listed in the below table SHOULD be considered for
640 combination with the "memento" Relation Type. A distinction is made
641 between responding servers that can be categorized as systems that
642 are the focus of RFC5829 [RFC5829] (such as version control systems)
643 and others that can not (such as Web archives). Note that, in terms
644 of RFC5829 [RFC5829], the last Memento (URI-Mn) is the version prior
645 to the latest (i.e. current) version.
647 +-----------------------------+---------------------+---------------+
648 | Memento Type | RFC5988 system | non RFC5988 |
649 | | | system |
650 +-----------------------------+---------------------+---------------+
651 | First Memento (URI-M0) | first | first |
652 | Last Memento (URI-Mn) | last | last |
653 | Selected Memento (URI-Mj) | NA | NA |
654 | Memento prior to selected | predecessor-version | prev |
655 | Memento (URI-Mi) | | |
656 | Memento next to selected | successor-version | next |
657 | Memento (URI-Mk) | | |
658 +-----------------------------+---------------------+---------------+
659 Table 2: The use of Relation Types
661 3. The Memento Framework, Datetime Negotiation component: HTTP
662 Interactions
664 This section describes the HTTP interactions of the Memento framework
665 for a variety of scenarios. First, Figure 2 provides a schematic
666 overview of a successful request/response chain that involves
667 datetime negotiation. Dashed lines depict HTTP transactions between
668 user agent and server. Appendix A shows these HTTP interactions in
669 detail for the case where the Original Resource resides on one
670 server, whereas both the TimeGate and the Mementos reside on another.
671 Scenarios also exist in which all these resources are on the same
672 server (for example, Content Management Systems) or on different
673 servers (for example, an aggregator of TimeGates). Note that, in
674 Step 2 and Step 6, the HTTP status code of the response is shown as
675 "200 OK", but a series of "206 Partial Content" responses could be
676 substituted without loss of generality.
678 1: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-R
679 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
680 3: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-G
681 4: UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
682 URI-R,URI-T,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -------- URI-G
683 5: UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------------> URI-Mj
684 6: UA <-- HTTP 200; Memento-Datetime: Tj; Link:
685 URI-R,URI-T,URI-G,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -- URI-Mj
687 Figure 2: Typical Memento request/response chain
689 o Step 1: In order to determine what the URI is of a TimeGate for an
690 Original Resource, the user agent issues an HTTP HEAD/GET request
691 against the URI of the Original Resource (URI-R).
693 o Step 2: The entity-header of the response from URI-R includes an
694 HTTP "Link" header with a Relation Type of "timegate" pointing at
695 a TimeGate (URI-G) for the Original Resource.
697 o Step 3: The user agent starts the datetime negotiation process
698 with the TimeGate by issuing an HTTP GET request against its URI-G
699 thereby including an "Accept-Datetime" HTTP header with a value of
700 the datetime of the desired prior state of the Original Resource.
702 o Step 4: The entity-header of the response from URI-G includes a
703 "Location" header pointing at the URI of a Memento (URI-Mj) for
704 the Original Resource. In addition, the entity-header contains an
705 HTTP "Link" header with a Relation Type of "original" pointing at
706 the Original Resource, and an HTTP "Link" header with a Relation
707 Type of "timemap" pointing at a TimeMap (URI-T). Also HTTP Links
708 pointing at various Mementos are provided using the "memento"
709 Relation Type, as specified in Section 2.2.1.4.
711 o Step 5: The user agent issues an HTTP GET request against the
712 URI-Mj of a Memento, obtained in Step 4.
714 o Step 6: The entity-header of the response from URI-Mj includes a
715 "Memento-Datetime" HTTP header with a value of the datetime of the
716 Memento. It also contains an HTTP "Link" header with a Relation
717 Type of "original" pointing at the Original Resource, with a
718 Relation Type of "timegate" pointing at a TimeGate associated with
719 the Original Resource, and with a Relation Type of "timemap"
720 pointing at a TimeMap. The state that is expressed by the
721 representation provided in the response is the state the Original
722 Resource had at the datetime expressed in the "Memento-Datetime"
723 header. This response also includes HTTP Links with a "memento"
724 Relation Type pointing at various Mementos, as specified in
725 Section 2.2.1.4.
727 The following sections detail the specifics of HTTP interactions with
728 Original Resources, TimeGates, Mementos, and TimeMaps under various
729 conditions.
731 3.1. Interactions with an Original Resource
733 This section details HTTP GET/HEAD requests targeted at an Original
734 Resource (URI-R).
736 3.1.1. Step 1: User Agent Requests an Original Resource
738 In order to try and discover a TimeGate for the Original Resource,
739 the user agent SHOULD issue an HTTP HEAD or GET request against the
740 Original Resource's URI. Use of the "Accept-Datetime" header in the
741 HTTP HEAD/GET request is OPTIONAL.
743 Figure 3 shows the use of HTTP HEAD indicating the user agent is not
744 interested in retrieving a representation of the Original Resource,
745 but only in determining a TimeGate for it. It also shows the use of
746 the "Accept-Datetime" header anticipating that the user agent will
747 set it for the entire duration of a Memento request/response cycle.
749 HEAD / HTTP/1.1
750 Host: a.example.org
751 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
752 Connection: close
753 Figure 3: User Agent Requests Original Resource
755 3.1.2. Step 2: Server Responds to a Request for an Original Resource
757 The response of the Original Resource's server to the user agent's
758 HTTP HEAD/GET request of Step 1, for the case where the Original
759 Resource exists, is as it would be in a regular HTTP request/response
760 cycle, but in addition MAY include a HTTP "Link" header with a
761 Relation Type of "timegate" that conveys the URI of the Original
762 Resource's TimeGate as the Target IRI of the Link. Multiple HTTP
763 Links with a relation type of "timegate" MAY be provided to
764 accommodate situations in which the server is aware of multiple
765 TimeGates for an Original Resource. The actual Target IRI provided
766 in the "timegate" Link may depend on several factors including the
767 datetime provided in the "Accept-Datetime" header, and the IP address
768 of the user agent. A response for this case is illustrated in
769 Figure 4.
771 HTTP/1.1 200 OK
772 Date: Thu, 21 Jan 2010 00:02:12 GMT
773 Server: Apache
774 Link:
775 ; rel="timegate"
776 Content-Length: 255
777 Connection: close
778 Content-Type: text/html; charset=iso-8859-1
780 Figure 4: Server of Original Resource Responds
782 Servers that actively maintain archives of their resources SHOULD
783 include the "timegate" HTTP "Link" header because this link is an
784 important way for a user agent to discover TimeGates for those
785 resources. This includes servers such as Content Management Systems,
786 Control Version Systems, and Web servers with associated
787 transactional archives Fitch [Fitch]. Servers that do not actively
788 maintain archives of their resources MAY include the "timegate" HTTP
789 "Link" header as a way to convey a preference for TimeGates for their
790 resources exposed by a third party archive. This includes servers
791 that rely on Web archives such as the Internet Archive to archive
792 their resources.
794 The server of the Original Resource MUST treat requests with and
795 without an "Accept-Datetime" header in the same way:
797 o The response MUST either always or never include a HTTP "Link"
798 header with an entry that has a "timegate" Relation Type and the
799 URI of a TimeGate as the Target IRI.
801 o The entity-body of the response MUST be the same, for user agent
802 requests with or without a "Accept-Datetime" header.
804 3.1.2.1. Original Resource is an Appropriate Memento
806 The "Memento-Datetime" header MAY be applied to an Original Resource
807 directly to indicate it is a FixedResource (see W3C.gen-ont-20090420
808 [W3C.gen-ont-20090420]), meaning that the state of the Original
809 Resource has not changed since the datetime conveyed in the "Memento-
810 Datetime" header, and as a promise that it will not change anymore
811 beyond it. This may occur, for example, for certain stable media
812 resources on news sites. In case the user agent's preferred datetime
813 is equal to or more recent than the datetime conveyed as the value of
814 "Memento-Datetime" in the server's response in Step 2, the user agent
815 SHOULD conclude it has located an appropriate Memento, and it SHOULD
816 NOT continue to Step 3.
818 Figure 5 illustrates such a response to a request for the resource
819 with URI http://a.example.org/pic that has been stable since it was
820 created. Note the use of both the "memento" and "original" Relation
821 Types for links that have as Target IRI the URI of the Original
822 Resource.
824 HTTP/1.1 200 OK
825 Date: Thu, 21 Jan 2010 00:02:12 GMT
826 Server: Apache
827 Link:
828
829 ; rel="original memento"
830 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT"
831 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
832 Content-Length: 255
833 Connection: close
834 Content-Type: text/html; charset=iso-8909-1
836 Figure 5: Response to a request for an Original Resource that was
837 created as a FixedResource
839 Cases may also exist in which a resource becomes stable at a certain
840 point in its existence, but changed previously. In such cases, the
841 Original Resource may know about a TimeGate that is aware of its
842 prior history and hence MAY also include a link with a "timegate"
843 Relation Type. This is illustrated in Figure 6, where the "memento"
844 and "original" Relation Types are used as in Figure 5, and the
845 existence of a TimeGate to negotiate for Mementos with datetimes
846 prior to Fri, 20 Mar 2009 11:00:00 GMT is indicated.
848 HTTP/1.1 200 OK
849 Date: Thu, 21 Jan 2010 00:02:12 GMT
850 Server: Apache
851 Link:
852
853 ; rel="original memento"
854 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT",
855
856 ; rel="timegate"
857 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
858 Content-Length: 255
859 Connection: close
860 Content-Type: text/html; charset=iso-8909-1
862 Figure 6: Response to a request for an Original Resource that became
863 a FixedResource
865 3.1.2.2. Server Exists and Original Resource Used to Exist
867 Servers SHOULD also provide a "timegate" HTTP "Link" header in
868 responses to requests for an Original Resource that the server knows
869 used to exist, but no longer does. This allows the use of an
870 Original Resource's URI as an entry point to representations of its
871 prior states even if the resource itself no longer exists. A
872 server's response for this case is illustrated in Figure 7.
874 HTTP/1.1 404 Not Found
875 Date: Thu, 21 Jan 2010 00:02:12 GMT
876 Server: Apache
877 Link:
878
879 ; rel="timegate"
880 Content-Length: 255
881 Connection: close
882 Content-Type: text/html; charset=iso-8909-1
884 Figure 7: Response to a request for an Original Resource that not
885 longer exists
887 In case the server is not aware of the prior existence of the
888 Original Resource, its response SHOULD NOT include a "timegate" HTTP
889 Link. Section 3.1.2.3 details what the user agent's behavior should
890 be in such cases.
892 3.1.2.3. Missing or Inadequate "timegate" Link in Original Server's
893 Response
895 A user agent MAY ignore the TimeGate returned in Step 2. However,
896 when engaging in a Memento request/response cycle, a user agent
897 SHOULD NOT proceed immediately to Step 3 by using a TimeGate of its
898 own preference but rather SHOULD always start the cycle by issuing an
899 HTTP GET/HEAD against the Original Resource (Step 1, Figure 3) as it
900 is an important way to learn about dedicated or preferred TimeGates
901 for the Original Resource. Also, cases exist in which the response
902 in Step 2 will not provide a "timegate" link, including:
904 o The Original Resource's server does not support the Memento
905 framework;
907 o The Original Resource no longer exists and the responding server
908 is not aware of its prior existence;
910 o The server that hosted the Original Resource no longer exists;
912 In all these cases, the user agent SHOULD attempt to determine an
913 appropriate TimeGate for the Original Resource, either automatically
914 or interactively supported by the user. The discovery mechanisms
915 described in Section 4 can support the user agent with this regard.
917 3.2. Interactions with a TimeGate
919 This section details HTTP GET/HEAD requests targeted at a TimeGate
920 (URI-G).
922 3.2.1. Step 3: User Agent Negotiates with a TimeGate
924 In order to negotiate with a TimeGate, the user agent MUST issue a
925 HTTP HEAD or GET against its URI, its request MUST include the
926 "Accept-Datetime" header to express its datetime preference, and the
927 use of that header MUST be as described in Section 2.1.1.1. The URI
928 of the TimeGate may have been provided as the Target IRI of a
929 "timegate" HTTP "Link" header in the response from the Original
930 Resource (Step 2, Figure 4), or may have resulted from another
931 discovery mechanism (see Section 4) or user interaction. Such a
932 request is illustrated in Figure 8.
934 GET /timegate/http://a.example.org HTTP/1.1
935 Host: arxiv.example.net
936 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
937 Connection: close
939 Figure 8: User agent negotiates with TimeGate
941 3.2.2. Step 4: Server Responds to Negotiation with TimeGate
943 In order to respond to a datetime negotiation request (Step 3,
944 Section 3.2.1), the server uses an internal algorithm to select the
945 Memento that best meets the user agent's datetime preference, and
946 redirects to it. The exact nature of the selection algorithm is at
947 the server's discretion but SHOULD be consistent. A variety of
948 approaches can be used including selecting the Memento that is
949 nearest in time (either past or future) or nearest in the past
950 relative to the requested datetime. The commons scenario for
951 datetime negotiation with a TimeGate is described in Section 3.2.2.1
952 but special cases exist, and they are addressed in Section 3.2.2.2
953 through Section 3.2.2.9.
955 3.2.2.1. Successful Scenario
957 In cases where the TimeGate exists, and the datetime provided in the
958 user agent's "Accept-Datetime" header can be parsed and does not
959 contain an interval indicator, the server selects a Memento based on
960 the user agent's datetime preference. The response MUST have a "302
961 Found" HTTP status code, and the "Location" header MUST be used to
962 convey the URI of the selected Memento. The "Vary" header MUST be
963 provided and it MUST include the "negotiate" and "accept-datetime"
964 values to indicate that datetime negotiation has taken place. The
965 "Link" header MUST be provided and contain links with Relation Types
966 subject to the considerations described in Section 2.2. The response
967 MUST NOT contain a "Memento-Datetime" header. Such a response is
968 illustrated in Figure 9.
970 HTTP/1.1 302 Found
971 Date: Thu, 21 Jan 2010 00:06:50 GMT
972 Server: Apache
973 Vary: negotiate, accept-datetime
974 Location:
975 http://arxiv.example.net/web/20010911203610/http://a.example.org
976 Link: ; rel="original",
977
978 ; rel="timemap"; type="application/link-format",
979
980 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
981
982 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
983
984 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
985
986 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
987
988 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
989 Content-Length: 0
990 Content-Type: text/plain; charset=UTF-8
991 Connection: close
993 Figure 9: Server of TimeGate responds
995 Note that if a user agent's "Accept-Datetime" header does not convey
996 an interval indicator, and conveys a datetime that is either earlier
997 than the datetime of the first Memento or later than the datetime of
998 the most recent Memento known to the server, the server's response is
999 as just described yet entails the selection of the first or most
1000 recent Memento, respectively. This approach is consistent with
1001 interpreting the absence of an interval indicator in the user agent's
1002 request as an indication of an infinite interval around its preferred
1003 datetime (see Section 2.1.1.1).
1005 This is illustrated in Figure 10 that shows the response from a
1006 TimeGate exposed by a MediaWiki server to a request by a user agent
1007 that has an "Accept-Datetime: Mon, 31 May 1999 00:00:00 GMT" header.
1008 Note that a link is provided with a "successor-version" Relation Type
1009 but not with a "predecessor-version" Relation Type.
1011 HTTP/1.1 302 Found
1012 Server: Apache
1013 Content-Length: 709
1014 Content-Type: text/html; charset=utf-8
1015 Date: Thu, 21 Jan 2010 00:09:40 GMT
1016 Location:
1017 http://a.example.org/w/index.php?title=Clock&oldid=1493688
1018 Vary: negotiate, accept-datetime
1019 Link: ; rel="original",
1020
1021 ; rel="timemap",
1022
1023 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
1024
1025 ; rel="successor-version memento"
1026 ; datetime="Tue, 30 Sep 2003 14:28:00 GMT",
1027
1028 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT"
1029 Connection: close
1031 Figure 10: A TimeGate's response to a request for a Memento with a
1032 datetime earlier than that of the first Memento
1034 3.2.2.2. Accept-Datetime with Interval Indicator Provided
1036 In case, in Step 3, the datetime provided in the user agent's
1037 "Accept-Datetime" header can be parsed, and contains an interval
1038 indicator, the response depends on whether the server is or is not
1039 aware of Mementos with datetimes within the expressed interval. If
1040 the server is aware of such Mementos, the server's response MUST be
1041 as in Section 3.2.2.1.
1043 However, if the responding server is not aware of any Mementos with
1044 "Memento-Datetime" values within the expressed interval, the server's
1045 response MUST have a "406 Not Acceptable" HTTP status code. The use
1046 of the "Vary" header MUST be as described in Section 3.2.2.1. The
1047 use of the "Link" header MUST be as described in Section 2.2.
1048 Specifically, the use of links with a "memento" Relation Type MUST
1049 follow the rules for the case where no Memento is selected by the
1050 responding server (Section 2.2.1.4) and it is RECOMMENDED that the
1051 server provides "memento" links pointing at Mementos that have
1052 "Memento-Datetime" values in the temporal vicinity of the interval
1053 expressed by the client. The response MUST NOT contain a "Memento-
1054 Datetime" header.
1056 As a result, a user agent that allows for the provision of an
1057 interval indicator in requests SHOULD anticipate possible "406 Not
1058 Acceptable" responses and provide the capability for their
1059 resolution. For example, the client can leverage the "memento" links
1060 returned by the responding server, can extend its preferred interval,
1061 or can remove it from further requests.
1063 Figure 11 shows a user agent using an "Accept-Datetime" header
1064 conveying an interval of interest starting 5 hours before and ending
1065 6 hours after Tue, 11 Sep 2001 20:35:00 GMT. Figure 12 shows the
1066 "406 Not Acceptable" response from the TimeGate that has links to the
1067 first and last Memento, as well to two Mementos, one on either
1068 temporal side of the user agent's preferred interval.
1070 GET /timegate/http://a.example.org HTTP/1.1
1071 Host: arxiv.example.net
1072 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT; -PT5H;+PT6H
1073 Connection: close
1075 Figure 11: User agent expresses interval of interest in Accept-
1076 Datetime header
1078 HTTP/1.1 406 Not Acceptable
1079 Date: Thu, 21 Jan 2010 00:06:50 GMT
1080 Server: Apache
1081 Vary: negotiate, accept-datetime
1082 Link: ; rel="original",
1083
1084 ; rel="timemap";type="application/link-format",
1085
1086 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1087
1088 ; rel="memento last"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1089
1090 ; rel="memento"; datetime="Mon, 10 Sep 2001 08:22:00 GMT",
1091
1092 ; rel="memento"; datetime="Wed, 12 Sep 2001 03:41:00 GMT"
1093 Content-Length: 1732
1094 Connection: close
1095 Content-Type: text/plain; charset=UTF-8
1097 Figure 12: A TimeGate's response indicating it has no Mementos within
1098 the interval of interest
1100 3.2.2.3. Multiple Matching Mementos
1102 Because the finest datetime granularity expressible using the RFC
1103 1123 [RFC1123] format used in HTTP is seconds level, cases may occur
1104 in which a TimeGate server is aware of multiple Mementos that meet
1105 the user agent's datetime preference. This may occur in Content
1106 Management Systems with very high update rates. The response in this
1107 case MUST be handled as in Section 3.2.2.1, with the selection of one
1108 of the matching Mementos.
1110 As an example, Figure 13 shows a hypothetical response from a
1111 TimeGate on a MediaWiki server to a request for a Memento for the
1112 Original Resource http://a.example.org/w/Clock for which two Mementos
1113 exist for the user agent's preferred datetime.
1115 HTTP/1.1 302 Found
1116 Server: Apache
1117 Content-Length: 705
1118 Content-Type: text/html; charset=utf-8
1119 Date: Thu, 21 Jan 2010 00:09:40 GMT
1120 Vary: negotiate, accept-datetime
1121 Location:
1122 http://a.example.org/w/index.php?title=Clock&oldid=322586071
1123 Link: ; rel="original",
1124
1125 ; rel="timemap";type="application/link-format",
1126
1127 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
1128
1129 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT",
1130
1131 ; rel="memento"; datetime="Sun, 31 May 2009 15:43:00 GMT",
1132
1133 ; rel="memento successor-version"
1134 ; datetime="Sun, 31 May 2009 15:43:00 GMT"
1135
1136 ; rel="memento predecessor-version"
1137 ; datetime="Sun, 31 May 2009 15:41:24 GMT"
1138 Connection: close
1140 Figure 13: A TimeGate's response to a request that has multiple
1141 Mementos with a matching datetime
1143 3.2.2.4. TimeGate Redirects to another TimeGate
1145 Cases may exist in which a TimeGate's response entails a redirects to
1146 another TimeGate, for example, because the responding TimeGate is
1147 aware that the other TimeGate is able to more precisely respond to a
1148 client's datetime preference. In such cases, the TimeGate's response
1149 MUST have a "302 Found" HTTP status code, and the "Location" header
1150 MUST be used to convey the URI of the other TimeGate. The "Vary"
1151 header MUST be provided and it MUST include the "negotiate" and
1152 "accept-datetime" values to indicate that, although datetime
1153 negotiation has not taken place, the responding TimeGate is capable
1154 of it. The "Link" header MUST be provided and contain links with
1155 Relation Types subject to the considerations described in
1156 Section 2.2. Specifically, the use of links with a "memento"
1157 Relation Type MUST follow the rules for the case where no Memento is
1158 selected by the responding server (Section 2.2.1.4). Also, a link
1159 with a "timegate" Relation Type MUST be provided that has as Target
1160 IRI the URI of the TimeGate to which the current TimeGate is
1161 redirecting the client. The response MUST NOT contain a "Memento-
1162 Datetime" header.
1164 A response in which the client is redirected by TimeGate
1165 http://arxiv.example.net/timegate/http://a.example.org to TimeGate
1166 http://otherarxiv.example.com/timegate/http://a.example.org for the
1167 Original Resource http://a.example.org is illustrated in Figure 14.
1168 Note the URI of the latter TimeGate in both the "Location" and "Link"
1169 header, in the latter case as the Target IRI of a "timegate" link.
1170 Note also that the "memento" and "timemap" links in this response
1171 reflect the knowledge of the responding TimeGate, not of the remote
1172 TimeGate.
1174 HTTP/1.1 302 Found
1175 Date: Thu, 21 Jan 2010 00:06:50 GMT
1176 Server: Apache
1177 Vary: negotiate, accept-datetime
1178 Location:
1179 http://otherarxiv.example.com/timegate/http://a.example.org
1180 Link: ; rel="original",
1181
1182 ; rel="timemap"; type="application/link-format",
1183
1184 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1185
1186 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1187
1188 ; rel="timegate"
1189 Content-Length: 0
1190 Content-Type: text/plain; charset=UTF-8
1191 Connection: close
1193 Figure 14: TimeGate redirects to another TimeGate
1195 3.2.2.5. Accept-Datetime and other Accept Headers Provided
1197 When interacting with a TimeGate, the regular content negotiation
1198 dimensions (media type, character encoding, language, and
1199 compression) remain available. It is the TimeGate server's
1200 responsibility to honor (or not) such content negotiation, and in
1201 doing so it MUST always first select a Memento that meets the user
1202 agent's datetime preference, and then consider honoring regular
1203 content negotiation for it. As a result of this approach, the
1204 returned Memento will not necessarily meet the user agent's regular
1205 content negotiation preferences. Therefore, it is RECOMMENDED that
1206 the server provides HTTP Links with a "memento" Relation Type
1207 pointing at Mementos that do meet the user agent's regular content
1208 negotiation requests and that have a value for the "Memento-Datetime"
1209 header in the temporal vicinity of the user agent's preferred
1210 datetime value.
1212 3.2.2.6. Accept-Datetime Unparseable
1214 In case, in Step 3, a user agent conveys a value for the "Accept-
1215 Datetime" request header that does not conform to the accept-dt-value
1216 construction rule of the BNF in Figure 1, the TimeGate server's
1217 response MUST have a "400 Bad Request" HTTP status code. With all
1218 other respects, responses in this case MUST be handled as described
1219 in Section 3.2.2.2.
1221 3.2.2.7. Accept-Datetime Not Provided
1223 In case, in Step 3, a user agent issues a request to a TimeGate and
1224 fails to include an "Accept-Datetime" request header, the response
1225 MUST be handled as in Section 3.2.2.1, with a selection of the most
1226 recent Memento known to the responding server.
1228 3.2.2.8. TimeGate Does Not Exist
1230 Cases may occur in which a user agent issues a request against a
1231 TimeGate that does not exist. This may, for example, occur when a
1232 user agent uses internal knowledge to construct the URI of an
1233 assumed, yet non-existent TimeGate. In these cases, the response
1234 from the target server MUST have a "404 Not Found" HTTP status code,
1235 and SHOULD include a "Vary" header that includes the "negotiate" and
1236 "accept-datetime" values as an indication that, generally, the server
1237 is capable of datetime negotiation. The response MUST NOT include a
1238 "Link" header with any of the Relation Types introduced in
1239 Section 2.2.1, and it MUST NOT contain a "Memento-Datetime" header.
1241 3.2.2.9. HTTP Methods other than HEAD/GET
1243 In the above, the safe HTTP methods GET and HEAD are described for
1244 TimeGates. TimeGates MAY support the safe HTTP methods OPTIONS and
1245 TRACE in the way described in RFC 2616 [RFC2616]. Unsafe HTTP
1246 methods (i.e. PUT, POST, DELETE) MUST NOT be supported by a
1247 TimeGate. Such requests MUST yield a response with a "405 Method Not
1248 Allowed" HTTP status code, and MUST include an "Allow" header to
1249 convey that only the HEAD and GET (and OPTIONALLY the OPTIONS and
1250 TRACE) methods are supported. In addition, the response MUST have a
1251 "Vary" header that includes the "negotiate" and "accept-datetime"
1252 values to indicate the TimeGate supports datetime negotiation.
1253 Figure 15 shows such a response.
1255 HTTP/1.1 405 Method Not Allowed
1256 Date: Thu, 21 Jan 2010 00:02:12 GMT
1257 Server: Apache
1258 Vary: negotiate, accept-datetime
1259 Allow: HEAD, GET
1260 Content-Length: 255
1261 Connection: close
1262 Content-Type: text/html; charset=iso-8909-1
1264 Figure 15: Response from a TimeGate accessed with HTTP method other
1265 than HEAD/GET
1267 3.2.3. Recognizing a TimeGate
1269 When a user agent issues a HTTP HEAD/GET request against an assumed
1270 TimeGate URI (e.g. URI is Target IRI of a link with a "timegate"
1271 Relation Type, URI is discovered as described in Section 4.1, etc.),
1272 it SHOULD NOT conclude that the targeted resource effectively is a
1273 TimeGate and hence will behave as described in Section 3.2.2.
1275 A user agent MUST decide it has reached a TimeGate if the response to
1276 a HTTP HEAD/GET request against the resource's URI contains a "Vary"
1277 header that includes the "negotiate" and "accept-datetime" values.
1278 If the response does not, the user agent MUST decide it has not
1279 reached a TimeGate and proceed as follows:
1281 o If the response contains a redirection, the user agent SHOULD
1282 follow it. Note that a chain of redirections is possible, e.g.
1283 URI-R -> URI-1 -> URI-2 -> ... -> URI-G
1285 o If the response does not contain a redirection, or if the
1286 redirection (chain) does not lead to a TimeGate, the user agent
1287 SHOULD attempt to determine an appropriate TimeGate for the
1288 Original Resource, either automatically or interactively supported
1289 by the user. The discovery mechanisms described in Section 4 can
1290 support the user agent with this regard.
1292 Resources that are not TimeGates (i.e. do not behave as described in
1293 Section 3.2.2) MUST NOT use a "Vary" header that includes the
1294 "accept-datetime" value.
1296 In certain cases, it is possible to implement Memento support in such
1297 a manner that an Original Resource coincides with its TimeGate, i.e.
1299 URI-R and URI-G are the same. This implementation pattern is NOT
1300 RECOMMENDED. It can make determining whether a resource is a
1301 TimeGate more challenging, and, more importantly, it may cause
1302 problems with caches. Observed caching problems, which
1303 implementations must take care to avoid, include:
1305 o Cache invalidation when switching between a request for the
1306 Original Resource and a negotiation with the TimeGate.
1308 o Delivering a (cached) Original Resource response when a TimeGate
1309 response was requested, and vice versa.
1311 3.3. Interactions with a Memento
1313 This section details HTTP GET/HEAD requests targeted at a Memento
1314 (URI-M).
1316 3.3.1. Step 5: User Agent Requests a Memento
1318 In Step 5, the user agent issues a HTTP GET request against the URI
1319 of a Memento. The user agent MAY include an "Accept-Datetime" header
1320 in this request, but the existence or absence of this header MUST NOT
1321 affect the server's response. The URI of the Memento may have
1322 resulted from a response in Step 4, or the user agent may simply have
1323 happened upon it. Such a request is illustrated in Figure 16.
1325 GET /web/20010911203610/http://a.example.org HTTP/1.1
1326 Host: arxiv.example.net
1327 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1328 Connection: close
1330 Figure 16: User agent requests Memento
1332 3.3.2. Step 6: Server Responds to a Request for a Memento
1334 This section describes possible responses to a request for a Memento.
1335 Section 3.3.2.1 discusses the common scenario, whereas
1336 Section 3.3.2.2 and Section 3.3.2.3 detail special cases whereby
1337 Mementos are archived copies of HTTP responses with 3xx, 4xx and 5xx
1338 status codes.
1340 3.3.2.1. Common Scenario
1342 If the Memento requested by the user agent in Step 5 exists, and is
1343 not a special Memento as described in Section 3.3.2.2 and
1344 Section 3.3.2.2, the server's response MUST have a "200 OK" HTTP
1345 status code or, where appropriate "206 Partial Content", and it MUST
1346 include a "Memento-Datetime" header with a value equal to the
1347 archival datetime of the Memento, that is, the datetime of the state
1348 of the Original Resource that is encapsulated in the Memento. The
1349 "Link" header MUST be provided and contain links subject to the
1350 considerations described in Section 2.2. The Target IRI and, when
1351 applicable, the datetime values in the "Link" header associated with
1352 the "memento" Relation Type SHOULD be the same as conveyed in Step 4,
1353 in case the TimeGate and the selected Memento reside on the same
1354 server. However, they MAY be different in case the TimeGate and the
1355 selected Memento reside on different servers.
1357 Figure 17 illustrates the server's response to the request issued
1358 against a Memento in Step 5 (Figure 16).
1360 HTTP/1.1 200 OK
1361 Date: Thu, 21 Jan 2010 00:09:40 GMT
1362 Server: Apache-Coyote/1.1
1363 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1364 Link: ; rel="original",
1365
1366 ; rel="timemap"; type="application/link-format",
1367
1368 ; rel="timegate",
1369
1370 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1371
1372 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1373
1374 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
1375
1376 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
1377
1378 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
1379 Content-Length: 23364
1380 Content-Type: text/html;charset=utf-8
1381 Connection: close
1383 Figure 17: Server of Memento responds
1385 The server's response MUST include the "Memento-Datetime" header
1386 regardless whether the user agent's request contained an "Accept-
1387 Datetime" header or not. This is the way by which resources make
1388 explicit that they are Mementos. Due to the sparseness of Mementos
1389 in most archives, the value of the "Memento-Datetime" header returned
1390 by a server may differ (significantly) from the value conveyed by the
1391 user agent in "Accept-Datetime".
1393 Although a Memento encapsulates a prior state of an Original
1394 Resource, the entity-body returned in response to an HTTP GET request
1395 issued against a Memento may very well not be byte-to-byte the same
1396 as an entity-body that was previously returned by that Original
1397 Resource. Various reasons exist why there are significant chances
1398 these would be different yet do convey substantially the same
1399 information. These include format migrations as part of a digital
1400 preservation strategy, URI-rewriting as applied by some Web archives,
1401 and the addition of banners as a means to brand Web archives.
1403 3.3.2.2. Memento of a 3XX Response
1405 Cases exist in which HTTP responses with 3XX status codes are
1406 archived. For example, crawl-based web archives commonly archive
1407 responses with HTTP status codes "301 Moved Permanently" and "302
1408 Found" whereas Linked Data archives hold on to "303 See Other"
1409 responses. But also other 3XX responses may be archived.
1411 If the Memento requested by the user agent is an archived version of
1412 an HTTP response with a 3XX status code, the server's response MUST
1413 have the same 3XX HTTP status code, and it MUST include a "Memento-
1414 Datetime" header with a value equal to the archival datetime of the
1415 original 3XX response. All other considerations, e.g. pertaining to
1416 the use of "Link" header, expressed in Section 3.3.2.1 apply.
1418 The client's handling of a HTTP response with a 3XX status code is
1419 not affected by the presence of a "Memento-Datetime" header. The
1420 client SHOULD behave in the same manner as it does with HTTP
1421 responses with a 3XX status code that do not have a "Memento-
1422 Datetime" header. For example:
1424 o For a response from a Memento that has a 3XX status code and
1425 contains a "Location" header, the client SHOULD continue on to the
1426 URI specified in that header.
1428 o For a response from a Memento that has a "300 Multiple Choices"
1429 status code, the response body SHOULD be presented to the user to
1430 allow selection of a URI.
1432 However, the client MUST be aware that the URI that was selected from
1433 the HTTP response with a 3XX status code might not be that of a
1434 Memento but rather of an Original Resource. In that case it SHOULD
1435 proceed by looking for a Memento of the selected Original Resource.
1437 For example, on April 11 2008 Figure 18 is the response to an HTTP
1438 GET request for http://a.example.org. This response is archived as a
1439 Memento of http://a.example.org, and this Memento's URI is
1440 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1441 The response to a HTTP HEAD/GET on this Memento is shown in
1442 Figure 19. In essence, it is a replay of the original response with
1443 "Memento-Datetime" and "Link" headers added, to allow a client to
1444 understand the response is a Memento. In Figure 19, the value of the
1445 "Location" header is the same as in the original response; it
1446 identifies an Original Resource. The client proceeds with finding a
1447 Memento for this Original Resource. Web archives sometimes overwrite
1448 the value that was originally provided in the "Location" header in
1449 order to point at a Memento they hold of the resource to which the
1450 redirect originally led. This is shown in Figure 20. In this case,
1451 the client may decide it found an appropriate Memento.
1453 HTTP/1.1 301 Moved Permanently
1454 Date: Fri, 11 Apr 2008 00:06:50 GMT
1455 Server: Apache
1456 Location: http://b.example.org
1457 Content-Length: 0
1458 Content-Type: text/plain; charset=UTF-8
1459 Connection: close
1461 Figure 18: Response to the User Agent Request is a Redirect
1463 HTTP/1.1 301 Moved Permanently
1464 Date: Thu, 21 Jan 2010 00:09:40 GMT
1465 Server: Apache-Coyote/1.1
1466 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1467 Location: http://b.example.org
1468 Link: ; rel="original",
1469
1470 ; rel="timemap"; type="application/link-format",
1471
1472 ; rel="timegate",
1473
1474 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1475
1476 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1477
1478 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1479
1480 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1481
1482 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1483 Content-Length: 0
1484 Content-Type: text/plain; charset=UTF-8
1485 Connection: close
1487 Figure 19: Response to a User Agent Request for a Memento of a
1488 Redirect; leads to an Original Resource
1490 HTTP/1.1 301 Moved Permanently
1491 Date: Thu, 21 Jan 2010 00:09:40 GMT
1492 Server: Apache-Coyote/1.1
1493 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1494 Location:
1495 http://arxiv.example.net/web/20080411000655/http://b.example.org
1496 Link: ; rel="original",
1497
1498 ; rel="timemap"; type="application/link-format",
1499
1500 ; rel="timegate",
1501
1502 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1503
1504 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1505
1506 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1507
1508 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1509
1510 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1511 Content-Length: 0
1512 Content-Type: text/plain; charset=UTF-8
1513 Connection: close
1515 Figure 20: Response to a User Agent Request for a Memento of a
1516 Redirect; leads to a Memento
1518 3.3.2.3. Memento of Responses with Other HTTP Status Codes
1520 Cases exist in which responses with 4xx and 5xx HTTP status codes are
1521 archived. If the Memento requested by the user agent is an archived
1522 version of such an HTTP response, the server's response MUST have the
1523 same 4xx or 5xx HTTP status code, and it MUST include a "Memento-
1524 Datetime" header with a value equal to the archival datetime of the
1525 original response. All other considerations, e.g. pertaining to the
1526 use of "Link" header, expressed in Section 3.3.2.1 apply.
1528 For example, on April 11 2008, Figure 21 is the 404 response to an
1529 HTTP GET request for http://a.example.org. This response is archived
1530 as a Memento of http://a.example.org, and this Memento's URI is
1531 http://arxiv.example.net/web/20080411000650/http://a.example.org.
1532 The response to a HTTP HEAD/GET on this Memento is shown in
1533 Figure 22. It is a replay of the original response with "Memento-
1534 Datetime" and "Link" headers added, to allow a client to understand
1535 the response is a Memento.
1537 HTTP/1.1 404 Not Found
1538 Date: Fri, 11 Apr 2008 00:06:50 GMT
1539 Server: Apache
1540 Content-Length: 0
1541 Content-Type: text/plain; charset=UTF-8
1542 Connection: close
1544 Figure 21: Response to the User Agent Request is a 404
1546 HTTP/1.1 404 Not Found
1547 Date: Thu, 21 Jan 2010 00:09:40 GMT
1548 Server: Apache-Coyote/1.1
1549 Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
1550 Link: ; rel="original",
1551
1552 ; rel="timemap"; type="application/link-format",
1553
1554 ; rel="timegate",
1555
1556 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1557
1558 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1559
1560 ; rel="memento"; datetime="Fri, 11 Apr 2008 00:06:50 GMT",
1561
1562 ; rel="prev memento"; datetime="Thu, 10 Apr 2008 20:30:51 GMT",
1563
1564 ; rel="next memento"; datetime="Sat, 12 Apr 2008 20:47:33 GMT"
1565 Content-Length: 0
1566 Content-Type: text/plain; charset=UTF-8
1567 Connection: close
1569 Figure 22: Response to a User Agent Request for a Memento of a 404
1570 Response
1572 3.3.2.4. Mementos Without a TimeGate
1574 Cases may occur in which a server that hosts Mementos does not expose
1575 a TimeGate for those Mementos. This can, for example, be the case if
1576 the server's Mementos result from taking a snapshot of the state of a
1577 set of Original Resources from another server at the time this other
1578 server is being retired. As a result, only a single Memento per
1579 Original Resource is hosted, making the introduction of a TimeGate
1580 unnecessary. But it may also be the case for servers that hosts
1581 multiple Mementos for an Original Resource but consider exposing
1582 TimeGates too expensive.
1584 In cases of Mementos without associated TimeGates, responses to a
1585 request for a Memento by a user agent MUST be as described in
1586 Section 3.3.2 with the exception that it will not contain a HTTP
1587 "Link" with a "timegate" Relation Type pointing at a TimeGate exposed
1588 by the responding server. It MAY still contain such a Link pointing
1589 at a TimeGate exposed elsewhere. Depending on whether one or more
1590 Mementos are hosted for an Original Resource, the response may or may
1591 not have a HTTP Link with a "timemap" Relation Type. However, the
1592 response MUST still contain a "Memento-Datetime" response header with
1593 a value that corresponds to archival datetime of the Memento.
1595 Figure 23 illustrates the server's response to the request issued
1596 against a Memento in Step 5 (Figure 16) for the case that Memento has
1597 no associated TimeGate. In this example, it is also assumed there is
1598 only one Memento for the Original Resource, and hence the Links with
1599 Relation Types "memento", "first", "last" all point at the same -
1600 responding - Memento.
1602 HTTP/1.1 200 OK
1603 Date: Thu, 21 Jan 2010 00:09:40 GMT
1604 Server: Apache-Coyote/1.1
1605 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1606 Link: ; rel="original",
1607
1608 ; rel="first last memento"
1609 ; datetime="Tue, 15 Sep 2000 11:28:26 GMT"
1610 Content-Length: 23364
1611 Content-Type: text/html;charset=utf-8
1612 Connection: close
1614 Figure 23: Server of Memento without TimeGate responds
1616 Note that a server issuing a response similar to that of Figure 23
1617 does not imply that there is no server whatsoever that exposes a
1618 TimeGate; it merely means that the responding server neither provides
1619 nor is aware of the location of a TimeGate.
1621 3.3.2.5. Memento Does not Exist
1623 Cases may occur in which a TimeGate's response (Step 4) points at a
1624 Memento that actually does not exist, resulting in a user agent's
1625 request (Step 5) for a non-existent Memento. In this case, the
1626 server's response MUST have the expected "404 Not Found" HTTP Status
1627 Code and it MUST NOT contain a "Memento-Datetime" header. Note that
1628 the absence of a Memento in an archive is distinct from the case of
1629 an archived response with a "404 Not Found" HTTP status code as is
1630 described in Section 3.3.2.3
1632 3.3.3. Recognizing a Memento
1634 When following the redirection provided by a confirmed TimeGate (see
1635 Section 3.2.3), a user agent SHOULD NOT assume that the targeted
1636 resource effectively is a Memento and hence will behave as described
1637 in Section 3.3.2.
1639 A user agent MUST decide it has reached a Memento if the response to
1640 a HTTP HEAD/GET request against the resource's URI contains a
1641 "Memento-Datetime" header with a legitimate value. If the response
1642 does not, the following applies:
1644 o If the response contains a redirection, the user agent SHOULD
1645 follow it. Even a chain of redirections is possible, e.g. URI-G
1646 -> URI-X -> URI-Y -> ... -> URI-M.
1648 o If the response by a confirmed TimeGate does not contain a
1649 redirection, or if the redirection (chain) that started at a
1650 confirmed TimeGate does not lead to a resource that provides a
1651 "Memento-Datetime" header, the user agent MAY still conclude that
1652 it has likely arrived at a Memento. That is because cases exist
1653 in which Web archives and CMS are made compliant with the Memento
1654 framework "by proxy". In these cases TimeGates will redirect to
1655 Mementos in such systems, but the responses from these Mementos
1656 will not (yet) include a "Memento-Datetime" header.
1658 3.4. Interactions with a TimeMap
1660 A TimeMap is introduced to support retrieving a comprehensive list of
1661 all Mementos for a specific Original Resource, known to a responding
1662 server. The entity-body of a response to an HTTP GET request issued
1663 against a TimeMap's URI:
1665 o MUST list the URI of the Original Resource that the response lists
1666 Mementos for;
1668 o MUST list the URI and datetime of each Memento for the Original
1669 Resource known to the responding server;
1671 o MUST list the URI of one or more TimeGates for the Original
1672 Resource except when no TimeGate exists (see Section 3.3.2.4);
1674 o SHOULD, for self-containment, list the URI of the TimeMap itself;
1676 o MUST unambiguously type listed resources as being Original
1677 Resource, TimeGate, Memento, or TimeMap.
1679 The entity-body of a response from a TimeMap MAY be serialized in
1680 various ways, but the link-value format serialization MUST be
1681 supported. In this serialization, the entity-body MUST be formatted
1682 in the same way as the value of a HTTP "Link" header, and hence MUST
1683 comply to the "link-value" construction rule of "Section 5. The Link
1684 Header Field" of RFC5988 [RFC5988], and the media type of the entity-
1685 body MUST be "application/link-format" as introduced in I-D.ietf-
1686 core-link-format [I-D.ietf-core-link-format]. All links conveyed in
1687 this serialization MUST be interpreted as having the URI of the
1688 Original Resource as their Context IRI. The URI of the Original
1689 Resource is provided in the entity-body as the Target IRI of the link
1690 with an "original" Relation Type.
1692 3.4.1. User Agent Requests a TimeMap
1694 In order to retrieve the link-value serialization of a TimeMap, a
1695 user agent SHOULD use an "Accept" request header with a value set to
1696 "application/link-format". This is shown in Figure 24.
1698 GET /timemap/http://a.example.org HTTP/1.1
1699 Host: arxiv.example.net
1700 Accept: application/link-format;q=1.0
1701 Connection: close
1703 Figure 24: Request for a TimeMap
1705 3.4.2. Server Responds to a Request for a TimeMap
1707 If the TimeMap requested by the user agent exists, the server's
1708 response MUST have a "200 OK" HTTP status code (or "206 Partial
1709 Content", where appropriate). Note that a TimeMap is itself an
1710 Original Resource for which Mementos may exist. For example, a
1711 response from a TimeMap could provide a "timegate" Link to a TimeGate
1712 via which prior TimeMap versions are available. In this case, the
1713 use of the "Link" header is subject to all considerations described
1714 in Section 2.2, with the TimeMap acting as the Original Resource.
1716 However, in case a TimeMap wants to explicitly indicate in its
1717 response headers for which Original Resource it is a TimeMap, it MUST
1718 do so by including a HTTP "Link" header with the following
1719 characteristics:
1721 o The Context IRI for the HTTP Link is the URI of the Original
1722 Resource;
1724 o The Relation Type is "timemap";
1726 o The Target IRI for the HTTP Link is the URI of the TimeMap.
1728 Because the Context IRI of this HTTP Link is not the URI of the
1729 TimeMap, as per RFC5988 [RFC5988], the default Context IRI must be
1730 overwritten by using the "anchor" attribute with a value of the URI
1731 of the Original Resource.
1733 The response from the TimeMap to the request of Figure 24 is shown in
1734 Figure 25. The response header shows the TimeMap explicitly
1735 conveying the URI of the Original Resource for which it is a TimeMap;
1736 for practical reasons the entity-body in the example has been
1737 abbreviated. Notice also the use of the "license" and "embargo"
1738 attributes introduced in Section 2.2.1.4 on the "memento" links in
1739 the TimeMap.
1741 HTTP/1.1 200 OK
1742 Date: Thu, 21 Jan 2010 00:06:50 GMT
1743 Server: Apache
1744 Link:
1745 ; anchor="http://a.example.org"; rel="timemap"
1746 ; type="application/link-format"
1747 Content-Length: 4883
1748 Content-Type: application/link-format
1749 Connection: close
1751 ;rel="original",
1752
1753 ; rel="timemap";type="application/link-format",
1754
1755 ; rel="timegate",
1756
1757 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT"
1758 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1759
1760 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT"
1761 ; license="http://creativecommons.org/publicdomain/zero/1.0/"
1762 ; embargo="Tue, 19 Apr 2011 00:00:00 GMT",
1763
1764 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT"
1765 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1766
1767 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT"
1768 ; license="http://creativecommons.org/publicdomain/zero/1.0/",
1769 ...
1771 Figure 25: Response from a TimeMap
1773 4. The Memento Framework, Discovery Component
1775 Section 3 describes how TimeGates, Mementos, Original Resources, and
1776 TimeMaps can be discovered by following HTTP Links with Relation
1777 Types "timegate", "memento", "original", and "timemap", respectively.
1779 Naturally, some of these links can also be embedded into
1780 representations of resources that have a media type that allows
1781 embedding of typed links. For example, an Original Resource that has
1782 an HTML representation can include a "timegate" link by using HTML's
1783 LINK element, e.g. . The use of such embedded links is also subject to
1786 the considerations of Section 2.2.
1788 In this section additional approaches are introduced that support
1789 batch discovery of TimeGates and Mementos. The approaches leverage
1790 the Robots Exclusion Protocol.
1792 4.1. Discovering TimeGates Via Robots Exclusion Protocol
1794 The Robots Exclusion Protocol's robots.txt file [robotstxt.org] is
1795 commonly used by Web site owners to give instructions about their
1796 site to Web robots. It is used both to protect resources hosted by a
1797 server from crawling and to facilitate discovering them. This
1798 document introduces the "TimeGate" and "Archived" directives for
1799 robots.txt to provide a server-wide mechanism to support TimeGate
1800 discovery that SHOULD be used by:
1802 o Servers of Original Resources;
1804 o Servers that provide access to Mementos of Original Resources by
1805 exposing TimeGates.
1807 A robots.txt file MAY contain zero or more occurrences of the
1808 "TimeGate" directive, and each occurrence MUST be followed by one or
1809 more associated "Archived" directives. The meaning of the directives
1810 is as follows:
1812 o TimeGate: Conveys the base URL (that is URI scheme, host and path
1813 component) that is shared by all URIs of TimeGates of a set of
1814 Original Resources.
1816 o Archived: Indicates - by means of mandatory host and optional path
1817 parts of a URI - for which set of Original Resources actual
1818 TimeGates are available that have the base URL conveyed in the
1819 associated TimeGate directive.
1821 For example, consider a wiki at http://a.example.org/w/ that supports
1822 the Memento framework and exposes TimeGates to access the wiki's
1823 history pages at base URL
1824 http://a.example.org/w/index.php/Special:TimeGate/. An actual
1825 TimeGate for the wiki's http://a.example.org/w/My_Title page would
1826 then be at http://a.example.org/w/index.php/Special:TimeGate/http://
1827 a.example.org/w/My_Title. This wiki SHOULD make its TimeGates
1828 discoverable by using the directives shown in Figure 26 in its
1829 robots.txt file.
1831 TimeGate: http://a.example.org/w/index.php/Special:TimeGate/
1832 Archived: a.example.org/w/
1834 Figure 26: robots.txt for a wiki, host of Original Resources,
1835 TimeGates, and Mementos
1837 As another example, consider a server of Original Resources at
1838 http://a.example.org/ and http://www.a.example.org/ that is aware
1839 that its resources are regularly crawled by a Web archive that
1840 generally exposes TimeGates at base URL
1841 http://arxiv.example.net/timegate/ and hence has TimeGate
1842 http://arxiv.example.net/timegate/http://a.example.org/ to access
1843 Mementos for http://a.example.org/. This server SHOULD make the
1844 remote TimeGates discoverable by including the directives shown in
1845 Figure 27 in its robots.txt file:
1847 TimeGate: http://arxiv.example.net/timegate/
1848 Archived: a.example.org/
1849 Archived: www.a.example.org/
1851 Figure 27: robots.txt for a server of Original Resources aware of
1852 remote TimeGates
1854 And, consider a Web archive that crawls a wide range of Original
1855 Resources, and exposes TimeGates to access the resulting Mementos at
1856 base URL http://arxiv.example.net/timegate/. In order to make its
1857 TimeGates discoverable, this Web archive SHOULD include the
1858 directives shown in Figure 28 in its robots.txt file:
1860 TimeGate: http://arxiv.example.net/timegate/
1861 Archived: *
1863 Figure 28: robots.txt for a Web Archive that hosts Mementos for a
1864 wide range of Original Resources
1866 4.2. Discovering Mementos via Robots Exclusion Protocol
1868 Servers can support discovery of their Mementos by crawlers through
1869 the use of the Robots Exclusion Protocol, but SHOULD do so in a
1870 manner that conveys to crawlers and mirroring applications that the
1871 sticky Memento-Datetime behavior (see Section 2.1.1) MUST be
1872 respected. To that end, servers SHOULD use the "User-agent" and
1873 "Allow" directives of the Robots Exclusion Protocol in the following
1874 manner:
1876 o User-agent: Has "memento" as its value;
1878 o Allow: Lists the path that contains Mementos that can be crawled,
1879 and for which content can be mirrored subject to the sticky
1880 Memento-Datetime behavior.
1882 Figure 29 shows the robots.txt for a server that generally disallows
1883 crawling, yet allows agents that respect the sticky Memento-Datetime
1884 behavior to crawl Mementos in the /web/ path.
1886 User-agent: *
1887 Disallow: /
1888 User-agent: memento
1889 Allow: /web/
1891 Figure 29: Restricting crawling to agents that respect sticky
1892 Memento-Datetime behavior
1894 5. IANA Considerations
1896 This memo requires IANA to register the Accept-Datetime and Memento-
1897 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1898 IANA registry.
1900 This memo requires IANA to register the "Link" header Relation Types
1901 "original", "timegate", "timemap", and "memento" defined in
1902 Section 2.2.1 in the appropriate IANA registry.
1904 This memo requires IANA to register the "datetime", "license", and
1905 "embargo" attributes for "Link" headers with a "memento" Relation
1906 Type, as defined in Section 2.2.1.4 in the appropriate IANA registry.
1908 6. Security Considerations
1910 Provision of a "timegate" HTTP "Link" header in responses to requests
1911 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1912 response codes) is OPTIONAL. The inclusion of this Link when
1913 requesting authentication is at the server's discretion; cases may
1914 exist in which a server protects the current state of a resource, but
1915 supports open access to prior states and thus chooses to supply a
1916 "timegate" HTTP "Link" header. Conversely, the server may choose to
1917 not advertise the TimeGate URIs (e.g., they exist in an intranet
1918 archive) for unauthenticated requests.
1920 Authentication, encryption and other security related issues are
1921 otherwise orthogonal to Memento.
1923 7. Changelog
1925 v04 2011-12-20 HVDS MLN RS draft-vandesompel-memento-03
1927 o Added description of Mementos of HTTP responses with 3XX, 4XX and
1928 5XX status code.
1930 o Clarified that a TimeGate must not use the "Memento-Datetime"
1931 header.
1933 o Added wording to warn for possible cache problems with Memento
1934 implementations that choose to have an Original Resource and and
1935 its TimeGate coincide.
1937 v03 2011-05-11 HVDS MLN RS draft-vandesompel-memento-02
1939 o Added scenario in which a TimeGate redirects to another TimeGate.
1941 o Reorganized TimeGate section to better reflect the difference
1942 between requests with and without interval indicator.
1944 o Added recommendation to provide "memento" links to Mementos in the
1945 vicinity of the preferred interval provided by the client, in case
1946 of a 406 response.
1948 o Removed TimeMap Feed material from the Discovery section as a
1949 result of discussions regarding (lack of) scalability of the
1950 approach with representatives of the International Internet
1951 Preservation Consortium. An alternative approach to support batch
1952 discovery of Mementos will be specified.
1954 v02 2011-04-28 HVDS MLN RS draft-vandesompel-memento-01
1956 o Introduced wording and reference to indicate a Memento is a
1957 FixedResource.
1959 o Introduced "Sticky Memento-Datetime" notion and clarified wording
1960 about retaining "Memento-Datetime" headers and values when a
1961 Memento is mirrored at different URI.
1963 o Introduced section about handling both datetime and regular
1964 negotiation.
1966 o Introduced section about Mementos Without TimeGate.
1968 o Made various changes in the section Relation Type "memento",
1969 including addition of "license" and "embargo" attributes, and
1970 clarification of rules regarding the use of "memento" links.
1972 o Moved section about TimeMaps inside the Datetime Negotiation
1973 section, and updated it.
1975 o Restarted the Discovery section from scratch.
1977 v01 2010-11-11 HVDS MLN RS First public version
1978 draft-vandesompel-memento-00
1980 v00 2010-10-19 HVDS MLN RS Limited circulation version
1982 2010-07-22 HVDS MLN First internal version
1984 8. Acknowledgements
1986 The Memento effort is funded by the Library of Congress. Many thanks
1987 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1988 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers
1989 for early feedback. Many thanks to Samuel Adams, Scott Ainsworth,
1990 Lyudmilla Balakireva, Frank McCown, Harihar Shankar, Brad Tofel for
1991 early implementations.
1993 9. References
1995 9.1. Normative References
1997 [I-D.ietf-core-link-format]
1998 Shelby, Z., "CoRE Link Format",
1999 draft-ietf-core-link-format-09 (work in progress),
2000 November 2011.
2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2003 Requirement Levels", BCP 14, RFC 2119, March 1997.
2005 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2006 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2007 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2009 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
2010 RFC 4151, October 2005.
2012 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
2013 Syndication Format", RFC 4287, December 2005.
2015 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
2016 for Simple Version Navigation between Web Resources",
2017 RFC 5829, April 2010.
2019 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
2021 9.2. Informative References
2023 [Fitch] Fitch, "Web site archiving - an approach to recording
2024 every materially different response produced by a
2025 website", July 2003,
2026 .
2028 [I-D.masinter-dated-uri]
2029 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
2030 dated URIs", draft-masinter-dated-uri-08 (work in
2031 progress), January 2011.
2033 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2034 and Support", STD 3, RFC 1123, October 1989.
2036 [W3C.REC-aww-20041215]
2037 Jacobs and Walsh, "Architecture of the World Wide Web",
2038 December 2004, .
2040 [W3C.gen-ont-20090420]
2041 Berners-Lee, "Architecture of the World Wide Web",
2042 April 2009, .
2044 [robotstxt.org]
2045 "Robots Exclusion Protocol", August 2010,
2046 .
2048 Appendix A. Appendix B: A Sample, Successful Memento Request/Response
2049 cycle
2051 Step 1 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-R
2052 HEAD / HTTP/1.1
2053 Host: a.example.org
2054 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2055 Connection: close
2057 Step 2 : UA <-- HTTP 200; Link: URI-G ----------------------- URI-R
2059 HTTP/1.1 200 OK
2060 Date: Thu, 21 Jan 2010 00:02:12 GMT
2061 Server: Apache
2062 Link:
2063 ; rel="timegate"
2064 Content-Length: 255
2065 Connection: close
2066 Content-Type: text/html; charset=iso-8859-1
2068 Step 3 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-G
2070 GET /timegate/http://a.example.org
2071 HTTP/1.1
2072 Host: arxiv.example.net
2073 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2074 Connection: close
2076 Step 4 : UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
2077 URI-R, URI-T, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-G
2079 HTTP/1.1 302 Found
2080 Date: Thu, 21 Jan 2010 00:06:50 GMT
2081 Server: Apache
2082 Vary: negotiate, accept-datetime
2083 Location:
2084 http://arxiv.example.net/web/20010911203610/http://a.example.org
2085 Link: ; rel="original",
2086
2087 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
2088
2089 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
2090
2091 ; rel="timemap"; type="application/link-format",
2092
2093 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
2094
2095 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
2096
2097 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
2098 Content-Length: 0
2099 Content-Type: text/plain; charset=UTF-8
2100 Connection: close
2102 Step 5 : UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------> URI-Mj
2104 GET /web/20010911203610/http://a.example.org
2105 HTTP/1.1
2106 Host: arxiv.example.net
2107 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
2108 Connection: close
2110 Step 6 : UA <-- HTTP 200; Memento-Datetime: Tj; Link: URI-R,
2111 URI-T, URI-G, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-Mj
2113 HTTP/1.1 200 OK
2114 Date: Thu, 21 Jan 2010 00:09:40 GMT
2115 Server: Apache-Coyote/1.1
2116 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
2117 Link: ; rel="original",
2118
2119 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
2120
2121 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
2122
2123 ; rel="timemap"; type="application/link-format",
2124
2125 ; rel="timegate",
2126
2127 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
2128
2129 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
2130
2131 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
2132 Content-Length: 23364
2133 Content-Type: text/html;charset=utf-8
2134 Connection: close
2136 A successful flow with TimeGate and Mementos on the same server
2138 Authors' Addresses
2140 Herbert VandeSompel
2141 Los Alamos National Laboratory
2142 PO Box 1663
2143 Los Alamos, New Mexico 87545
2144 USA
2146 Phone: +1 505 667 1267
2147 Email: hvdsomp@gmail.com
2148 URI: http://public.lanl.gov/herbertv/
2150 Michael Nelson
2151 Old Dominion University
2152 Norfolk, Virginia 23529
2153 USA
2155 Phone: +1 757 683 6393
2156 Email: mln@cs.odu.edu
2157 URI: http://www.cs.odu.edu/~mln/
2159 Robert Sanderson
2160 Los Alamos National Laboratory
2161 PO Box 1663
2162 Los Alamos, New Mexico 87545
2163 USA
2165 Phone: +1 505 665 5804
2166 Email: azaroth42@gmail.com