Changeset 2539


Ignore:
Timestamp:
06/01/14 23:53:08 (6 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:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2538 r2539  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 8, 2014";
     450       content: "Expires July 10, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-04">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-06">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <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.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 4, 2014</td>
     523               <td class="right">January 6, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 8, 2014</td>
     526               <td class="left">Expires: July 10, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 8, 2014.</p>
     555         <p>This Internet-Draft will expire on July 10, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    841841         </p>
    842842         <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
    843             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
    844             effective request URI, unless those semantics are disabled when they are inconsistent with the request method.
     843            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.
    845844         </p>
    846845      </div>
     
    11941193            </p>
    11951194            <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
    1196                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
    1197                an HTML form.
     1195               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.
    11981196            </p>
    11991197            <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

    r2538 r2539  
    286286   semantics in the request method (<xref target="methods"/>) and a few
    287287   request-modifying header fields (<xref target="request.header.fields"/>).
    288    Resource owners &SHOULD-NOT; include request semantics within a URI,
    289    such as by specifying an action to invoke within the path or query
    290    components of the effective request URI, unless those semantics are
    291    disabled when they are inconsistent with the request method.
     288   If there is a conflict between the method semantics and any semantic
     289   implied by the URI itself, as described in <xref target="safe.methods"/>,
     290   the method semantics take precedence.
    292291</t>
    293292</section>
     
    888887   The purpose of a payload in a request is defined by the method semantics.
    889888   For example, a representation in the payload of a PUT request
    890    (<xref target="PUT"/>) represents the desired state of the <x:ref>target resource</x:ref>
    891    if the request is successfully applied, whereas a representation in the
    892    payload of a POST request (<xref target="POST"/>) represents an anonymous
    893    resource for providing data to be processed, such as the information that
    894    a user entered within an HTML form.
     889   (<xref target="PUT"/>) represents the desired state of the
     890   <x:ref>target resource</x:ref> if the request is successfully applied,
     891   whereas a representation in the payload of a POST request
     892   (<xref target="POST"/>) represents information to be processed by the
     893   target resource.
    895894</t>
    896895<t>
Note: See TracChangeset for help on using the changeset viewer.