Ignore:
Timestamp:
09/12/12 16:54:07 (10 years ago)
Author:
fielding@…
Message:

Clean up pseudo normative text regarding use of registered values; partly addresses #419

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2046 r2047  
    12071207         the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
    12081208      </p>
    1209       <p id="rfc.section.3.2.1.p.2">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1209      <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
    12101210      </p>
    12111211      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
    … …  
    12141214         conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
    12151215      </p>
    1216       <p id="rfc.section.3.2.2.p.2">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)].
     1216      <p id="rfc.section.3.2.2.p.2">A sender <em class="bcp14">MUST NOT</em> generate multiple header fields with the same field name in a message unless either the entire field value for that header
     1217         field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
    12171218      </p>
    12181219      <p id="rfc.section.3.2.2.p.3">Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing
    … …  
    15351536  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    15361537  <a href="#rule.parameter" class="smpl">value</a>              = <a href="#rule.token.separators" class="smpl">word</a>
    1537 </pre><p id="rfc.section.4.p.5">All transfer-coding names are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
     1538</pre><p id="rfc.section.4.p.5">All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined
     1539         in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
    15381540      </p>
    15391541      <div id="rfc.iref.c.9"></div>
    … …  
    20972099      </p>
    20982100      <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    2099          by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    2100          in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
     2101         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure
     2102         defined in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    21012103      </p>
    21022104      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2046 r2047  
    11931193</t>
    11941194<t>
    1195    New HTTP header fields &SHOULD; be registered with IANA in the
     1195   New HTTP header fields ought to be be registered with IANA in the
    11961196   Message Header Field Registry, as described in &iana-header-registry;.
    1197    Unrecognized header fields &MUST; be forwarded by a proxy unless the
     1197   A proxy &MUST; forward unrecognized header fields unless the
    11981198   field-name is listed in the <x:ref>Connection</x:ref> header field
    11991199   (<xref target="header.connection"/>) or the proxy is specifically
    1200    configured to block or otherwise transform such fields.
    1201    Unrecognized header fields &SHOULD; be ignored by other recipients.
     1200   configured to block, or otherwise transform, such fields.
     1201   Other recipients &SHOULD; ignore unrecognized header fields.
    12021202</t>
    12031203</section>
    … …  
    12161216</t>
    12171217<t>
    1218    Multiple header fields with the same field name &MUST-NOT; be
    1219    sent in a message unless the entire field value for that
    1220    header field is defined as a comma-separated list [i.e., #(values)].
     1218   A sender &MUST-NOT; generate multiple header fields with the same field
     1219   name in a message unless either the entire field value for that
     1220   header field is defined as a comma-separated list [i.e., #(values)]
     1221   or the header field is a well-known exception (as noted below).
    12211222</t>
    12221223<t>
    … …  
    18731874</artwork></figure>
    18741875<t>
    1875    All transfer-coding names are case-insensitive and &SHOULD; be registered
     1876   All transfer-coding names are case-insensitive and ought to be registered
    18761877   within the HTTP Transfer Coding registry, as defined in
    18771878   <xref target="transfer.coding.registry"/>.
    … …  
    30863087   the family of Hypertext Transfer Protocols, as defined by the HTTP
    30873088   version rules of <xref target="http.version"/> and future updates to this
    3088    specification. Additional tokens can be registered with IANA using the
     3089   specification. Additional tokens ought to be registered with IANA using the
    30893090   registration procedure defined in <xref target="upgrade.token.registry"/>.
    30903091</t>

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

    r2046 r2047  
    916916  Text/HTML;Charset="utf-8"
    917917  text/html; charset="utf-8"
    918 </pre><p id="rfc.section.3.1.1.1.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
    919          outlined in <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>. Use of non-registered media types is discouraged.
     918</pre><p id="rfc.section.3.1.1.1.p.8">Internet media types ought to be registered with IANA according to the procedures defined in <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>.
    920919      </p>
    921920      <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;<a id="charset" href="#charset">Charset</a></h4>
    … …  
    923922      </p>
    924923      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#charset" class="smpl">charset</a> = <a href="#imported.abnf" class="smpl">token</a>
    925 </pre><p id="rfc.section.3.1.1.2.p.3">The IANA Character Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;) maintains the set of tokens registered for use on the Internet as charset names <a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>.
     924</pre><p id="rfc.section.3.1.1.2.p.3">Charset names ought to be registered in IANA Character Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;) according to the procedures defined in <a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>.
    926925      </p>
    927926      <h4 id="rfc.section.3.1.1.3"><a href="#rfc.section.3.1.1.3">3.1.1.3</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h4>
    … …  
    985984      </p>
    986985      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#imported.abnf" class="smpl">token</a>
    987 </pre><p id="rfc.section.3.1.2.1.p.3">All content-coding values are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Content Coding registry, as defined in <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;9.4</a>. They are used in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.1.2.2</a>) header fields.
     986</pre><p id="rfc.section.3.1.2.1.p.3">All content-coding values are case-insensitive and ought to be registered within the HTTP Content Coding registry, as defined
     987         in <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;9.4</a>. They are used in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.1.2.2</a>) header fields.
    988988      </p>
    989989      <p id="rfc.section.3.1.2.1.p.4">The following content-coding values are defined by this specification: </p>
    … …  
    13551355      <p id="rfc.section.5.1.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;5.3</a>.
    13561356      </p>
    1357       <p id="rfc.section.5.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and registered within the HTTP
    1358          Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;9.1</a>.
     1357      <p id="rfc.section.5.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and ought to be registered within
     1358         the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;9.1</a>.
    13591359      </p>
    13601360      <p id="rfc.section.5.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;8.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or
    … …  
    34633463         or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
    34643464      </p>
    3465       <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them
    3466          with "X-" if they are to be registered (either immediately or in the future).
     3465      <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name
     3466         with "X-" unless the header field will never be used on the Internet. (The "x-" prefix idiom has been extensively misused
     3467         in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet
     3468         processing, since the prefix would ensure that private names never collide with a newly registered Internet name.)
    34673469      </p>
    34683470      <p id="rfc.section.9.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters

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

    r2046 r2047  
    380380</artwork></figure>
    381381<t>
    382    Media-type values are registered with the Internet Assigned Number
    383    Authority (IANA). The media type registration process is
    384    outlined in <xref target="BCP13"/>. Use of non-registered media types is
    385    discouraged.
     382   Internet media types ought to be registered with IANA according to the
     383   procedures defined in <xref target="BCP13"/>.
    386384</t>
    387385</section>
    … …  
    398396</artwork></figure>
    399397<t>
    400    The IANA Character Set registry
     398   Charset names ought to be registered in IANA Character Set registry
    401399   (<eref target="http://www.iana.org/assignments/character-sets"/>)
    402    maintains the set of tokens registered for use on the Internet as
    403    charset names  <xref target="RFC2978"/>.
     400   according to the procedures defined in <xref target="RFC2978"/>.
    404401</t>
    405402</section>
    … …  
    526523   used to allow a representation to be compressed or otherwise usefully
    527524   transformed without losing the identity of its underlying media type
    528    and without loss of information. Frequently, the representation is stored in
    529    coded form, transmitted directly, and only decoded by the recipient.
     525   and without loss of information. Frequently, the representation is stored
     526   in coded form, transmitted directly, and only decoded by the recipient.
    530527</t>
    531528<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
    … …  
    533530</artwork></figure>
    534531<t>
    535    All content-coding values are case-insensitive and &SHOULD; be registered
     532   All content-coding values are case-insensitive and ought to be registered
    536533   within the HTTP Content Coding registry, as defined in
    537534   <xref target="content.coding.registry"/>. They are used in the
    … …  
    11741171<t>
    11751172   Additional methods &MAY; be used in HTTP; many have already been
    1176    standardized outside the scope of this specification and registered
    1177    within the HTTP Method Registry maintained by IANA, as defined in
    1178    <xref target="method.registry"/>.
     1173   standardized outside the scope of this specification and ought to be
     1174   registered within the HTTP Method Registry maintained by IANA, as defined
     1175   in <xref target="method.registry"/>.
    11791176</t>
    11801177<t>
    … …  
    43454342<t>
    43464343   The requirements for header field names are defined in
    4347    <xref target="BCP90"/>.  Authors of specifications
    4348    defining new fields are advised to keep the name as short as practical, and
    4349    not to prefix them with "X-" if they are to be registered (either
    4350    immediately or in the future).
     4344   <xref target="BCP90"/>.  Authors of specifications defining new fields are
     4345   advised to keep the name as short as practical and to not prefix the name
     4346   with "X-" unless the header field will never be used on the Internet.
     4347   (The "x-" prefix idiom has been extensively misused in practice; it was
     4348   intended to only be used as a mechanism for avoiding name collisions inside
     4349   proprietary software or intranet processing, since the prefix would ensure
     4350   that private names never collide with a newly registered Internet name.)
    43514351</t>
    43524352<t>
Note: See TracChangeset for help on using the changeset viewer.