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