[ietf-types] The application/www-form-urlencoded format

[Bjoern Hoehrmann <[e-mail]>]

Hi,

  http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
scribes the application/www-form-urlencoded format, a variant of the
application/x-www-form-urlencoded format first described in RFC 1866.
RFC 1866 recommended that implementations also accept ";" as separator,
which the draft permits and prefers, and RFC 1866 failed to define the
character encoding to use, the draft addresses that by mandating UTF-8,
which is universally recommended these days. As the ampersand will be
handled as it would be for the RFC 1866 format, I believe the formats
are similar enough that using the very similar name is justified. [1]

The draft probably still has some rough edges in the prose but the
format is not going to change. I believe it addresses the feedback I
got since the first draft published four years ago; public feedback at
http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30

The template is as follows. Looking at RFC 4288 again, it seems instead
of "8bit" the encoding considerations should be "binary".

   Type name:               application
   Subtype name:            www-form-urlencoded
   Required parameters:     none
   Optional parameters:     none

      Note: The media type does not have a 'charset' parameter, it
      is incorrect specify one and to associate any significance to
      it if specified. The character encoding is always UTF-8. The
      Unicode encoding form signature is not supported; a leading
      U+FEFF character will be considered part of a <name>.

   Encoding considerations: 8bit

   Security considerations: See section 9.
   Interoperability considerations:
      None, except as noted in other sections of this document.

   Published specification: RFC XXXX
   Applications that use this media type:
      Systems that interchange data sets of name-value pairs.

   Additional information:

      Magic number(s):             n/a
      File extension(s):           n/a
      Macintosh file type code(s): TEXT
      Fragment identifiers:        n/a

   Person & email address to contact for further information:
      See Author's Address section.

   Intended usage:          COMMON
   Restrictions on usage:   n/a
   Author:                  See Author's Address section.
   Change controller:       The IESG.

[1] The regular expression to match both names is slightly simpler if
    they only differ in the "x-", and it seems fitting to standardize
    an "x-" type by removing the "x-", but if there is a good argument
    why using similar names is a bad idea, I am also quite open to name
    it application/name-value-pairs or something like that instead.

Let me know if anyone sees any other problem. Thanks,
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/