Ignore:
Timestamp:
Sep 9, 2012, 7:46:17 PM (7 years ago)
Author:
fielding@…
Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1873 r1875  
    15681568      <div id="rfc.iref.t.1"></div>
    15691569      <div id="rfc.iref.m.8"></div>
    1570       <p id="rfc.section.5.3.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;6.1.1</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1570      <p id="rfc.section.5.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;6.1.1</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    15711571      </p>
    15721572      <p id="rfc.section.5.3.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
     
    31663166      <p id="rfc.section.9.5.p.6">A parameter value that matches the <a href="#imported.abnf" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
    31673167      </p>
    3168       <p id="rfc.section.9.5.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications,
    3169          implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition.
    3170       </p>
    3171       <p id="rfc.section.9.5.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
     3168      <p id="rfc.section.9.5.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
    31723169         outlined in <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged.
    31733170      </p>
     
    31873184      <h3 id="rfc.section.9.5.2"><a href="#rfc.section.9.5.2">9.5.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    31883185      <p id="rfc.section.9.5.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body.
    3189          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.3"><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.
     3186         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.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender <em class="bcp14">MUST</em> generate only CRLF to represent line breaks between body-parts.
    31903187      </p>
    31913188      <p id="rfc.section.9.5.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does
     
    31933190         each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
    31943191      </p>
    3195       <p id="rfc.section.9.5.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".
     3192      <p id="rfc.section.9.5.2.p.3">A recipient <em class="bcp14">MUST</em> treat an unrecognized multipart subtype as being equivalent to "multipart/mixed".
    31963193      </p>
    31973194      <div class="note" id="rfc.section.9.5.2.p.4">
Note: See TracChangeset for help on using the changeset viewer.