Ticket #20: i20.2.diff

File i20.2.diff, 4.6 KB (added by julian.reschke@…, 9 years ago)

new path, now also removing the special case for Accept-Encoding

  • p3-payload.xml

     
    367367   Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>
    368368   <xref target="RFC2277"/>.
    369369</t>
    370 
    371 <section title="Missing Charset" anchor="missing.charset">
    372 <t>
    373    Some HTTP/1.0 software has interpreted a Content-Type header field without
    374    charset parameter incorrectly to mean "recipient should guess".
    375    Senders wishing to defeat this behavior &MAY; include a charset
    376    parameter even when the charset is ISO-8859-1 (<xref target="ISO-8859-1"/>) and &SHOULD; do so when
    377    it is known that it will not confuse the recipient.
    378 </t>
    379 <t>
    380    Unfortunately, some older HTTP/1.0 clients did not deal properly with
    381    an explicit charset parameter. HTTP/1.1 recipients &MUST; respect the
    382    charset label provided by the sender; and those user agents that have
    383    a provision to "guess" a charset &MUST; use the charset from the
    384    content-type field if they support that charset, rather than the
    385    recipient's preference, when initially displaying a document. See
    386    <xref target="canonicalization.and.text.defaults"/>.
    387 </t>
    388370</section>
    389 </section>
    390371
    391372<section title="Content Codings" anchor="content.codings">
    392373  <x:anchor-alias value="content-coding"/>
     
    554535   If a representation is encoded with a content-coding, the underlying
    555536   data &MUST; be in a form defined above prior to being encoded.
    556537</t>
    557 <t>
    558    The "charset" parameter is used with some media types to define the
    559    character encoding (<xref target="character.sets"/>) of the data. When no explicit charset
    560    parameter is provided by the sender, media subtypes of the "text"
    561    type are defined to have a default charset value of "ISO-8859-1" when
    562    received via HTTP. Data in character encodings other than "ISO-8859-1" or
    563    its subsets &MUST; be labeled with an appropriate charset value. See
    564    <xref target="missing.charset"/> for compatibility problems.
    565 </t>
    566538</section>
    567539
    568540<section title="Multipart Types" anchor="multipart.types">
     
    10881060</artwork></figure>
    10891061<t>
    10901062   The special value "*", if present in the Accept-Charset field,
    1091    matches every character encoding (including ISO-8859-1) which is not
    1092    mentioned elsewhere in the Accept-Charset field. If no "*" is present
    1093    in an Accept-Charset field, then all character encodings not explicitly
    1094    mentioned get a quality value of 0, except for ISO-8859-1, which gets
    1095    a quality value of 1 if not explicitly mentioned.
     1063   matches every character encoding which is not mentioned elsewhere in the
     1064   Accept-Charset field. If no "*" is present in an Accept-Charset field, then
     1065   all character encodings not explicitly mentioned get a quality value of 0.
    10961066</t>
    10971067<t>
    10981068   If no Accept-Charset header field is present, the default is that any
     
    17211691
    17221692<references title="Normative References">
    17231693
    1724 <reference anchor="ISO-8859-1">
    1725   <front>
    1726     <title>
    1727      Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1
    1728     </title>
    1729     <author>
    1730       <organization>International Organization for Standardization</organization>
    1731     </author>
    1732     <date year="1998"/>
    1733   </front>
    1734   <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
    1735 </reference>
    1736 
    17371694<reference anchor="Part1">
    17381695  <front>
    17391696    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
     
    26002557  (<xref target="character.sets"/>)
    26012558</t>
    26022559<t>
     2560  Remove the default character encoding for text media types; the default
     2561  now is whatever the media type definition says.
     2562  (<xref target="canonicalization.and.text.defaults"/>)
     2563</t>
     2564<t>
    26032565  Change ABNF productions for header fields to only define the field value.
    26042566  (<xref target="header.fields"/>)
    26052567</t>
    26062568<t>
     2569  Remove ISO-8859-1 special-casing in Accept-Charset.
     2570  (<xref target="header.accept-charset"/>)
     2571</t>
     2572<t>
    26072573  Remove base URI setting semantics for Content-Location due to poor
    26082574  implementation support, which was caused by too many broken servers emitting
    26092575  bogus Content-Location header fields, and also the potentially undesirable effect
     
    30753041  Closed issues:
    30763042  <list style="symbols">
    30773043    <t>
     3044      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/20"/>:
     3045      "Default charsets for text media types"
     3046    </t>
     3047    <t>
    30783048      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
    30793049      "untangle ABNFs for header fields"
    30803050    </t>