Ignore:
Timestamp:
Jul 24, 2010, 2:23:44 AM (10 years ago)
Author:
julian.reschke@…
Message:

Remove "Changes from RFC 2068" sections (see #220)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r901 r911  
    48844884</section>
    48854885
    4886 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
    4887 <t>
    4888    This specification has been carefully audited to correct and
    4889    disambiguate key word usage; RFC 2068 had many problems in respect to
    4890    the conventions laid out in <xref target="RFC2119"/>.
    4891 </t>
    4892 <t>
    4893    Transfer-coding and message lengths all interact in ways that
    4894    required fixing exactly when chunked encoding is used (to allow for
    4895    transfer encoding that might not be self delimiting); it was important
    4896    to straighten out exactly how message lengths are computed. (Sections
    4897    <xref target="transfer.codings" format="counter"/>, <xref target="message.body" format="counter"/>,
    4898    <xref target="header.content-length" format="counter"/>,
    4899    see also <xref target="Part5"/>)
    4900 </t>
    4901 <t>
    4902    The use and interpretation of HTTP version numbers has been clarified
    4903    by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol
    4904    version they support to deal with problems discovered in HTTP/1.0
    4905    implementations (<xref target="http.version"/>)
    4906 </t>
    4907 <t>
    4908    Quality Values of zero should indicate that "I don't want something"
    4909    to allow clients to refuse a representation. (<xref target="quality.values"/>)
    4910 </t>
    4911 <t>
    4912    Transfer-coding had significant problems, particularly with
    4913    interactions with chunked encoding. The solution is that transfer-codings
    4914    become as full fledged as content-codings. This involves
    4915    adding an IANA registry for transfer-codings (separate from content
    4916    codings), a new header field (TE) and enabling trailer headers in the
    4917    future. Transfer encoding is a major performance benefit, so it was
    4918    worth fixing <xref target="Nie1997"/>. TE also solves another, obscure, downward
    4919    interoperability problem that could have occurred due to interactions
    4920    between authentication trailers, chunked encoding and HTTP/1.0
    4921    clients.(Section
    4922    <xref target="transfer.codings" format="counter"/>,
    4923    <xref target="chunked.encoding" format="counter"/>,
    4924    <xref target="non-modifiable.headers" format="counter"/>,
    4925    and <xref target="header.te" format="counter"/>)
    4926 </t>
    4927 <t>
    4928   Proxies should be able to add Content-Length when appropriate.
    4929   (<xref target="non-modifiable.headers"/>)
    4930 </t>
    4931 </section>
    4932 
    49334886<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    49344887<t>
     
    57165669      "HTTP(s) URI scheme definitions"
    57175670    </t>
     5671    <t>
     5672      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     5673      "consider removing the 'changes from 2068' sections"
     5674    </t>
    57185675  </list>
    57195676</t>
Note: See TracChangeset for help on using the changeset viewer.