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

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

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (6 diffs)

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

@@ -380 +380 @@
 </artwork></figure>
 <t>
-   Media-type values are registered with the Internet Assigned Number
-   Authority (IANA). The media type registration process is
-   outlined in <xref target="BCP13"/>. Use of non-registered media types is
-   discouraged.
+   Internet media types ought to be registered with IANA according to the
+   procedures defined in <xref target="BCP13"/>.
 </t>
 </section>
@@ -398 +396 @@
 </artwork></figure>
 <t>
-   The IANA Character Set registry
+   Charset names ought to be registered in IANA Character Set registry
    (<eref target="http://www.iana.org/assignments/character-sets"/>)
-   maintains the set of tokens registered for use on the Internet as
-   charset names  <xref target="RFC2978"/>.
+   according to the procedures defined in <xref target="RFC2978"/>.
 </t>
 </section>
@@ -526 +523 @@
    used to allow a representation to be compressed or otherwise usefully
    transformed without losing the identity of its underlying media type
-   and without loss of information. Frequently, the representation is stored in
-   coded form, transmitted directly, and only decoded by the recipient.
+   and without loss of information. Frequently, the representation is stored
+   in coded form, transmitted directly, and only decoded by the recipient.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
@@ -533 +530 @@
 </artwork></figure>
 <t>
-   All content-coding values are case-insensitive and &SHOULD; be registered
+   All content-coding values are case-insensitive and ought to be registered
    within the HTTP Content Coding registry, as defined in
    <xref target="content.coding.registry"/>. They are used in the
@@ -1174 +1171 @@
 <t>
    Additional methods &MAY; 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
-   <xref target="method.registry"/>.
+   standardized outside the scope of this specification and ought to be
+   registered within the HTTP Method Registry maintained by IANA, as defined
+   in <xref target="method.registry"/>.
 </t>
 <t>
@@ -4345 +4342 @@
 <t>
    The requirements for header field names are defined in
-   <xref target="BCP90"/>.  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).
+   <xref target="BCP90"/>.  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.)
 </t>
 <t>