Changeset 1227 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Mar 28, 2011, 8:34:32 AM (9 years ago)

Author:

fielding@…

Message:

editorial: use explicit extended mark-up to emphasize definitions.

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (12 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -532 +532 @@
 <t>
    HTTP is a stateless request/response protocol that operates by exchanging
-   messages across a reliable transport or session-layer connection. An HTTP
-   "client" is a program that establishes a connection to a server for the
-   purpose of sending one or more HTTP requests.  An HTTP "server" is a
+   messages across a reliable transport or session-layer
+   "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a
+   program that establishes a connection to a server for the purpose of
+   sending one or more HTTP requests.  An HTTP "<x:dfn>server</x:dfn>" is a
    program that accepts connections in order to service HTTP requests by
    sending HTTP responses.
@@ -542 +543 @@
 <iref primary="true" item="browser"/>
 <iref primary="true" item="spider"/>
+<iref primary="true" item="sender"/>
+<iref primary="true" item="recipient"/>
 <t>
    Note that the terms client and server refer only to the roles that
    these programs perform for a particular connection.  The same program
    might act as a client on some connections and a server on others.  We use
-   the term "user agent" to refer to the program that initiates a request,
+   the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request,
    such as a WWW browser, editor, or spider (web-traversing robot), and
-   the term "origin server" to refer to the program that can originate
+   the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate
    authoritative responses to a request.  For general requirements, we use
-   the term "sender" to refer to whichever component sent a given message
-   and the term "recipient" to refer to any component that receives the
+   the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message
+   and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the
    message.
 </t>
@@ -569 +572 @@
 <iref primary="true" item="response"/>
 <t>
-   A client sends an HTTP request to the server in the form of a request
-   message (<xref target="request"/>), beginning with a method, URI, and
+   A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
+   <x:dfn>message</x:dfn> (<xref target="request"/>), beginning with a method, URI, and
    protocol version, followed by MIME-like header fields containing
    request modifiers, client information, and payload metadata, an empty
@@ -577 +580 @@
 </t>
 <t>
-   A server responds to the client's request by sending an HTTP response
-   message (<xref target="response"/>), beginning with a status line that
+   A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn>
+   <x:dfn>message</x:dfn> (<xref target="response"/>), beginning with a status line that
    includes the protocol version, a success or error code, and textual
    reason phrase, followed by MIME-like header fields containing server
@@ -643 +646 @@
    HTTP enables the use of intermediaries to satisfy requests through
    a chain of connections.  There are three common forms of HTTP
-   intermediary: proxy, gateway, and tunnel.  In some cases,
+   <x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel.  In some cases,
    a single intermediary might act as an origin server, proxy, gateway,
    or tunnel, switching behavior based on the nature of each request.
@@ -668 +671 @@
 <iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
 <iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
-   We use the terms "upstream" and "downstream" to describe various
-   requirements in relation to the directional flow of a message:
-   all messages flow from upstream to downstream.
-   Likewise, we use the terms "inbound" and "outbound" to refer to
-   directions in relation to the request path: "inbound" means toward
-   the origin server and "outbound" means toward the user agent.
+   We use the terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>"
+   to describe various requirements in relation to the directional flow of a
+   message: all messages flow from upstream to downstream.
+   Likewise, we use the terms inbound and outbound to refer to
+   directions in relation to the request path:
+   "<x:dfn>inbound</x:dfn>" means toward the origin server and
+   "<x:dfn>outbound</x:dfn>" means toward the user agent.
 </t>
 <t><iref primary="true" item="proxy"/>
-   A "proxy" is a message forwarding agent that is selected by the
+   A "<x:dfn>proxy</x:dfn>" is a message forwarding agent that is selected by the
    client, usually via local configuration rules, to receive requests
    for some type(s) of absolute URI and attempt to satisfy those
@@ -689 +693 @@
 <iref primary="true" item="transforming proxy"/>
 <iref primary="true" item="non-transforming proxy"/>
-   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed
+   An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>" if it is designed
    or configured to modify request or response messages in a semantically
    meaningful way (i.e., modifications, beyond those required by normal
@@ -701 +705 @@
    organization) that selected the proxy and are beyond the scope of
    this specification.  However, when a proxy is not intended to transform
-   a given message, we use the term "non-transforming proxy" to target
+   a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target
    requirements that preserve HTTP message semantics.
 </t>
 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
 <iref primary="true" item="accelerator"/>
-   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
+   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>")
+   is a receiving agent that acts
    as a layer above some other server(s) and translates the received
    requests to the underlying server's protocol.  Gateways are often
    used to encapsulate legacy or untrusted information services, to
-   improve server performance through "accelerator" caching, and to
+   improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to
    enable partitioning or load-balancing of HTTP services across
    multiple machines.
@@ -729 +734 @@
 </t>
 <t><iref primary="true" item="tunnel"/>
-   A "tunnel" acts as a blind relay between two connections
+   A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections
    without changing the messages. Once active, a tunnel is not
    considered a party to the HTTP communication, though the tunnel might
@@ -744 +749 @@
    filters or redirecting agents (usually violating HTTP semantics,
    causing security problems, and otherwise making a mess of things).
-   Such a network intermediary, often referred to as an "interception proxy"
-   <xref target="RFC3040"/>, "transparent proxy" <xref target="RFC1919"/>,
-   or "captive portal",
+   Such a network intermediary, often referred to as an "<x:dfn>interception proxy</x:dfn>"
+   <xref target="RFC3040"/>, "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/>,
+   or "<x:dfn>captive portal</x:dfn>",
    differs from an HTTP proxy because it has not been selected by the client.
    Instead, the network intermediary redirects outgoing TCP port 80 packets
@@ -761 +766 @@
 <iref primary="true" item="cache"/>
 <t>
-   A "cache" is a local store of previous response messages and the
+   A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the
    subsystem that controls its message storage, retrieval, and deletion.
    A cache stores cacheable responses in order to reduce the response
@@ -781 +786 @@
 </artwork></figure>
 <t><iref primary="true" item="cacheable"/>
-   A response is "cacheable" if a cache is allowed to store a copy of
+   A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of
    the response message for use in answering subsequent requests.
    Even when a response is cacheable, there might be additional