Define the application/x-www-form-urlencoded MIME type

[annevk]

HTML has/had this:

  <h3><dfn><code>application/x-www-form-urlencoded</code></dfn></h3>

  <p>This registration is for community review and will be submitted to the IESG for review,
  approval, and registration with IANA.</p>

  <!--
   To: ietf-types@iana.org
   Subject: Registration of media type application/x-www-form-urlencoded
  -->

  <dl>
   <dt>Type name:</dt>
   <dd>application</dd>
   <dt>Subtype name:</dt>
   <dd>x-www-form-urlencoded</dd>
   <dt>Required parameters:</dt>
   <dd>No parameters</dd>
   <dt>Optional parameters:</dt>
   <dd>No parameters</dd>
   <dt>Encoding considerations:</dt>
   <dd>7bit (US-ASCII encoding of octets that themselves can be encoding text using any <span>ASCII-compatible encoding</span>)</dd>
   <dt>Security considerations:</dt>
   <dd>
    <p>In isolation, an <code>application/x-www-form-urlencoded</code>
    payload poses no security risks. However, as this type is usually
    used as part of a form submission, all the risks that apply to
    HTML forms need to be considered in the context of this type.</p>
   </dd>
   <dt>Interoperability considerations:</dt>
   <dd>
    Rules for generating and processing
    <code>application/x-www-form-urlencoded</code> payloads are
    defined in this specification.
   </dd>
   <dt>Published specification:</dt>
   <dd>
    This document is the relevant specification.
    Algorithms for <span data-x="application/x-www-form-urlencoded encoding algorithm">encoding</span>
    and <span data-x="application/x-www-form-urlencoded decoding algorithm">decoding</span> are defined.
   </dd>
   <dt>Applications that use this media type:</dt>
   <dd>
    Web browsers and servers.
   </dd>
   <dt>Additional information:</dt>
   <dd>
    <dl>
     <dt>Magic number(s):</dt>
     <dd>There is no reliable mechanism for recognising <code>application/x-www-form-urlencoded</code> payloads.</dd>
     <dt>File extension(s):</dt>
     <dd>Not applicable.</dd>
     <dt>Macintosh file type code(s):</dt>
     <dd>Not applicable.</dd>
    </dl>
   </dd>
   <dt>Person &amp; email address to contact for further information:</dt>
   <dd>Ian Hickson &lt;ian@hixie.ch></dd>
   <dt>Intended usage:</dt>
   <dd>Common</dd>
   <dt>Restrictions on usage:</dt>
   <dd>This type is only intended to be used to describe HTML form
   submission payloads.</dd>
   <dt>Author:</dt>
   <dd>Ian Hickson &lt;ian@hixie.ch></dd>
   <dt>Change controller:</dt>
   <dd>W3C</dd>
  </dl>

  <p>Fragment identifiers have no meaning with the <code>application/x-www-form-urlencoded</code>
  type.</p>

None of this seem sreally useful, but I guess we can add a similar section.

[domenic]

HTML also has a few open bugs on removing the IANA stuff (1, 2, full list), although actually perusing their contents it seems like maybe they're about protocol handlers and web+, not about IANA in general. @Hixie, what was the plan in this regard?

[Hixie]

If we had the bandwidth, I think replacing IANA's registry with an actively maintained list of what's implemented and what's currently proposed, with things in the latter list having a deadline by which they have to show implementation or be dropped, is the way to go. The problem is that this requires an active continuous investment forever.

The problem with the IANA lists is that they depend on people proactively registering their stuff and basically nobody does that.

[masinter]

Neither the URL scheme registry nor the media type registry require registration in advance, and both allow basically anyone to register a value, not just the owner,

Consider the possibility that it really is less work to fix the IANA registry than replace it.

[annevk]

Duplicating this into #452. No need to have the template inline, but I agree that we should try to register as long as there is no better alternative.

[domenic]

No need to have the template inline

Hmm, that seems to be pretty common practice across WHATWG/W3C specs still. Do you think we should, e.g., remove https://html.spec.whatwg.org/multipage/iana.html#iana ?

[annevk]

I think we could, but we should update IANA first so it actually points to the correct standard.