Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7089

HTTP Framework for Time-Based Access to Resource States -- Memento

Pages: 50
Informational
Part 2 of 3 – Pages 14 to 35
First   Prev   Next

Top   ToC   RFC7089 - Page 14   prevText

4. Datetime Negotiation: HTTP Interactions

Figure 2 depicts a specific pattern to implement the Memento framework. Multiple patterns exist, and they can be grouped as follows: o Pattern 1 (Section 4.1) - The Original Resource acts as its own TimeGate o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for the Original Resource
Top   ToC   RFC7089 - Page 15
   o  Pattern 3 (Section 4.3) - The Original Resource is a Fixed
      Resource

   o  Pattern 4 (Section 4.4) - Mementos without a TimeGate

   Details of the HTTP interactions for common cases for each of those
   patterns are provided in Sections 4.1 through 4.4.  Appendix A
   summarizes the use of the "Vary", "Memento-Datetime", and "Link"
   headers in responses from Original Resources, TimeGates, and Mementos
   for the various patterns.  Special cases are described in
   Section 4.5.  Note that in the following sections, the HTTP status
   code of the responses with an entity-body is shown as "200 OK", but a
   series of "206 Partial Content" responses could be substituted.

   Figure 4 shows a user agent that attempts to datetime negotiate with
   the Original Resource http://a.example.org/ by including an "Accept-
   Datetime" header in its HTTP HEAD request.  This initiating request
   is the same for Pattern 1 (Section 4.1) through Pattern 3
   (Section 4.3).

   HEAD / HTTP/1.1
   Host: a.example.org
   Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
   Connection: close

            Figure 4: User Agent Attempts Datetime Negotiation
                          with Original Resource

4.1. Pattern 1 - The Original Resource Acts as Its Own TimeGate

In this implementation pattern, the Original Resource acts as its own TimeGate, which means that URI-R and URI-G coincide. Content management systems and revision control systems can support datetime negotiation in this way as they are commonly aware of the version history of their own resources. The response to this request when datetime negotiation for this resource is supported depends on the negotiation style it uses (200- style or 302-style) and on the existence or absence of a URI-M for Mementos that is distinct from the URI-R of the associated Original Resource. The various cases are summarized in the below table, and the server responses for each are detailed in the remainder of this section.
Top   ToC   RFC7089 - Page 16
   +-------------------+------------+----------+---------+-------------+
   |      Pattern      |  Original  | TimeGate | Memento | Negotiation |
   |                   |  Resource  |          |         |    Style    |
   +-------------------+------------+----------+---------+-------------+
   |    Pattern 1.1    |    URI-R   |   URI-R  |  URI-M  |     302     |
   |  (Section 4.1.1)  |            |          |         |             |
   |    Pattern 1.2    |    URI-R   |   URI-R  |  URI-M  |     200     |
   |  (Section 4.1.2)  |            |          |         |             |
   |    Pattern 1.3    |    URI-R   |   URI-R  |  URI-R  |     200     |
   |  (Section 4.1.3)  |            |          |         |             |
   +-------------------+------------+----------+---------+-------------+

                            Table 1: Pattern 1

4.1.1. Pattern 1.1 - URI-R=URI-G; 302-Style Negotiation; Distinct URI-M

