Changeset 1926 for draft-ietf-httpbis

Timestamp:

01/10/12 10:17:51 (11 years ago)

Author:

fielding@…

Message:

(editorial) tweak intro to better match document order

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (1 diff)

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

@@ -842 +842 @@
       </ul>
       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
-      <p id="rfc.section.1.p.1">Each HTTP message is either a request or a response. A server listens on a connection for a request, parses each message received,
-         interprets the message semantics in relation to the identified request target, and responds to that request with one or more
-         response messages. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
-      </p>
-      <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with resources regardless of their type, nature, or implementation. HTTP
-         semantics includes the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;5</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;6</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;7</a>), and other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;8</a>).
-      </p>
-      <p id="rfc.section.1.p.3"><span id="rfc.iref.c.1"></span> In addition, this document defines the payload of messages (a.k.a., content), the associated metadata header fields that define
-         how the payload is intended to be interpreted by a recipient, the request header fields that might influence content selection,
-         and the various selection algorithms that are collectively referred to as "<dfn>content negotiation</dfn>".
+      <p id="rfc.section.1.p.1">Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a
+         request, parses each message received, interprets the message semantics in relation to the identified request target, and
+         responds to that request with one or more response messages. A client constructs request messages to communicate specific
+         intentions, and examines received responses to see if the intentions were carried out and determine how to interpret the results.
+         This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
+      </p>
+      <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resource" title="Resource">Section&nbsp;2</a>), regardless of its type, nature, or implementation, and for transferring content in message payloads in the form of a representation
+         (<a href="#representation" title="Representation">Section&nbsp;3</a>).
+      </p>
+      <p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;5</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;6</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;7</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;8</a>).
+      </p>
+      <p id="rfc.section.1.p.4"><span id="rfc.iref.c.1"></span> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient,
+         the request header fields that might influence content selection, and the various selection algorithms that are collectively
+         referred to as "<dfn>content negotiation</dfn>" (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).
       </p>
       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>

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

@@ -193 +193 @@
 <section title="Introduction" anchor="introduction">
 <t>
-   Each HTTP message is either a request or a response. A server listens on a
-   connection for a request, parses each message received, interprets the
-   message semantics in relation to the identified request target, and
-   responds to that request with one or more response messages.
+   Each Hypertext Transfer Protocol (HTTP) message is either a request or a
+   response. A server listens on a connection for a request, parses each
+   message received, interprets the message semantics in relation to the
+   identified request target, and responds to that request with one or more
+   response messages. A client constructs request messages to communicate
+   specific intentions, and examines received responses to see if the
+   intentions were carried out and determine how to interpret the results.
    This document defines HTTP/1.1 request and response semantics in terms of
    the architecture defined in <xref target="Part1"/>.
 </t>
 <t>
-   HTTP provides a uniform interface for interacting with resources regardless
-   of their type, nature, or implementation.  HTTP semantics includes the
-   intentions defined by each request method (<xref target="methods"/>),
-   extensions to those semantics that might be described in request header
-   fields (<xref target="request.header.fields"/>),
+   HTTP provides a uniform interface for interacting with a resource
+   (<xref target="resource"/>), regardless of its type, nature, or
+   implementation, and for transferring content  in message payloads in the
+   form of a representation (<xref target="representation"/>).
+</t>
+<t>
+   HTTP semantics include the intentions defined by each request method
+   (<xref target="methods"/>), extensions to those semantics that might be
+   described in request header fields (<xref target="request.header.fields"/>),
    the meaning of status codes to indicate a machine-readable response
-   (<xref target="status.codes"/>), and other control data
+   (<xref target="status.codes"/>), and the meaning of other control data
    and resource metadata that might be given in response header fields
    (<xref target="response.header.fields"/>).
 </t>
 <t><iref item="content negotiation"/>
-   In addition, this document defines the payload of messages (a.k.a.,
-   content), the associated metadata header fields that define how the payload
-   is intended to be interpreted by a recipient, the request header fields
-   that might influence content selection, and the various selection
+   This document also defines representation metadata that describe how a
+   payload is intended to be interpreted by a recipient, the request header
+   fields that might influence content selection, and the various selection
    algorithms that are collectively referred to as
-   "<x:dfn>content negotiation</x:dfn>".
+   "<x:dfn>content negotiation</x:dfn>" (<xref target="content.negotiation"/>).
 </t>
 <section title="Conformance and Error Handling" anchor="conformance">