Ignore:
Timestamp:
Feb 20, 2012, 6:12:49 PM (8 years ago)
Author:
fielding@…
Message:

For consistency and readability, do not hyphenate "message body"
unless we are referring to the message-body ABNF rule.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r1528 r1544  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 10, 2012";
     462       content: "Expires August 23, 2012";
    463463  }
    464464  @bottom-right {
     
    511511      <meta name="dct.creator" content="Reschke, J. F.">
    512512      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    513       <meta name="dct.issued" scheme="ISO8601" content="2012-02-07">
     513      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    515515      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    537537            </tr>
    538538            <tr>
    539                <td class="left">Expires: August 10, 2012</td>
     539               <td class="left">Expires: August 23, 2012</td>
    540540               <td class="right">J. Mogul</td>
    541541            </tr>
     
    594594            <tr>
    595595               <td class="left"></td>
    596                <td class="right">February 7, 2012</td>
     596               <td class="right">February 20, 2012</td>
    597597            </tr>
    598598         </tbody>
     
    622622         in progress”.
    623623      </p>
    624       <p>This Internet-Draft will expire on August 10, 2012.</p>
     624      <p>This Internet-Draft will expire on August 23, 2012.</p>
    625625      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    626626      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    799799      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    800800  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    801   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>&gt;
     801  <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a>&gt;
    802802</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    803803      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
     
    831831      </p>
    832832      <ul class="empty">
    833          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     833         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    834834         </li>
    835835      </ul>
     
    837837      </p>
    838838      <ul class="empty">
    839          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     839         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    840840         </li>
    841841      </ul>
     
    843843      </p>
    844844      <ul class="empty">
    845          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     845         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    846846         </li>
    847847      </ul>
     
    855855         <li>Pointer to specification text</li>
    856856      </ul>
    857       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     857      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    858858      </p>
    859859      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
     
    900900      </p>
    901901      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    902       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body.
     902      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body.
    903903         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
    904904      </p>
    905       <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does
    906          not use the multipart boundary as an indicator of message-body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
    907          each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
     905      <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does
     906         not use the multipart boundary as an indicator of message body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
     907         each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
    908908      </p>
    909909      <p id="rfc.section.2.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
     
    932932      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
    933933      <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
    934          in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
     934         in the form of header fields, and data, in the form of the sequence of octets in the message body after any transfer-coding
    935935         has been decoded.
    936936      </p>
     
    955955               <tr>
    956956                  <td class="left">Content-Length</td>
    957                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     957                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    958958               </tr>
    959959               <tr>
     
    965965      </div>
    966966      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    967       <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     967      <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure
    968968         safe and proper transfer of the message.
    969969      </p>
     
    984984      </p>
    985985      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    986       <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
    987          is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
    988          the same effective request URI.
     986      <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
     987         body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
     988         with the same effective request URI.
    989989      </p>
    990990      <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
     
    11011101         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
    11021102      </p>
    1103       <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
     1103      <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
    11041104      </p>
    11051105      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    1106          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     1106         and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    11071107         within extension header fields not defined by this specification.
    11081108      </p>
     
    11541154      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    11551155         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1156          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     1156         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    11571157      </p>
    11581158      <div class="note" id="rfc.section.6.1.p.5">
     
    12841284         </li>
    12851285         <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable
    1286             unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
     1286            unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    12871287         </li>
    12881288         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
     
    15461546                  <td class="left">compress</td>
    15471547                  <td class="left">UNIX "compress" program method</td>
    1548                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1548                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15491549                  </td>
    15501550               </tr>
     
    15531553                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    15541554                  </td>
    1555                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1555                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15561556                  </td>
    15571557               </tr>
     
    15591559                  <td class="left">gzip</td>
    15601560                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1561                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1561                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15621562                  </td>
    15631563               </tr>
     
    17771777      </div>
    17781778      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
    1779       <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
     1779      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,
    17801780         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
    17811781         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
     
    18291829      </p>
    18301830      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1831       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     1831      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    18321832      </p>
    18331833      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
     
    22472247                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li>
    22482248                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">3.2</a></li>
     2249                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
     2250                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.1</a></li>
    22492251                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.7</a></li>
    2250                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
    2251                         <li><em>Section 5.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
    2252                         <li><em>Section 5.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2.2.1</a></li>
    2253                         <li><em>Section 5.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
    2254                         <li><em>Section 5.1.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li>
    2255                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li>
    2256                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.1</a></li>
    2257                         <li><em>Section 8.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
     2252                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
     2253                        <li><em>Section 5.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
     2254                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2.2.1</a></li>
     2255                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
     2256                        <li><em>Section 5.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li>
     2257                        <li><em>Section 5.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li>
    22582258                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">9</a></li>
    22592259                     </ul>
     
    22612261                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul>
    22622262                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">A.3</a></li>
    2263                         <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
     2263                        <li><em>Section 10.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
    22642264                     </ul>
    22652265                  </li>
Note: See TracChangeset for help on using the changeset viewer.