In this case, the response to the user agent's request of Figure 4 has a "302 Found" HTTP status code, and the "Location" header conveys the URI-M of the selected Memento. The use of Memento response headers and links in the response from URI-R=URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST NOT contain a "Memento-Datetime" header. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2. The server's response to the request of Figure 4 is shown in Figure 5. Note the inclusion of the recommended link to the TimeGate that, in this case, has a Target IRI that is the URI-R of the Original Resource.
Top   ToC   RFC7089 - Page 17
   HTTP/1.1 302 Found
   Date: Thu, 21 Jan 2010 00:06:50 GMT
   Server: Apache
   Vary: accept-datetime
   Location:
    http://a.example.org/?version=20010320133610
   Link: <http://a.example.org/>; rel="original timegate"
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

            Figure 5: Response from URI-R=URI-G for Pattern 1.1

   In a subsequent request, shown in Figure 6, the user agent can obtain
   the selected Memento by issuing an HTTP GET request against the URI-M
   that was provided in the "Location" header.  The inclusion of the
   "Accept-Datetime" header in this request is not needed but will
   typically occur as the user agent is in datetime negotiation mode.

   GET /?version=20010320133610 HTTP/1.1
   Host: a.example.org
   Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
   Connection: close

              Figure 6: User Agent Requests Selected Memento

   The response has a "200 OK" HTTP status code, and the entity-body of
   the response contains the representation of the selected Memento.
   The use of Memento response headers and links in the response from
   URI-M is as follows:

   o  A "Vary" header that includes an "accept-datetime" value MUST NOT
      be provided.

   o  The response MUST include a "Memento-Datetime" header.  Its value
      expresses the archival datetime of the Memento.

   o  The "Link" header MUST be provided, and it MUST contain at least a
      link with the "original" Relation Type that has the URI-R of the
      Original Resource as Target IRI.  The provision of other links is
      encouraged and is subject to the considerations described in
      Section 2.2.

   The server's response to the request of Figure 6 is shown in
   Figure 7.  Note the provision of the required "original", and the
   recommended "timegate" and "timemap" links.  The former two point to
Top   ToC   RFC7089 - Page 18
   the Original Resource, which acts as its own TimeGate.  The latter
   has "from" and "until" attributes to indicate the temporal interval
   covered by Mementos listed in the linked TimeMap.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:06:51 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
   Link: <http://a.example.org/>; rel="original timegate",
    <http://a.example.org/?version=all&style=timemap>
      ; rel="timemap"; type="application/link-format"
      ; from="Tue, 15 Sep 2000 11:28:26 GMT"
      ; until="Wed, 20 Jan 2010 09:34:33 GMT"
   Content-Length: 23364
   Content-Type: text/html;charset=utf-8
   Connection: close

               Figure 7: Response from URI-M for Pattern 1.1

4.1.2. Pattern 1.2 - URI-R=URI-G; 200-Style Negotiation; Distinct URI-M

In this case, the response to the user agent's request of Figure 4 has a "200 OK" HTTP status code, and the "Content-Location" header conveys the URI-M of the selected Memento. The use of Memento response headers and links in the response from URI-R=URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST include a "Memento-Datetime" header. Its value expresses the archival datetime of the selected Memento. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2. The server's response to the request of Figure 4 is shown in Figure 8. Note the provision of optional "memento" links pointing at the oldest and most recent Memento for the Original Resource known to the responding server.
Top   ToC   RFC7089 - Page 19
   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:06:50 GMT
   Server: Apache
   Vary: accept-datetime
   Content-Location:
    http://a.example.org/?version=20010320133610
   Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
   Link: <http://a.example.org/>; rel="original timegate",
    <http://a.example.org/?version=20000915112826>
    ; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT",
    <http://a.example.org/?version=20100120093433>
    ; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT",
    <http://a.example.org/?version=all&style=timemap>
    ; rel="timemap"; type="application/link-format"
   Content-Length: 23364
   Content-Type: text/html;charset=utf-8
   Connection: close

            Figure 8: Response from URI-R=URI-G for Pattern 1.2

   In a subsequent request, which is the same as Figure 4 but with HTTP
   GET instead of HEAD, the user agent can obtain the representation of
   the selected Memento.  It will be provided as the entity-body of a
   response that has the same Memento headers as in Figure 8.

4.1.3. Pattern 1.3 - URI-R=URI-G; 200-Style Negotiation; No Distinct URI-M

In this case, the response to the user agent's request of Figure 4 has a "200 OK" HTTP status code, and it does not contain a "Content- Location" nor a "Location" header as there is no URI-M of the selected Memento to convey. The use of Memento response headers and links in the response from URI-R=URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST include a "Memento-Datetime" header. Its value expresses the archival datetime of the selected Memento. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2.
Top   ToC   RFC7089 - Page 20
   The server's response to the request of Figure 4 is shown in
   Figure 9.  The recommended "timemap" and "timegate" links are
   included in addition to the mandatory "original" link.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:06:50 GMT
   Server: Apache
   Vary: accept-datetime
   Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT
   Link: <http://a.example.org/>; rel="original timegate",
    <http://a.example.org/?version=all&style=timemap>
      ; rel="timemap"; type="application/link-format"
   Content-Length: 23364
   Content-Type: text/html;charset=utf-8
   Connection: close

            Figure 9: Response from URI-R=URI-G for Pattern 1.3

   In a subsequent request, which is the same as Figure 4 but with HTTP
   GET instead of HEAD, the user agent can obtain the representation of
   the selected Memento.  It will be provided as the entity-body of a
   response that has the same Memento headers as in Figure 9.

