Changeset 2119 for draft-ietf-httpbis/latest

Timestamp:

13/01/13 10:22:41 (10 years ago)

Author:

fielding@…

Message:

Accept-Language: clean up prose and note descending order of priority for equal weights (as defined in RFC4647 and original HTTP); partly addresses #426

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1999 +1999 @@
       </p>
       <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
-</pre><p id="rfc.section.5.3.5.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>)
-      </p>
-      <p id="rfc.section.5.3.5.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.
-      </p>
-      <div class="note" id="rfc.section.5.3.5.p.7"> 
-         <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
-         </p> 
-      </div>
-      <p id="rfc.section.5.3.5.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
+</pre><p id="rfc.section.5.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". If no quality values are assigned
+         or multiple language tags have been assigned the same quality, the same-weighted languages are listed in descending order
+         of priority. Additional discussion of language priority lists can be found in <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>.
+      </p>
+      <p id="rfc.section.5.3.5.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. The
+         "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined for HTTP in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
+      </p>
+      <p id="rfc.section.5.3.5.p.7">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
          preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section&nbsp;9.6</a>).
       </p>
-      <p id="rfc.section.5.3.5.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
-         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.
-      </p>
-      <div class="note" id="rfc.section.5.3.5.p.10"> 
-         <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementers of the fact that users are not
-            familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example,
-            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
-            A user agent might suggest in such a case to add "en" to get the best matching behavior.
+      <p id="rfc.section.5.3.5.p.8">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic
+         preference. A user agent that does not provide such control to the user <em class="bcp14">MUST NOT</em> send an Accept-Language header field.
+      </p>
+      <div class="note" id="rfc.section.5.3.5.p.9"> 
+         <p> <b>Note:</b> User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details
+            of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any
+            kind of English document if British English is not available. A user agent might suggest, in such a case, to add "en" to the
+            list for better matching behavior.
          </p> 
       </div>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -2320 +2320 @@
 <t>
    would mean: "I prefer Danish, but will accept British English and
-   other types of English". (See also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
+   other types of English". If no quality values are assigned or multiple
+   language tags have been assigned the same quality, the same-weighted
+   languages are listed in descending order of priority.
+   Additional discussion of language priority lists can be found in
+   <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>.
 </t>
 <t>
    For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines 
    several matching schemes. Implementations can offer the most appropriate
-   matching scheme for their requirements. 
-</t>
-<x:note>
-  <t>
-    &Note; The "Basic Filtering" scheme (<xref target="RFC4647"
-    x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
-    previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
-  </t>
-</x:note>
+   matching scheme for their requirements. The "Basic Filtering" scheme
+   (<xref target="RFC4647" x:fmt="," x:sec="3.3.1"/>) is identical to the
+   matching scheme that was previously defined for HTTP in
+   <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
+</t>
 <t>
    It might be contrary to the privacy expectations of the user to send
@@ -2340 +2340 @@
 </t>
 <t>
-   As intelligibility is highly dependent on the individual user, it is
-   recommended that client applications make the choice of linguistic
-   preference available to the user. If the choice is not made
-   available, then the Accept-Language header field &MUST-NOT; be given in
-   the request.
+   Since intelligibility is highly dependent on the individual user,
+   user agents need to allow user control over the linguistic preference.
+   A user agent that does not provide such control to the user &MUST-NOT;
+   send an Accept-Language header field.
 </t>
 <x:note>
   <t>
-    &Note; When making the choice of linguistic preference available to
-    the user, we remind implementers of  the fact that users are not
-    familiar with the details of language matching as described above,
-    and ought to be provided appropriate guidance. As an example, users
-    might assume that on selecting "en-gb", they will be served any
-    kind of English document if British English is not available. A
-    user agent might suggest in such a case to add "en" to get the
-    best matching behavior.
+    &Note; User agents ought to provide guidance to users when setting a
+    preference, since users are rarely familiar with the details of language
+    matching as described above. For example, users might assume that on
+    selecting "en-gb", they will be served any kind of English document if
+    British English is not available. A user agent might suggest, in such a
+    case, to add "en" to the list for better matching behavior.
   </t>
 </x:note>