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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 27 September 2010 06:53 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48B63A6B13 for <ietf-types@core3.amsl.com>; Sun, 26 Sep 2010 23:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.558
X-Spam-Level:
X-Spam-Status: No, score=-99.558 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HssqimUXwivX for <ietf-types@core3.amsl.com>; Sun, 26 Sep 2010 23:53:04 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 2BEA13A69C5 for <ietf-types@ietf.org>; Sun, 26 Sep 2010 23:53:02 -0700 (PDT)
Received: from acspool01.acbb.aoyama.ac.jp (acspool01.acbb.aoyama.ac.jp [133.2.20.162]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id o8R6rIbR001648 for <ietf-types@iana.org>; Sun, 26 Sep 2010 23:53:39 -0700
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by acspool01.acbb.aoyama.ac.jp (secret/secret) with ESMTP id o8Q5ScwR009580 for <ietf-types@iana.org>; Sun, 26 Sep 2010 14:28:39 +0900
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id o8Q5Pg3B027357 for <ietf-types@iana.org>; Sun, 26 Sep 2010 14:25:42 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6f20_2360_81c040a4_c92e_11df_949b_001d096c566a; Sun, 26 Sep 2010 14:25:42 +0900
Received: from [IPv6:::1] ([133.2.210.1]:45271) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1453ADA> for <ietf-types@iana.org> from <duerst@it.aoyama.ac.jp>; Sun, 26 Sep 2010 14:25:41 +0900
Message-ID: <4C9ED94B.6080505@it.aoyama.ac.jp>
Date: Sun, 26 Sep 2010 14:25:31 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <k1os96p03o78p78490hei104biadpiepit@hive.bjoern.hoehrmann.de>
In-Reply-To: <k1os96p03o78p78490hei104biadpiepit@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Delayed for 25:24:38 by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Sun, 26 Sep 2010 23:53:39 -0700 (PDT)
Cc: ietf-types@iana.org
Subject: Re: [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: Mon, 27 Sep 2010 06:53:05 -0000

Hello Björn,

Can you give some rough information on where 
application/www-form-urlencoded is implemented or implementation is planned?

Also, in many cases, an identifier without x- denotes just the same as 
the identifier with the x-. I think it would be good if the registration 
template contained at least a small reminder and pointer to make clear 
that it's not exactly the same as the x- variant.

Regards,   Martin.


On 2010/09/26 6:14, Bjoern Hoehrmann wrote:
> 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,

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp