diff --git a/httpbis/draft-snell-link-method-10.txt b/httpbis/draft-snell-link-method-11.txt similarity index 89% rename from httpbis/draft-snell-link-method-10.txt rename to httpbis/draft-snell-link-method-11.txt index 944d215..8b17e58 100644 --- a/httpbis/draft-snell-link-method-10.txt +++ b/httpbis/draft-snell-link-method-11.txt @@ -4,12 +4,12 @@ Individual Submission J. Snell Internet-Draft -Intended status: Standards Track August 1, 2014 -Expires: February 2, 2015 +Intended status: Standards Track October 22, 2014 +Expires: April 25, 2015 HTTP Link and Unlink Methods - draft-snell-link-method-10 + draft-snell-link-method-11 Abstract @@ -31,7 +31,7 @@ Status of This Memo 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 February 2, 2015. + This Internet-Draft will expire on April 25, 2015. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Snell Expires February 2, 2015 [Page 1] +Snell Expires April 25, 2015 [Page 1] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 Table of Contents @@ -109,9 +109,9 @@ Table of Contents -Snell Expires February 2, 2015 [Page 2] +Snell Expires April 25, 2015 [Page 2] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 The target and context IRIs of a Link relationship are determined @@ -165,9 +165,9 @@ Internet-Draft HTTP Link and Unlink Methods August 2014 -Snell Expires February 2, 2015 [Page 3] +Snell Expires April 25, 2015 [Page 3] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 provide the information about the relationships that are to be @@ -221,9 +221,9 @@ Internet-Draft HTTP Link and Unlink Methods August 2014 -Snell Expires February 2, 2015 [Page 4] +Snell Expires April 25, 2015 [Page 4] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 6. Example @@ -277,9 +277,9 @@ Internet-Draft HTTP Link and Unlink Methods August 2014 -Snell Expires February 2, 2015 [Page 5] +Snell Expires April 25, 2015 [Page 5] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 Example 5: Add an existing resource to a collection: @@ -304,6 +304,16 @@ Internet-Draft HTTP Link and Unlink Methods August 2014 Link: ; rel="follow"; anchor="acct:sally@example.org" + Example 8: Using the Link anchor attribute to change the context IRI + using a fragment identifier (in this example, a link with the + relationship type "http://schema.org/knows" is established between + "http://example.org/alice#me" and "http://example.com/bob#me" + + LINK /alice HTTP/1.1 + Host: example.org + Link: ; rel="http://schema.org/knows"; + anchor="#me" + 7. Security Considerations The LINK and UNLINK methods are subject to the same general security @@ -319,25 +329,22 @@ Internet-Draft HTTP Link and Unlink Methods August 2014 registry at (see Section 8.1 of [RFC7231]). - +-------------+------+------------+---------------+ - | Method Name | Safe | Idempotent | Specification | - +-------------+------+------------+---------------+ - | LINK | No | Yes | Section 3 | - | UNLINK | No | Yes | Section 4 | - +-------------+------+------------+---------------+ - - - - -Snell Expires February 2, 2015 [Page 6] +Snell Expires April 25, 2015 [Page 6] -Internet-Draft HTTP Link and Unlink Methods August 2014 +Internet-Draft HTTP Link and Unlink Methods October 2014 + +-------------+------+------------+---------------+ + | Method Name | Safe | Idempotent | Specification | + +-------------+------+------------+---------------+ + | LINK | No | Yes | Section 3 | + | UNLINK | No | Yes | Section 4 | + +-------------+------+------------+---------------+ + 9. References 9.1. Normative References @@ -382,11 +389,4 @@ Author's Address - - - - - - - -Snell Expires February 2, 2015 [Page 7] \ No newline at end of file +Snell Expires April 25, 2015 [Page 7] diff --git a/httpbis/draft-snell-link-method-10.xml b/httpbis/draft-snell-link-method-11.xml similarity index 85% rename from httpbis/draft-snell-link-method-10.xml rename to httpbis/draft-snell-link-method-11.xml index 5a496be..8814298 100644 --- a/httpbis/draft-snell-link-method-10.xml +++ b/httpbis/draft-snell-link-method-11.xml @@ -1,5 +1,5 @@ - - + @@ -7,134 +7,134 @@ ]> - - - - - - - - +<?rfc toc="yes"?> +<?rfc strict="yes"?> +<?rfc symrefs="yes" ?> +<?rfc sortrefs="yes"?> +<?rfc compact="yes"?> +<rfc category="std" ipr="trust200811" docName="draft-snell-link-method-11"> + <front> + <title abbrev="HTTP Link and Unlink Methods"> HTTP Link and Unlink Methods - - - -
- jasnell@gmail.com -
- - - - - Applications - Individual Submission - I-D + + + +
+ jasnell@gmail.com +
+ + + + + Applications + Individual Submission + I-D http link unlink method - - + + This specification defines the semantics of the LINK and UNLINK HTTP methods. - - - - - - + + -
+ + + + +
This specification updates the HTTP LINK and UNLINK methods originally defined in . - + - In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", - "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + 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 . - + + +
-
-
- + - The LINK and UNLINK methods are used to manage relationships + The LINK and UNLINK methods are used to manage relationships between resources. Those relationships are defined using the Link - model established in Section 3 of . For - every individual link, the context IRI, link relation type, target - IRI, and optional collection of target attributes MUST be considered; - that is, for any effective request URI, there can exist at most one Link - relationship between any context and target IRI pairing with any given + model established in Section 3 of . For + every individual link, the context IRI, link relation type, target + IRI, and optional collection of target attributes MUST be considered; + that is, for any effective request URI, there can exist at most one Link + relationship between any context and target IRI pairing with any given combination of link relation type and target attributes. - + - Within LINK and UNLINK requests, a Link - header field is used to describe a Link relationship to be + Within LINK and UNLINK requests, a Link + header field is used to describe a Link relationship to be managed. Any single LINK or UNLINK request MAY contain multiple Link header fields, each of which describes a separate relationship between - a context IRI and target IRI. When a LINK request contains multiple + a context IRI and target IRI. When a LINK request contains multiple Link header fields, the server MUST create all of the specified relationships or not create any of them. Likewise, when an UNLINK request contains - multiple Link header fields, the server MUST either remove all the + multiple Link header fields, the server MUST either remove all the specified relationship or not remove any of them. - + - The target and context IRIs of a Link relationship are determined - following the requirements specified in Sections 5.1 and 5.2 of + The target and context IRIs of a Link relationship are determined + following the requirements specified in Sections 5.1 and 5.2 of . - + When determining whether or not a relationship already exists between - a context IRI and target IRI, implementations will need to compare the + a context IRI and target IRI, implementations will need to compare the given IRIs with other, previously established relationships. To do so, - the implementation MUST first resolve the IRIs as required by - and then compare on a case-sensitive, - character-by-character basis. For instance, the IRIs - "http://example.org/foo" and "http://example.org/Foo" MUST NOT be + the implementation MUST first resolve the IRIs as required by + and then compare on a case-sensitive, + character-by-character basis. For instance, the IRIs + "http://example.org/foo" and "http://example.org/Foo" MUST NOT be considered to be equivalent. - +
- +
- + The LINK method is used to establish one or more relationships between - the resource identified by the effective request URI and one or more other + the resource identified by the effective request URI and one or more other resources. Metadata contained within Link header fields - provide information about the relationships being established. A payload + provide information about the relationships being established. A payload within a LINK request has no defined semantics. - + - LINK requests are idempotent but are not safe. Establishing a - relationship causes an inherent change to the state of the target + LINK requests are idempotent but are not safe. Establishing a + relationship causes an inherent change to the state of the target resource. - + Any successful response (using a 2xx status code) to a LINK request indicates that all of the Link relationships described in the request - have been established. No specific 2xx status code is required. + have been established. No specific 2xx status code is required. Responses to LINK requests SHOULD contain one Link header field for each Link relationship established by the LINK request. - + - Responses to LINK requests are not cacheable. If a LINK request passes - through a cache that has one or more stored responses for the effective - request URI, those stored responses will be invalidated (see Section 6 + Responses to LINK requests are not cacheable. If a LINK request passes + through a cache that has one or more stored responses for the effective + request URI, those stored responses will be invalidated (see Section 6 of ). @@ -142,41 +142,41 @@ 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 - (). A conditional - LINK requests that the relationship be established only under the + (). A conditional + LINK requests that the relationship be established only under the circumstances described by the conditional header field(s). - +
- +
- + The UNLINK method is used to remove one or more relationships - between the resource identified by the effective request URI and - other resources. Metadata contained within Link header fields - provide the information about the - relationships that are to be removed. A payload within an UNLINK request + between the resource identified by the effective request URI and + other resources. Metadata contained within Link header fields + provide the information about the + relationships that are to be removed. A payload within an UNLINK request has no defined semantics. - + - UNLINK request messages are idempotent but are not safe. Removing a - relationship causes an inherent change to the state of the target + UNLINK request messages are idempotent but are not safe. Removing a + relationship causes an inherent change to the state of the target resource. - + Responses to UNLINK requests SHOULD contain one Link header field for each Link relationship removed by the UNLINK request. - + Any successful response (using a 2xx status code) to an UNLINK request indicates that all of the Link relationships described in the request - have been removed. No specific 2xx status code is required. + have been removed. No specific 2xx status code is required. - + Responses to UNLINK requests are not cacheable. If an UNLINK request passes through a cache that has one or more stored responses @@ -188,42 +188,42 @@ The semantics of the UNLINK method change to a "conditional UNLINK" if the request message includes an If-Modified-Since, If-Unmodified- Since, If-Match, If-None-Match, or If-Range header field - (). A conditional - UNLINK requests that the relationship be established only under the + (). A conditional + UNLINK requests that the relationship be established only under the circumstances described by the conditional header field(s).
- + - The use of the LINK and UNLINK request methods to manage relationships - between resources has no direct bearing on the use or appearance of Link - header fields within any other HTTP request or response message - involving the same effective request URI. Nor do the methods have any + The use of the LINK and UNLINK request methods to manage relationships + between resources has no direct bearing on the use or appearance of Link + header fields within any other HTTP request or response message + involving the same effective request URI. Nor do the methods have any direct normative impact on the use of link-like structures within the resource representations returned by a server for any particular resource. - + - Whether and how to represent relationships managed using LINK + Whether and how to represent relationships managed using LINK and UNLINK is left solely at the discretion of the server implementation. - + - This specification does not define a means of discovering or - enumerating the relationships that have been established using the + This specification does not define a means of discovering or + enumerating the relationships that have been established using the LINK request method. - +
- + There exists a broad range of possible use cases for the LINK and UNLINK methods. The examples that follow illustrate a subset of those cases. - +
Example 1: Creating two separate links between an image and the profiles of two people associated with the image:; rel="tag" Link: ; rel="tag" ]]>
- +
Possible response:; rel="tag" Link: ; rel="tag" ]]>
- +
Example 2: Removing an existing Link relationship between two resources:; rel="tag" ]]>
- +
Possible response:; rel="tag" ]]>
- +
Example 3: Establish a "pingback" or "trackback" style link to a blog entry about an article; rel="mention" ]]>
- +
Example 4: Establish a link between two semantically related resources:; rel="describedBy" ]]>
- +
Example 5: Add an existing resource to a collection:; rel="item" ]]>
- -
Example 6: Link one resource to another that monitors its + +
Example 6: Link one resource to another that monitors its current state (e.g. pub/sub); rel="monitor" ]]>
- -
Example 7: Using the Link anchor attribute to change the - context IRI (in this example, a link relationship is established between + +
Example 7: Using the Link anchor attribute to change the + context IRI (in this example, a link relationship is established between the IRIs "acct:joe@example.org" and "acct:sally@example.org") ; rel="follow"; + Link: ; rel="follow"; anchor="acct:sally@example.org" ]]>
- + +
Example 8: Using the Link anchor attribute to change the + context IRI using a fragment identifier (in this example, a link with the + relationship type "http://schema.org/knows" is established between + "http://example.org/alice#me" and "http://example.com/bob#me" + ; rel="http://schema.org/knows"; + anchor="#me" + ]]>
+
- The LINK and UNLINK methods are subject to the same general security - considerations as all HTTP methods as described in + The LINK and UNLINK methods are subject to the same general security + considerations as all HTTP methods as described in . - + - Because the LINK and UNLINK methods cause changes to a resource's state, - the server is responsible for determining the client's authorization to + Because the LINK and UNLINK methods cause changes to a resource's state, + the server is responsible for determining the client's authorization to make such changes.
- + - IANA is requested to add the LINK and UNLINK methods to the + IANA is requested to add the LINK and UNLINK methods to the permanent registry at <http://www.iana.org/assignments/http-methods> (see Section 8.1 of ). - + Method Name Safe Idempotent Specification - + LINK No Yes - + UNLINK No Yes - + - +
- + - + &rfc2119; &rfc5988; &part2; @@ -344,5 +355,5 @@ &rfc2068; - - \ No newline at end of file + +