Ignore:
Timestamp:
Mar 24, 2009, 1:48:26 PM (11 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.xml

    r547 r563  
    350350   to determine the exact mapping is not permitted.
    351351</t>
    352 <t><list><t>
    353       <x:h>Note:</x:h> This use of the term "character set" is more commonly
    354       referred to as a "character encoding." However, since HTTP and
    355       MIME share the same registry, it is important that the terminology
    356       also be shared.
    357 </t></list></t>
     352<x:note>
     353  <t>
     354    <x:h>Note:</x:h> This use of the term "character set" is more commonly
     355    referred to as a "character encoding." However, since HTTP and
     356    MIME share the same registry, it is important that the terminology
     357    also be shared.
     358  </t>
     359</x:note>
    358360<t anchor="rule.charset">
    359361  <x:anchor-alias value="charset"/>
     
    603605   application &MUST; treat it as being equivalent to "multipart/mixed".
    604606</t>
    605 <t><list><t>
    606       <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
    607       for carrying form data suitable for processing via the POST
    608       request method, as described in <xref target="RFC2388"/>.
    609 </t></list></t>
     607<x:note>
     608  <t>
     609    <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
     610    for carrying form data suitable for processing via the POST
     611    request method, as described in <xref target="RFC2388"/>.
     612  </t>
     613</x:note>
    610614</section>
    611615</section>
     
    756760   the process of selecting the best representation for a given response
    757761   when there are multiple representations available.
    758   <list><t>
    759       <x:h>Note:</x:h> This is not called "format negotiation" because the
    760       alternate representations may be of the same media type, but use
    761       different capabilities of that type, be in different languages,
    762       etc.
    763   </t></list>
    764 </t>
     762</t>
     763<x:note>
     764  <t>
     765    <x:h>Note:</x:h> This is not called "format negotiation" because the
     766    alternate representations may be of the same media type, but use
     767    different capabilities of that type, be in different languages,
     768    etc.
     769  </t>
     770</x:note>
    765771<t>
    766772   Any response containing an entity-body &MAY; be subject to negotiation,
     
    954960   media-range, using the qvalue scale from 0 to 1 (&qvalue;). The
    955961   default value is q=1.
    956   <list><t>
    957       <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
    958       parameters from Accept extension parameters is due to historical
    959       practice. Although this prevents any media type parameter named
    960       "q" from being used with a media range, such an event is believed
    961       to be unlikely given the lack of any "q" parameters in the IANA
    962       media type registry and the rare usage of any media type
    963       parameters in Accept. Future media types are discouraged from
    964       registering any parameter named "q".
    965   </t></list>
    966 </t>
     962</t>
     963<x:note>
     964  <t>
     965    <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
     966    parameters from Accept extension parameters is due to historical
     967    practice. Although this prevents any media type parameter named
     968    "q" from being used with a media range, such an event is believed
     969    to be unlikely given the lack of any "q" parameters in the IANA
     970    media type registry and the rare usage of any media type
     971    parameters in Accept. Future media types are discouraged from
     972    registering any parameter named "q".
     973  </t>
     974</x:note>
    967975<t>
    968976   The example
     
    11541162   additional information that a different content-coding is meaningful
    11551163   to the client.
    1156   <list><t>
    1157       <x:h>Note:</x:h> If the request does not include an Accept-Encoding field,
    1158       and if the "identity" content-coding is unavailable, then
    1159       content-codings commonly understood by HTTP/1.0 clients (i.e.,
    1160       "gzip" and "compress") are preferred; some older clients
    1161       improperly display messages sent with other content-codings.  The
    1162       server might also make this decision based on information about
    1163       the particular user-agent or client.
    1164     </t><t>
    1165       <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
    1166       associated with content-codings. This means that qvalues will not
    1167       work and are not permitted with x-gzip or x-compress.
    1168     </t></list>
    1169 </t>
     1164</t>
     1165<x:note>
     1166  <t>
     1167    <x:h>Note:</x:h> If the request does not include an Accept-Encoding field,
     1168    and if the "identity" content-coding is unavailable, then
     1169    content-codings commonly understood by HTTP/1.0 clients (i.e.,
     1170    "gzip" and "compress") are preferred; some older clients
     1171    improperly display messages sent with other content-codings.  The
     1172    server might also make this decision based on information about
     1173    the particular user-agent or client.
     1174  </t>
     1175</x:note>
     1176<x:note>
     1177  <t>
     1178    <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
     1179    associated with content-codings. This means that qvalues will not
     1180    work and are not permitted with x-gzip or x-compress.
     1181  </t>
     1182</x:note>
    11701183</section>
    11711184
     
    12181231   matches every tag not matched by any other range present in the
    12191232   Accept-Language field.
    1220   <list><t>
    1221       <x:h>Note:</x:h> This use of a prefix matching rule does not imply that
    1222       language tags are assigned to languages in such a way that it is
    1223       always true that if a user understands a language with a certain
    1224       tag, then this user will also understand all languages with tags
    1225       for which this tag is a prefix. The prefix rule simply allows the
    1226       use of prefix tags if this is the case.
    1227   </t></list>
    1228 </t>
     1233</t>
     1234<x:note>
     1235  <t>
     1236    <x:h>Note:</x:h> This use of a prefix matching rule does not imply that
     1237    language tags are assigned to languages in such a way that it is
     1238    always true that if a user understands a language with a certain
     1239    tag, then this user will also understand all languages with tags
     1240    for which this tag is a prefix. The prefix rule simply allows the
     1241    use of prefix tags if this is the case.
     1242  </t>
     1243</x:note>
    12291244<t>
    12301245   The language quality factor assigned to a language-tag by the
     
    12501265   available, then the Accept-Language header field &MUST-NOT; be given in
    12511266   the request.
    1252   <list><t>
    1253       <x:h>Note:</x:h> When making the choice of linguistic preference available to
    1254       the user, we remind implementors of  the fact that users are not
    1255       familiar with the details of language matching as described above,
    1256       and should provide appropriate guidance. As an example, users
    1257       might assume that on selecting "en-gb", they will be served any
    1258       kind of English document if British English is not available. A
    1259       user agent might suggest in such a case to add "en" to get the
    1260       best matching behavior.
    1261   </t></list>
    1262 </t>
     1267</t>
     1268<x:note>
     1269  <t>
     1270    <x:h>Note:</x:h> When making the choice of linguistic preference available to
     1271    the user, we remind implementors of  the fact that users are not
     1272    familiar with the details of language matching as described above,
     1273    and should provide appropriate guidance. As an example, users
     1274    might assume that on selecting "en-gb", they will be served any
     1275    kind of English document if British English is not available. A
     1276    user agent might suggest in such a case to add "en" to get the
     1277    best matching behavior.
     1278  </t>
     1279</x:note>
    12631280</section>
    12641281
     
    14771494   the text actually transmitted &MUST; be left unaltered when computing
    14781495   the digest.
    1479   <list><t>
    1480       <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for
    1481       HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
    1482       in which the application of Content-MD5 to HTTP entity-bodies
    1483       differs from its application to MIME entity-bodies. One is that
    1484       HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
    1485       does use Transfer-Encoding and Content-Encoding. Another is that
    1486       HTTP more frequently uses binary content types than MIME, so it is
    1487       worth noting that, in such cases, the byte order used to compute
    1488       the digest is the transmission byte order defined for the type.
    1489       Lastly, HTTP allows transmission of text types with any of several
    1490       line break conventions and not just the canonical form using CRLF.
    1491   </t></list>
    1492 </t>
     1496</t>
     1497<x:note>
     1498  <t>
     1499    <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for
     1500    HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
     1501    in which the application of Content-MD5 to HTTP entity-bodies
     1502    differs from its application to MIME entity-bodies. One is that
     1503    HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
     1504    does use Transfer-Encoding and Content-Encoding. Another is that
     1505    HTTP more frequently uses binary content types than MIME, so it is
     1506    worth noting that, in such cases, the byte order used to compute
     1507    the digest is the transmission byte order defined for the type.
     1508    Lastly, HTTP allows transmission of text types with any of several
     1509    line break conventions and not just the canonical form using CRLF.
     1510  </t>
     1511</x:note>
    14931512</section>
    14941513
Note: See TracChangeset for help on using the changeset viewer.