Changeset 1177 for draft-ietf-httpbis/latest/p3-payload.html

Timestamp:

14/03/11 03:25:50 (9 years ago)

Author:

fielding@…

Message:

update generated HTML

File:

• draft-ietf-httpbis/latest/p3-payload.html (modified) (7 diffs)

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

@@ -546 +546 @@
          </li>
          <li>2.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
-               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#character.sets">Character Sets</a><ul>
+               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#character.sets">Character Encodings (charset)</a><ul>
                      <li>2.1.1&nbsp;&nbsp;&nbsp;<a href="#missing.charset">Missing Charset</a></li>
                   </ul>
@@ -685 +685 @@
   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
-      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Sets</a></h2>
-      <p id="rfc.section.2.1.p.1">HTTP uses the same definition of the term "character set" as that described for MIME:</p>
-      <p id="rfc.section.2.1.p.2">The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence
-         of octets into a sequence of characters. Note that unconditional conversion in the other direction is not required, in that
-         not all characters might be available in a given character set and a character set might provide more than one sequence of
-         octets to represent a particular character. This definition is intended to allow various kinds of character encoding, from
-         simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO-2022's techniques.
-         However, the definition associated with a MIME character set name <em class="bcp14">MUST</em> fully specify the mapping to be performed from octets to characters. In particular, use of external profiling information
-         to determine the exact mapping is not permitted.
-      </p>
-      <div class="note" id="rfc.section.2.1.p.3"> 
-         <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
-            share the same registry, it is important that the terminology also be shared.
-         </p> 
-      </div>
+      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
+      <p id="rfc.section.2.1.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p>
       <div id="rule.charset">
-         <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
+         <p id="rfc.section.2.1.p.2">  A character encoding is identified by a case-insensitive token. The complete set of tokens is defined by the IANA Character
             Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;).
          </p>
       </div>
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a>
-</pre><p id="rfc.section.2.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA
-         Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry.
-      </p>
-      <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
+</pre><p id="rfc.section.2.1.p.4">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA
+         Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry.
+      </p>
+      <p id="rfc.section.2.1.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
          token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
          value of the charset parameter can be quoted.
       </p>
-      <p id="rfc.section.2.1.p.8">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
+      <p id="rfc.section.2.1.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
       </p>
       <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>
@@ -810 +797 @@
       <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
       </p>
-      <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
+      <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
          to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1"
          or its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section&nbsp;2.1.1</a> for compatibility problems.
@@ -1151 +1138 @@
       <div id="rfc.iref.h.2"></div>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
-      <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what response character sets are acceptable. This
-         field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
-         to a server which is capable of representing documents in those character sets.
+      <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response
+         payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal
+         that capability to a server which is capable of representing documents in those character encodings.
       </p>
       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
@@ -1159 +1146 @@
   <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
                          [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
-</pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
+</pre><p id="rfc.section.6.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
          example is
       </p>
       <div id="rfc.figure.u.16"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
-</pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
-         not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
-         not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly
-         mentioned.
-      </p>
-      <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character set is acceptable. If an Accept-Charset header
-         field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header field,
-         then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
+</pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding (including ISO-8859-1) which
+         is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character
+         encodings not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not
+         explicitly mentioned.
+      </p>
+      <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character encoding is acceptable. If an Accept-Charset
+         header field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header
+         field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
       </p>
       <div id="rfc.iref.a.3"></div>
@@ -1773 +1760 @@
       </p>
       <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
-         a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent
-         CR and LF, as is the case for some multi-byte character sets.
+         a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10
+         to represent CR and LF, respectively, as is the case for some multi-byte character encodings.
       </p>
       <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
@@ -1813 +1800 @@
       </p>
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
-      <p id="rfc.section.C.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>)
+      <p id="rfc.section.C.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;2.1</a>)
       </p>
       <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken