Ticket #285: 285.diff

p2-semantics.xml

@@ -73 +73 @@
   <!ENTITY status-407                 "<xref target='Part7' x:rel='#status.407' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-412                 "<xref target='Part4' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-416                 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY p3-header-fields           "<xref target='Part3' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY p4-status-codes            "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY p5-status-codes            "<xref target='Part5' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY p7-status-codes            "<xref target='Part7' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -1816 +1817 @@
 <t>
    The resource identified by the request is only capable of generating
    response representations which have content characteristics not acceptable
-   according to the accept header fields sent in the request.
+   according to the Accept and Accept-* header fields sent in the request
+   (see &p3-header-fields;).
 </t>
 <t>
    Unless it was a HEAD request, the response &SHOULD; include a representation
@@ -4157 +4159 @@
 
 <section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15">
 <t>
-  None yet.
+  Closed issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
+      "Strength of requirements on Accept re: 406"
+    </t>
+  </list>
 </t>
 </section>
 </section>

p3-payload.xml

@@ -844 +844 @@
   </list>
 </t>
 <t>
+   Server-driven negotiation allows the user agent to specify its preferences,
+   but it cannot expect responses to always honour them. For example, the origin
+   server might not implement server-driven negotiation, or it might decide that
+   sending a response that doesn't conform to them is better than sending a 406
+   (Not Acceptable) response.
+</t>
+<t>
+   Many of the mechanisms for expressing preferences use quality values to
+   declare relative preference. See &qvalue; for more information. 
+</t>
+<t>
    HTTP/1.1 includes the following header fields for enabling
    server-driven negotiation through description of user agent
    capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
@@ -972 +983 @@
 </t>
 <t>
    If no Accept header field is present, then it is assumed that the
-   client accepts all media types. If an Accept header field is present,
-   and if the server cannot send a response which is acceptable
-   according to the combined Accept field value, then the server &SHOULD;
-   send a 406 (Not Acceptable) response.
+   client accepts all media types. If an Accept header field is present in a
+   request, but the server cannot send a response which is acceptable, then
+   the server can either send a response in another format, or a 406 (Not
+   Acceptable) response. 
 </t>
 <t>
    A more elaborate example is
@@ -1069 +1080 @@
 </t>
 <t>
    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 &SHOULD; send
-   an error response with the 406 (Not Acceptable) status code, though
-   the sending of an unacceptable response is also allowed.
+   character encoding is acceptable. If an Accept-Charset header field is
+   present in a request, but the server cannot send a response which is
+   acceptable, then the server can either use another character encoding, or
+   send a 406 (Not Acceptable) response.
 </t>
 </section>
 
@@ -1130 +1140 @@
   </list>
 </t>
 <t>
-   If an Accept-Encoding field is present in a request, and if the
-   server cannot send a response which is acceptable according to the
-   Accept-Encoding header field, then the server &SHOULD; send an error response
-   with the 406 (Not Acceptable) status code.
+   If an Accept-Encoding field is present in a request, but the server cannot
+   send a response which is acceptable, then the server &SHOULD; send a
+   response without any encoding (i.e., the "identity" encoding).
 </t>
 <t>
    If no Accept-Encoding field is present in a request, the server &MAY;
@@ -3010 +3019 @@
 
 <section title="Since draft-ietf-httpbis-p3-payload-15" anchor="changes.since.15">
 <t>
-  None yet.
+  Closed issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
+      "Strength of requirements on Accept re: 406"
+    </t>
+  </list>
 </t>
 </section>