Ignore:
Timestamp:
Sep 3, 2012, 2:29:18 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) change of terms for content negotiation:

server-driven => proactive (UA sends Accept* fields)
agent-driven => reactive (UA waits for 300/Alternatives)

File:
1 edited

Legend:

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

    r1857 r1858  
    597597               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    598598               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
    599                      <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
    600                      <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
     599                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
     600                     <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
    601601                  </ul>
    602602               </li>
     
    11181118         more than one is available.
    11191119      </p>
    1120       <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
    1121          based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
    1122          for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
    1123          "active content" pattern, where the server returns active content which runs on the client and, based on client available
    1124          parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
     1120      <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
     1121         upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for
     1122         the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active
     1123         content" pattern, where the server returns active content which runs on the client and, based on client available parameters,
     1124         selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    11251125      </p>
    11261126      <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    11271127         of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    1128          a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    1129          to choose from is very large, agent-driven negotiation might not be appropriate.
     1128         a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
     1129         to choose from is very large, reactive negotiation might not be appropriate.
    11301130      </p>
    11311131      <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
    11321132         be considered to be the "same information".
    11331133      </p>
    1134       <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h3>
    1135       <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven
     1134      <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
     1135      <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
    11361136         negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    11371137         language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    11381138         pertaining to the request (such as the network address of the client).
    11391139      </p>
    1140       <p id="rfc.section.3.5.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
     1140      <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
    11411141         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    11421142         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    11431143         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    11441144      </p>
    1145       <p id="rfc.section.3.5.1.p.3">Server-driven negotiation has disadvantages: </p>
     1145      <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p>
    11461146      <ol>
    11471147         <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
     
    11551155         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    11561156      </ol>
    1157       <p id="rfc.section.3.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
    1158          them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
    1159          that doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
     1157      <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
     1158         For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
     1159         doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
    11601160            (Not Acceptable)</a> response.
    11611161      </p>
    1162       <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
     1162      <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
    11631163         and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;6.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    11641164         within extension header fields not defined by this specification.
     
    11681168         </p>
    11691169      </div>
    1170       <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
    1171       </p>
    1172       <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h3>
    1173       <p id="rfc.section.3.5.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
     1170      <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
     1171      </p>
     1172      <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
     1173      <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
    11741174         an initial response from the origin server. Selection is based on a list of the available representations of the response
    11751175         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     
    11771177         user selecting from a generated (possibly hypertext) menu.
    11781178      </p>
    1179       <p id="rfc.section.3.5.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
    1180          or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
     1179      <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1180         encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    11811181         when public caches are used to distribute server load and reduce network usage.
    11821182      </p>
    1183       <p id="rfc.section.3.5.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
     1183      <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
    11841184         This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    11851185         for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    11861186         and used within HTTP/1.1.
    11871187      </p>
    1188       <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
    1189          server-driven negotiation.
     1188      <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
     1189         proactive negotiation.
    11901190      </p>
    11911191      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
     
    17141714      </div>
    17151715      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1716       <p id="rfc.section.6.3.1.p.1">Many of the request header fields for server-driven content negotiation use a common parameter, named "q", to assign a relative
     1716      <p id="rfc.section.6.3.1.p.1">Many of the request header fields for proactive content negotiation use a common parameter, named "q", to assign a relative
    17171717         "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue")
    17181718         because the same parameter name is often used within server configurations to assign a weight to the relative quality of the
     
    24172417         </li>
    24182418         <li>
    2419             <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
     2419            <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
    24202420            </p>
    24212421         </li>
     
    24462446      <div id="rfc.iref.s.14"></div>
    24472447      <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    2448       <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information
     2448      <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information
    24492449         (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    24502450         location.
Note: See TracChangeset for help on using the changeset viewer.