Changeset 2539 for draft-ietf-httpbis

Timestamp:

06/01/14 23:53:08 (9 years ago)

Author:

fielding@…

Message:

Reduce the resource owners SHOULD NOT... for action parameters in Resources to a discussion of precedence and forward reference to the MUST discussion under Safe Methods; remove mention of anonymous resources since it is superfluous to and distracting from the discussion of payloads; both in response to Resnick comments, see #532

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (6 diffs)
• p2-semantics.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -448 +448 @@
   }
   @bottom-center {
-       content: "Expires July 8, 2014";
+       content: "Expires July 10, 2014";
   }
   @bottom-right {
@@ -493 +493 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2014-01-04">
+      <meta name="dct.issued" scheme="ISO8601" content="2014-01-06">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -521 +521 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">January 4, 2014</td>
+               <td class="right">January 6, 2014</td>
             </tr>
             <tr>
-               <td class="left">Expires: July 8, 2014</td>
+               <td class="left">Expires: July 10, 2014</td>
                <td class="right"></td>
             </tr>
@@ -553 +553 @@
             in progress”.
          </p>
-         <p>This Internet-Draft will expire on July 8, 2014.</p>
+         <p>This Internet-Draft will expire on July 10, 2014.</p>
       </div>
       <div id="rfc.copyrightnotice">
@@ -841 +841 @@
          </p>
          <p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the
-            request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). Resource owners <em class="bcp14">SHOULD NOT</em> include request semantics within a URI, such as by specifying an action to invoke within the path or query components of the
-            effective request URI, unless those semantics are disabled when they are inconsistent with the request method.
+            request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, the method semantics take precedence.
          </p>
       </div>
@@ -1194 +1193 @@
             </p>
             <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of
-               a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
-               an HTML form.
+               a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
             </p>
             <p id="rfc.section.3.3.p.3">In a response, the payload's purpose is defined by both the request method and the response status code. For example, the

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -286 +286 @@
    semantics in the request method (<xref target="methods"/>) and a few
    request-modifying header fields (<xref target="request.header.fields"/>).
-   Resource owners &SHOULD-NOT; include request semantics within a URI,
-   such as by specifying an action to invoke within the path or query
-   components of the effective request URI, unless those semantics are
-   disabled when they are inconsistent with the request method.
+   If there is a conflict between the method semantics and any semantic
+   implied by the URI itself, as described in <xref target="safe.methods"/>,
+   the method semantics take precedence.
 </t>
 </section>
@@ -888 +887 @@
    The purpose of a payload in a request is defined by the method semantics.
    For example, a representation in the payload of a PUT request
-   (<xref target="PUT"/>) represents the desired state of the <x:ref>target resource</x:ref>
-   if the request is successfully applied, whereas a representation in the
-   payload of a POST request (<xref target="POST"/>) represents an anonymous
-   resource for providing data to be processed, such as the information that
-   a user entered within an HTML form.
+   (<xref target="PUT"/>) represents the desired state of the
+   <x:ref>target resource</x:ref> if the request is successfully applied,
+   whereas a representation in the payload of a POST request
+   (<xref target="POST"/>) represents information to be processed by the
+   target resource.
 </t>
 <t>