4.2. Pattern 2 - A Remote Resource Acts as a TimeGate for the Original Resource

In this implementation pattern, the Original Resource does not act as its own TimeGate, which means that URI-R and URI-G are different. This pattern is typically implemented by servers for which the history of their resources is recorded in remote systems such as Web archives and transactional archives [Fitch]. But servers that maintain their own history, such as content management systems and version control systems, may also implement this pattern, for example, to distribute the load involved in responding to requests for current and prior representations of resources between different servers. This pattern is summarized in the below table and is detailed in the remainder of this section. Three cases exist that differ regarding the negotiation style that is used by the remote TimeGate and regarding the existence of a URI-M for Mementos that is distinct from the URI-G of the TimeGate.
Top   ToC   RFC7089 - Page 21
   +-------------------+------------+----------+---------+-------------+
   |      Pattern      |  Original  | TimeGate | Memento | Negotiation |
   |                   |  Resource  |          |         |    Style    |
   +-------------------+------------+----------+---------+-------------+
   |    Pattern 2.1    |    URI-R   |   URI-G  |  URI-M  |     302     |
   |  (Section 4.2.1)  |            |          |         |             |
   |    Pattern 2.2    |    URI-R   |   URI-G  |  URI-M  |     200     |
   |  (Section 4.2.2)  |            |          |         |             |
   |    Pattern 2.3    |    URI-R   |   URI-G  |  URI-G  |     200     |
   |  (Section 4.2.3)  |            |          |         |             |
   +-------------------+------------+----------+---------+-------------+

                            Table 2: Pattern 2

   The response by the Original Resource to the request shown in
   Figure 4 is the same for all three cases.  The use of headers and
   links in the response from URI-R is as follows:

   o  A "Vary" header that includes an "accept-datetime" value MUST NOT
      be provided.

   o  The response MUST NOT contain a "Memento-Datetime" header.

   o  The "Link" header SHOULD be provided.  It MUST NOT include a link
      with an "original" Relation Type.  If a preferred TimeGate is
      associated with the Original Resource, then it MUST include a link
      with a "timegate" Relation Type that has the URI-G of the TimeGate
      as Target IRI.  If a preferred TimeMap is associated with the
      Original Resource, then it SHOULD include a link with a "timemap"
      Relation Type that has the URI-T of the TimeGate as Target IRI.
      Multiple "timegate" and "timemap" links can be provided to
      accommodate situations in which the server is aware of multiple
      TimeGates or TimeMaps for the Original Resource.

   Figure 10 shows such a response.  Note the absence of an "original"
   link as the responding resource is neither a TimeGate nor a Memento.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:02:12 GMT
   Server: Apache
   Link: <http://arxiv.example.net/timegate/http://a.example.org/>
      ; rel="timegate"
   Content-Length: 255
   Connection: close
   Content-Type: text/html; charset=iso-8859-1

            Figure 10: Response from URI-R<>URI-G for Pattern 2
Top   ToC   RFC7089 - Page 22
   Once a user agent has obtained the URI-G of a remote TimeGate for the
   Original Resource, it can engage in datetime negotiation with that
   TimeGate.  Figure 11 shows the request issued against the TimeGate,
   whereas Sections 4.2.1 through 4.2.3 detail the responses for various
   TimeGate implementation patterns.

   HEAD /timegate/http://a.example.org/ HTTP/1.1
   Host: arxiv.example.net
   Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
   Connection: close

           Figure 11: User Agent Engages in Datetime Negotiation
                           with Remote TimeGate

4.2.1. Pattern 2.1 - URI-R<>URI-G; 302-Style Negotiation; Distinct URI-M

