Ignore:
Timestamp:
May 27, 2011, 1:06:18 AM (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.html

    r1276 r1293  
    371371  }
    372372  @bottom-center {
    373        content: "Expires November 2, 2011";
     373       content: "Expires November 28, 2011";
    374374  }
    375375  @bottom-right {
     
    404404      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    405405      <link rel="Appendix" title="A Changes from the RFC 2616 Definition" href="#rfc.section.A">
    406       <link rel="Appendix" title="B Differences compared to RFC 2183" href="#rfc.section.B">
     406      <link rel="Appendix" title="B Differences Compared to RFC 2183" href="#rfc.section.B">
    407407      <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C">
    408408      <link rel="Appendix" title="D Advice on Generating Content-Disposition Header Fields" href="#rfc.section.D">
     
    412412      <meta name="dct.creator" content="Reschke, J. F.">
    413413      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-content-disp-latest">
    414       <meta name="dct.issued" scheme="ISO8601" content="2011-05-01">
     414      <meta name="dct.issued" scheme="ISO8601" content="2011-05-27">
    415415      <meta name="dct.abstract" content="RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.">
    416416      <meta name="description" content="RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.">
     
    430430               <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
    431431               </td>
    432                <td class="right">May 1, 2011</td>
     432               <td class="right">May 27, 2011</td>
    433433            </tr>
    434434            <tr>
     
    437437            </tr>
    438438            <tr>
    439                <td class="left">Expires: November 2, 2011</td>
     439               <td class="left">Expires: November 28, 2011</td>
    440440               <td class="right"></td>
    441441            </tr>
     
    466466         in progress”.
    467467      </p>
    468       <p>This Internet-Draft will expire on November 2, 2011.</p>
     468      <p>This Internet-Draft will expire on November 28, 2011.</p>
    469469      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    470470      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    492492         <li>7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    493493         <li>8.&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
    494                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameter</a></li>
     494               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameters</a></li>
    495495               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    496496            </ul>
     
    504504         <li><a href="#rfc.authors">Author's Address</a></li>
    505505         <li>A.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li>
    506          <li>B.&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li>
     506         <li>B.&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></li>
    507507         <li>C.&nbsp;&nbsp;&nbsp;<a href="#alternatives">Alternative Approaches to Internationalization</a><ul>
    508508               <li>C.1&nbsp;&nbsp;&nbsp;<a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li>
     
    533533      </ul>
    534534      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    535       <p id="rfc.section.1.p.1">RFC 2616 defines the Content-Disposition response header field in <a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, but points out that it is not part of the HTTP/1.1 Standard (<a href="http://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>):
     535      <p id="rfc.section.1.p.1">RFC 2616 defines the Content-Disposition response header field (<a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) but points out that it is not part of the HTTP/1.1 Standard (<a href="http://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>):
    536536      </p>
    537537      <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5">
     
    541541      </blockquote>
    542542      <p id="rfc.section.1.p.3">This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability
    543          testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions
    544          (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects.
     543         testing with existing user agents (UAs), it fully defines a profile of the features defined in the Multipurpose Internet Mail
     544         Extensions (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects.
    545545      </p>
    546546      <div class="note" id="rfc.section.1.p.4">
    547          <p> <b>Note:</b> this document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such
     547         <p> <b>Note:</b> This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such
    548548            as when using the media type "multipart/form-data" (<a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>).
    549549         </p>
     
    565565      <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
    566566      </p>
    567       <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,
     567      <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 behavior (e.g., the implementation is a validator). As such,
    568568         the default handling of invalid fields is to ignore them.
    569569      </p>
     
    604604      <p id="rfc.section.4.1.p.5">Note that due to the rules for implied linear whitespace (<a href="http://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), <em class="bcp14">OPTIONAL</em> whitespace can appear between words (token or quoted-string) and separator characters.
    605605      </p>
    606       <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited
     606      <p id="rfc.section.4.1.p.6">Furthermore, note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited
    607607         use for filenames and is likely to be ignored by recipients.
    608608      </p>
     
    630630         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).
    631631      </p>
    632       <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
    633          information. In particular:
     632      <p id="rfc.section.4.3.p.5">It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the
     633         desired information. In particular:
    634634      </p>
    635635      <ul>
    636636         <li>
    637             <p>Recipients <em class="bcp14">MUST NOT</em> be able to write into any location other than one to which they are specifically entitled. To illustrate the problem consider
     637            <p>Recipients <em class="bcp14">MUST NOT</em> be able to write into any location other than one to which they are specifically entitled. To illustrate the problem, consider
    638638               the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this
    639639               is to never trust folder name information in the filename parameter, for instance by stripping all but the last path segment
    640                and only consider the actual filename (where 'path segment' are the components of the field value delimited by the path separator
    641                characters "\" and "/").
     640               and only considering the actual filename (where 'path segment' are the components of the field value delimited by the path
     641               separator characters "\" and "/").
    642642            </p>
    643643         </li>
    644644         <li>
    645645            <p>Many platforms do not use Internet Media Types (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file
    646                extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients which
     646               extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that
    647647               make use of file extensions to determine the media type <em class="bcp14">MUST</em> ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
    648648            </p>
     
    673673      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="examples" href="#examples">Examples</a></h1>
    674674      <div id="rfc.figure.u.4"></div>
    675       <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p>  <pre class="text">Content-Disposition: Attachment; filename=example.html
     675      <p>Direct the UA to show "save as" dialog, with a filename of "example.html":</p>  <pre class="text">Content-Disposition: Attachment; filename=example.html
    676676</pre><div id="rfc.figure.u.5"></div>
    677       <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html"
     677      <p>Direct the UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html"
    678678         for a subsequent save operation:
    679679      </p>  <pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html"
    680680</pre>  <p>Note: this uses the quoted-string form so that the space character can be included.</p>
    681681      <div id="rfc.figure.u.6"></div>
    682       <p>Direct UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p>  <pre class="text">Content-Disposition: attachment;
     682      <p>Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p>  <pre class="text">Content-Disposition: attachment;
    683683                     filename*= UTF-8''<b>%e2%82%ac</b>%20rates
    684684</pre>  <p>Here, the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.4"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> is also used to encode the non-ISO-8859-1 character.
    685685      </p>
    686686      <div id="rfc.figure.u.7"></div>
    687       <p>Same as above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:</p>  <pre class="text">Content-Disposition: attachment;
     687      <p>This example is the same as above, but adding the "filename" parameter for compatibility with user agents not implementing
     688         RFC 5987:
     689      </p>  <pre class="text">Content-Disposition: attachment;
    688690                     filename="EURO rates";
    689691                     filename*=utf-8''<b>%e2%82%ac</b>%20rates
     
    697699      <p id="rfc.section.7.p.1">Using server-supplied information for constructing local filenames introduces many risks. These are summarized in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>.
    698700      </p>
    699       <p id="rfc.section.7.p.2">Furthermore, implementers also ought to be aware of the Security Considerations applying to HTTP (see <a href="http://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="http://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>).
     701      <p id="rfc.section.7.p.2">Furthermore, implementers ought to be aware of the security considerations applying to HTTP (see <a href="http://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="http://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>).
    700702      </p>
    701703      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
    702       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="registry" href="#registry">Registry for Disposition Values and Parameter</a></h2>
     704      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="registry" href="#registry">Registry for Disposition Values and Parameters</a></h2>
    703705      <p id="rfc.section.8.1.p.1">This specification does not introduce any changes to the registration procedures for disposition values and parameters that
    704706         are defined in <a href="http://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.5"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
     
    769771         <tr>
    770772            <td class="reference"><b id="RFC2183">[RFC2183]</b></td>
    771             <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC&nbsp;2183, August&nbsp;1997.
     773            <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC&nbsp;2183, August&nbsp;1997.
    772774            </td>
    773775         </tr>
     
    817819         </li>
    818820      </ul>
    819       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></h1>
     821      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></h1>
    820822      <p id="rfc.section.B.p.1"> <a href="http://tools.ietf.org/html/rfc2183#section-2">Section 2</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.7"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The
    821          majority of user agents does not implement these, thus they have been omitted from this specification.
     823         majority of user agents do not implement these; thus, they have been omitted from this specification.
    822824      </p>
    823825      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="alternatives" href="#alternatives">Alternative Approaches to Internationalization</a></h1>
     
    827829         Track specifies exactly one solution (<a href="#RFC2231" id="rfc.xref.RFC2231.1"><cite title="MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations">[RFC2231]</cite></a>, clarified and profiled for HTTP in <a href="#RFC5987" id="rfc.xref.RFC5987.9"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>).
    828830      </p>
    829       <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explains how they are inferior
    830          to the RFC 5987 encoding used in this specification.
     831      <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explain how they are inferior
     832         to the RFC&nbsp;5987 encoding used in this specification.
    831833      </p>
    832834      <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;<a id="alternatives.rfc2047" href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2>
    833835      <p id="rfc.section.C.1.p.1">RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters
    834          - see <a href="http://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>:
     836          see <a href="http://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>:
    835837      </p>
    836838      <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5">
     
    845847      </p>
    846848      <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<a id="alternatives.percent" href="#alternatives.percent">Percent Encoding</a></h2>
    847       <p id="rfc.section.C.2.p.1">Some user agents accept percent encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding
     849      <p id="rfc.section.C.2.p.1">Some user agents accept percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding
    848850         of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
    849851      </p>
    850852      <p id="rfc.section.C.2.p.2">In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence
    851          to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually
     853         to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually
    852854         expect.
    853855      </p>
     
    856858         to be more likely to be the correct interpretation.
    857859      </p>
    858       <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and furthermore risks misinterpreting the actual value.</p>
     860      <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and, furthermore, risks misinterpreting the actual value.</p>
    859861      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="alternatives.implementations" href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2>
    860862      <p id="rfc.section.C.4.p.1">Unfortunately, as of March 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches discussed
     
    938940         </li>
    939941         <li>Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some
    940             user agents, and can be considered as an illegal path character.
     942            user agents, and "\" can be considered an illegal path character.
    941943         </li>
    942944         <li>Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1,
     
    957959         </li>
    958960      </ul>
    959       <p id="rfc.section.D.p.3">Note that this advice is based upon UA behaviour at the time of writing, and might be superseded. At the time of publication
     961      <p id="rfc.section.D.p.3">Note that this advice is based upon UA behavior at the time of writing, and might be superseded. At the time of publication
    960962         of this document, &lt;<a href="http://purl.org/NET/http/content-disposition-tests">http://purl.org/NET/http/content-disposition-tests</a>&gt; provides an overview of current levels of support in various implementations.
    961963      </p>
     
    10471049      </p>
    10481050      <h2 id="rfc.section.E.14"><a href="#rfc.section.E.14">E.14</a>&nbsp;<a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-content-disp-09</a></h2>
    1049       <p id="rfc.section.E.14.p.1">None yet.</p>
     1051      <p id="rfc.section.E.14.p.1">Editorial changes made during RFC-Editor AUTH48 phase.</p>
    10501052      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    10511053      <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> <a href="#rfc.index.U">U</a>
Note: See TracChangeset for help on using the changeset viewer.