Ignore:
Timestamp:
Jul 23, 2010, 2:19:25 AM (9 years ago)
Author:
julian.reschke@…
Message:

change citing style to match RFC Editor expectations (see <http://www.rfc-editor.org/rfc-style-guide/rfc-style>, Section 3.3)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r878 r879  
    715715      </p>
    716716      <div class="note" id="rfc.section.2.1.p.3">
    717          <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
     717         <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
    718718            share the same registry, it is important that the terminology also be shared.
    719719         </p>
     
    736736      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
    737737      <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should
    738          guess." Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
     738         guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
    739739      </p>
    740740      <p id="rfc.section.2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially
     
    10311031      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    10321032</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
    1033          quality."
     1033         quality".
    10341034      </p>
    10351035      <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
     
    10411041          text/x-dvi; q=0.8, text/x-c
    10421042</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
    1043          send the text/x-dvi representation, and if that does not exist, send the text/plain representation."
     1043         send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
    10441044      </p>
    10451045      <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
     
    11431143      <ol>
    11441144         <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1145             is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable.")
     1145            is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    11461146         </li>
    11471147         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
     
    11891189      </p>
    11901190      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    1191 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
     1191</pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    11921192      </p>
    11931193      <p id="rfc.section.5.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
     
    12491249         it is intended.
    12501250      </p>
    1251       <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented
     1251      <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
    12521252         simultaneously in the original Maori and English versions, would call for
    12531253      </p>
    12541254      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
    12551255</pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    1256          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
     1256         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    12571257         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    12581258      </p>
Note: See TracChangeset for help on using the changeset viewer.