In case the TimeGate uses a 302 negotiation style, the response to the user agent's request of Figure 11 has a "302 Found" HTTP status code, and the "Location" header conveys the URI-M of the selected Memento. The use of Memento response headers and links in the response from URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST NOT contain a "Memento-Datetime" header. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2. The server's response to the request of Figure 11 is shown in Figure 12. It contains the mandatory "original" link that points back to the Original Resource associated with this TimeGate, and it shows the recommended "timemap" link that includes "from" and "until" attributes.
Top   ToC   RFC7089 - Page 23
   HTTP/1.1 302 Found
   Date: Thu, 21 Jan 2010 00:02:14 GMT
   Server: Apache
   Vary: accept-datetime
   Location:
    http://arxiv.example.net/web/20010321203610/http://a.example.org/
   Link: <http://a.example.org/>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org/>
      ; rel="timemap"; type="application/link-format"
      ; from="Tue, 15 Sep 2000 11:28:26 GMT"
      ; until="Wed, 20 Jan 2010 09:34:33 GMT"
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

           Figure 12: Response from URI-G<>URI-R for Pattern 2.1

   In a subsequent HTTP GET request, shown in Figure 13, the user agent
   can obtain the selected Memento by issuing an HTTP GET request
   against the URI-M that was provided in the "Location" header.  The
   inclusion of the "Accept-Datetime" header in this request is not
   needed but will typically occur as the user agent is in datetime
   negotiation mode.

   GET /web/20010321203610/http://a.example.org/ HTTP/1.1
   Host: arxiv.example.net/
   Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT
   Connection: close

              Figure 13: User Agent Requests Selected Memento

   The response has a "200 OK" HTTP status code.  The use of Memento
   response headers and links in the response from URI-M is as follows:

   o  A "Vary" header that includes an "accept-datetime" value MUST NOT
      be provided.

   o  The response MUST include a "Memento-Datetime" header.  Its value
      expresses the archival datetime of the Memento.

   o  The "Link" header MUST be provided, and it MUST contain at least a
      link with the "original" Relation Type that has the URI-R of the
      Original Resource as Target IRI.  The provision of other links is
      encouraged and is subject to the considerations described in
      Section 2.2.
Top   ToC   RFC7089 - Page 24
   The server's response to the request of Figure 13 is shown in
   Figure 14.  Note the provision of the recommended "timegate" and
   "timemap" links.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:02:15 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
   Link: <http://a.example.org/>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org/>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org/>
      ; rel="timegate"
   Content-Length: 25532
   Content-Type: text/html;charset=utf-8
   Connection: close

              Figure 14: Response from URI-M for Pattern 2.1

4.2.2. Pattern 2.2 - URI-R<>URI-G; 200-Style Negotiation; Distinct URI-M

In case the TimeGate uses a 200 negotiation style, and each Memento has a distinct URI-M, the response to the user agent's request of Figure 11 has a "200 OK" HTTP status code, and the "Content-Location" header conveys the URI-M of the selected Memento. The use of Memento response headers and links in the response from URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST include a "Memento-Datetime" header. Its value expresses the archival datetime of the Memento. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2. The server's response to the request of Figure 11 is shown in Figure 15.
Top   ToC   RFC7089 - Page 25
   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Vary: accept-datetime
   Content-Location:
    http://arxiv.example.net/web/20010321203610/http://a.example.org/
   Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
   Link: <http://a.example.org/>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org/>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org/>
      ; rel="timegate"
   Content-Length: 25532
   Content-Type: text/html;charset=utf-8
   Connection: close

           Figure 15: Response from URI-G<>URI-R for Pattern 2.2

   In a subsequent request, which is the same as Figure 11 but with HTTP
   GET instead of HEAD, the user agent can obtain the representation of
   the selected Memento.  It will be provided as the entity-body of a
   response that has the same Memento headers as Figure 15.

4.2.3. Pattern 2.3 - URI-R<>URI-G; 200-Style Negotiation; No Distinct URI-M

