Changeset 1390 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Aug 8, 2011, 12:37:45 PM (8 years ago)

Author:

fielding@…

Message:

Be intolerant. Move cache date requirements hiding in appendix to p6.

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (6 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -430 +430 @@
 
 <section title="Basic Rules" anchor="basic.rules">
-<t anchor="rule.CRLF">
-  <x:anchor-alias value="CRLF"/>
-   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
-   protocol elements other than the message-body
-   (see <xref target="tolerant.applications"/> for tolerant applications).
-</t>
 <t anchor="rule.LWS">
    This specification uses three rules to denote the use of linear
@@ -1230 +1224 @@
    the server is reading the protocol stream at the beginning of a
    message and receives a CRLF first, it &SHOULD; ignore the CRLF.
+   Likewise, although the line terminator for the start-line and header
+   fields is the sequence CRLF, we recommend that recipients recognize a
+   single LF as a line terminator and ignore any CR.
 </t>
 <t>
@@ -1584 +1581 @@
    as incomplete.  A response that terminates in the middle of the header
    block (before the empty line is received) cannot be assumed to convey the
-   full semantics of the response and &MUST-NOT; be stored by a cache.
+   full semantics of the response and &MUST; be treated as an error.
 </t>
 <t>
@@ -2035 +2032 @@
    all three formats (for compatibility with HTTP/1.0), though they &MUST;
    only generate the RFC 1123 format for representing HTTP-date values
-   in header fields. See <xref target="tolerant.applications"/> for further information.
+   in header fields.
 </t>
 <t>
@@ -2934 +2931 @@
         respond with a 417 (Expectation Failed) status code.
     </t>
-    <t> Proxies &SHOULD; maintain a cache recording the HTTP version
+    <t> Proxies &SHOULD; maintain a record of the HTTP version
         numbers received from recently-referenced next-hop servers.
     </t>
@@ -4886 +4883 @@
 
 
-<section title="Tolerant Applications" anchor="tolerant.applications">
-<t>
-   Although this document specifies the requirements for the generation
-   of HTTP/1.1 messages, not all applications will be correct in their
-   implementation. We therefore recommend that operational applications
-   be tolerant of deviations whenever those deviations can be
-   interpreted unambiguously.
-</t>
-<t>
-   The line terminator for header fields is the sequence CRLF.
-   However, we recommend that applications, when parsing such headers fields,
-   recognize a single LF as a line terminator and ignore the leading CR.
-</t>
-<t>
-   The character encoding of a representation &SHOULD; be labeled as the lowest
-   common denominator of the character codes used within that representation, with
-   the exception that not labeling the representation is preferred over labeling
-   the representation with the labels US-ASCII or ISO-8859-1. See &payload;.
-</t>
-<t>
-   Additional rules for requirements on parsing and encoding of dates
-   and other potential problems with date encodings include:
-</t>
-<t>
-  <list style="symbols">
-     <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date
-        which appears to be more than 50 years in the future is in fact
-        in the past (this helps solve the "year 2000" problem).</t>
-
-     <t>Although all date formats are specified to be case-sensitive, 
-        recipients &SHOULD; match day, week and timezone names
-        case-insensitively.</t>
-             
-     <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
-        Expires date as earlier than the proper value, but &MUST-NOT;
-        internally represent a parsed Expires date as later than the
-        proper value.</t>
-
-     <t>All expiration-related calculations &MUST; be done in GMT. The
-        local time zone &MUST-NOT; influence the calculation or comparison
-        of an age or expiration time.</t>
-
-     <t>If an HTTP header field incorrectly carries a date value with a time
-        zone other than GMT, it &MUST; be converted into GMT using the
-        most conservative possible conversion.</t>
-  </list>
-</t>
-</section>
-
 <section title="HTTP Version History" anchor="compatibility">
 <t>