Changeset 163 for draft-ietf-httpbis/latest/p4-conditional.html

Timestamp:

12/01/08 05:09:10 (14 years ago)

Author:

fielding@…

Message:

editorial: make introductions more active and consistent

File:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (4 diffs)

draft-ietf-httpbis/latest/p4-conditional.html

@@ -521 +521 @@
       </ul>
       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
-      <p id="rfc.section.1.p.1">This document defines aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right
-         now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> with only minor changes. This introduction will be revised in the next draft.
+      <p id="rfc.section.1.p.1">This document defines HTTP/1.1 response metadata for indicating potential changes to payload content, including modification
+         time stamps and opaque entity-tags, and the HTTP conditional request mechanisms that allow preconditions to be placed on a
+         request method. Conditional GET requests allow for efficient cache updates. Other conditional request methods are used to
+         protect against overwriting or misunderstanding the state of a resource that has been changed unbeknownst to the requesting
+         client.
+      </p>
+      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
+         errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections on
+         resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition
+         of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more
+         content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements
+         had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
       </p>
       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
@@ -756 +766 @@
          header <em class="bcp14">MUST</em> be ignored.
       </p>
-      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
+      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
       </p>
       <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
@@ -837 +847 @@
          If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
       </p>
-      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
+      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
       </p>
       <p id="rfc.section.6.4.p.9">Examples:</p>
@@ -1064 +1074 @@
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 15.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li>
+                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1</a>, <a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 15.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li>
                      </ul>
                   </li>