In case the TimeGate uses a 200 negotiation style, but Mementos have no distinct URIs, the response to the user agent's request of Figure 11 has a "200 OK" HTTP status code, and it does not contain a "Content-Location" nor "Location" header as there is no URI-M of the selected Memento to convey. The use of Memento response headers and links in the response from URI-G is as follows: o The "Vary" header MUST be provided, and it MUST include the "accept-datetime" value. o The response MUST include a "Memento-Datetime" header. Its value expresses the archival datetime of the Memento. o The "Link" header MUST be provided, and it MUST contain at least a link with the "original" Relation Type that has the URI-R of the Original Resource as Target IRI. The provision of other links is encouraged and is subject to the considerations described in Section 2.2.
Top   ToC   RFC7089 - Page 26
   The server's response to the request of Figure 11 is shown in
   Figure 16.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Vary: accept-datetime
   Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
   Link: <http://a.example.org/>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org/>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org/>
      ; rel="timegate"
   Content-Length: 25532
   Content-Type: text/html;charset=utf-8
   Connection: close

           Figure 16: Response from URI-G<>URI-R for Pattern 2.3

   In a subsequent request, which is the same as Figure 11 but with HTTP
   GET instead of HEAD, the user agent can obtain the representation of
   the selected Memento.  It will be provided as the entity-body of a
   response that has the same Memento headers as Figure 16.

4.3. Pattern 3 - The Original Resource is a Fixed Resource

This pattern does not involve datetime negotiation with a TimeGate, but it can be implemented for Original Resources that never change state or do not change anymore past a certain point in their existence, meaning that URI-R and URI-M coincide either from the outset or starting at some point in time. This pattern is summarized in the below table. Examples are tweets or stable media resources on news sites. +----------+----------------+----------+---------+------------------+ | Pattern | Original | TimeGate | Memento | Negotiation | | | Resource | | | Style | +----------+----------------+----------+---------+------------------+ | Pattern | URI-R | - | URI-R | - | | 3 | | | | | +----------+----------------+----------+---------+------------------+ Table 3: Pattern 3
Top   ToC   RFC7089 - Page 27
   Servers that host such resources can support the Memento framework by
   treating the stable resource (FixedResource as per
   [W3C.gen-ont-20090420]) as a Memento.  The use of Memento response
   headers and links in responses from such a stable resource is as
   follows:

   o  A "Vary" header that includes an "accept-datetime" value MUST NOT
      be provided.

   o  The response MUST include a "Memento-Datetime" header.  Its value
      expresses the datetime at which the resource became stable.
      Providing this value includes a promise that the resource has not
      changed since this datetime and will not change anymore beyond it.

   o  The "Link" header MUST be provided and MUST have a link with the
      "original" Relation Type that has the URI-R of the stable resource
      itself as Target IRI.

   Figure 17 shows a response to an HTTP HEAD request for the resource
   with URI-R http://a.example.org/ that has been stable since March 20,
   2009.

   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT
   Link: <http://a.example.org/>; rel="original"
   Content-Length: 875
   Content-Type: text/html;charset=utf-8
   Connection: close

            Figure 17: Response from URI-R=URI-M for Pattern 3

4.4. Pattern 4 - Mementos without a TimeGate

