Changeset 2291 for draft-ietf-httpbis/latest

Timestamp:

12/06/13 08:26:28 (10 years ago)

Author:

julian.reschke@…

Message:

Add fallback discussion for Accept-Language (see #448). Also tune the statements for other Accept-* header fields (MAY->can).

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (8 diffs)
• p2-semantics.xml (modified) (4 diffs)

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

@@ -449 +449 @@
   }
   @bottom-center {
-       content: "Expires December 11, 2013";
+       content: "Expires December 14, 2013";
   }
   @bottom-right {
@@ -494 +494 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-06-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-06-12">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -522 +522 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">June 9, 2013</td>
+               <td class="right">June 12, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: December 11, 2013</td>
+               <td class="left">Expires: December 14, 2013</td>
                <td class="right"></td>
             </tr>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 11, 2013.</p>
+      <p>This Internet-Draft will expire on December 14, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1872 +1872 @@
          quality".
       </p>
-      <p id="rfc.section.5.3.2.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept
-         header field is present in a request and none of the available representations for the response have a media type that is
-         listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept header field by treating the response as if it is not subject to content negotiation.
+      <p id="rfc.section.5.3.2.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If the header
+         field is present in a request and none of the available representations for the response have a media type that is listed
+         as acceptable, the origin server can either honor the header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the header field by treating the response as if it is not subject to content negotiation.
       </p>
       <p id="rfc.section.5.3.2.p.10">A more elaborate example is</p>
@@ -1957 +1957 @@
       </p>
       <p id="rfc.section.5.3.3.p.7">If an Accept-Charset header field is present in a request and none of the available representations for the response has a
-         charset that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field, by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response, or disregard the Accept-Charset header field by treating the resource as if it is not subject to content negotiation.
+         charset that is listed as acceptable, the origin server can either honor the header field, by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response, or disregard the header field by treating the resource as if it is not subject to content negotiation.
       </p>
       <div id="rfc.iref.a.3"></div>
@@ -2012 +2012 @@
       <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".</p>
-      <p id="rfc.section.5.3.5.p.6">Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly
+      <p id="rfc.section.5.3.5.p.6">A request without any Accept-Language header field implies that the user agent will accept any language in response. If the
+         header field is present in a request and none of the available representations for the response have a matching language tag,
+         the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation,
+         or honor the header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able
+         to use (with translation software, for example).
+      </p>
+      <p id="rfc.section.5.3.5.p.7">Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly
          for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon.
          For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also
          listing them in order of decreasing quality. 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.7">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
+      <p id="rfc.section.5.3.5.p.8">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.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
+      <p id="rfc.section.5.3.5.p.9">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">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic
+      <p id="rfc.section.5.3.5.p.10">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.10"> 
+      <div class="note" id="rfc.section.5.3.5.p.11"> 
          <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
@@ -4498 +4504 @@
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/436">http://tools.ietf.org/wg/httpbis/trac/ticket/436</a>&gt;: "explain list expansion in ABNF appendices"
+         </li>
+         <li> &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448</a>&gt;: "Fallback for Accept-Language"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/449">http://tools.ietf.org/wg/httpbis/trac/ticket/449</a>&gt;: "Receiving a higher minor HTTP version number"

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

@@ -2127 +2127 @@
 <t>
    A request without any Accept header field implies that the user agent
-   will accept any media type in response.
-   If an Accept header field is present in a request and none of the
-   available representations for the response have a media type that is
-   listed as acceptable, the origin server &MAY; either honor the Accept
-   header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
-   or disregard the Accept header field by treating the response as if
-   it is not subject to content negotiation.
+   will accept any media type in response. If the header field is present in a
+   request and none of the available representations for the response have a
+   media type that is listed as acceptable, the origin server can either honor
+   the header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
+   or disregard the header field by treating the response as if it is not
+   subject to content negotiation.
 </t>
 <t>
@@ -2225 +2224 @@
 <t>
    A request without any Accept-Charset header field implies that the user
-   agent will accept any charset in response.
-   Most general-purpose user agents do not send Accept-Charset, unless
-   specifically configured to do so, because a detailed list of supported
-   charsets makes it easier for a server to identify an individual by virtue
-   of the user agent's request characteristics (<xref target="fingerprinting"/>).
+   agent will accept any charset in response. Most general-purpose user agents
+   do not send Accept-Charset, unless specifically configured to do so, because
+   a detailed list of supported charsets makes it easier for a server to
+   identify an individual by virtue of the user agent's request characteristics
+   (<xref target="fingerprinting"/>).
 </t>
 <t>
    If an Accept-Charset header field is present in a request and none of the
    available representations for the response has a charset that is listed as
-   acceptable, the origin server &MAY; either honor the Accept-Charset header
-   field, by sending a <x:ref>406 (Not Acceptable)</x:ref> response, or
-   disregard the Accept-Charset header field by treating the resource as if
-   it is not subject to content negotiation.
+   acceptable, the origin server can either honor the header field, by sending a
+   <x:ref>406 (Not Acceptable)</x:ref> response, or disregard the header field by
+   treating the resource as if it is not subject to content negotiation.
 </t>
 </section>
@@ -2340 +2338 @@
    would mean: "I prefer Danish, but will accept British English and
    other types of English".
+</t>
+<t>
+   A request without any Accept-Language header field implies that the user
+   agent will accept any language in response. If the header field is present
+   in a request and none of the available representations for the response have
+   a matching language tag, the origin server can either disregard the header
+   field by treating the response as if it is not subject to content
+   negotiation, or honor the header field by sending a <x:ref>406 (Not Acceptable)</x:ref>
+   response. However, the latter is not encouraged, as doing so can prevent
+   users from accessing content that they might be able to use (with
+   translation software, for example). 
 </t>
 <t>
@@ -6344 +6353 @@
     </t>
     <t>
+      <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448"/>:
+      "Fallback for Accept-Language"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/449"/>:
       "Receiving a higher minor HTTP version number"