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

Bjoern Hoehrmann <derhoermi@gmx.net> Sat, 25 September 2010 21:41 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C56CB3A69FB for <ietf-types@core3.amsl.com>; Sat, 25 Sep 2010 14:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.375
X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-1.976, BAYES_50=0.001, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id HW9KcCjRyvWI for <ietf-types@core3.amsl.com>; Sat, 25 Sep 2010 14:41:38 -0700 (PDT)
Received: from pechora6.dc.icann.org (pechora6.icann.org []) by core3.amsl.com (Postfix) with ESMTP id C280D3A6925 for <ietf-types@ietf.org>; Sat, 25 Sep 2010 14:41:27 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net []) by pechora6.dc.icann.org (8.13.8/8.13.8) with SMTP id o8PLfOnw011786 for <ietf-types@iana.org>; Sat, 25 Sep 2010 17:41:46 -0400
Received: (qmail invoked by alias); 25 Sep 2010 21:14:41 -0000
Received: from dslb-094-223-218-126.pools.arcor-ip.net (EHLO hive) [] by mail.gmx.net (mp059) with SMTP; 25 Sep 2010 23:14:41 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/X5/Ud1C/XkwUTWp5wwSJNp6Fudt8kEH1jIFAhRD gWedR21GNRtnar
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: ietf-types@iana.org
Date: Sat, 25 Sep 2010 23:14:39 +0200
Message-ID: <k1os96p03o78p78490hei104biadpiepit@hive.bjoern.hoehrmann.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Greylist: Delayed for 00:26:41 by milter-greylist-4.2.3 (pechora6.dc.icann.org []); Sat, 25 Sep 2010 17:41:47 -0400 (EDT)
Subject: [ietf-types] The application/www-form-urlencoded format
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Sep 2010 21:41:44 -0000


  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

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:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/