Ignore:
Timestamp:
12/11/08 19:58:51 (14 years ago)
Author:
julian.reschke@…
Message:

Move Terminology Section to the back.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r345 r346  
    306306</section>
    307307
    308 <section title="Terminology" anchor="intro.terminology">
    309 <t>
    310    This specification uses a number of terms to refer to the roles
    311    played by participants in, and objects of, the HTTP communication.
    312 </t>
    313 <t>
    314   <iref item="connection"/>
    315   <x:dfn>connection</x:dfn>
    316   <list>
    317     <t>
    318       A transport layer virtual circuit established between two programs
    319       for the purpose of communication.
    320     </t>
    321   </list>
    322 </t>
    323 <t>
    324   <iref item="message"/>
    325   <x:dfn>message</x:dfn>
    326   <list>
    327     <t>
    328       The basic unit of HTTP communication, consisting of a structured
    329       sequence of octets matching the syntax defined in <xref target="http.message"/> and
    330       transmitted via the connection.
    331     </t>
    332   </list>
    333 </t>
    334 <t>
    335   <iref item="request"/>
    336   <x:dfn>request</x:dfn>
    337   <list>
    338     <t>
    339       An HTTP request message, as defined in <xref target="request"/>.
    340     </t>
    341   </list>
    342 </t>
    343 <t>
    344   <iref item="response"/>
    345   <x:dfn>response</x:dfn>
    346   <list>
    347     <t>
    348       An HTTP response message, as defined in <xref target="response"/>.
    349     </t>
    350   </list>
    351 </t>
    352 <t>
    353   <iref item="resource"/>
    354   <x:dfn>resource</x:dfn>
    355   <list>
    356     <t>
    357       A network data object or service that can be identified by a URI,
    358       as defined in <xref target="uri"/>. Resources may be available in multiple
    359       representations (e.g. multiple languages, data formats, size, and
    360       resolutions) or vary in other ways.
    361     </t>
    362   </list>
    363 </t>
    364 <t>
    365   <iref item="entity"/>
    366   <x:dfn>entity</x:dfn>
    367   <list>
    368     <t>
    369       The information transferred as the payload of a request or
    370       response. An entity consists of metainformation in the form of
    371       entity-header fields and content in the form of an entity-body, as
    372       described in &entity;.
    373     </t>
    374   </list>
    375 </t>
    376 <t>
    377   <iref item="representation"/>
    378   <x:dfn>representation</x:dfn>
    379   <list>
    380     <t>
    381       An entity included with a response that is subject to content
    382       negotiation, as described in &content.negotiation;. There may exist multiple
    383       representations associated with a particular response status.
    384     </t>
    385   </list>
    386 </t>
    387 <t>
    388   <iref item="content negotiation"/>
    389   <x:dfn>content negotiation</x:dfn>
    390   <list>
    391     <t>
    392       The mechanism for selecting the appropriate representation when
    393       servicing a request, as described in &content.negotiation;. The
    394       representation of entities in any response can be negotiated
    395       (including error responses).
    396     </t>
    397   </list>
    398 </t>
    399 <t>
    400   <iref item="variant"/>
    401   <x:dfn>variant</x:dfn>
    402   <list>
    403     <t>
    404       A resource may have one, or more than one, representation(s)
    405       associated with it at any given instant. Each of these
    406       representations is termed a `variant'.  Use of the term `variant'
    407       does not necessarily imply that the resource is subject to content
    408       negotiation.
    409     </t>
    410   </list>
    411 </t>
    412 <t>
    413   <iref item="client"/>
    414   <x:dfn>client</x:dfn>
    415   <list>
    416     <t>
    417       A program that establishes connections for the purpose of sending
    418       requests.
    419     </t>
    420   </list>
    421 </t>
    422 <t>
    423   <iref item="user agent"/>
    424   <x:dfn>user agent</x:dfn>
    425   <list>
    426     <t>
    427       The client which initiates a request. These are often browsers,
    428       editors, spiders (web-traversing robots), or other end user tools.
    429     </t>
    430   </list>
    431 </t>
    432 <t>
    433   <iref item="server"/>
    434   <x:dfn>server</x:dfn>
    435   <list>
    436     <t>
    437       An application program that accepts connections in order to
    438       service requests by sending back responses. Any given program may
    439       be capable of being both a client and a server; our use of these
    440       terms refers only to the role being performed by the program for a
    441       particular connection, rather than to the program's capabilities
    442       in general. Likewise, any server may act as an origin server,
    443       proxy, gateway, or tunnel, switching behavior based on the nature
    444       of each request.
    445     </t>
    446   </list>
    447 </t>
    448 <t>
    449   <iref item="origin server"/>
    450   <x:dfn>origin server</x:dfn>
    451   <list>
    452     <t>
    453       The server on which a given resource resides or is to be created.
    454     </t>
    455   </list>
    456 </t>
    457 <t>
    458   <iref item="proxy"/>
    459   <x:dfn>proxy</x:dfn>
    460   <list>
    461     <t>
    462       An intermediary program which acts as both a server and a client
    463       for the purpose of making requests on behalf of other clients.
    464       Requests are serviced internally or by passing them on, with
    465       possible translation, to other servers. A proxy &MUST; implement
    466       both the client and server requirements of this specification. A
    467       "transparent proxy" is a proxy that does not modify the request or
    468       response beyond what is required for proxy authentication and
    469       identification. A "non-transparent proxy" is a proxy that modifies
    470       the request or response in order to provide some added service to
    471       the user agent, such as group annotation services, media type
    472       transformation, protocol reduction, or anonymity filtering. Except
    473       where either transparent or non-transparent behavior is explicitly
    474       stated, the HTTP proxy requirements apply to both types of
    475       proxies.
    476     </t>
    477   </list>
    478 </t>
    479 <t>
    480   <iref item="gateway"/>
    481   <x:dfn>gateway</x:dfn>
    482   <list>
    483     <t>
    484       A server which acts as an intermediary for some other server.
    485       Unlike a proxy, a gateway receives requests as if it were the
    486       origin server for the requested resource; the requesting client
    487       may not be aware that it is communicating with a gateway.
    488     </t>
    489   </list>
    490 </t>
    491 <t>
    492   <iref item="tunnel"/>
    493   <x:dfn>tunnel</x:dfn>
    494   <list>
    495     <t>
    496       An intermediary program which is acting as a blind relay between
    497       two connections. Once active, a tunnel is not considered a party
    498       to the HTTP communication, though the tunnel may have been
    499       initiated by an HTTP request. The tunnel ceases to exist when both
    500       ends of the relayed connections are closed.
    501     </t>
    502   </list>
    503 </t>
    504 <t>
    505   <iref item="cache"/>
    506   <x:dfn>cache</x:dfn>
    507   <list>
    508     <t>
    509       A program's local store of response messages and the subsystem
    510       that controls its message storage, retrieval, and deletion. A
    511       cache stores cacheable responses in order to reduce the response
    512       time and network bandwidth consumption on future, equivalent
    513       requests. Any client or server may include a cache, though a cache
    514       cannot be used by a server that is acting as a tunnel.
    515     </t>
    516   </list>
    517 </t>
    518 <t>
    519   <iref item="cacheable"/>
    520   <x:dfn>cacheable</x:dfn>
    521   <list>
    522     <t>
    523       A response is cacheable if a cache is allowed to store a copy of
    524       the response message for use in answering subsequent requests. The
    525       rules for determining the cacheability of HTTP responses are
    526       defined in &caching;. Even if a resource is cacheable, there may
    527       be additional constraints on whether a cache can use the cached
    528       copy for a particular request.
    529     </t>
    530   </list>
    531 </t>
    532 <t>
    533   <iref item="upstream"/>
    534   <iref item="downstream"/>
    535   <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>
    536   <list>
    537     <t>
    538       Upstream and downstream describe the flow of a message: all
    539       messages flow from upstream to downstream.
    540     </t>
    541   </list>
    542 </t>
    543 <t>
    544   <iref item="inbound"/>
    545   <iref item="outbound"/>
    546   <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>
    547   <list>
    548     <t>
    549       Inbound and outbound refer to the request and response paths for
    550       messages: "inbound" means "traveling toward the origin server",
    551       and "outbound" means "traveling toward the user agent"
    552     </t>
    553   </list>
    554 </t>
    555 </section>
    556 
    557308<section title="Overall Operation" anchor="intro.overall.operation">
    558309<t>
    … …  
    43764127</section>
    43774128
     4129<section title="Terminology" anchor="terminology">
     4130<t>
     4131   This specification uses a number of terms to refer to the roles
     4132   played by participants in, and objects of, the HTTP communication.
     4133</t>
     4134<t>
     4135  <iref item="connection"/>
     4136  <x:dfn>connection</x:dfn>
     4137  <list>
     4138    <t>
     4139      A transport layer virtual circuit established between two programs
     4140      for the purpose of communication.
     4141    </t>
     4142  </list>
     4143</t>
     4144<t>
     4145  <iref item="message"/>
     4146  <x:dfn>message</x:dfn>
     4147  <list>
     4148    <t>
     4149      The basic unit of HTTP communication, consisting of a structured
     4150      sequence of octets matching the syntax defined in <xref target="http.message"/> and
     4151      transmitted via the connection.
     4152    </t>
     4153  </list>
     4154</t>
     4155<t>
     4156  <iref item="request"/>
     4157  <x:dfn>request</x:dfn>
     4158  <list>
     4159    <t>
     4160      An HTTP request message, as defined in <xref target="request"/>.
     4161    </t>
     4162  </list>
     4163</t>
     4164<t>
     4165  <iref item="response"/>
     4166  <x:dfn>response</x:dfn>
     4167  <list>
     4168    <t>
     4169      An HTTP response message, as defined in <xref target="response"/>.
     4170    </t>
     4171  </list>
     4172</t>
     4173<t>
     4174  <iref item="resource"/>
     4175  <x:dfn>resource</x:dfn>
     4176  <list>
     4177    <t>
     4178      A network data object or service that can be identified by a URI,
     4179      as defined in <xref target="uri"/>. Resources may be available in multiple
     4180      representations (e.g. multiple languages, data formats, size, and
     4181      resolutions) or vary in other ways.
     4182    </t>
     4183  </list>
     4184</t>
     4185<t>
     4186  <iref item="entity"/>
     4187  <x:dfn>entity</x:dfn>
     4188  <list>
     4189    <t>
     4190      The information transferred as the payload of a request or
     4191      response. An entity consists of metainformation in the form of
     4192      entity-header fields and content in the form of an entity-body, as
     4193      described in &entity;.
     4194    </t>
     4195  </list>
     4196</t>
     4197<t>
     4198  <iref item="representation"/>
     4199  <x:dfn>representation</x:dfn>
     4200  <list>
     4201    <t>
     4202      An entity included with a response that is subject to content
     4203      negotiation, as described in &content.negotiation;. There may exist multiple
     4204      representations associated with a particular response status.
     4205    </t>
     4206  </list>
     4207</t>
     4208<t>
     4209  <iref item="content negotiation"/>
     4210  <x:dfn>content negotiation</x:dfn>
     4211  <list>
     4212    <t>
     4213      The mechanism for selecting the appropriate representation when
     4214      servicing a request, as described in &content.negotiation;. The
     4215      representation of entities in any response can be negotiated
     4216      (including error responses).
     4217    </t>
     4218  </list>
     4219</t>
     4220<t>
     4221  <iref item="variant"/>
     4222  <x:dfn>variant</x:dfn>
     4223  <list>
     4224    <t>
     4225      A resource may have one, or more than one, representation(s)
     4226      associated with it at any given instant. Each of these
     4227      representations is termed a `variant'.  Use of the term `variant'
     4228      does not necessarily imply that the resource is subject to content
     4229      negotiation.
     4230    </t>
     4231  </list>
     4232</t>
     4233<t>
     4234  <iref item="client"/>
     4235  <x:dfn>client</x:dfn>
     4236  <list>
     4237    <t>
     4238      A program that establishes connections for the purpose of sending
     4239      requests.
     4240    </t>
     4241  </list>
     4242</t>
     4243<t>
     4244  <iref item="user agent"/>
     4245  <x:dfn>user agent</x:dfn>
     4246  <list>
     4247    <t>
     4248      The client which initiates a request. These are often browsers,
     4249      editors, spiders (web-traversing robots), or other end user tools.
     4250    </t>
     4251  </list>
     4252</t>
     4253<t>
     4254  <iref item="server"/>
     4255  <x:dfn>server</x:dfn>
     4256  <list>
     4257    <t>
     4258      An application program that accepts connections in order to
     4259      service requests by sending back responses. Any given program may
     4260      be capable of being both a client and a server; our use of these
     4261      terms refers only to the role being performed by the program for a
     4262      particular connection, rather than to the program's capabilities
     4263      in general. Likewise, any server may act as an origin server,
     4264      proxy, gateway, or tunnel, switching behavior based on the nature
     4265      of each request.
     4266    </t>
     4267  </list>
     4268</t>
     4269<t>
     4270  <iref item="origin server"/>
     4271  <x:dfn>origin server</x:dfn>
     4272  <list>
     4273    <t>
     4274      The server on which a given resource resides or is to be created.
     4275    </t>
     4276  </list>
     4277</t>
     4278<t>
     4279  <iref item="proxy"/>
     4280  <x:dfn>proxy</x:dfn>
     4281  <list>
     4282    <t>
     4283      An intermediary program which acts as both a server and a client
     4284      for the purpose of making requests on behalf of other clients.
     4285      Requests are serviced internally or by passing them on, with
     4286      possible translation, to other servers. A proxy &MUST; implement
     4287      both the client and server requirements of this specification. A
     4288      "transparent proxy" is a proxy that does not modify the request or
     4289      response beyond what is required for proxy authentication and
     4290      identification. A "non-transparent proxy" is a proxy that modifies
     4291      the request or response in order to provide some added service to
     4292      the user agent, such as group annotation services, media type
     4293      transformation, protocol reduction, or anonymity filtering. Except
     4294      where either transparent or non-transparent behavior is explicitly
     4295      stated, the HTTP proxy requirements apply to both types of
     4296      proxies.
     4297    </t>
     4298  </list>
     4299</t>
     4300<t>
     4301  <iref item="gateway"/>
     4302  <x:dfn>gateway</x:dfn>
     4303  <list>
     4304    <t>
     4305      A server which acts as an intermediary for some other server.
     4306      Unlike a proxy, a gateway receives requests as if it were the
     4307      origin server for the requested resource; the requesting client
     4308      may not be aware that it is communicating with a gateway.
     4309    </t>
     4310  </list>
     4311</t>
     4312<t>
     4313  <iref item="tunnel"/>
     4314  <x:dfn>tunnel</x:dfn>
     4315  <list>
     4316    <t>
     4317      An intermediary program which is acting as a blind relay between
     4318      two connections. Once active, a tunnel is not considered a party
     4319      to the HTTP communication, though the tunnel may have been
     4320      initiated by an HTTP request. The tunnel ceases to exist when both
     4321      ends of the relayed connections are closed.
     4322    </t>
     4323  </list>
     4324</t>
     4325<t>
     4326  <iref item="cache"/>
     4327  <x:dfn>cache</x:dfn>
     4328  <list>
     4329    <t>
     4330      A program's local store of response messages and the subsystem
     4331      that controls its message storage, retrieval, and deletion. A
     4332      cache stores cacheable responses in order to reduce the response
     4333      time and network bandwidth consumption on future, equivalent
     4334      requests. Any client or server may include a cache, though a cache
     4335      cannot be used by a server that is acting as a tunnel.
     4336    </t>
     4337  </list>
     4338</t>
     4339<t>
     4340  <iref item="cacheable"/>
     4341  <x:dfn>cacheable</x:dfn>
     4342  <list>
     4343    <t>
     4344      A response is cacheable if a cache is allowed to store a copy of
     4345      the response message for use in answering subsequent requests. The
     4346      rules for determining the cacheability of HTTP responses are
     4347      defined in &caching;. Even if a resource is cacheable, there may
     4348      be additional constraints on whether a cache can use the cached
     4349      copy for a particular request.
     4350    </t>
     4351  </list>
     4352</t>
     4353<t>
     4354  <iref item="upstream"/>
     4355  <iref item="downstream"/>
     4356  <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>
     4357  <list>
     4358    <t>
     4359      Upstream and downstream describe the flow of a message: all
     4360      messages flow from upstream to downstream.
     4361    </t>
     4362  </list>
     4363</t>
     4364<t>
     4365  <iref item="inbound"/>
     4366  <iref item="outbound"/>
     4367  <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>
     4368  <list>
     4369    <t>
     4370      Inbound and outbound refer to the request and response paths for
     4371      messages: "inbound" means "traveling toward the origin server",
     4372      and "outbound" means "traveling toward the user agent"
     4373    </t>
     4374  </list>
     4375</t>
     4376</section>
     4377
    43784378<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
    43794379
Note: See TracChangeset for help on using the changeset viewer.