Changeset 1875 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

Sep 9, 2012, 7:46:17 PM (7 years ago)

Author:

fielding@…

Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (5 diffs)

draft-ietf-httpbis/latest/p6-cache.xml

@@ -18 +18 @@
   <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
   <!ENTITY architecture                "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY conformance                 "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -298 +299 @@
 </section>
 
-<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
+<section title="Conformance and Error Handling" anchor="conformance">
 <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -305 +306 @@
 </t>
 <t>
-   This specification targets conformance criteria according to the role of
-   a participant in HTTP communication.  Hence, HTTP requirements are placed
-   on senders, recipients, clients, servers, user agents, intermediaries,
-   origin servers, proxies, gateways, or caches, depending on what behavior
-   is being constrained by the requirement. See &architecture; for definitions
-   of these terms.
-</t>
-<t>
-   The verb "generate" is used instead of "send" where a requirement
-   differentiates between creating a protocol element and merely forwarding a
-   received element downstream.
-</t>
-<t>
-   An implementation is considered conformant if it complies with all of the
-   requirements associated with the roles it partakes in HTTP. Note that
-   SHOULD-level requirements are relevant here, unless one of the documented
-   exceptions is applicable.
-</t>
-<t>
-   This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>).
-   In addition to the prose requirements placed upon them, senders &MUST-NOT;
-   generate protocol elements that do not match the grammar defined by the
-   ABNF rules for those protocol elements that are applicable to the sender's
-   role. If a received protocol element is processed, the recipient &MUST; be
-   able to parse any value that would match the ABNF rules for that protocol
-   element, excluding only those rules not applicable to the recipient's role.
-</t>
-<t>
-   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
-   protocol element from an invalid construct.  HTTP does not define
-   specific error handling mechanisms except when they have a direct impact
-   on security, since different applications of the protocol require
-   different error handling strategies.  For example, a Web browser might
-   wish to transparently recover from a response where the
-   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
-   whereas a systems control client might consider any form of error recovery
-   to be dangerous.
+   Conformance criteria and considerations regarding error handling
+   are defined in &conformance;.
 </t>
 </section>
@@ -816 +781 @@
 <t>
   <list style="symbols">
-     <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date
+     <t>Recipients &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>
@@ -824 +789 @@
         case-insensitively.</t>
              
-     <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
+     <t>An implementation &MAY; internally represent a parsed
         <x:ref>Expires</x:ref> 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
+     <t>Recipients &MUST; perform all expiration-related calculations in GMT.
+        The local time zone &MUST-NOT; influence the calculation or comparison
         of an age or expiration time.</t>