idnits 2.17.1
draft-vandesompel-memento-00.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 is 1 instance of too long lines in the document, the longest one
being 25 characters in excess of 72.
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 12, 2010) is 4907 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-14) exists of
draft-ietf-core-link-format-01
** 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-07
Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force H. VandeSompel
3 Internet-Draft Los Alamos National Laboratory
4 Intended status: Informational M. Nelson
5 Expires: May 16, 2011 Old Dominion University
6 R. Sanderson
7 Los Alamos National Laboratory
8 November 12, 2010
10 HTTP framework for time-based access to resource states -- Memento
11 draft-vandesompel-memento-00
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 interlinking
23 resources with their archival/version resources. It also introduces
24 an approach to discover and serialize a list of resources known to a
25 server, each of which provides access to a representation of a prior
26 state of a same resource.
28 Status of this Memo
30 This Internet-Draft is submitted in full conformance with the 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 May 16, 2011.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
47 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
48 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
49 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 6
50 2. The Memento Framework, Datetime Negotiation component:
51 HTTP headers, HTTP Link Relation Types . . . . . . . . . . . . 7
52 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 7
53 2.1.1. Accept-Datetime, Memento-Datetime . . . . . . . . . . 7
54 2.1.1.1. Values for Accept-Datetime . . . . . . . . . . . . 8
55 2.1.1.2. Values for Memento-Datetime . . . . . . . . . . . 9
56 2.1.2. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 9
57 2.1.3. Location . . . . . . . . . . . . . . . . . . . . . . . 10
58 2.1.4. Link . . . . . . . . . . . . . . . . . . . . . . . . . 10
59 2.2. Link Header Relation Types . . . . . . . . . . . . . . . . 10
60 2.2.1. Memento Framework Relation Types . . . . . . . . . . . 10
61 2.2.1.1. Relation Type "original" . . . . . . . . . . . . . 11
62 2.2.1.2. Relation Type "timegate" . . . . . . . . . . . . . 11
63 2.2.1.3. Relation Type "timemap" . . . . . . . . . . . . . 12
64 2.2.1.4. Relation Type "memento" . . . . . . . . . . . . . 12
65 2.2.2. Other Relation Types . . . . . . . . . . . . . . . . . 13
66 3. The Memento Framework, Datetime Negotiation component:
67 HTTP Interactions . . . . . . . . . . . . . . . . . . . . . . 14
68 3.1. Interactions with an Original Resource . . . . . . . . . . 16
69 3.1.1. Step 1: User Agent Requests an Original Resource . . . 16
70 3.1.2. Step 2: Server Responds to a Request for an
71 Original Resource . . . . . . . . . . . . . . . . . . 16
72 3.1.2.1. Original Resource is an Appropriate Memento . . . 17
73 3.1.2.2. Server Exists and Original Resource Used to
74 Exist . . . . . . . . . . . . . . . . . . . . . . 19
75 3.1.2.3. Missing or Inadequate "timegate" Link in
76 Original Server's Response . . . . . . . . . . . . 19
77 3.2. Interactions with a TimeGate . . . . . . . . . . . . . . . 20
78 3.2.1. Step 3: User Agent Negotiates with a TimeGate . . . . 20
79 3.2.2. Step 4: Server Responds to Negotiation with
80 TimeGate . . . . . . . . . . . . . . . . . . . . . . . 20
81 3.2.2.1. Successful Scenario . . . . . . . . . . . . . . . 20
82 3.2.2.2. Datetime Out of the Server's Range . . . . . . . . 21
83 3.2.2.3. Accept-Datetime Not Provided . . . . . . . . . . . 22
84 3.2.2.4. Multiple Matching Mementos . . . . . . . . . . . . 22
85 3.2.2.5. Datetime Out of the User Agent's Range . . . . . . 23
86 3.2.2.6. Accept-Datetime Unparseable . . . . . . . . . . . 24
87 3.2.2.7. TimeGate Does Not Exist . . . . . . . . . . . . . 24
88 3.2.2.8. HTTP Methods other than HEAD/GET . . . . . . . . . 25
89 3.2.3. Recognizing a TimeGate . . . . . . . . . . . . . . . . 25
90 3.3. Interactions with a Memento . . . . . . . . . . . . . . . 26
91 3.3.1. Step 5: User Agent Requests a Memento . . . . . . . . 26
92 3.3.2. Step 6: Server Responds to a Request for a Memento . . 26
93 3.3.2.1. Memento Does not Exist . . . . . . . . . . . . . . 27
94 3.3.3. Recognizing a Memento . . . . . . . . . . . . . . . . 28
95 4. The Memento Framework, Discovery Component . . . . . . . . . . 28
96 4.1. TimeMaps . . . . . . . . . . . . . . . . . . . . . . . . . 28
97 4.2. Discovery of TimeMaps, TimeGates . . . . . . . . . . . . . 30
98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
100 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31
101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
104 9.2. Informative References . . . . . . . . . . . . . . . . . . 32
105 Appendix A. Appendix B: A Sample, Successful Memento
106 Request/Response cycle . . . . . . . . . . . . . . . 32
107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
108 Intellectual Property and Copyright Statements . . . . . . . . . . 36
110 1. Introduction
112 1.1. Terminology
114 This specification uses the terms "resource", "request", "response",
115 "entity", "entity-body", "entity-header", "content negotiation",
116 "client", "user agent", "server" as described in RFC 2616 [RFC2616],
117 and it uses the terms "representation" and "resource state" as
118 described in W3C.REC-aww-20041215 [W3C.REC-aww-20041215].
120 In addition, the following terms specific to the Memento framework
121 are introduced:
123 o Original Resource: An Original Resource is a resource that exists
124 or used to exist, and for which access to one of its prior states
125 is desired.
127 o Memento: A Memento for an Original Resource is a resource that
128 encapsulates a prior state of the Original Resource. A Memento
129 for an Original Resource as it existed at time Tj is a resource
130 that encapsulates the state that the Original Resource had at time
131 Tj.
133 o TimeGate: A TimeGate for an Original Resource is a resource that
134 supports negotiation to allow selective, datetime-based, access to
135 prior states of the Original Resource.
137 o TimeMap: A TimeMap for an Original Resource is a resource from
138 which a list of URIs of Mementos of the Original Resource is
139 available.
141 1.2. Purpose
143 The state of an Original Resource may change over time.
144 Dereferencing its URI at any specific moment in time during its
145 existence yields a representation of its then current state.
146 Dereferencing its URI at any time past its existence no longer yields
147 a meaningful representation, if any. Still, in both cases, resources
148 may exist that encapsulate prior states of the Original Resource.
149 Each such resource, named a Memento, has its own URI that, when
150 dereferenced, returns a representation of a prior state of the
151 Original Resource. Mementos may, for example, exist in Web archives,
152 Content Management Systems, or Revision Control Systems.
154 Examples are:
156 Mementos for Original Resource http://www.ietf.org/ :
158 o http://web.archive.org/web/19970107171109/http://www.ietf.org/
160 o http://webarchive.nationalarchives.gov.uk/20080906200044/http://
161 www.ietf.org/
163 Mementos for Original Resource
164 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol :
166 o http://en.wikipedia.org/w/
167 index.php?title=Hypertext_Transfer_Protocol&oldid=366806574
169 o http://en.wikipedia.org/w/
170 index.php?title=Hypertext_Transfer_Protocol&oldid=33912
172 o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/
173 wiki/Hypertext_Transfer_Protocol
175 Mementos for Original Resource http://www.w3.org/TR/webarch/ :
177 o http://www.w3.org/TR/2004/PR-webarch-20041105/
179 o http://www.w3.org/TR/2002/WD-webarch-20020830/
181 o http://webarchive.nationalarchives.gov.uk/20100304163140/http://
182 www.w3.org/TR/webarch/
184 In the abstract, Memento introduces a mechanism to access versions of
185 Web resources that:
187 o Is fully distributed in the sense that resource versions may
188 reside on multiple hosts, and that any such host is likely only
189 aware of the versions it holds;
191 o Uses the global notion of datetime as a resource version indicator
192 and access key;
194 o Leverages the following primitives of W3C.REC-aww-20041215
195 [W3C.REC-aww-20041215]: resource, resource state, representation,
196 content negotiation, and link.
198 The core components of Memento's mechanism to access resource
199 versions are:
201 1. The abstract notion of the state of a resource identified by
202 URI-R as it existed at some time Tj. Note the relationship with the
203 ability to identify a the state of a resource at some datetime Tj by
204 means of a URI as intended by the proposed Dated URI scheme
205 I-D.masinter-dated-uri [I-D.masinter-dated-uri].
207 2. A bridge from the present to the past, consisting of:
209 o An appropriately typed link from a resource identified by URI-R to
210 an associated TimeGate identified by URI-G, which is aware of (at
211 least part of the) version history of the resource identified by
212 URI-R;
214 o The ability to content negotiate in the datetime dimension with
215 the TimeGate identified by URI-G, as a means to obtain a
216 representation of the state that the resource identified by URI-R
217 had at some datetime Tj.
219 3. A bridge from the past to the present, consisting of
220 appropriately typed link from a resource identified by URI-M, which
221 encapsulates the state a resource identified by URI-R had at some
222 dateimte Tj, to the resource identified by URI-R.
224 This document is concerned with specifying an instantiation of these
225 abstractions for resources that are identified by HTTP(S) URIs.
227 1.3. Notational Conventions
229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
231 document are to be interpreted as described in RFC 2119 [RFC2119].
233 When needed for extra clarity, the following conventions are used:
235 o URI-R is used to denote the URI of an Original Resource.
237 o URI-G is used to denote the URI of a TimeGate.
239 o URI-M is used to denote the URI of a Memento.
241 o URI-T is used to denote the URI of a TimeMap.
243 o When scenarios are described that involve multiple Mementos,
244 URI-M0 denotes the URI of the first Memento known to the
245 responding server, URI-Mn denotes the URI of the most recent known
246 Memento, URI-Mj denotes the URI of the selected Memento, URI-Mi
247 denotes the URI of the Memento that is temporally previous to the
248 selected Memento, and URI-Mk denotes the URI of the Memento that
249 is temporally after the selected Memento. The respective
250 datetimes for these Mementos is T0, Tn, Tj, Ti, and Tk; it holds
251 that T0 <= Ti <= Tj <= Tk <= Tn.
253 2. The Memento Framework, Datetime Negotiation component: HTTP headers,
254 HTTP Link Relation Types
256 The Memento framework is concerned with Original Resources,
257 TimeGates, Mementos, and TimeMaps that are identified by HTTP or
258 HTTPS URIs. Details are only provided for resources identified by
259 HTTP URIs but apply similarly to HTTPS resources.
261 2.1. HTTP Headers
263 The Memento framework operates at the level of HTTP request and
264 response headers. It introduces two new headers ("Accept-Datetime",
265 "Memento-Datetime"), introduces new values for two existing headers
266 ("Vary", "Link"), and uses an existing header ("Location") without
267 modification. All these headers are described below. Other HTTP
268 headers are present or absent in Memento response/request cycles as
269 specified by RFC 2616 [RFC2616].
271 2.1.1. Accept-Datetime, Memento-Datetime
273 The "Accept-Datetime" request header is used by a user agent to
274 indicate it wants to retrieve a representation of a Memento that
275 encapsulates a past state of an Original Resource. To that end, the
276 "Accept-Datetime" header is conveyed in an HTTP GET/HEAD request
277 issued against a TimeGate for an Original Resource, and its value
278 indicates the datetime of the desired past state of the Original
279 Resource. The "Accept-Datetime" request header has no defined
280 meaning for HTTP methods other than HEAD and GET.
282 The "Memento-Datetime" response header is used by a server to
283 indicate that the response contains a representation of a Memento,
284 and its value expresses the datetime of the state of an Original
285 Resource that is encapsulated in that Memento. The URI of that
286 Original Resource is provided in the response, as the Target IRI (see
287 RFC5988 [RFC5988]) of a link provided in the HTTP "Link" header that
288 has a Relation Type of "original" (see Section 2.2).
290 The presence of a Memento-Datetime header and associated value for a
291 given resource constitutes a promise that the resource is stable and
292 that its state will no longer change. Therefore, the server that
293 originally assigns the header and value, MUST retain the Memento-
294 Datetime header in all responses to HTTP HEAD/GET requests (with or
295 without "Accept-Datetime" header) that occur against the resource
296 after the time of the original assignment of the header, and it MUST
297 NOT change its associated value. Similarly, if an application is
298 mirroring the resource at a different URI, it SHOULD retain the
299 resource's Memento-Datetime header and value if mirroring the
300 resource does not include a meaningful change to the resource's
301 state. For example, this behavior allows duplicating a Web archive
302 at a new location while preserving the Memento-Datetime values of the
303 archived resources.
305 2.1.1.1. Values for Accept-Datetime
307 Values for the "Accept-Datetime" header consist of a MANDATORY
308 datetime expressed according to the RFC 1123 [RFC1123] format, which
309 is formalized by the rfc1123-date construction rule of the BNF in
310 Figure 1, and an OPTIONAL interval indicator expressed according to
311 the iso8601-interval rule of the BNF in Figure 1. The datetime MUST
312 be represented in Greenwich Mean Time (GMT).
314 Examples of "Accept-Datetime" request headers with and without an
315 interval indicator:
317 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
318 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT; -P3DT5H;+P2DT6H
320 The user agent uses the MANDATORY datetime value to convey its
321 preferred datetime for a Memento; it uses the OPTIONAL interval
322 indicator to convey it is interested in retrieving Mementos that
323 reside within this interval around the preferred datetime, and not
324 interested in Mementos that reside outside of it. Not using an
325 interval indicator is equivalent with expressing an infinite interval
326 around the preferred datetime.
328 The interval mechanism can be regarded as an implementation of the
329 functionality intended by the q-value approach that is used in
330 regular content negotiation. The q-value approach is not supported
331 for Memento's datetime negotiation because it is well-suited for
332 negotiation over a discrete space of mostly predictable values, not
333 for negotiation over a continuum of unpredictable datetime values.
335 accept-dt-value = rfc1123-date *SP [ iso8601-interval ]
336 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
337 date1 = 2DIGIT SP month SP 4DIGIT
338 ; day month year (e.g., 20 Mar 1957)
339 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
340 ; 00:00:00 - 23:59:59 (e.g., 14:33:22)
341 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" |
342 "Sun"
343 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
344 "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
345 iso8601-interval = ";" *SP "-" duration *SP ";" *SP "+" duration
346 duration = "P" ( dur-date | dur-week )
347 dur-date = ( dur-day | dur-month | dur-year ) [ dur-time ]
348 dur-year = 1*DIGIT "Y" [ dur-month ] [ dur-day ]
349 dur-month = 1*DIGIT "M" [ dur-day ]
350 dur-day = 1*DIGIT "D"
351 dur-time = "T" ( dur-hour | dur-minute | dur-second )
352 dur-hour = 1*DIGIT "H" [ dur-minute ] [ dur-second ]
353 dur-minute = 1*DIGIT "M" [ dur-second ]
354 dur-second = 1*DIGIT "S"
355 dur-week = 1*DIGIT "W"
357 Figure 1: BNF for the datetime format
359 2.1.1.2. Values for Memento-Datetime
361 Values for the "Memento-Datetime" headers MUST be datetimes expressed
362 according to the rfc1123-date construction rule of the BNF in
363 Figure 1; they MUST be represented in Greenwich Mean Time (GMT).
365 An example "Memento-Datetime" response header:
367 Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT
369 2.1.2. Vary
371 The "Vary" response header is used in responses to indicate the
372 dimensions in which content negotiation was successfully applied.
373 This header is used in the Memento framework to indicate both whether
374 datetime negotiation was applied or is supported by the responding
375 server.
377 For example, this use of the "Vary" header indicates that datetime is
378 the only dimension in which negotiation was applied:
380 Vary: negotiate, accept-datetime
381 The use of the "Vary" header in this example shows that both datetime
382 negotiation, and media type content negotiation was applied:
384 Vary: negotiate, accept-datetime, accept
386 2.1.3. Location
388 The "Location" header is used as defined in RFC 2616 [RFC2616].
389 Examples are given in Section 3 below.
391 2.1.4. Link
393 The "Link" response header is specified in RFC5988 [RFC5988]. The
394 Memento framework introduces new Relation Types to convey typed links
395 among Original Resources, TimeGates, Mementos, and TimeMaps. Already
396 existing Relation Types, among others, aimed at supporting navigation
397 among a series of ordered resources may also be used in the Memento
398 framework. This is detailed in Link Header Relation Types
399 (Section 2.2), below.
401 2.2. Link Header Relation Types
403 The "Link" header specified in RFC5988 [RFC5988] is semantically
404 equivalent to the "" element in HTML, as well as the "atom:
405 link" feed-level element in Atom RFC 4287 [RFC4287]. By default, the
406 origin of a link expressed by an entry in a "Link" header (named
407 Context IRI in RFC5988 [RFC5988]) is the IRI of the requested
408 resource.
410 2.2.1. Memento Framework Relation Types
412 The Relation Types used in the Memento framework are listed in the
413 remainder of this section, and their use is summarized in the below
414 table. Appendix A shows a Memento request/response cycle that uses
415 all the Relation Types that are introduced here.
417 +-----------+---------------------+---------------+-----------------+
418 | Relation | Original Resource | TimeGate | Memento |
419 | Type | | | |
420 +-----------+---------------------+---------------+-----------------+
421 | original | NA, except see | REQUIRED, 1 | REQUIRED, 1 |
422 | | Section 3.1.2.1 | | |
423 | timegate | RECOMMENDED, 0 or | NA | RECOMMENDED, 0 |
424 | | more | | or more |
425 | timemap | NA | RECOMMENDED, | RECOMMENDED, 0 |
426 | | | 0 or 1 | or more |
427 | memento | NA, except see | REQUIRED, 1 | REQUIRED, 1 or |
428 | | Section 3.1.2.1 | or more | more |
429 +-----------+---------------------+---------------+-----------------+
431 Table 1: The use of Relation Types
433 For several of the Relation Types introduced in the Memento
434 framework, the use of a "datetime" attribute is REQUIRED. The value
435 for this attribute MUST be a datetime expressed according to the RFC
436 1123 [RFC1123] format, which is formalized by the rfc1123-date
437 construction rule of the BNF in Figure 1; it MUST be represented in
438 Greenwich Mean Time (GMT).
440 2.2.1.1. Relation Type "original"
442 "original" -- A "Link" header entry with a Relation Type of
443 "original" is used to point from a TimeGate or a Memento to their
444 associated Original Resource. In all cases, an entry with the
445 "original" Relation Type MUST occur exactly once in a Link header.
446 Details for the entry are as follows:
448 o Context IRI: URI-G, URI-Mj
450 o Target IRI: URI-R
452 o Relation Type: "original"
454 o Use: REQUIRED
456 o Cardinality: 1
458 2.2.1.2. Relation Type "timegate"
460 "timegate" -- A "Link" header entry with a Relation Type of
461 "timegate" is used to point both from an Original Resource or a
462 Memento to a TimeGate for the Original Resource. In both cases, the
463 use of an entry with the "timegate" Relation Type is RECOMMENDED.
464 Since more than one TimeGate can exist for any Original Resource,
465 multiple entries with a "timegate" Relation Type MAY occur, each with
466 a distinct Target IRI. Details for the entry are as follows:
468 o Context IRI: URI-R or URI-Mj
470 o Target IRI: URI-G
472 o Relation Type: "timegate"
473 o Use: RECOMMENDED
475 o Cardinality: 0 or more
477 2.2.1.3. Relation Type "timemap"
479 "timemap" -- A "Link" header entry with a Relation Type of "timemap"
480 is used to point from both a TimeGate or a Memento to a TimeMap
481 resource from which a list of Mementos known to the responding server
482 is available. Use of an entry with the "timemap" Relation Type is
483 RECOMMENDED, and if used it MUST occur exactly once. This link MUST
484 include a "type" attribute and its value MUST be "application/
485 link-format", referring to the MIME type introduced in I-D.ietf-core-
486 link-format [I-D.ietf-core-link-format]. Details for the entry are
487 as follows:
489 o Context IRI: URI-G or URI-Mi
491 o Target IRI: URI-T
493 o Relation Type: "timemap"
495 o Target Attribute: "type"
497 o Use: RECOMMENDED
499 o Cardinality: 0 or more
501 2.2.1.4. Relation Type "memento"
503 "memento" -- A "Link" header entry with a Relation Type of "memento"
504 is used to point from both a TimeGate and a Memento to various
505 Mementos for an Original Resource. This link MUST include a
506 "datetime" attribute with a value that matches the Memento-Datetime
507 of the Memento that is the target of the link; that is, the value of
508 the Memento-Datetime header that is returned when the URI of the
509 linked Memento is dereferenced. Use of entries with the "memento"
510 Relation Type is REQUIRED and it MUST be as follows:
512 For all responses to HTTP HEAD/GET requests issued against an
513 existing TimeGate or Memento:
515 o One "memento" link MUST be included that has as Target IRI the URI
516 of the temporally first Memento known to the responding server;
518 o One "memento" link MUST be included that has as Target IRI the URI
519 of the temporally most recent Memento known to the responding
520 server.
522 For all responses to HTTP HEAD/GET requests issued against a TimeGate
523 or a Memento, in which a Memento is selected or served by the
524 responding server:
526 o One "memento" link MUST be included that has as Target IRI the URI
527 of the Memento that was selected or served;
529 o One "memento" link SHOULD be included that has as Target IRI the
530 URI of the Memento that is previous to the selected Memento in the
531 temporal series of all Mementos (sorted by ascending Memento-
532 Datetime values) known to the server;
534 o One "memento" link SHOULD be included that has as Target IRI the
535 URI the Memento that is next to the selected Memento in the
536 temporal series of all Mementos (sorted by ascending Memento-
537 Datetime values) known to the server.
539 o Other "memento" links MAY only be included if both the previous
540 and next links are provided. Each of these OPTIONAL "memento"
541 links MUST have as Target IRI the URI of a Memento other than the
542 ones listed above.
544 Note that the Target IRI of some of these links may coincide. For
545 example, if the selected Memento actually is the first Memento known
546 to the server, only three distinct "memento" links may result. The
547 value for the "datetime" attribute of these links would be the
548 datetimes of the first (equal to selected), next, and most recent
549 Memento known to the responding server.
551 The summary is as follows:
553 o Context IRI: URI-G, URI-Mj
555 o Target IRI: URI-M
557 o Relation Type: "memento"
559 o Target Attribute: "datetime"
561 o Use: REQUIRED
563 o Cardinality: 1 or more
565 2.2.2. Other Relation Types
567 Web Linking RFC5988 [RFC5988] allows for the inclusion of links with
568 different Relation Types but the same Target IRI, and hence the
569 Relation Types introduced by the Memento framework MAY be combined
570 with others as deemed necessary. As the "memento" Relation Type
571 focuses on conveying the datetime of a linked Memento, Relation Types
572 that allow navigating among the temporally ordered series of Mementos
573 known to a server are of particular importance. With this regard,
574 the Relation Types listed in the below table SHOULD be considered for
575 combination with the "memento" Relation Type. A distinction is made
576 between responding servers that can be categorized as systems that
577 are the focus of RFC5829 [RFC5829] (such as version contol systems)
578 and others that can not (such as Web archives). Note that, in terms
579 of RFC5829 [RFC5829], the last Memento (URI-Mn) is the version prior
580 to the latest (i.e. current) version.
582 +-----------------------------+---------------------+---------------+
583 | Memento Type | RFC5988 system | non RFC5988 |
584 | | | system |
585 +-----------------------------+---------------------+---------------+
586 | First Memento (URI-M0) | first | first |
587 | Last Memento (URI-Mn) | last | last |
588 | Selected Memento (URI-Mj) | NA | NA |
589 | Memento prior to selected | predecessor-version | prev |
590 | Memento (URI-Mi) | | |
591 | Memento next to selected | successor-version | next |
592 | Memento (URI-Mk) | | |
593 +-----------------------------+---------------------+---------------+
595 Table 2: The use of Relation Types
597 3. The Memento Framework, Datetime Negotiation component: HTTP
598 Interactions
600 This section describes the HTTP interactions of the Memento framework
601 for a variety of scenarios. First, Figure 2 provides a schematic
602 overview of a successful request/response chain that involves
603 datetime negotiation. Dashed lines depict HTTP transactions between
604 user agent and server. Appendix A shows these HTTP interactions in
605 detail for the case where the Original Resource resides on one
606 server, whereas both the TimeGate and the Mementos reside on another.
607 Scenarios also exist in which all these resources are on the same
608 server (for example, Content Management Systems) or on different
609 servers (for example, an aggregator of TimeGates). Note that, in
610 Step 2 and Step 6, the HTTP status code of the response is shown as
611 "200 OK", but a series of "206 Partial Content" could be substituted
612 without loss of generality.
614 1: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-R
615 2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R
616 3: UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------------> URI-G
617 4: UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
618 URI-R,URI-T,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -------- URI-G
619 5: UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------------> URI-Mj
620 6: UA <-- HTTP 200; Memento-Datetime: Tj; Link:
621 URI-R,URI-T,URI-G,URI-M0,URI-Mn,URI-Mi,URI-Mj,URI-Mk -- URI-Mj
623 Figure 2: Typical Memento request/response chain
625 o Step 1: In order to determine what the URI is of a TimeGate for an
626 Original Resource, the user agent issues an HTTP HEAD/GET request
627 against the URI of the Original Resource (URI-R).
629 o Step 2: The entity-header of the response from URI-R includes an
630 HTTP "Link" header with a Relation Type of "timegate" pointing at
631 a TimeGate (URI-G) for the Original Resource.
633 o Step 3: The user agent starts the datetime negotiation process
634 with the TimeGate by issuing an HTTP GET request against its URI-G
635 thereby including an "Accept-Datetime" HTTP header with a value of
636 the datetime of the desired prior state of the Original Resource.
638 o Step 4: The entity-header of the response from URI-G includes a
639 "Location" header pointing at the URI of a Memento (URI-Mj) for
640 the Original Resource. In addition, the entity-header contains an
641 HTTP "Link" header with a Relation Type of "original" pointing at
642 the Original Resource, and an HTTP "Link" header with a Relation
643 Type of "timemap" pointing at a TimeMap (URI-T). Also HTTP Links
644 pointing at various Mementos are provided using the "memento"
645 Relation Type, as specified in Section 2.2.1.4.
647 o Step 5: The user agent issues an HTTP GET request against the
648 URI-Mj of a Memento, obtained in Step 4.
650 o Step 6: The entity-header of the response from URI-Mj includes a
651 "Memento-Datetime" HTTP header with a value of the datetime of the
652 Memento. It also contains an HTTP "Link" header with a Relation
653 Type of "original" pointing at the Original Resource, with a
654 Relation Type of "timegate" pointing at a TimeGate associated with
655 the Original Resource, and with a Relation Type of "timemap"
656 pointing at a TimeMap. The state that is expressed by the
657 representation provided in the response is the state the Original
658 Resource had at the datetime expressed in the "Memento-Datetime"
659 header. This response also includes HTTP Links with a "memento"
660 Relation Type pointing at various Mementos, as specified in
661 Section 2.2.1.4.
663 The following sections detail the specifics of HTTP interactions with
664 Original Resources, TimeGates and Mementos under various conditions.
666 3.1. Interactions with an Original Resource
668 This section details HTTP GET/HEAD requests targeted at an Original
669 Resource (URI-R).
671 3.1.1. Step 1: User Agent Requests an Original Resource
673 In order to try and discover a TimeGate for the Original Resource,
674 the user agent MAY issue an HTTP HEAD or GET request against the
675 Original Resource's URI. Use of the "Accept-Datetime" header in the
676 HTTP HEAD/GET request is OPTIONAL.
678 Figure 3 shows the use of HTTP HEAD indicating the user agent is not
679 interested in retrieving a representation of the Original Resource,
680 but only in determining a TimeGate for it. It also shows the use of
681 the "Accept-Datetime" header anticipating that the user agent will
682 set it for the entire duration of a Memento request/response cycle.
684 HEAD / HTTP/1.1
685 Host: a.example.org
686 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
687 Connection: close
689 Figure 3: User Agent Requests Original Resource
691 3.1.2. Step 2: Server Responds to a Request for an Original Resource
693 The response of the Original Resource's server to the user agent's
694 HTTP HEAD/GET request of Step 1, for the case where the Original
695 Resource exists, is as it would be in a regular HTTP request/response
696 cycle, but in addition MAY include a HTTP "Link" header with a
697 Relation Type of "timegate" that conveys the URI of the Original
698 Resource's TimeGate as the Target IRI of the Link. Multiple HTTP
699 Links with a relation type of "timegate" MAY be provided to
700 accomodate situations in which the server is aware of multiple
701 TimeGates for an Original Resource. The actual Target IRI provided
702 in the "timegate" Link may depend on several factors including the
703 datetime provided in the "Accept-Datetime" header, and the IP address
704 of the user agent. A response for this case is illustrated in
705 Figure 4.
707 HTTP/1.1 200 OK
708 Date: Thu, 21 Jan 2010 00:02:12 GMT
709 Server: Apache
710 Link:
711 ; rel="timegate"
712 Content-Length: 255
713 Connection: close
714 Content-Type: text/html; charset=iso-8859-1
716 Figure 4: Server of Original Resource Responds
718 Servers that actively maintain archives of their resources SHOULD
719 include the "timegate" HTTP "Link" header because this link is an
720 important way for a user agent to discover TimeGates for those
721 resources. This includes servers such as Content Management Systems,
722 Control Version Systems, and Web servers with associated
723 transactional archives Fitch [Fitch]. Servers that do not actively
724 maintain archives of their resources MAY include the "timegate" HTTP
725 "Link" header as a way to convey a preference for TimeGates for their
726 resources exposed by a third party archive. This includes servers
727 that rely on Web archives such as the Internet Archive to archive
728 their resources.
730 The server of the Original Resource MUST treat requests with and
731 without an "Accept-Datetime" header in the same way:
733 o The response MUST either always or never include a HTTP "link"
734 header with an entry that has a "timegate" Relation Type and the
735 URI of a TimeGate as the Target IRI.
737 o The entity-body of the response MUST be the same, for user agent
738 requests with or without a "Accept-Datetime" header.
740 3.1.2.1. Original Resource is an Appropriate Memento
742 The "Memento-Datetime" header MAY be applied to an Original Resource
743 directly as both an indication that the state of the Original
744 Resource has not changed since the datetime conveyed in the "Memento-
745 Datetime" header, and as a promise that it will not change anymore
746 beyond it. This may occur, for example, for certain stable media
747 resources on news sites. In case the user agent's preferred datetime
748 is equal to or more recent than the datetime conveyed as the value of
749 Memento-Datetime in the server's response in Step 2, the user agent
750 SHOULD conclude it has located an appropriate Memento, and it SHOULD
751 NOT continue to Step 3.
753 Figure 5 illustrates such a response to a request for the resource
754 with URI http://a.example.org/pic that has been stable since it was
755 created. Note the use of both the "memento" and "original" Relation
756 Types for links that have as Target IRI the URI of the Original
757 Resource.
759 HTTP/1.1 200 OK
760 Date: Thu, 21 Jan 2010 00:02:12 GMT
761 Server: Apache
762 Link:
763
764 ; rel="original memento"
765 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT"
766 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
767 Content-Length: 255
768 Connection: close
769 Content-Type: text/html; charset=iso-8909-1
771 Figure 5: Response to a request for an Original Resource that was
772 created stable
774 Cases may also exist in which a resource becomes stable at a certain
775 point in its existence, but changed previously. In such cases, the
776 Original Resource may know about a TimeGate that is aware of its
777 prior history and hence MAY also include a link with a "timegate"
778 Relation Type. This is illustrated in Figure 6, where the "memento"
779 and "original" Relation Types are used as in Figure 5, and the
780 existence of a TimeGate to negotiate for Mementos with datetimes
781 prior to Fri, 20 Mar 2009 11:00:00 GMT is indicated.
783 HTTP/1.1 200 OK
784 Date: Thu, 21 Jan 2010 00:02:12 GMT
785 Server: Apache
786 Link:
787
788 ; rel="original memento"
789 ; datetime="Fri, 20 Mar 2009 11:00:00 GMT",
790
791 ; rel="timegate"
792 Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
793 Content-Length: 255
794 Connection: close
795 Content-Type: text/html; charset=iso-8909-1
797 Figure 6: Response to a request for an Original Resource that became
798 stable
800 3.1.2.2. Server Exists and Original Resource Used to Exist
802 Servers SHOULD also provide a "timegate" HTTP "Link" header in
803 responses to requests for an Original Resource that the server knows
804 used to exist, but no longer does. This allows the use of an
805 Original Resource's URI as an entry point to representations of its
806 prior states even if the resource itself no longer exists. A
807 server's response for this case is illustrated in Figure 7.
809 HTTP/1.1 404 Not Found
810 Date: Thu, 21 Jan 2010 00:02:12 GMT
811 Server: Apache
812 Link:
813
814 ; rel="timegate"
815 Content-Length: 255
816 Connection: close
817 Content-Type: text/html; charset=iso-8909-1
819 Figure 7: Response to a request for an Original Resource that not
820 longer exists
822 In case the server is not aware of the prior existence of the
823 Original Resource, its response SHOULD NOT include a "timegate" HTTP
824 Link. Section 3.1.2.3 details what the user agent's behavior should
825 be in such cases.
827 3.1.2.3. Missing or Inadequate "timegate" Link in Original Server's
828 Response
830 A user agent MAY ignore the TimeGate returned in Step 2. However,
831 when engaging in a Memento request/response cycle, a user agent
832 SHOULD NOT proceed immediately to Step 3 by using a TimeGate of its
833 own preference but rather SHOULD always start the cycle by issuing an
834 HTTP GET/HEAD against the Original Resource (Step 1, Figure 3) as it
835 is an important way to learn about dedicated or preferred TimeGates
836 for the Original Resource. Also, cases exist in which the response
837 in Step 2 will not provide a "timegate" link, including:
839 o The Original Resource's server does not support the Memento
840 framework;
842 o The Original Resource does no longer exist and the responding
843 server is not aware of its prior existence;
845 o The server that hosted the Original Resource no longer exists;
846 In all these cases, the user agent SHOULD attempt to determine an
847 appropriate TimeGate for the Original Resource, either automatically
848 or interactively supported by the user.
850 3.2. Interactions with a TimeGate
852 This section details HTTP GET/HEAD requests targeted at a TimeGate
853 (URI-G).
855 3.2.1. Step 3: User Agent Negotiates with a TimeGate
857 In order to negotiate with a TimeGate, the user agent MUST issue a
858 HTTP HEAD or GET against its URI, its request MUST include the
859 "Accept-Datetime" header to express its datetime preference, and the
860 use of that header MUST be as described in Section 2.1.1.1. The URI
861 of the TimeGate may have been provided as the Target IRI of a
862 "timegate" HTTP "Link" header in the response from the Original
863 Resource (Step 2, Figure 4), or may have resulted from another
864 discovery mechanism, for example, based on the aggregation of
865 TimeMaps (Section 4.1) or user interaction. Such a request is
866 illustrated in Figure 8.
868 GET /web/timegate/http://a.example.org HTTP/1.1
869 Host: arxiv.example.net
870 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
871 Connection: close
873 Figure 8: User agent negotiates with TimeGate
875 3.2.2. Step 4: Server Responds to Negotiation with TimeGate
877 In order to respond to a datetime negotiation request (Step 3,
878 Section 3.2.1), the server uses an internal algorithm to select the
879 Memento that best meets the user agent's datetime preference, and
880 redirects to it. The exact nature of the selection algorithm is at
881 the server's discretion but SHOULD be consistent. A variety of
882 approaches can be used including selecting the Memento that is
883 nearest in time (either past or future) or nearest in the past
884 relative to the requested datetime. Special cases for datetime
885 negotiation with a TimeGate exist, and they are addressed in
886 Section 3.2.2.3 through Section 3.2.2.7.
888 3.2.2.1. Successful Scenario
890 In cases where the TimeGate exists, and the datetime provided in the
891 user agent's "Accept-Datetime" header can be parsed and is not out of
892 range, the server selects a Memento based on the user agent's
893 datetime preference. The response MUST have a "302 Found" HTTP
894 status code, and the "Location" header MUST be used to convey the URI
895 of the selected Memento. The "Vary" header MUST be provided and it
896 MUST include the "negotiate" and "accept-datetime" values to indicate
897 that datetime negotiation has taken place. The "Link" header MUST be
898 provided and contain links with Relation Types subject to the
899 considerations described in Section 2.2. Such a response is
900 illustrated in Figure 9.
902 HTTP/1.1 302 Found
903 Date: Thu, 21 Jan 2010 00:06:50 GMT
904 Server: Apache
905 Vary: negotiate, accept-datetime
906 Location:
907 http://arxiv.example.net/web/20010911203610/http://a.example.org
908 Link: ; rel="original",
909
910 ; rel="timemap"; type="application/link-format",
911
912 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
913
914 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
915
916 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
917
918 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
919
920 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
921 Content-Length: 0
922 Content-Type: text/plain; charset=UTF-8
923 Connection: close
925 Figure 9: Server of TimeGate responds
927 Note that the regular content negotiation dimensions (media type,
928 character encoding, language, and compression) remain available. It
929 is the TimeGate server's responsibility to honor (or not) such
930 content negotiation, and in doing so it MUST always first select a
931 Memento that meets the user agent's datetime preference, and then
932 consider honoring regular content negotiation for it.
934 3.2.2.2. Datetime Out of the Server's Range
936 In case, in Step 3, a user agent's "Accept-Datetime" header does not
937 convey an interval indicator, and conveys a datetime that is either
938 earlier than the datetime of the first Memento or later than the
939 datetime of the most recent Memento known to the server, the server's
940 response MUST be as described in Section 3.2.2.1, with a selection of
941 the first or most recent Memento, respectively.
943 This is illustrated in Figure 10 that shows the response from a
944 TimeGate exposed by a MediaWiki server to a request by a user agent
945 that has an "Accept-Datetime: Mon, 31 May 1999 00:00:00 GMT" header.
946 Note that a link is provided with a "successor-version" Relation Type
947 but not with a "predecessor-version" Relation Type.
949 HTTP/1.1 302 Found
950 Server: Apache
951 Content-Length: 709
952 Content-Type: text/html; charset=utf-8
953 Date: Thu, 21 Jan 2010 00:09:40 GMT
954 Location:
955 http://a.example.org/w/index.php?title=Clock&oldid=1493688
956 Vary: negotiate, accept-datetime
957 Link: ; rel="original",
958
959 ; rel="timemap",
960
961 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
962
963 ; rel="successor-version memento"
964 ; datetime="Tue, 30 Sep 2003 14:28:00 GMT",
965
966 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT"
967 Connection: close
969 Figure 10: A TimeGate's response to a request for a Memento with a
970 datetime earlier than that of the first Memento
972 3.2.2.3. Accept-Datetime Not Provided
974 In case, in Step 3, a user agent issues a request to a TimeGate and
975 fails to include an "Accept-Datetime" request header, the response
976 MUST be handled as in Section 3.2.2.1, with a selection of the most
977 recent Memento known to the responding server.
979 3.2.2.4. Multiple Matching Mementos
981 Because the finest datetime granularity epxressable using the RFC
982 1123 [RFC1123] format used in HTTP is seconds level, cases may occur
983 in which a TimeGate server is aware of multiple Mementos that meet
984 the user agent's datetime preference. This may occur in CMS with
985 very high update rates. The response in this case MUST be handled as
986 in Section 3.2.2.1, with the selection of one of the matching
987 Mementos.
989 As an example, Figure 11 shows a hypothetical response from a
990 TimeGate on a MediaWiki server to a request for a Memento for the
991 Original Resource http://a.example.org/w/Clock for which two Mementos
992 exist for the user agent's preferred datetime.
994 HTTP/1.1 302 Found
995 Server: Apache
996 Content-Length: 705
997 Content-Type: text/html; charset=utf-8
998 Date: Thu, 21 Jan 2010 00:09:40 GMT
999 Vary: negotiate, accept-datetime
1000 Location:
1001 http://a.example.org/w/index.php?title=Clock&oldid=322586071
1002 Link: ; rel="original",
1003
1004 ; rel="timemap";type="application/link-format",
1005
1006 ; rel="first memento"; datetime="Sun, 28 Sep 2003 01:42:00 GMT",
1007
1008 ; rel="last memento"; datetime="Tue, 12 Jan 2010 19:55:00 GMT",
1009
1010 ; rel="memento"; datetime="Sun, 31 May 2009 15:43:00 GMT",
1011
1012 ; rel="memento successor-version"
1013 ; datetime="Sun, 31 May 2009 15:43:00 GMT"
1014
1015 ; rel="memento predecessor-version"
1016 ; datetime="Sun, 31 May 2009 15:41:24 GMT"
1017 Connection: close
1019 Figure 11: A TimeGate's response to a request that has multiple
1020 Mementos with a matching datetime
1022 3.2.2.5. Datetime Out of the User Agent's Range
1024 In case, in Step 3, a user agent conveys an interval indicator, and
1025 the responding server is not aware of any Mementos with datetimes
1026 within the expressed interval, the server's response MUST have a "406
1027 Not Acceptable" HTTP status code. The use of the "Vary" header MUST
1028 be as described in Section 3.2.2.1. The use of the "Link" header
1029 MUST be as described in Section 2.2. Specifically, the use of links
1030 with a "memento" Relation Type MUST follow the rules for the case
1031 where no Memento is selected by the responding server, i.e. only
1032 "memento" links to the first and most recent Mementos MUST be
1033 provided (Section 2.2.1.4).
1035 Figure 12 shows a user agent using an "Accept-Datetime" header
1036 conveying an interval of interest starting 5 hours before and ending
1037 6 hours after Tue, 11 Sep 2001 20:35:00 GMT. Figure 13 shows the
1038 response from the TimeGate.
1040 GET /web/timegate/http://a.example.org HTTP/1.1
1041 Host: arxiv.example.net
1042 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT; -P5H;+P6H
1043 Connection: close
1045 Figure 12: User agent expresses interval of interest in Accept-
1046 Datetime header
1048 HTTP/1.1 406 Not Acceptable
1049 Date: Thu, 21 Jan 2010 00:06:50 GMT
1050 Server: Apache
1051 Vary: negotiate, accept-datetime
1052 Link: ; rel="original",
1053
1054 ; rel="timemap";type="application/link-format",
1055
1056 ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1057
1058 ; rel="memento last"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1059 Content-Length: 1732
1060 Connection: close
1061 Content-Type: text/plain; charset=UTF-8
1063 Figure 13: A TimeGate's response indicating it has no Mementos within
1064 the interval of interest
1066 3.2.2.6. Accept-Datetime Unparseable
1068 In case, in Step 3, a user agent conveys a value for the "Accept-
1069 Datetime" request header that does not conform to the accept-dt-value
1070 construction rule of the BNF in Figure 1, the TimeGate server's
1071 response MUST have a "400 Bad Request" HTTP status code. With all
1072 other respects, responses in this case MUST be handled as described
1073 in Section 3.2.2.5
1075 3.2.2.7. TimeGate Does Not Exist
1077 Cases may occur in which a user agent issues a request against a
1078 TimeGate that does not exist. This may, for example, occur when a
1079 user agent uses internal knowledge to construct the URI of an
1080 assumed, yet non-existent TimeGate. In these cases, the response
1081 from the target server MUST have a "404 Not Found" HTTP status code,
1082 and SHOULD include a "Vary" header that includes the "negotiate" and
1083 "accept-datetime" values as an indication that, generally, the server
1084 is capable of datetime negotiation. The response MUST NOT include a
1085 "Link" header with any of the Relation Types introduced in
1086 Section 2.2.1.
1088 3.2.2.8. HTTP Methods other than HEAD/GET
1090 In the above, the safe HTTP methods GET and HEAD are described for
1091 TimeGates. TimeGates MAY support the safe HTTP methods OPTIONS and
1092 TRACE in the way described in RFC 2616 [RFC2616]. Unsafe HTTP
1093 methods (i.e. PUT, POST, DELETE) MUST NOT be supported by a
1094 TimeGate. Such requests MUST yield a response with a "405 Method Not
1095 Allowed" HTTP status code, and MUST include an "Allow" header to
1096 convey that only the HEAD and GET (and OPTIONALLY the OPTIONS and
1097 TRACE) methods are supported. In addition, the response MUST have a
1098 "Vary" header that includes the "negotiate" and "accept-datetime"
1099 values to indicate the TimeGate supports datetime negotiation.
1100 Figure 14 shows such a response.
1102 HTTP/1.1 405 Method Not Allowed
1103 Date: Thu, 21 Jan 2010 00:02:12 GMT
1104 Server: Apache
1105 Vary: negotiate, accept-datetime
1106 Allow: HEAD, GET
1107 Content-Length: 255
1108 Connection: close
1109 Content-Type: text/html; charset=iso-8909-1
1111 Figure 14: Response from a TimeGate accessed with HTTP method other
1112 than HEAD/GET
1114 3.2.3. Recognizing a TimeGate
1116 When a user agent issues a HTTP HEAD/GET request against a resource
1117 of which it found the URI as the Target IRI of an entry in the "Link"
1118 header with a "timegate" Relation Type, it SHOULD NOT assume that the
1119 targeted resource effectively is a TimeGate and hence will behave as
1120 described in Section 3.2.2.
1122 A user agent MUST decide it has reached a TimeGate if the response to
1123 a HTTP HEAD/GET request against the resource's URI contains a "Vary"
1124 header that includes the "negotiate" and "accept-datetime" values.
1125 If the response does not, the user agent MUST decide it has not
1126 reached a TimeGate and proceed as follows:
1128 o If the response contains a redirection, the user agent SHOULD
1129 follow it. Note that even a chain of redirections is possible,
1130 e.g. URI-R -> URI-1 -> URI-2 -> ... -> URI-G
1132 o If the response does not contain a redirection, or if the
1133 redirection (chain) does not lead to a TimeGate, the user agent
1134 SHOULD attempt to determine an appropriate TimeGate for the
1135 Original Resource, either automatically or interactively supported
1136 by the user.
1138 Resources that are not TimeGates (i.e. do not behave as described in
1139 Section 3.2.2) MUST NOT use a "Vary" header that includes the
1140 "accept-datetime" value.
1142 3.3. Interactions with a Memento
1144 This section details HTTP GET/HEAD requests targeted at a Memento
1145 (URI-M).
1147 3.3.1. Step 5: User Agent Requests a Memento
1149 In Step 5, the user agent issues a HTTP GET request against the URI
1150 of a Memento. The user agent MAY include an "Accept-Datetime" header
1151 in this request, but the existence or absence of this header MUST NOT
1152 affect the server's response. The URI of the Memento may have
1153 resulted from a response in Step 4, or the user agent may simply have
1154 happened upon it. Such a request is illustrated in Figure 15.
1156 GET /web/20010911203610/http://a.example.org HTTP/1.1
1157 Host: arxiv.example.net
1158 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1159 Connection: close
1161 Figure 15: User agent requests Memento
1163 3.3.2. Step 6: Server Responds to a Request for a Memento
1165 If the Memento requested by the user agent in Step 5 exists, the
1166 server's response MUST have a "200 OK" HTTP status code (or "206
1167 Partial Content", where appropriate), and it MUST include a "Memento-
1168 Datetime" header with a value equal to the archival datetime of the
1169 Memento, that is, the datetime of the state of the Original Resource
1170 that is encapsulated in the Memento. The "Link" header MUST be
1171 provided and contain links subject to the considerations described in
1172 Section 2.2. The Target IRI and, when applicable, the datetime
1173 values in the "Link" header associated with the "memento" Relation
1174 Type SHOULD be the same as conveyed in Step 4, in case the TimeGate
1175 and the selected Memento reside on the same server. However, they
1176 MAY be different in case the TimeGate and the selected Memento reside
1177 on different servers.
1179 Figure 16 illustrates the server's response to the request issued
1180 against a Memento in Step 5 (Figure 15).
1182 HTTP/1.1 200 OK
1183 Date: Thu, 21 Jan 2010 00:09:40 GMT
1184 Server: Apache-Coyote/1.1
1185 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1186 Link: ; rel="original",
1187
1188 ; rel="timemap"; type="application/link-format",
1189
1190 ; rel="timegate",
1191
1192 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1193
1194 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1195
1196 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
1197
1198 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
1199
1200 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
1201 Content-Length: 23364
1202 Content-Type: text/html;charset=utf-8
1203 Connection: close
1205 Figure 16: Server of Memento responds
1207 The server's response MUST include the "Memento-Datetime" header
1208 regardless whether the user agent's request contained an "Accept-
1209 Datetime" header or not. This is the way by which resources make
1210 explicit that they are Mementos. Due to the sparseness of Mementos
1211 in most archives, the value of the "Memento-Datetime" header returned
1212 by a server may differ (significantly) from the value conveyed by the
1213 user agent in "Accept-Datetime".
1215 Although a Memento encapsulates a prior state of an Original
1216 Resource, the entity-body returned in response to an HTTP GET request
1217 issued against a Memento may very well not be byte-to-byte the same
1218 as an entity-body that was previously returned by that Original
1219 Resource. Various reasons exist why there are significant chances
1220 these would be different yet do convey substantially the same
1221 information. These include format migrations as part of a digital
1222 preservation strategy, URI-rewriting as applied by some Web archives,
1223 and the addition of banners as a means to brand Web archives.
1225 3.3.2.1. Memento Does not Exist
1227 Cases may occur in which a TimeGate's response (Step 4) points at a
1228 Memento that actually does not exist, resulting in a user agent's
1229 request (Step 5) for a non-existent Memento. In this case, the
1230 server's response MUST have the expected "404 Not Found" HTTP Status
1231 Code and it MUST NOT contain a "Memento-Datetime" header.
1233 3.3.3. Recognizing a Memento
1235 When following the redirection provided by a confirmed TimeGate (see
1236 Section 3.2.3), a user agent SHOULD NOT assume that the targeted
1237 resource effectively is a Memento and hence will behave as described
1238 in Section 3.3.2.
1240 A user agent MUST decide it has reached a Memento if the response to
1241 a HTTP HEAD/GET request against the resource's URI contains a
1242 "Memento-Datetime" header with a legitimate value. If the response
1243 does not, the following applies:
1245 o If the response contains a redirection, the user agent SHOULD
1246 follow it. Even a chain of redirections is possible, e.g. URI-G
1247 -> URI-X -> URI-Y -> ... -> URI-M.
1249 o If the response by a confirmed TimeGate does not contain a
1250 redirection, or if the redirection (chain) that started at a
1251 confirmed TimeGate does not lead to a resource that provides a
1252 "Memento-Datetime" header, the user agent MAY still conclude that
1253 it has likely arrived at a Memento. That is because cases exist
1254 in which archives and CMS are made compliant with the Memento
1255 framework "by proxy". In these cases TimeGates will redirect to
1256 Mementos in such systems, but the responses from these Mementos
1257 will not (yet) include a "Memento-Datetime" header.
1259 4. The Memento Framework, Discovery Component
1261 4.1. TimeMaps
1263 A TimeMap resource is introduced to support retrieving a
1264 comprehensive list of all Mementos known to a responding server. The
1265 entity-body of a response to an HTTP GET request issued against a
1266 TimeMap's URI:
1268 o MUST list the URI of the Original Resource that the response lists
1269 Mementos for;
1271 o MUST list the URI of one or more TimeGates for the Original
1272 Resource;
1274 o MUST list the URI and datetime of each Memento known to the
1275 responding server;
1277 o SHOULD, for self-containment, list the URI of the TimeMap itself;
1279 o MUST unambiguously type listed resources as being Original
1280 Resource, TimeGate, Memento, or TimeMap.
1282 TimeMaps MAY be serialized in various ways, but the link-value format
1283 serialization MUST be supported. In this serialization, the entity-
1284 body MUST be formatted in the same way as the value of a HTTP "Link"
1285 header, and hence MUST comply to the "link-value" construction rule
1286 of "Section 5. The Link Header Field" of RFC5988 [RFC5988]. The
1287 media type of the entity-body MUST be "application/link-format", and
1288 the use of the Relation Types is subject to the considerations in
1289 Section 2.2 with the following execptions:
1291 o Instead of a Memento selected by the responding server, all
1292 Mementos known to the server MUST be listed;
1294 o Since no Memento was selected by the server, the entity-body MUST
1295 NOT contain links with "prev", "next", "predecessor-version",
1296 "successor-version" Relation Types.
1298 In order to retrieve the link-value serialization of a TimeMap, a
1299 user agent SHOULD use an "Accept: application/link-format" header.
1300 This is shown in Figure 17. The response from the TimeMap is shown
1301 in Figure 18; for practical reasons the entity-body in the example
1302 has been abbreviated.
1304 GET /web/timemap/http://a.example.org HTTP/1.1
1305 Host: arxiv.example.net
1306 Accept: application/link-format;q=1.0
1307 Connection: close
1309 Figure 17: Request for a TimeMap
1311 HTTP/1.1 200 OK
1312 Date: Thu, 21 Jan 2010 00:06:50 GMT
1313 Server: Apache
1314 Connection: close
1315 Content-Type: application/link-format
1317 ;rel="original",
1318
1319 ; rel="timemap";type="application/link-format",
1320
1321 ; rel="timegate",
1322
1323 ; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
1324
1325 ; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT",
1326
1327 ; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT",
1328
1329 ; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT",
1330 ...
1332 Figure 18: Response from a TimeMap
1334 4.2. Discovery of TimeMaps, TimeGates
1336 As described in Section 3, TimeMaps and TimeGates can be discovered
1337 via HTTP Links with the "timemap" and "timegate" Relation Type,
1338 respectively. Additional discovery mechanisms are RECOMMENDED,
1339 including:
1341 o The inclusion of HTML LINK elements with "timegate" and "timemap"
1342 rel types in Original Resources that provide an HTML response,
1343 e.g. ;
1347 o The implementation of batch discovery mechanisms for TimeMaps
1348 using SiteMaps or feed technology.
1350 5. IANA Considerations
1352 This memo requires IANA to register the "Link" header Relation Types
1353 defined in Section 2.2.1 in the appropriate IANA registry.
1355 This memo requires IANA to register the Accept-Datetime and Memento-
1356 Datetime HTTP headers defined in Section 2.1.1 in the appropriate
1357 IANA registry.
1359 6. Security Considerations
1361 Provision of a "timegate" HTTP "Link" header in responses to requests
1362 for an Original Resource that is protected (e.g., 401 or 403 HTTP
1363 response codes) is OPTIONAL. The inclusion of this Link when
1364 requesting authentication is at the server's discretion; cases may
1365 exist in which a server protects the current state of a resource, but
1366 supports open access to prior states and thus chooses to supply a
1367 "timegate" HTTP "Link" header. Conversely, the server may choose to
1368 not advertise the TimeGate URIs (e.g., they exist in an intranet
1369 archive) for unauthenticated requests.
1371 Authentication, encryption and other security related issues are
1372 otherwise orthogonal to Memento.
1374 7. Changelog
1376 o v01 2010-11-11 HVDS MLN RS First public version
1378 o v00 2010-10-19 HVDS MLN RS Limited circulation version
1380 o 2010-07-22 HVDS MLN First internal version
1382 8. Acknowledgements
1384 The Memento effort is funded by the Library of Congress. Many thanks
1385 to Kris Carpenter Negulescu, Michael Hausenblas, Erik Hetzner, Larry
1386 Masinter, Gordon Mohr, Mark Nottingham, David Rosenthal, Ed Summers
1387 for early feedback. Many thanks to Samuel Adams, Scott Ainsworth,
1388 Lyudmilla Balakireva, Frank McCown, Harihar Shankar, Brad Tofel for
1389 early implementations.
1391 9. References
1393 9.1. Normative References
1395 [I-D.ietf-core-link-format]
1396 Shelby, Z., "CoRE Link Format",
1397 draft-ietf-core-link-format-01 (work in progress),
1398 October 2010.
1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1401 Requirement Levels", BCP 14, RFC 2119, March 1997.
1403 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1404 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1405 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1407 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
1408 for Simple Version Navigation between Web Resources",
1409 RFC 5829, April 2010.
1411 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
1413 9.2. Informative References
1415 [Fitch] Fitch, "Web site archiving - an approach to recording
1416 every materially different response produced by a
1417 website", July 2003,
1418 .
1420 [I-D.masinter-dated-uri]
1421 Masinter, L., "The 'tdb' and 'duri' URI schemes, based on
1422 dated URIs", draft-masinter-dated-uri-07 (work in
1423 progress), October 2010.
1425 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1426 and Support", STD 3, RFC 1123, October 1989.
1428 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1429 Syndication Format", RFC 4287, December 2005.
1431 [W3C.REC-aww-20041215]
1432 Jacobs and Walsh, "Architecture of the World Wide Web",
1433 December 2004, .
1435 Appendix A. Appendix B: A Sample, Successful Memento Request/Response
1436 cycle
1438 Step 1 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-R
1440 HEAD / HTTP/1.1
1441 Host: a.example.org
1442 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1443 Connection: close
1445 Step 2 : UA <-- HTTP 200; Link: URI-G ----------------------- URI-R
1447 HTTP/1.1 200 OK
1448 Date: Thu, 21 Jan 2010 00:02:12 GMT
1449 Server: Apache
1450 Link:
1451 ; rel="timegate"
1452 Content-Length: 255
1453 Connection: close
1454 Content-Type: text/html; charset=iso-8859-1
1456 Step 3 : UA --- HTTP GET/HEAD; Accept-Datetime: Tj ---------> URI-G
1458 GET /web/timegate/http://a.example.org
1459 HTTP/1.1
1460 Host: arxiv.example.net
1461 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1462 Connection: close
1464 Step 4 : UA <-- HTTP 302; Location: URI-Mj; Vary; Link:
1465 URI-R, URI-T, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-G
1467 HTTP/1.1 302 Found
1468 Date: Thu, 21 Jan 2010 00:06:50 GMT
1469 Server: Apache
1470 Vary: negotiate, accept-datetime
1471 Location:
1472 http://arxiv.example.net/web/20010911203610/http://a.example.org
1473 Link: ; rel="original",
1474
1475 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1476
1477 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1478
1479 ; rel="timemap"; type="application/link-format",
1480
1481 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
1482
1483 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
1484
1485 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
1486 Content-Length: 0
1487 Content-Type: text/plain; charset=UTF-8
1488 Connection: close
1490 Step 5 : UA --- HTTP GET URI-Mj; Accept-Datetime: Tj -------> URI-Mj
1492 GET /web/20010911203610/http://a.example.org
1493 HTTP/1.1
1494 Host: arxiv.example.net
1495 Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT
1496 Connection: close
1498 Step 6 : UA <-- HTTP 200; Memento-Datetime: Tj; Link: URI-R,
1499 URI-T, URI-G, URI-M0, URI-Mn, URI-Mi, URI-Mj, URI-Mk ---- URI-Mj
1501 HTTP/1.1 200 OK
1502 Date: Thu, 21 Jan 2010 00:09:40 GMT
1503 Server: Apache-Coyote/1.1
1504 Memento-Datetime: Tue, 11 Sep 2001 20:36:10 GMT
1505 Link: ; rel="original",
1506
1507 ; rel="first memento"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
1508
1509 ; rel="last memento"; datetime="Tue, 08 Jul 2008 09:34:33 GMT",
1510
1511 ; rel="timemap"; type="application/link-format",
1512
1513 ; rel="timegate",
1514
1515 ; rel="memento"; datetime="Tue, 11 Sep 2001 20:36:10 GMT",
1516
1517 ; rel="prev memento"; datetime="Tue, 11 Sep 2001 20:30:51 GMT",
1518
1519 ; rel="next memento"; datetime="Tue, 11 Sep 2001 20:47:33 GMT"
1520 Content-Length: 23364
1521 Content-Type: text/html;charset=utf-8
1522 Connection: close
1524 A successful flow with TimeGate and Mementos on the same server
1526 Authors' Addresses
1528 Herbert VandeSompel
1529 Los Alamos National Laboratory
1530 PO Box 1663
1531 Los Alamos, New Mexico 87545
1532 USA
1534 Phone: +1 505 667 1267
1535 Email: hvdsomp@gmail.com
1536 URI: http://public.lanl.gov/herbertv/
1537 Michael Nelson
1538 Old Dominion University
1539 Norfolk, Virginia 23529
1540 USA
1542 Phone: +1 757 683 6393
1543 Email: mln@cs.odu.edu
1544 URI: http://www.cs.odu.edu/~mln/
1546 Robert Sanderson
1547 Los Alamos National Laboratory
1548 PO Box 1663
1549 Los Alamos, New Mexico 87545
1550 USA
1552 Phone: +1 505 665 5804
1553 Email: azaroth42@gmail.com
1555 Copyright Notice
1557 Copyright (c) 2010 IETF Trust and the persons identified as the
1558 document authors. All rights reserved.
1560 This document is subject to BCP 78 and the IETF Trust's Legal
1561 Provisions Relating to IETF Documents
1562 (http://trustee.ietf.org/license-info) in effect on the date of
1563 publication of this document. Please review these documents
1564 carefully, as they describe your rights and restrictions with respect
1565 to this document. Code Components extracted from this document must
1566 include Simplified BSD License text as described in Section 4.e of
1567 the Trust Legal Provisions and are provided without warranty as
1568 described in the Simplified BSD License.