Ignore:
Timestamp:
24/03/09 20:48:26 (14 years ago)
Author:
julian.reschke@…
Message:

replace <list> elements used for indentation by <x:note> elements

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r560 r563  
    3636cite {
    3737  font-style: normal;
     38}
     39div.note {
     40  margin-left: 2em;
    3841}
    3942dd {
    … …  
    475478         <tr>
    476479            <td class="header left"></td>
    477             <td class="header right">March 12, 2009</td>
     480            <td class="header right">March 24, 2009</td>
    478481         </tr>
    479482      </table>
    … …  
    670673         to determine the exact mapping is not permitted.
    671674      </p>
    672       <dl class="empty">
    673          <dd> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
     675      <div class="note">
     676         <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
    674677            share the same registry, it is important that the terminology also be shared.
    675          </dd>
    676       </dl>
     678         </p>
     679      </div>
    677680      <div id="rule.charset">
    678681         <p id="rfc.section.2.1.p.4">  HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character
    … …  
    800803         an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    801804      </p>
    802       <dl class="empty">
    803          <dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
     805      <div class="note">
     806         <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
    804807            method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>.
    805          </dd>
    806       </dl>
     808         </p>
     809      </div>
    807810      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="language.tags" href="#language.tags">Language Tags</a></h2>
    808811      <p id="rfc.section.2.4.p.1">A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information
    … …  
    876879         all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity
    877880         types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the
    878          best representation for a given response when there are multiple representations available. 
    879       </p>
    880       <dl class="empty">
    881          <dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
     881         best representation for a given response when there are multiple representations available.
     882      </p>
     883      <div class="note">
     884         <p> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
    882885            capabilities of that type, be in different languages, etc.
    883          </dd>
    884       </dl>
    885       <p id="rfc.section.4.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.
    886       </p>
    887       <p id="rfc.section.4.p.3">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two
     886         </p>
     887      </div>
     888      <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.
     889      </p>
     890      <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
    888891         kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred
    889892         to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server
    … …  
    978981      <p id="rfc.section.5.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    979982         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    980          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 
    981       </p>
    982       <dl class="empty">
    983          <dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
     983         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     984      </p>
     985      <div class="note">
     986         <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
    984987            Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
    985988            be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
    986989            in Accept. Future media types are discouraged from registering any parameter named "q".
    987          </dd>
    988       </dl>
    989       <p id="rfc.section.5.1.p.5">The example</p>
     990         </p>
     991      </div>
     992      <p id="rfc.section.5.1.p.6">The example</p>
    990993      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    991 </pre><p id="rfc.section.5.1.p.7"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
     994</pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    992995         quality."
    993996      </p>
    994       <p id="rfc.section.5.1.p.8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
     997      <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    995998         is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
    996999         the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
    9971000      </p>
    998       <p id="rfc.section.5.1.p.9">A more elaborate example is</p>
     1001      <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
    9991002      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10001003          text/x-dvi; q=0.8, text/x-c
    1001 </pre><p id="rfc.section.5.1.p.11">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
     1004</pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    10021005         send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
    10031006      </p>
    1004       <p id="rfc.section.5.1.p.12">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
     1007      <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    10051008         to a given type, the most specific reference has precedence. For example,
    10061009      </p>
    10071010      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
    1008 </pre><p id="rfc.section.5.1.p.14">have the following precedence: </p>
     1011</pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
    10091012      <ol>
    10101013         <li>text/html;level=1</li>
    … …  
    10131016         <li>*/*</li>
    10141017      </ol>
    1015       <p id="rfc.section.5.1.p.15">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
     1018      <p id="rfc.section.5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
    10161019         which matches that type. For example,
    10171020      </p>
    10181021      <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10191022          text/html;level=2;q=0.4, */*;q=0.5
    1020 </pre><p id="rfc.section.5.1.p.17">would cause the following values to be associated:</p>
     1023</pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
    10211024      <div id="rfc.table.u.1">
    10221025         <table summary="" class="tt full" cellpadding="3" cellspacing="0">
    … …  
    10551058         </table>
    10561059      </div>
    1057       <p id="rfc.section.5.1.p.18"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
     1060      <p id="rfc.section.5.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
    10581061         is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
    10591062      </p>
    … …  
    11181121      <p id="rfc.section.5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
    11191122         then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the
    1120          client. 
    1121       </p>
    1122       <dl class="empty">
    1123          <dd> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
     1123         client.
     1124      </p>
     1125      <div class="note">
     1126         <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    11241127            commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    11251128            messages sent with other content-codings. The server might also make this decision based on information about the particular
    11261129            user-agent or client.
    1127          </dd>
    1128          <dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
     1130         </p>
     1131      </div>
     1132      <div class="note">
     1133         <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    11291134            not work and are not permitted with x-gzip or x-compress.
    1130          </dd>
    1131       </dl>
     1135         </p>
     1136      </div>
    11321137      <div id="rfc.iref.a.4"></div>
    11331138      <div id="rfc.iref.h.4"></div>
    … …  
    11551160      </blockquote>
    11561161      <p id="rfc.section.5.4.p.8">The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in
    1157          the Accept-Language field. 
    1158       </p>
    1159       <dl class="empty">
    1160          <dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always
     1162         the Accept-Language field.
     1163      </p>
     1164      <div class="note">
     1165         <p> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always
    11611166            true that if a user understands a language with a certain tag, then this user will also understand all languages with tags
    11621167            for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
    1163          </dd>
    1164       </dl>
    1165       <p id="rfc.section.5.4.p.9">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range
     1168         </p>
     1169      </div>
     1170      <p id="rfc.section.5.4.p.10">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range
    11661171         in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor
    11671172         assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned
    11681173         a quality factor greater than 0 are acceptable.
    11691174      </p>
    1170       <p id="rfc.section.5.4.p.10">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
     1175      <p id="rfc.section.5.4.p.11">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
    11711176         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;7.1</a>.
    11721177      </p>
    1173       <p id="rfc.section.5.4.p.11">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    1174          of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 
    1175       </p>
    1176       <dl class="empty">
    1177          <dd> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
     1178      <p id="rfc.section.5.4.p.12">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
     1179         of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request.
     1180      </p>
     1181      <div class="note">
     1182         <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    11781183            familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
    11791184            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    11801185            A user agent might suggest in such a case to add "en" to get the best matching behavior.
    1181          </dd>
    1182       </dl>
     1186         </p>
     1187      </div>
    11831188      <div id="rfc.iref.c.2"></div>
    11841189      <div id="rfc.iref.h.5"></div>
    … …  
    12791284         The Transfer-Encoding header field is not allowed within body-parts.
    12801285      </p>
    1281       <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 
    1282       </p>
    1283       <dl class="empty">
    1284          <dd> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
     1286      <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
     1287      </p>
     1288      <div class="note">
     1289         <p> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
    12851290            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
    12861291            is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another
    … …  
    12881293            used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types
    12891294            with any of several line break conventions and not just the canonical form using CRLF.
    1290          </dd>
    1291       </dl>
     1295         </p>
     1296      </div>
    12921297      <div id="rfc.iref.c.6"></div>
    12931298      <div id="rfc.iref.h.9"></div>
Note: See TracChangeset for help on using the changeset viewer.