Ignore:
Timestamp:
Feb 21, 2011, 5:36:36 AM (9 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

Location:
draft-ietf-httpbis-content-disp/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html

    r1134 r1135  
    551551         but it does not define special handling of these invalid field-values.
    552552      </p>
    553       <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
    554       </p>
    555       <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,
     553      <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
     554      </p>
     555      <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,
    556556         the default handling of invalid fields is to ignore them.
    557557      </p>
     
    596596      </p>
    597597      <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>
    598       <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
     598      <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
    599599         to save the response locally, rather than process it normally (as per its media type).
    600600      </p>
     
    618618         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).
    619619      </p>
    620       <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
     620      <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
    621621         information. In particular:
    622622      </p>
     
    788788      <ul>
    789789         <li>According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This
    790             restriction has been removed, because user agents in practice do not check the content type, and it also discourages properly
     790            restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly
    791791            declaring the media type.
    792792         </li>
  • draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml

    r1134 r1135  
    131131</t>
    132132<t>
    133   Sending implementations &MUST-NOT; generate Content-Disposition header fields
    134   that are invalid.
    135 </t>
    136 <t>
    137   Consuming implementations &MAY; take steps to recover a usable field-value
     133  Senders &MUST-NOT; generate Content-Disposition header fields that are
     134  invalid.
     135</t>
     136<t>
     137  Recipients &MAY; take steps to recover a usable field-value
    138138  from an invalid header field, but &SHOULD-NOT; reject the message outright,
    139139  unless this is explicitly desirable behaviour (e.g., the implementation is a
     
    204204<t>
    205205  If the disposition type matches "attachment" (case-insensitively), this
    206   indicates that the user agent should prompt the user to save the response
     206  indicates that the recipient should prompt the user to save the response
    207207  locally, rather than process it normally (as per its media type).
    208208</t>
     
    247247</t>
    248248<t>
    249   It is essential that user agents treat the specified filename as advisory
     249  It is essential that recipients treat the specified filename as advisory
    250250  only, thus be very careful in extracting the desired information.
    251251  In particular:
     
    666666    According to RFC 2616, the disposition type "attachment" only applies to
    667667    content of type "application/octet-stream". This restriction has been
    668     removed, because user agents in practice do not check the content type, and
     668    removed, because recipients in practice do not check the content type, and
    669669    it also discourages properly declaring the media type.
    670670  </t>
Note: See TracChangeset for help on using the changeset viewer.