Changeset 1122 for draft-ietf-httpbis-content-disp

Timestamp:

Feb 17, 2011, 5:21:25 AM (9 years ago)

Author:

julian.reschke@…

Message:

s/Content-Location/Content?-Disposition/

Location:

draft-ietf-httpbis-content-disp/latest

Files:

• draft-ietf-httpbis-content-disp.html (modified) (2 diffs)
• draft-ietf-httpbis-content-disp.xml (modified) (3 diffs)

draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html

@@ -545 +545 @@
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="conformance.and.error.handling" href="#conformance.and.error.handling">Conformance and Error Handling</a></h1>
       <p id="rfc.section.3.p.1">This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP
-         user agents) of the Content-Location header field. An implementation is considered conformant if it complies with all of the
-         requirements associated with its role.
+         user agents) of the Content-Disposition header field. An implementation is considered conformant if it complies with all of
+         the requirements associated with its role.
       </p>
       <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements,
          but it does not define special handling of these invalid field-values.
       </p>
-      <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Location header fields that are invalid.
+      <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
       </p>
       <p id="rfc.section.3.p.4">Consuming implementations <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such,
@@ -967 +967 @@
       </ul>
       <h2 id="rfc.section.D.10"><a href="#rfc.section.D.10">D.10</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-content-disp-05</a></h2>
-      <p id="rfc.section.D.10.p.1">None yet.</p>
+      <p id="rfc.section.D.10.p.1">Fixed two typos where the new Conformance section said "Content-Location" instead of "Content-Disposition".</p>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
       <p class="noprint"><a href="#rfc.index.C">C</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.R">R</a> 

draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml

@@ -122 +122 @@
   This specification defines conformance criteria for both senders (usually,
   HTTP origin servers) and recipients (usually, HTTP user agents) of the
-  Content-Location header field. An implementation is considered conformant if
+  Content-Disposition header field. An implementation is considered conformant if
   it complies with all of the requirements associated with its role.
 </t>
@@ -131 +131 @@
 </t>
 <t>
-  Sending implementations &MUST-NOT; generate Content-Location header fields
+  Sending implementations &MUST-NOT; generate Content-Disposition header fields
   that are invalid.
 </t>
@@ -970 +970 @@
 <section title="Since draft-ietf-httpbis-content-disp-05" anchor="changes.since.05">
 <t>
-  None yet.
+  Fixed two typos where the new Conformance section said "Content-Location" instead
+  of "Content-Disposition".
 </t>
 </section>