[apps-discuss] Feedback on multipart/form-data

Larry Masinter <masinter@adobe.com> Thu, 15 August 2013 18:30 UTC

Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7011E81FB for <apps-discuss@ietfa.amsl.com>; Thu, 15 Aug 2013 11:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRk-Lp8t8vYs for <apps-discuss@ietfa.amsl.com>; Thu, 15 Aug 2013 11:29:58 -0700 (PDT)
Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 464C211E8183 for <apps-discuss@ietf.org>; Thu, 15 Aug 2013 11:29:57 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUg0eJMhGvWph/0ZC16hLPN+BGplbhNab@postini.com; Thu, 15 Aug 2013 11:29:58 PDT
Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7FIQQD8014128; Thu, 15 Aug 2013 11:26:26 -0700 (PDT)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7FIPCwB000637; Thu, 15 Aug 2013 11:29:54 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Thu, 15 Aug 2013 11:28:42 -0700
From: Larry Masinter <masinter@adobe.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Thu, 15 Aug 2013 11:28:39 -0700
Thread-Topic: Feedback on multipart/form-data
Thread-Index: Ac6Z42DyQFQ/iycLRw+sZckifzMy8A==
Message-ID: <C68CB012D9182D408CED7B884F441D4D34728C1A86@nambxv01a.corp.adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ian Hickson <ian@hixie.ch>
Subject: [apps-discuss] Feedback on multipart/form-data
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 18:30:03 -0000

I'm working on a revision to  RFC 2388 multipart/form-data 
but I want some feedback before submitting a first draft.

I sent a pointer before, 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8

but perhaps you can comment instead on 
     https://github.com/masinter/multipart-form-data


RFC 2388 was clear:
   Field names originally in non-ASCII character sets may be encoded
   within the value of the "name" parameter using the standard method
   described in RFC 2047.

For reasons I don't understand, browsers did different, incompatible
things. 

I think the main advice is: 

* those creating HTML forms 
   SHOULD use ASCII field names, since deployed HTML processors vary,
   and field names shouldn't be visible to the user anyway.

* Those developing server infrastructure to read multipart/form-data uploads
   SHOULD be aware of the varying behavior of the browsers in translating
   non-ASCII field names, and look for any of the variants (if they're 
   expecting non-ASCII field names). 

* Those developing browsers should migrate toward a standard 
  encoding, but the server infrastructure will still have to do
  fuzzy match for a long while.

What should the browsers migrate to?

 http://www.rfc-editor.org/rfc/rfc5987.txt 
seems like a more recent proposal and possibly implemented in HTTP anyway.

Sites that use non-ASCII field names and want to work with multiple
browsers already have to do fuzzy matching.

The problem is that the fuzzy matchers already deployed might not
recognize any *NEW* encodings.

So I suppose having a name* value would be necessary.