Ignore:
Timestamp:
27/05/11 08:06:18 (9 years ago)
Author:
julian.reschke@…
Message:

apply RFC-Editor AUTH48 changes

File:
1 edited

Legend:

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

    r1276 r1293  
    2323  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
    2424  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
     25  <!ENTITY mdash "&#8212;">
    2526]>
    2627
     
    7879<section title="Introduction" anchor="introduction">
    7980<t>
    80   RFC 2616 defines the Content-Disposition response header field in <xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>,
     81  RFC 2616 defines the Content-Disposition response header field
     82  (<xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>)
    8183  but points out that it is not part of the HTTP/1.1 Standard (<xref target="RFC2616" x:fmt="sec" x:sec="15.5"/>):
    8284</t>
     
    9092  This specification takes over the definition and registration of
    9193  Content-Disposition, as used in HTTP.
    92   Based on interoperability testing with existing User Agents,
     94  Based on interoperability testing with existing user agents (UAs),
    9395  it fully defines a profile of the
    9496  features defined in the Multipurpose Internet Mail Extensions (MIME) variant (<xref target="RFC2183"/>) of the
     
    98100<x:note>
    99101  <t>
    100     <x:h>Note:</x:h> this document does not apply to Content-Disposition
     102    <x:h>Note:</x:h> This document does not apply to Content-Disposition
    101103    header fields appearing in payload bodies transmitted over HTTP, such as
    102104    when using the media type "multipart/form-data" (<xref target="RFC2388"/>).
     
    137139  Recipients &MAY; take steps to recover a usable field-value
    138140  from an invalid header field, but &SHOULD-NOT; reject the message outright,
    139   unless this is explicitly desirable behaviour (e.g., the implementation is a
     141  unless this is explicitly desirable behavior (e.g., the implementation is a
    140142  validator). As such, the default handling of invalid fields is to ignore them.
    141143</t>
     
    195197</t>
    196198<t>
    197   Furthermore note that the format used for ext-value allows specifying a
     199  Furthermore, note that the format used for ext-value allows specifying a
    198200  natural language (e.g., "en"); this is of limited use for filenames and is
    199201  likely to be ignored by recipients.
     
    248250<t>
    249251  It is essential that recipients treat the specified filename as advisory
    250   only, thus be very careful in extracting the desired information.
     252  only, and thus be very careful in extracting the desired information.
    251253  In particular:
    252254  <list style="symbols">
    253255    <x:lt><t>
    254256      Recipients &MUST-NOT; be able to write into any location other than one
    255       to which they are specifically entitled. To illustrate the problem
     257      to which they are specifically entitled. To illustrate the problem,
    256258      consider the consequences of being able to overwrite well-known system
    257259      locations (such as "/etc/passwd"). One strategy to achieve this is to
    258260      never trust folder name information in the filename parameter, for
    259       instance by stripping all but the last path segment and only consider the
    260       actual filename (where 'path segment' are the components of the field
     261      instance by stripping all but the last path segment and only considering
     262      the actual filename (where 'path segment' are the components of the field
    261263      value delimited by the path separator characters "\" and "/").
    262264    </t></x:lt>
     
    266268      extensions instead. Trusting the server-provided file extension could
    267269      introduce a privilege escalation when the saved file is later opened
    268       (consider ".exe"). Thus, recipients which make use of file extensions
     270      (consider ".exe"). Thus, recipients that make use of file extensions
    269271      to determine the media type &MUST; ensure that a file extension
    270272      is used that is safe, optimally matching the media type of the received
     
    317319<figure>
    318320<preamble>
    319 Direct UA to show "save as" dialog, with a filename of "example.html": 
     321Direct the UA to show "save as" dialog, with a filename of "example.html": 
    320322</preamble>
    321323<artwork type="example">
     
    324326<figure>
    325327<preamble>
    326 Direct UA to behave as if the Content-Disposition header field wasn't present,
     328Direct the UA to behave as if the Content-Disposition header field wasn't present,
    327329but to remember the filename "an example.html" for a subsequent save operation:
    328330</preamble>
     
    337339<figure>
    338340<preamble>
    339 Direct UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
     341Direct the UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
    340342</preamble>
    341343<artwork type="example" x:indent-with="  ">
     
    350352<figure>
    351353<preamble>
    352 Same as above, but adding the "filename" parameter for compatibility with
    353 user agents not implementing RFC 5987:
     354This example is the same as above, but adding the "filename" parameter for
     355compatibility with user agents not implementing RFC 5987:
    354356</preamble>
    355357<artwork type="example" x:indent-with="  ">
     
    385387</t>
    386388<t>
    387   Furthermore, implementers also ought to be aware of the Security
    388   Considerations applying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/>
     389  Furthermore, implementers ought to be aware of the security considerations
     390  applying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/>
    389391  (see <xref target="RFC5987" x:fmt="sec" x:sec="5"/>).
    390392</t>
     
    393395<section title="IANA Considerations" anchor="iana.considerations">
    394396
    395 <section title="Registry for Disposition Values and Parameter" anchor="registry">
     397<section title="Registry for Disposition Values and Parameters" anchor="registry">
    396398<t>
    397399  This specification does not introduce any changes to the registration
     
    566568        <address><email>sdorner@qualcomm.com</email></address>
    567569      </author>
    568       <author initials="K." surname="Moore" fullname="Keith Moore">
     570      <author initials="K." surname="Moore" fullname="Keith Moore" role="editor">
    569571        <organization>Department of Computer Science</organization>
    570572        <address><email>moore@cs.utk.edu</email></address>
     
    710712</section>
    711713
    712 <section title="Differences compared to RFC 2183" anchor="diffs.compared.to.rfc2183">
     714<section title="Differences Compared to RFC 2183" anchor="diffs.compared.to.rfc2183">
    713715<t>
    714716  <xref target="RFC2183" x:fmt="of" x:sec="2"/> defines several additional
    715717  disposition parameters: "creation-date", "modification-date",
    716   "quoted-date-time", and "size". The majority of user agents does not implement
    717   these, thus they have been omitted from this specification.
     718  "quoted-date-time", and "size". The majority of user agents do not implement
     719  these; thus, they have been omitted from this specification.
    718720</t>
    719721</section>
     
    734736<t>
    735737  For completeness, the sections below describe the various approaches that
    736   have been tried, and explains how they are inferior to the RFC 5987
     738  have been tried, and explain how they are inferior to the RFC&#160;5987
    737739  encoding used in this specification.
    738740</t>
     
    742744  RFC 2047 defines an encoding mechanism for
    743745  header fields, but this encoding is not supposed to be used for
    744   header field parameters - see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 
     746  header field parameters &mdash; see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 
    745747</t>
    746748<x:blockquote cite="http://tools.ietf.org/html/rfc2047#section-5">
     
    763765<section title="Percent Encoding" anchor="alternatives.percent">
    764766<t>
    765   Some user agents accept percent encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
     767  Some user agents accept percent-encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
    766768  sequences of characters. The character encoding being used for decoding
    767769  depends on various factors, including the encoding of the referring page,
     
    772774  In practice, this is hard to use because those user agents that do not
    773775  support it will display the escaped character sequence to the user. For those
    774   user agents that do implement this it is difficult to predict what character
     776  user agents that do implement this, it is difficult to predict what character
    775777  encoding they actually expect.
    776778</t>
     
    784786</t>
    785787<t>
    786   As with the approaches above, this is not interoperable and furthermore
     788  As with the approaches above, this is not interoperable and, furthermore,
    787789  risks misinterpreting the actual value.
    788790</t>
     
    875877    <t>Avoid including the "\" character in the quoted-string form of the
    876878    filename parameter, as escaping is not implemented by some user agents,
    877     and can be considered as an illegal path character.</t>
     879    and "\" can be considered an illegal path character.</t>
    878880    <t>Avoid using non-ASCII characters in the filename parameter. Although
    879881    most existing implementations will decode them as ISO-8859-1, some
     
    905907</t>
    906908<t>
    907   Note that this advice is based upon UA behaviour at the time of writing, and
     909  Note that this advice is based upon UA behavior at the time of writing, and
    908910  might be superseded. At the time of publication of this document,
    909911  <eref target="http://purl.org/NET/http/content-disposition-tests"/> provides
     
    11011103<section title="Since draft-ietf-httpbis-content-disp-09" anchor="changes.since.09">
    11021104<t>
    1103   None yet.
     1105  Editorial changes made during RFC-Editor AUTH48 phase.
    11041106</t>
    11051107</section>
Note: See TracChangeset for help on using the changeset viewer.