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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 27 September 2010 07:23 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 64EB83A6C7E for <ietf-types@core3.amsl.com>; Mon, 27 Sep 2010 00:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.576
X-Spam-Level:
X-Spam-Status: No, score=-99.576 tagged_above=-999 required=5 tests=[AWL=-0.386, 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 jNzcuJ22FjhW for <ietf-types@core3.amsl.com>; Mon, 27 Sep 2010 00:23:07 -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 2314F3A69FA for <ietf-types@ietf.org>; Mon, 27 Sep 2010 00:23:06 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id o8R7NOrU005917 for <ietf-types@iana.org>; Mon, 27 Sep 2010 00:23:44 -0700
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id o8R7NNc3013271 for <ietf-types@iana.org>; Mon, 27 Sep 2010 16:23:23 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0e3c_5cec_1cffae4a_ca08_11df_a37a_001d096c5782; Mon, 27 Sep 2010 16:23:23 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35489) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1454B5E> for <ietf-types@iana.org> from <duerst@it.aoyama.ac.jp>; Mon, 27 Sep 2010 16:23:22 +0900
Message-ID: <4CA0465E.1060803@it.aoyama.ac.jp>
Date: Mon, 27 Sep 2010 16:23:10 +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: Anne van Kesteren <annevk@opera.com>
References: <k1os96p03o78p78490hei104biadpiepit@hive.bjoern.hoehrmann.de> <op.vjmuz10364w2qv@anne-van-kesterens-macbook-pro.local> <679v96hgl3jqatro4epeqlneqoms020uhe@hive.bjoern.hoehrmann.de> <op.vjnqdzm664w2qv@anne-van-kesterens-macbook-pro.local>
In-Reply-To: <op.vjnqdzm664w2qv@anne-van-kesterens-macbook-pro.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Mon, 27 Sep 2010 00:23:44 -0700 (PDT)
Cc: ietf-types@iana.org, Bjoern Hoehrmann <derhoermi@gmx.net>
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 07:23:08 -0000

On 2010/09/27 5:40, Anne van Kesteren wrote:
> On Sun, 26 Sep 2010 22:19:40 +0200, Bjoern Hoehrmann <derhoermi@gmx.net>
> wrote:
>> * Anne van Kesteren wrote:

>>> Most other such formats ignore a leading U+FEFF.
>>
>> I can't think of any format that's always UTF-8 encoded yet allows for
>> it, but anyway, treating it as part of a name is simpler than ignoring
>> it, I think people are more likely to implement that correctly than if
>> I were to require recognizing it.
>
> text/event-stream and text/cache-manifest.

Ignoring a leading U+FEFF makes sense for formats that are in most ways 
close to files. That's the case for most MIME types. But this one is 
very clearly different; it's more like a micro-level format for a single 
line of data composed of many fields, than a file format. In that case, 
ignoring a leading U+FEFF seems to make very little sense. Also, while a 
large number of servers these days can work with UTF-8 easily, I 
wouldn't know of any server infrastructure that ingnored an U+FEFF in 
this case.

Regards,    Martin.


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