Re: Comments on File Upload

Francois Yergeau (yergeau@alis.ca)
Fri, 4 Aug 95 14:07:58 EDT

>From: Larry Masinter <masinter@parc.xerox.com>
>Date: Thu, 3 Aug 1995 00:04:01 PDT
>
>The changes you are proposing are very minor optimizations and
>complicate the spec and MIME compatibility greatly. I just don't think
>they are a good idea.

Complicate greatly? Come now, the changes I proposed amount to the
net addition of two lines, and actually represent a simplification in
one instance.

>I don't think it is a good idea to make the default content-type
>depend on the URL scheme.

It is already so in the HTML spec (see section 4.1, text/html media
type). I don't think it is a good idea to impose an old SMTP
restriction on all protocols present and future.

>Is it 'text/plain; charset=US-ASCII' for
>'mailto:', but 'text/plain; charset=ISO-8859-1' for 'http:', but what
>is it for ftp:? Or some new URL scheme?

Then make it ISO-8859-1 everywhere but in mail. Leave 7-bit
brokenness problems only to those who *have* to deal with them (MUAs).

>It just isn't that much extra
>overhead to include the actual content-type if it isn't the MIME
>default.

It's even less overhead if the default is better defined. It also
makes for simpler implementation (except for, again, MUAs, which have
to do it anyway) if you don't have to test for 8-bit octets and
include a meaningless C-T-E header. Your wording on C-T-E headers
places useless requirements on HTTP user agents, with no benefit.

>In addition, I don't think RFC 1522 encoding is appropriate to
>introduce into multipart/form-data headers; it's a complex mechanism
>for little or no benefit.

I disagree strongly here. It is not "little or no benefit" to let a
large majority of the world's population make up names in their own
language.

For one thing, RFC 1522 is part of MIME and it actually diminishes
MIME compatibility to forbid its use.

As for complexity, I think it would be less complicated for a WYSIWYG
HTML editor to simply RFC1522-encode whatever the user types than to
enforce this restriction (requires interaction, telling the user: "No,
no, you can't call this Number field 'Numéro', the 'merkins have once
again forced US-ASCII down your throat").

There are already far too many cases where ASCII is imposed by
backwards compatibility issues. This is not one of them, so please
don't gratuitously limit the protocol.

-- 
François Yergeau <yergeau@alis.ca>
Alis Technologies Inc., Montréal
Tél: +1 (514) 738-9171
Fax: +1 (514) 342-0318