Ignore:
Timestamp:
Dec 9, 2012, 7:44:14 AM (7 years ago)
Author:
fielding@…
Message:

Reference BCP numbers when informative and not section specific; Note added requirement on URI consistency with method semantics; partly addresses #419

File:
1 edited

Legend:

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

    r2045 r2046  
    328328</texttable>
    329329
    330 <section title="Data Type" anchor="data.type">
     330<section title="Processing the Data" anchor="data.type">
    331331
    332332<section title="Media Type" anchor="media.type">
     
    339339   and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in
    340340   order to provide open and extensible data typing and type negotiation.
     341   Media types define both a data format and various processing models:
     342   how to process that data in accordance with each context in which it
     343   is received.
    341344</t>
    342345<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
     
    379382   Media-type values are registered with the Internet Assigned Number
    380383   Authority (IANA). The media type registration process is
    381    outlined in <xref target="RFC4288"/>. Use of non-registered media types is
     384   outlined in <xref target="BCP13"/>. Use of non-registered media types is
    382385   discouraged.
    383386</t>
     
    508511</section>
    509512
    510 <section title="Data Encoding" anchor="data.encoding">
     513<section title="Encoding for Compression or Integrity" anchor="data.encoding">
    511514
    512515<section title="Content Codings" anchor="content.codings">
     
    43304333   HTTP header fields are registered within the Message Header Field Registry
    43314334   located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>,
    4332    as defined by <xref target="RFC3864"/>.
     4335   as defined by <xref target="BCP90"/>.
    43334336</t>
    43344337
     
    43424345<t>
    43434346   The requirements for header field names are defined in
    4344    <xref target="RFC3864" x:fmt="of" x:sec="4.1"/>.  Authors of specifications
     4347   <xref target="BCP90"/>.  Authors of specifications
    43454348   defining new fields are advised to keep the name as short as practical, and
    43464349   not to prefix them with "X-" if they are to be registered (either
     
    53555358</reference>
    53565359
    5357 <reference anchor='RFC3864'>
     5360<reference anchor='BCP90'>
    53585361  <front>
    53595362    <title>Registration Procedures for Message Header Fields</title>
     
    53765379</reference>
    53775380
    5378 <reference anchor="RFC4288">
     5381<reference anchor="BCP13">
    53795382  <front>
    53805383    <title>Media Type Specifications and Registration Procedures</title>
     
    56475650<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    56485651<t>
     5652   Request semantics embedded in a URI should be disabled when those
     5653   semantics are inconsistent with the request method, since this is a
     5654   common cause of interoperability failure.
     5655</t>
     5656<t>
    56495657  The term "representation" is introduced, replacing both "entity" and
    56505658  "variant."
    56515659  (<xref target="representations" />)
     5660</t>
     5661<t>
     5662  Rules for identifying the payload of a message have been defined.
     5663  (<xref target="identifying.payload" />)
    56525664</t>
    56535665<t>
     
    56635675  resources).
    56645676  (<xref target="header.content-location"/>)
    5665 </t>
    5666 <t>
    5667   Rules for identifying the payload of a message have been defined.
    5668   (<xref target="identifying.payload" />)
    56695677</t>
    56705678<t>
Note: See TracChangeset for help on using the changeset viewer.