HTTP Link and Unlink Methods
draft-snell-link-method-00
| The information below is for an old version of the document |
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2012-10-08
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group J. Snell
Internet-Draft October 8, 2012
Intended status: Informational
Expires: April 11, 2013
HTTP Link and Unlink Methods
draft-snell-link-method-00
Abstract
This specification defines the semantics of the Link and Unlink HTTP
methods.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Snell Expires April 11, 2013 [Page 1]
Internet-Draft HTTP Link and Unlink Methods October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LINK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. UNLINK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Snell Expires April 11, 2013 [Page 2]
Internet-Draft HTTP Link and Unlink Methods October 2012
1. Introduction
This specification updates the HTTP LINK and UNLINK methods
originally defined in [RFC2068]. These were originally defined as
"additional request methods" that were later dropped entirely from
follow-on iterations of the HTTP specification due to previous lack
of interest or use.
TODO: Fill in explanation as to why this is needed.
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in [RFC2119].
2. LINK
The LINK method is used to establish one or more Link relationships
between the existing resource identified by the effective request URI
and other resources. Metadata contained within Link header fields
[RFC5988] provide the information about which other resources are
being linked to the target resource and the type of link being
established. A payload within a LINK request message has no defined
semantics.
The semantics of the LINK method change to a "conditional LINK" if
the request message includes an If-Modified-Since, If-Unmodified-
Since, If-Match, If-None-Match, or If-Range header field
([I-D.ietf-httpbis-p4-conditional]). A conditional LINK requests
that the Link be established only under the circumstances described
by the conditional header field(s).
LINK request messages are idempotent. For any pair of resources,
only a single Link of any given relation type can exist. However,
multiple links of different relation types can be established between
those resources.
LINK request messages are not safe, however, in that establishing a
Link causes an inherent change to the state of the target resource.
The response to a LINK request is cacheable and MAY be used to
satisfy subsequent LINK requests (see [I-D.ietf-httpbis-p6-cache]).
However, caching such responses is not likely to provide any
significant benefit or be supported by existing infrastructure.
A single LINK request message can contain multiple Link header
fields, each of which establishes a separate Link relationship with
the target resource. In such cases, the server MUST accept the
Snell Expires April 11, 2013 [Page 3]
Show full document text