Changeset 2047 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

09/12/12 16:54:07 (8 years ago)

Author:

fielding@…

Message:

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

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (5 diffs)

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

@@ -916 +916 @@
   Text/HTML;Charset="utf-8"
   text/html; charset="utf-8"
-</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
-         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.
+</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>.
       </p>
       <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>
@@ -923 +922 @@
       </p>
       <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>
-</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>.
+</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>.
       </p>
       <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>
@@ -985 +984 @@
       </p>
       <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>
-</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.
+</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
+         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.
       </p>
       <p id="rfc.section.3.1.2.1.p.4">The following content-coding values are defined by this specification: </p>
@@ -1355 +1355 @@
       <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>.
       </p>
-      <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
-         Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;9.1</a>.
+      <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
+         the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;9.1</a>.
       </p>
       <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
@@ -3463 +3463 @@
          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.
       </p>
-      <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
-         with "X-" if they are to be registered (either immediately or in the future).
+      <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
+         with "X-" unless the header field will never be used on the Internet. (The "x-" prefix idiom has been extensively misused
+         in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet
+         processing, since the prefix would ensure that private names never collide with a newly registered Internet name.)
       </p>
       <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