Cases may occur in which a server hosts Mementos but does not expose a TimeGate for them. This can, for example, be the case if the server's Mementos result from taking a snapshot of the state of a set of Original Resources from another server as it is being retired. As a result, only a single Memento per Original Resource is hosted, making the introduction of a TimeGate unnecessary. But it may also be the case for servers that host multiple Mementos for an Original Resource but consider exposing TimeGates too expensive. In this case, URI-R and URI-M are distinct, but a TimeGate is absent. This case is summarized in the below table.
Top   ToC   RFC7089 - Page 28
   +----------+----------------+----------+---------+------------------+
   |  Pattern |    Original    | TimeGate | Memento |    Negotiation   |
   |          |    Resource    |          |         |       Style      |
   +----------+----------------+----------+---------+------------------+
   |  Pattern |      URI-R     |     -    |  URI-M  |         -        |
   |     4    |                |          |         |                  |
   +----------+----------------+----------+---------+------------------+

                            Table 4: Pattern 4

   Servers that host such Mementos without TimeGates can still support
   the Memento framework by providing the appropriate Memento headers
   and links.  Their use is as follows for a response from URI-M:

   o  A "Vary" header that includes an "accept-datetime" value MUST NOT
      be provided.

   o  The response MUST include a "Memento-Datetime" header.  Its value
      expresses the archival datetime of the Memento.

   o  The "Link" header MUST be provided, and it MUST have a link with
      the "original" Relation Type that has the URI-R of the associated
      Original Resource as Target IRI.  The provision of other links is
      encouraged and is subject to the considerations described in
      Section 2.2.

   Figure 18 shows a response to an HTTP HEAD request for the Memento
   with URI-M
   http://arxiv.example.net/web/20010321203610/http://a.example.org/.
   Note the use of links: three links have the URI-M of the Memento as
   Target IRI and have respective Relation Types "memento", "first", and
   "last".  This combination indicates that this is the only Memento for
   the Original Resource with Target IRI provided by the "original" link
   (http://a.example.org/) of which the server is aware.  Note also that
   such a response does not imply that there is no server whatsoever
   that exposes a TimeGate; it merely means that the responding server
   neither provides nor is aware of the location of a TimeGate.
Top   ToC   RFC7089 - Page 29
   HTTP/1.1 200 OK
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT
   Link: <http://a.example.org/>; rel="original",
    <http://arxiv.example.net/web/20010321203610/http://a.example.org/>
      ; rel="first last memento"
      ; datetime="Wed, 21 Mar 2001 20:36:10 GMT"
   Content-Length: 25532
   Content-Type: text/html;charset=utf-8
   Connection: close

            Figure 18: Response from URI-M<>URI-R for Pattern 4

4.5. Special Cases

4.5.1. Original Resource Provides No "timegate" Link

Cases exist in which the response from the Original Resource does not contain a "timegate" link, including: o The Original Resource's server does not support the Memento framework; o The Original Resource no longer exists, and the responding server is not aware of its prior existence; o The server that hosted the Original Resource no longer exists. In all these cases, the user agent should attempt to determine an appropriate TimeGate for the Original Resource, either automatically or interactively supported by the user.

4.5.2. Server Exists but Original Resource No Longer Does

Cases exist in which the server knows that an Original Resource used to exist, but no longer provides a current representation. If there is a preferred TimeGate for such a discontinued Original Resource, then the server MUST include a "timegate" link in responses to requests for it. This may allow access to Mementos for the Original Resource even if it no longer exists. A server's response to a request for the discontinued resource http://a.example.org/pic is illustrated in Figure 19.
Top   ToC   RFC7089 - Page 30
   HTTP/1.1 404 Not Found
   Date: Thu, 21 Jan 2010 00:02:12 GMT
   Server: Apache
   Link:
    <http://arxiv.example.net/timegate/http://a.example.org/pic>
     ; rel="timegate"
   Content-Length: 255
   Content-Type: text/html; charset=iso-8909-1
   Connection: close

    Figure 19: Response from an Original Resource That No Longer Exists

4.5.3. Issues with Accept-Datetime

The following special cases may occur regarding the "Accept-Datetime" header when a user agent issues a request against a TimeGate: o If the value of the "Accept-Datetime" is either earlier than the datetime of the first Memento or later than the datetime of the most recent Memento known to the TimeGate, the first or most recent Memento MUST be selected, respectively. o If the value of the "Accept-Datetime" does not conform to the rfc1123-date construction rule of the BNF in Figure 1, the response MUST have a "400 Bad Request" HTTP status code. o If a user agent issues a request against a TimeGate and fails to include an "Accept-Datetime" request header, the most recent Memento SHOULD be selected. In all cases, the use of headers and links in responses is as described for TimeGates in the respective scenarios.

4.5.4. Memento of a 3XX Response

Cases exist in which HTTP responses with 3XX status codes are archived. For example, crawl-based Web archives commonly archive responses with HTTP status codes "301 Moved Permanently" and "302 Found", whereas Linked Data archives hold on to "303 See Other" responses. If the Memento requested by the user agent is an archived version of an HTTP response with a 3XX status code, the server's response MUST have the same 3XX HTTP status code. The use of other Memento headers is as described for Mementos in the respective scenarios.
Top   ToC   RFC7089 - Page 31
   The user agent's handling of an HTTP response with a 3XX status code
   is not affected by the presence of a "Memento-Datetime" header.  The
   user agent MUST behave in the same manner as it does with HTTP
   responses with a 3XX status code that do not have a "Memento-
   Datetime" header.

   However, the user agent MUST be aware that the URI that was selected
   from the "Location" header of an HTTP response with a 3XX status code
   might not be that of a Memento but rather of an Original Resource.
   In the latter case, it SHOULD proceed by looking for a Memento of the
   selected Original Resource.

   For example, Figure 20 shows the response to an HTTP GET request for
   http://a.example.org issued on April 11, 2008.  This response is
   archived as a Memento of http://a.example.org that has as URI-M
   http://arxiv.example.net/web/20080411000650/http://a.example.org.
   The response to an HTTP GET on this URI-M is shown in Figure 21.  It
   is a replay of the original response with "Memento-Datetime" and
   "Link" headers added, to allow a user agent to understand the
   response is a Memento.  In Figure 21, the value of the "Location"
   header is the same as in the original response; it identifies an
   Original Resource.  The user agent proceeds with finding a Memento
   for this Original Resource.  Web archives sometimes overwrite the
   value that was originally provided in the "Location" header in order
   to point at a Memento they hold of the resource to which the redirect
   originally led.  This is shown in Figure 22.  In this case, the user
   agent may decide it found an appropriate Memento.

   HTTP/1.1 301 Moved Permanently
   Date: Fri, 11 Apr 2008 00:06:50 GMT
   Server: Apache
   Location: http://b.example.org
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

                     Figure 20: Response Is a Redirect
Top   ToC   RFC7089 - Page 32
   HTTP/1.1 301 Moved Permanently
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
   Location: http://b.example.org
   Link: <http://a.example.org>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org>
      ; rel="timegate"
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

           Figure 21: Response is a Memento of a Redirect; Leads
                          to an Original Resource

   HTTP/1.1 301 Moved Permanently
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
   Location:
    http://arxiv.example.net/web/20080411000655/http://b.example.org
   Link: <http://a.example.org>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org>
      ; rel="timegate"
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

    Figure 22: Response is a Memento of a Redirect; Leads to a Memento

4.5.5. Memento of Responses with 4XX or 5XX HTTP Status Codes

Cases exist in which responses with 4XX and 5XX HTTP status codes are archived. If the Memento requested by the user agent is an archived version of such an HTTP response, the server's response MUST have the same 4XX or 5XX HTTP status code. The use of headers and links in responses is as described for Mementos in the respective scenarios. For example, Figure 23 shows the 404 response to an HTTP GET request for http://a.example.org issued on April 11, 2008. This response is archived as a Memento of http://a.example.org that has as URI-M http://arxiv.example.net/web/20080411000650/http://a.example.org. The response to an HTTP HEAD on this URI-M is shown in Figure 24. It
Top   ToC   RFC7089 - Page 33
   is a replay of the original response with "Memento-Datetime" and
   "Link" headers added, to allow a user agent to understand the
   response is a Memento.

   HTTP/1.1 404 Not Found
   Date: Fri, 11 Apr 2008 00:06:50 GMT
   Server: Apache
   Content-Length: 255
   Content-Type: text/plain; charset=UTF-8
   Connection: close

                       Figure 23: Response Is a 404

   HTTP/1.1 404 Not Found
   Date: Thu, 21 Jan 2010 00:09:40 GMT
   Server: Apache-Coyote/1.1
   Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT
   Link: <http://a.example.org>; rel="original",
    <http://arxiv.example.net/timemap/http://a.example.org>
      ; rel="timemap"; type="application/link-format",
    <http://arxiv.example.net/timegate/http://a.example.org>
      ; rel="timegate"
   Content-Length: 255
   Content-Type: text/plain; charset=UTF-8
   Connection: close

                 Figure 24: Response Is a Memento of a 404

4.5.6. Sticky "Memento-Datetime" and "original" Link for Mementos

A response to an HTTP HEAD/GET request issued against a Memento: o Includes a "Memento-Datetime" header that entails a promise that the response is archived, frozen in time. The value of the header expresses the archival datetime of the Memento. o Includes a link in the HTTP "Link" header with an "original" Relation Type that unambiguously points to the Original Resource associated with the Memento. The Target IRI of the link is the URI-R of that Original Resource. Both the "Memento-Datetime" header and the "original" link MUST be "sticky" in the following ways: o The server that originally assigns them MUST retain them in all responses to HTTP requests (with or without an "Accept-Datetime" request header) that occur against the Memento after the time of
Top   ToC   RFC7089 - Page 34
      their original assignment, and the server MUST NOT change the
      value of the "Memento-Datetime" header nor the Target IRI of the
      "original" link.

   o  Applications that mirror Mementos at a different URI MUST retain
      them and MUST NOT change them unless mirroring involves a
      meaningful state change.  This allows, among others, duplicating a
      Web archive at a new location while preserving the value of the
      "Memento-Datetime" header and the link with the "original"
      Relation Type for the archived resources.  For example, when
      mirroring, the "Last-Modified" header will be updated to reflect
      the time of mirroring at the new URI, whereas the value for
      "Memento-Datetime" will be maintained.

4.5.7. Intermediate Resources

An intermediate resource is a resource that issues a redirect to a TimeGate, to a Memento, or to another intermediate resource, and thus plays an active role in the Memento infrastructure. Intermediate resources commonly exist in Web archives on the path from a TimeGate to an appropriate Memento. A response of an intermediate resource has an HTTP status code indicative of HTTP redirection (e.g., 302) and uses Memento headers and links that allow user agents to recognize that the resource plays a role in the Memento framework: o A "Vary" header that includes an "accept-datetime" value MUST NOT be provided. o The response MUST NOT include a "Memento-Datetime" header. o The "Link" header MUST be provided, and it MUST have a link with the "original" Relation Type that has the URI-R of the associated Original Resource as Target IRI. Links with "timegate", "timemap", and "memento" Relation Types are OPTIONAL and, if provided, MUST pertain to the Original Resource for which the user agent is trying to obtain a Memento. A user agent MUST follow a redirection provided by an intermediate resource; multiple such redirections can be chained. Consider the case where a user agent follows the "timegate" link provided in Figure 10 and engages in datetime negotiation with the assumed TimeGate in the manner shown in Figure 11. But instead of receiving a response as shown in Figure 12, it receives the one shown below in Figure 25. Such a response is unambiguously recognizable as coming from an intermediate resource.
Top   ToC   RFC7089 - Page 35
   HTTP/1.1 302 Found
   Date: Thu, 21 Jan 2010 00:06:50 GMT
   Server: Apache
   Location:
    http://arxiv.example.net/new-timegate/http://a.example.org/
   Link: <http://a.example.org>; rel="original"
   Content-Length: 0
   Content-Type: text/plain; charset=UTF-8
   Connection: close

          Figure 25: Redirecting Resource Redirects to a TimeGate

4.5.8. Resources Excluded from Datetime Negotiation

When delivering a Memento to a user agent, a Web archive commonly enhances that Memento's archived content, for example, by including a banner that provides branding and highlights the archival status of the Memento. The resources that are involved in providing such system-specific functionality, many times JavaScript or images, must be used in their current state. A server that generally supports datetime negotiation should make resources that need to be excluded from datetime negotiation recognizable. Doing so allows a user agent to refrain from attempting to access a Memento for them. In order to achieve this, the server SHOULD include a special-purpose link in the HTTP "Link" header when responding to an HTTP HEAD/GET request to a resource excluded from datetime negotiation. This link has "http://mementoweb.org/terms/donotnegotiate" as Target IRI and "type", defined in [RFC6903], as the value of the "rel" attribute. Other Memento headers as defined in Section 2.1 SHOULD NOT be provided. Figure 26 shows the response to an HTTP HEAD request from a resource excluded from datetime negotiation. HTTP/1.1 200 OK Date: Thu, 21 Jan 2010 00:09:40 GMT Server: Apache-Coyote/1.1 Link: <http://mementoweb.org/terms/donotnegotiate>; rel="type" Content-Length: 238 Content-Type: application/javascript; charset=UTF-8 Connection: close Figure 26: Response to an HTTP HEAD Request from a Resource Excluded from Datetime Negotiation


(next page on part 3)

Next Section