Ignore:
Timestamp:
Mar 28, 2011, 8:34:32 AM (9 years ago)
Author:
fielding@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1214 r1227  
    532532<t>
    533533   HTTP is a stateless request/response protocol that operates by exchanging
    534    messages across a reliable transport or session-layer connection. An HTTP
    535    "client" is a program that establishes a connection to a server for the
    536    purpose of sending one or more HTTP requests.  An HTTP "server" is a
     534   messages across a reliable transport or session-layer
     535   "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a
     536   program that establishes a connection to a server for the purpose of
     537   sending one or more HTTP requests.  An HTTP "<x:dfn>server</x:dfn>" is a
    537538   program that accepts connections in order to service HTTP requests by
    538539   sending HTTP responses.
     
    542543<iref primary="true" item="browser"/>
    543544<iref primary="true" item="spider"/>
     545<iref primary="true" item="sender"/>
     546<iref primary="true" item="recipient"/>
    544547<t>
    545548   Note that the terms client and server refer only to the roles that
    546549   these programs perform for a particular connection.  The same program
    547550   might act as a client on some connections and a server on others.  We use
    548    the term "user agent" to refer to the program that initiates a request,
     551   the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request,
    549552   such as a WWW browser, editor, or spider (web-traversing robot), and
    550    the term "origin server" to refer to the program that can originate
     553   the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate
    551554   authoritative responses to a request.  For general requirements, we use
    552    the term "sender" to refer to whichever component sent a given message
    553    and the term "recipient" to refer to any component that receives the
     555   the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message
     556   and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the
    554557   message.
    555558</t>
     
    569572<iref primary="true" item="response"/>
    570573<t>
    571    A client sends an HTTP request to the server in the form of a request
    572    message (<xref target="request"/>), beginning with a method, URI, and
     574   A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
     575   <x:dfn>message</x:dfn> (<xref target="request"/>), beginning with a method, URI, and
    573576   protocol version, followed by MIME-like header fields containing
    574577   request modifiers, client information, and payload metadata, an empty
     
    577580</t>
    578581<t>
    579    A server responds to the client's request by sending an HTTP response
    580    message (<xref target="response"/>), beginning with a status line that
     582   A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn>
     583   <x:dfn>message</x:dfn> (<xref target="response"/>), beginning with a status line that
    581584   includes the protocol version, a success or error code, and textual
    582585   reason phrase, followed by MIME-like header fields containing server
     
    643646   HTTP enables the use of intermediaries to satisfy requests through
    644647   a chain of connections.  There are three common forms of HTTP
    645    intermediary: proxy, gateway, and tunnel.  In some cases,
     648   <x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel.  In some cases,
    646649   a single intermediary might act as an origin server, proxy, gateway,
    647650   or tunnel, switching behavior based on the nature of each request.
     
    668671<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
    669672<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    670    We use the terms "upstream" and "downstream" to describe various
    671    requirements in relation to the directional flow of a message:
    672    all messages flow from upstream to downstream.
    673    Likewise, we use the terms "inbound" and "outbound" to refer to
    674    directions in relation to the request path: "inbound" means toward
    675    the origin server and "outbound" means toward the user agent.
     673   We use the terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>"
     674   to describe various requirements in relation to the directional flow of a
     675   message: all messages flow from upstream to downstream.
     676   Likewise, we use the terms inbound and outbound to refer to
     677   directions in relation to the request path:
     678   "<x:dfn>inbound</x:dfn>" means toward the origin server and
     679   "<x:dfn>outbound</x:dfn>" means toward the user agent.
    676680</t>
    677681<t><iref primary="true" item="proxy"/>
    678    A "proxy" is a message forwarding agent that is selected by the
     682   A "<x:dfn>proxy</x:dfn>" is a message forwarding agent that is selected by the
    679683   client, usually via local configuration rules, to receive requests
    680684   for some type(s) of absolute URI and attempt to satisfy those
     
    689693<iref primary="true" item="transforming proxy"/>
    690694<iref primary="true" item="non-transforming proxy"/>
    691    An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed
     695   An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>" if it is designed
    692696   or configured to modify request or response messages in a semantically
    693697   meaningful way (i.e., modifications, beyond those required by normal
     
    701705   organization) that selected the proxy and are beyond the scope of
    702706   this specification.  However, when a proxy is not intended to transform
    703    a given message, we use the term "non-transforming proxy" to target
     707   a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target
    704708   requirements that preserve HTTP message semantics.
    705709</t>
    706710<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    707711<iref primary="true" item="accelerator"/>
    708    A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
     712   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>")
     713   is a receiving agent that acts
    709714   as a layer above some other server(s) and translates the received
    710715   requests to the underlying server's protocol.  Gateways are often
    711716   used to encapsulate legacy or untrusted information services, to
    712    improve server performance through "accelerator" caching, and to
     717   improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to
    713718   enable partitioning or load-balancing of HTTP services across
    714719   multiple machines.
     
    729734</t>
    730735<t><iref primary="true" item="tunnel"/>
    731    A "tunnel" acts as a blind relay between two connections
     736   A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections
    732737   without changing the messages. Once active, a tunnel is not
    733738   considered a party to the HTTP communication, though the tunnel might
     
    744749   filters or redirecting agents (usually violating HTTP semantics,
    745750   causing security problems, and otherwise making a mess of things).
    746    Such a network intermediary, often referred to as an "interception proxy"
    747    <xref target="RFC3040"/>, "transparent proxy" <xref target="RFC1919"/>,
    748    or "captive portal",
     751   Such a network intermediary, often referred to as an "<x:dfn>interception proxy</x:dfn>"
     752   <xref target="RFC3040"/>, "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/>,
     753   or "<x:dfn>captive portal</x:dfn>",
    749754   differs from an HTTP proxy because it has not been selected by the client.
    750755   Instead, the network intermediary redirects outgoing TCP port 80 packets
     
    761766<iref primary="true" item="cache"/>
    762767<t>
    763    A "cache" is a local store of previous response messages and the
     768   A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the
    764769   subsystem that controls its message storage, retrieval, and deletion.
    765770   A cache stores cacheable responses in order to reduce the response
     
    781786</artwork></figure>
    782787<t><iref primary="true" item="cacheable"/>
    783    A response is "cacheable" if a cache is allowed to store a copy of
     788   A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of
    784789   the response message for use in answering subsequent requests.
    785790   Even when a response is cacheable, there might be additional
Note: See TracChangeset for help on using the changeset viewer.