Changeset 911 for draft-ietf-httpbis


Ignore:
Timestamp:
24/07/10 09:23:44 (10 years ago)
Author:
julian.reschke@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
7 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>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r910 r911  
    32683268</references>
    32693269
    3270 <section title="Compatibility with Previous Versions" anchor="compatibility">
    3271 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
    3272 <t>
    3273    Clarified which error code should be used for inbound server failures
    3274    (e.g., DNS failures). (<xref target="status.504"/>).
    3275 </t>
    3276 <t>
    3277    201 (Created) had a race that required an ETag be sent when a resource is
    3278    first created. (<xref target="status.201"/>).
    3279 </t>
    3280 <t>
    3281    303 (See Also) and 307 (Temporary Redirect) added to address user agent
    3282    failure to implement status code 302 properly.
    3283    (Section <xref target="status.303" format="counter"/> and <xref target="status.307" format="counter"/>)
    3284 </t>
    3285 <t>
    3286    Rewrite of message transmission requirements to make it much harder
    3287    for implementors to get it wrong, as the consequences of errors here
    3288    can have significant impact on the Internet, and to deal with the
    3289    following problems:
    3290   <list style="numbers">
    3291       <t>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
    3292          this was incorrectly placing a requirement on the behavior of
    3293          an implementation of a future version of HTTP/1.x</t>
    3294 
    3295       <t>Made it clear that user-agents should retry requests, not
    3296          "clients" in general.</t>
    3297 
    3298       <t>Converted requirements for clients to ignore unexpected 100
    3299          (Continue) responses, and for proxies to forward 100 responses,
    3300          into a general requirement for 1xx responses.</t>
    3301 
    3302       <t>Modified some TCP-specific language, to make it clearer that
    3303          non-TCP transports are possible for HTTP.</t>
    3304 
    3305       <t>Require that the origin server &MUST-NOT; wait for the request
    3306          body before it sends a required 100 (Continue) response.</t>
    3307 
    3308       <t>Allow, rather than require, a server to omit 100 (Continue) if
    3309          it has already seen some of the request body.</t>
    3310 
    3311       <t>Allow servers to defend against denial-of-service attacks and
    3312          broken clients.</t>
    3313   </list>
    3314 </t>
    3315 <t>
    3316    This change adds the Expect header and 417 status code.
    3317 </t>
    3318 <t>
    3319    Clean up confusion between 403 and 404 responses. (Section <xref target="status.403" format="counter"/>,
    3320    <xref target="status.404" format="counter"/>, and <xref target="status.410" format="counter"/>)
    3321 </t>
    3322 <t>
    3323    The PATCH<iref item="PATCH method" primary="true"/><iref item="Methods" subitem="PATCH" primary="true"/>, LINK<iref item="LINK method" primary="true"/><iref item="Methods" subitem="LINK" primary="true"/>, UNLINK<iref item="UNLINK method" primary="true"/><iref item="Methods" subitem="UNLINK" primary="true"/> methods were defined but not commonly
    3324    implemented in previous versions of this specification. See <xref target="RFC2068" x:fmt="of" x:sec="19.6.1"/>.
    3325 </t>
    3326 </section>
    3327 
    33283270<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    33293271<t>
    … …  
    33763318  (<xref target="header.server"/>)
    33773319</t>
    3378 </section>
    3379 
    33803320</section>
    33813321
    … …  
    38593799      "Status codes and caching"
    38603800    </t>
     3801    <t>
     3802      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     3803      "consider removing the 'changes from 2068' sections"
     3804    </t>
    38613805  </list>
    38623806</t>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r908 r911  
    27392739</section>
    27402740
    2741 <section title="Compatibility with Previous Versions" anchor="compatibility">
    2742 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
    2743 <t>
    2744    Charset wildcarding is introduced to avoid explosion of character set
    2745    names in accept headers. (<xref target="header.accept-charset"/>)
    2746 </t>
    2747 <t>
    2748    Content-Base was deleted from the specification: it was not
    2749    implemented widely, and there is no simple, safe way to introduce it
    2750    without a robust extension mechanism. In addition, it is used in a
    2751    similar, but not identical fashion in MHTML <xref target="RFC2557"/>.
    2752 </t>
    2753 <t>
    2754    A content-coding of "identity" was introduced, to solve problems
    2755    discovered in caching. (<xref target="content.codings"/>)
    2756 </t>
    2757 <t>
    2758    The Alternates<iref item="Alternates header" primary="true"/><iref item="Headers" subitem="Alternate" primary="true"/>, Content-Version<iref item="Content-Version header" primary="true"/><iref item="Headers" subitem="Content-Version" primary="true"/>, Derived-From<iref item="Derived-From header" primary="true"/><iref item="Headers" subitem="Derived-From" primary="true"/>, Link<iref item="Link header" primary="true"/><iref item="Headers" subitem="Link" primary="true"/>, URI<iref item="URI header" primary="true"/><iref item="Headers" subitem="URI" primary="true"/>, Public<iref item="Public header" primary="true"/><iref item="Headers" subitem="Public" primary="true"/> and
    2759    Content-Base<iref item="Content-Base header" primary="true"/><iref item="Headers" subitem="Content-Base" primary="true"/> header fields were defined in previous versions of this
    2760    specification, but not commonly implemented. See <xref target="RFC2068" x:fmt="of" x:sec="19.6.2"/>.
    2761 </t>
    2762 </section>
    2763 
    27642741<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    27652742<t>
    … …  
    27782755  (<xref target="no.content-transfer-encoding"/>)
    27792756</t>
    2780 </section>
    2781 
    27822757</section>
    27832758
    … …  
    32153190      "'requested resource' in content-encoding definition"
    32163191    </t>
     3192    <t>
     3193      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     3194      "consider removing the 'changes from 2068' sections"
     3195    </t>
    32173196  </list>
    32183197</t>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r908 r911  
    14861486</references>
    14871487
    1488 <section title="Compatibility with Previous Versions" anchor="compatibility">
    1489 
    14901488<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    14911489<t>
    … …  
    14941492  <xref target="header.if-none-match" format="counter"/>).
    14951493</t>
    1496 </section>
    1497 
    14981494</section>
    14991495
    … …  
    17061702      "Clarify entity / representation / variant terminology"
    17071703    </t>
     1704    <t>
     1705      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     1706      "consider removing the 'changes from 2068' sections"
     1707    </t>
    17081708  </list>
    17091709</t>

  • draft-ietf-httpbis/latest/p5-range.xml

    r908 r911  
    598598   ranges), these are transmitted as a multipart message. The multipart
    599599   media type used for this purpose is "multipart/byteranges" as defined
    600    in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue.
     600   in <xref target="internet.media.type.multipart.byteranges"/>.
    601601</t>
    602602<t>
    … …  
    13021302
    13031303<section title="Compatibility with Previous Versions" anchor="compatibility">
    1304 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
    1305 <t>
    1306    Transfer-coding and message lengths all interact in ways that
    1307    required fixing exactly when chunked encoding is used (to allow for
    1308    transfer encoding that may not be self delimiting); it was important
    1309    to straighten out exactly how message lengths are computed.
    1310    (<xref target="header.content-range"/>,
    1311    see also <xref target="Part1"/>)
    1312 </t>
    1313 <t>
    1314    There are situations where a server (especially a proxy) does not
    1315    know the full length of a response but is capable of serving a
    1316    byterange request. We therefore need a mechanism to allow byteranges
    1317    with a content-range not indicating the full length of the message.
    1318    (<xref target="header.content-range"/>)
    1319 </t>
    1320 <t>
    1321    Range request responses would become very verbose if all meta-data
    1322    were always returned; by allowing the server to only send needed
    1323    headers in a 206 response, this problem can be avoided.
    1324    (Section <xref target="status.206" format="counter"/>
    1325    and <xref target="header.if-range" format="counter"/>)
    1326 </t>
    1327 <t>
    1328    Fix problem with unsatisfiable range requests; there are two cases:
    1329    syntactic problems, and range doesn't exist in the document. The 416
    1330    status code was needed to resolve this ambiguity needed to indicate
    1331    an error for a byte range request that falls outside of the actual
    1332    contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>)
    1333 </t>
    1334 </section>
    1335 
    13361304<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    13371305<t>
    … …  
    15941562      "Clarify entity / representation / variant terminology"
    15951563    </t>
     1564    <t>
     1565      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     1566      "Clarify entity / representation / variant terminology"
     1567    </t>
     1568    <t>
     1569      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     1570      "consider removing the 'changes from 2068' sections"
     1571    </t>
    15961572  </list>
    15971573</t>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r908 r911  
    21382138</references>
    21392139
    2140 <section anchor="compatibility" title="Compatibility with Previous Versions">
    2141 
    2142 <section anchor="changes.from.rfc.2068" title="Changes from RFC 2068">
    2143 <t>
    2144   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add
    2145   this missing case.
    2146   (Sections <xref format="counter" target="response.cacheability" />, <xref format="counter" target="header.cache-control" />).
    2147 </t>
    2148 <t>
    2149   Range request responses would become very verbose if all meta-data were always returned;
    2150   by allowing the server to only send needed headers in a 206 response, this problem can be
    2151   avoided.
    2152   (<xref target="combining.headers" />)
    2153 </t>
    2154 <t>
    2155   The Cache-Control: max-age directive was not properly defined for responses.
    2156   (<xref target="cache-response-directive"/>)
    2157 </t>
    2158 <t>
    2159   Warnings could be cached incorrectly, or not updated appropriately. (Section <xref
    2160     format="counter" target="expiration.model" />, <xref format="counter"
    2161     target="combining.headers" />, <xref format="counter" target="header.cache-control" />,
    2162   and <xref format="counter" target="header.warning" />) Warning also needed to be a general
    2163   header, as PUT or other methods may have need for it in requests.
    2164 </t>
    2165 </section>
    2166 
    21672140<section anchor="changes.from.rfc.2616" title="Changes from RFC 2616">
    21682141<t>
    … …  
    21852158</t>
    21862159</section>
    2187 
    2188     </section>
    21892160
    21902161<?BEGININC p6-cache.abnf-appendix ?>
    … …  
    25072478<section title="Since draft-ietf-httpbis-p6-cache-10" anchor="changes.since.10">
    25082479<t>
    2509   None yet.
     2480  Closed issues:
     2481  <list style="symbols">
     2482    <t>
     2483      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     2484      "consider removing the 'changes from 2068' sections"
     2485    </t>
     2486  </list>
    25102487</t>
    25112488</section>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r874 r911  
    831831</references>
    832832
    833 
    834 <section title="Compatibility with Previous Versions" anchor="compatibility">
    835 
     833<!-- re-add this once we have changes
    836834<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    837835</section>
    838 
    839 </section>
    840 
     836 -->
     837 
    841838<?BEGININC p7-auth.abnf-appendix ?>
    842839<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
Note: See TracChangeset for help on using the changeset viewer.