Ignore:
Timestamp:
15/01/10 10:04:46 (12 years ago)
Author:
julian.reschke@…
Message:

Add new introduction about Content Negotiation, remove section about transparent conneg, instead just mention RFC 2295 (see #81)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p3-payload.html

    r741 r745  
    401401      <meta name="DC.Creator" content="Reschke, J. F.">
    402402      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
     403      <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-15">
    404404      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    405405      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: July 5, 2010</td>
     429               <td class="left">Expires: July 19, 2010</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
    … …  
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">January 1, 2010</td>
     486               <td class="right">January 15, 2010</td>
    487487            </tr>
    488488         </tbody>
    … …  
    514514      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    515515      </p>
    516       <p>This Internet-Draft will expire in July 5, 2010.</p>
     516      <p>This Internet-Draft will expire in July 19, 2010.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    570570               <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
    571571               <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
    572                <li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#transparent.negotiation">Transparent Negotiation</a></li>
    573572            </ul>
    574573         </li>
    … …  
    918917      </p>
    919918      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    920       <p id="rfc.section.4.p.1">Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable
    921          to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not
    922          all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity
    923          types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the
    924          best representation for a given response when there are multiple representations available.
    925       </p>
    926       <div class="note">
    927          <p> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
    928             capabilities of that type, be in different languages, etc.
    929          </p>
    930       </div>
    931       <p id="rfc.section.4.p.3">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.
    932       </p>
    933       <p id="rfc.section.4.p.4">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two
    934          kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred
    935          to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server
    936          in order to provide server-driven negotiation for subsequent requests.
     919      <p id="rfc.section.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
     920         processing. Often, the server has different ways of representing the same information; for example, in different formats,
     921         languages, or using different character encodings.
     922      </p>
     923      <p id="rfc.section.4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
     924         which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
     925         provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource,
     926         when more than one is available.
     927      </p>
     928      <p id="rfc.section.4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
     929         based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
     930         for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
     931         "active content" pattern, where the server returns active content which runs on the client and, based on client available
     932         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.
     933      </p>
     934      <p id="rfc.section.4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
     935         of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
     936         a user-agent), server-driven negotiation becomes unwieldy, and may not be appropriate. Conversely, when the number of representations
     937         to choose from is very large, agent-driven negotiation may not be appropriate.
     938      </p>
     939      <p id="rfc.section.4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
     940         be considered to be the "same information".
    937941      </p>
    938942      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
    … …  
    963967         header fields not defined by this specification.
    964968      </p>
    965       <p id="rfc.section.4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><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.
     969      <div class="note">
     970         <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
     971         </p>
     972      </div>
     973      <p id="rfc.section.4.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><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.
    966974      </p>
    967975      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
    … …  
    981989         and used within HTTP/1.1.
    982990      </p>
    983       <p id="rfc.section.4.2.p.4">HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when
    984          the server is unwilling or unable to provide a varying response using server-driven negotiation.
    985       </p>
    986       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="transparent.negotiation" href="#transparent.negotiation">Transparent Negotiation</a></h2>
    987       <p id="rfc.section.4.3.p.1">Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with
    988          a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance
    989          are completely understood by the cache, then the cache becomes capable of performing server-driven negotiation on behalf of
    990          the origin server for subsequent requests on that resource.
    991       </p>
    992       <p id="rfc.section.4.3.p.2">Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin
    993          server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the
    994          right response.
    995       </p>
    996       <p id="rfc.section.4.3.p.3">This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism
    997          from being developed as an extension that could be used within HTTP/1.1.
     991      <p id="rfc.section.4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
     992         when the server is unwilling or unable to provide a varying response using server-driven negotiation.
    998993      </p>
    999994      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    15921587      <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
    15931588      </h2>
    1594       <table>                             
     1589      <table>                               
    15951590         <tr>
    15961591            <td class="reference"><b id="BCP97">[BCP97]</b></td>
    … …  
    16261621            <td class="reference"><b id="RFC2277">[RFC2277]</b></td>
    16271622            <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
     1623            </td>
     1624         </tr>
     1625         <tr>
     1626            <td class="reference"><b id="RFC2295">[RFC2295]</b></td>
     1627            <td class="top"><a href="mailto:koen@win.tue.nl" title="Technische Universiteit Eindhoven">Holtman, K.</a> and <a href="mailto:mutz@hpl.hp.com" title="Hewlett-Packard Company">A.H. Mutz</a>, “<a href="http://tools.ietf.org/html/rfc2295">Transparent Content Negotiation in HTTP</a>”, RFC&nbsp;2295, March&nbsp;1998.
    16281628            </td>
    16291629         </tr>
    … …  
    20322032      <p id="rfc.section.E.10.p.1">Closed issues: </p>
    20332033      <ul>
     2034         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/81">http://tools.ietf.org/wg/httpbis/trac/ticket/81</a>&gt;: "Content Negotiation for media types"
     2035         </li>
    20342036         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/181">http://tools.ietf.org/wg/httpbis/trac/ticket/181</a>&gt;: "Accept-Language: which RFC4647 filtering?"
    20352037         </li>
    … …  
    22392241                  </li>
    22402242                  <li class="indline1"><em>RFC2277</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9.2</b></a></li>
     2243                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>
    22412244                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li>
    22422245                  <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li>
Note: See TracChangeset for help on using the changeset viewer.