* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 745


Ignore:
Timestamp:
2010-01-15 02:04:46 (5 years ago)
Author:
julian.reschke@gmx.de
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 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> 
  • draft-ietf-httpbis/latest/p3-payload.xml

    r741 r745  
    807807<section title="Content Negotiation" anchor="content.negotiation"> 
    808808<t> 
    809    Most HTTP responses include an entity which contains information for 
    810    interpretation by a human user. Naturally, it is desirable to supply 
    811    the user with the "best available" entity corresponding to the 
    812    request. Unfortunately for servers and caches, not all users have the 
    813    same preferences for what is "best," and not all user agents are 
    814    equally capable of rendering all entity types. For that reason, HTTP 
    815    has provisions for several mechanisms for "content negotiation" -- 
    816    the process of selecting the best representation for a given response 
    817    when there are multiple representations available. 
    818 </t> 
    819 <x:note> 
    820   <t> 
    821     <x:h>Note:</x:h> This is not called "format negotiation" because the 
    822     alternate representations may be of the same media type, but use 
    823     different capabilities of that type, be in different languages, 
    824     etc. 
    825   </t> 
    826 </x:note> 
    827 <t> 
    828    Any response containing an entity-body &MAY; be subject to negotiation, 
    829    including error responses. 
    830 </t> 
    831 <t> 
    832    There are two kinds of content negotiation which are possible in 
    833    HTTP: server-driven and agent-driven negotiation. These two kinds of 
    834    negotiation are orthogonal and thus may be used separately or in 
    835    combination. One method of combination, referred to as transparent 
    836    negotiation, occurs when a cache uses the agent-driven negotiation 
    837    information provided by the origin server in order to provide 
    838    server-driven negotiation for subsequent requests. 
     809   HTTP responses include a representation which contains information for 
     810   interpretation, whether by a human user or for further processing. 
     811   Often, the server has different ways of representing the 
     812   same information; for example, in different formats, languages, 
     813   or using different character encodings. 
     814</t> 
     815<t> 
     816   HTTP clients and their users might have different or variable 
     817   capabilities, characteristics or preferences which would influence 
     818   which representation, among those available from the server, 
     819   would be best for the server to deliver. For this reason, HTTP 
     820   provides mechanisms for "content negotiation" -- a process of 
     821   allowing selection of a representation of a given resource, 
     822   when more than one is available. 
     823</t> 
     824<t> 
     825   This specification defines two patterns of content negotiation; 
     826   "server-driven", where the server selects the representation based 
     827   upon the client's stated preferences, and "agent-driven" negotiation, 
     828   where the server provides a list of representations for the client to 
     829   choose from, based upon their metadata. In addition,  there are 
     830   other patterns: some applications use an "active content" pattern, 
     831   where the server returns active content which runs on the client 
     832   and, based on client available parameters, selects additional 
     833   resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>) 
     834   has also been proposed. 
     835</t> 
     836<t> 
     837   These patterns are all widely used, and have trade-offs in applicability 
     838   and practicality. In particular, when the number of preferences or 
     839   capabilities to be expressed by a client are large (such as when many 
     840   different formats are supported by a user-agent), server-driven 
     841   negotiation becomes unwieldy, and may not be appropriate. Conversely, 
     842   when the number of representations to choose from is very large, 
     843   agent-driven negotiation may not be appropriate. 
     844</t> 
     845<t> 
     846   Note that in all cases, the supplier of representations has the 
     847   responsibility for determining which representations might be 
     848   considered to be the "same information". 
    839849</t> 
    840850 
     
    891901   capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset 
    892902   (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language 
    893    (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). However, an 
    894    origin server is not limited to these dimensions and &MAY; vary the 
    895    response based on any aspect of the request, including information 
     903   (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). 
     904   However, an origin server is not limited to these dimensions and &MAY; vary  
     905   the response based on any aspect of the request, including information 
    896906   outside the request-header fields or within extension header fields 
    897907   not defined by this specification. 
    898908</t> 
     909<x:note> 
     910  <t> 
     911    <x:h>Note:</x:h> In practice, User-Agent based negotiation is fragile, 
     912    because new clients might not be recognized.  
     913  </t> 
     914</x:note> 
    899915<t> 
    900916   The Vary header field (&header-vary;) can be used to express the parameters the 
     
    933949</t> 
    934950<t> 
    935    HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) 
     951   This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) 
    936952   status codes for enabling agent-driven negotiation when the server is 
    937953   unwilling or unable to provide a varying response using server-driven 
    938954   negotiation. 
    939 </t> 
    940 </section> 
    941  
    942 <section title="Transparent Negotiation" anchor="transparent.negotiation"> 
    943 <t> 
    944    Transparent negotiation is a combination of both server-driven and 
    945    agent-driven negotiation. When a cache is supplied with a form of the 
    946    list of available representations of the response (as in agent-driven 
    947    negotiation) and the dimensions of variance are completely understood 
    948    by the cache, then the cache becomes capable of performing server-driven 
    949    negotiation on behalf of the origin server for subsequent 
    950    requests on that resource. 
    951 </t> 
    952 <t> 
    953    Transparent negotiation has the advantage of distributing the 
    954    negotiation work that would otherwise be required of the origin 
    955    server and also removing the second request delay of agent-driven 
    956    negotiation when the cache is able to correctly guess the right 
    957    response. 
    958 </t> 
    959 <t> 
    960    This specification does not define any mechanism for transparent 
    961    negotiation, though it also does not prevent any such mechanism from 
    962    being developed as an extension that could be used within HTTP/1.1. 
    963955</t> 
    964956</section> 
     
    22832275</reference> 
    22842276 
     2277<reference anchor='RFC2295'> 
     2278  <front> 
     2279    <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title> 
     2280    <author initials='K.' surname='Holtman' fullname='Koen Holtman'> 
     2281      <organization>Technische Universiteit Eindhoven</organization> 
     2282      <address> 
     2283        <email>koen@win.tue.nl</email> 
     2284      </address> 
     2285    </author> 
     2286    <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'> 
     2287      <organization>Hewlett-Packard Company</organization> 
     2288      <address> 
     2289        <email>mutz@hpl.hp.com</email> 
     2290      </address> 
     2291    </author> 
     2292    <date year='1998' month='March'/> 
     2293  </front> 
     2294  <seriesInfo name='RFC' value='2295'/> 
     2295</reference> 
     2296 
    22852297<reference anchor="RFC2388"> 
    22862298  <front> 
     
    30793091  <list style="symbols">  
    30803092    <t> 
     3093      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/81"/>: 
     3094      "Content Negotiation for media types" 
     3095    </t> 
     3096    <t> 
    30813097      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/181"/>: 
    30823098      "Accept-Language: which RFC4647 filtering?" 
Note: See TracChangeset for help on using the changeset viewer.