Changeset 1135 for draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html

Timestamp:

21/02/11 13:36:36 (12 years ago)

Author:

julian.reschke@…

Message:

consuming implementations -> recipients, sending implementations -> senders, some cases of U-A -> recipient; U-A only used when talking about speicific implementations, not protocol behavior

File:

• draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html (modified) (4 diffs)

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

@@ -551 +551 @@
          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-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,
+      <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
+      </p>
+      <p id="rfc.section.3.p.4">Recipients <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,
          the default handling of invalid fields is to ignore them.
       </p>
@@ -596 +596 @@
       </p>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="disposition.type" href="#disposition.type">Disposition Type</a></h2>
-      <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user
+      <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user
          to save the response locally, rather than process it normally (as per its media type).
       </p>
@@ -618 +618 @@
          more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section&nbsp;5</a> for an example).
       </p>
-      <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired
+      <p id="rfc.section.4.3.p.5">It is essential that recipients treat the specified filename as advisory only, thus be very careful in extracting the desired
          information. In particular: 
       </p>
@@ -788 +788 @@
       <ul>
          <li>According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This
-            restriction has been removed, because user agents in practice do not check the content type, and it also discourages properly
+            restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly
             declaring the media type.
          </li>