Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)

weber@eit.COM (Jay C. Weber)
Date: Wed, 6 Apr 1994 19:38:06 --100
Message-id: <9404061735.AA02880@eit.COM>
Reply-To: weber@eit.COM
Precedence: bulk
From: weber@eit.COM (Jay C. Weber)
To: Multiple recipients of list <>
Subject: Re: FORM ENCTYPE=multipart/www-form  (was: Toward closure on HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1149

> From: Dave Raggett <>
> My thoughts on a multipart/related format for forms are to start with
> an SGML based encoding for most fields and to use additional parts
> as needed for data which doesn't fit neatly into the SGML scheme, e.g.
> audio, pen input (as JOT), and file data. This way you normally just
> see one part.
> The next step is to define the SGML DTD for form contents and to
> specify the naming scheme for referencing data in other parts.
> The SGML ID notation springs to mind here.

Oh yeah, I forgot to mention that if someone wants to invent another
ENCTYPE, say text/sgml-www-form, then you can just use that as the
catch-all content-type instead of application/www-form-url-encoded.

But I guess the strong version of your thoughts is to require this new
SGML-based simple form value type, and bury www-form-url-encoded in

I'm sure there are others who'll say "sure that would have been more
elegant, but why invent a new simple form format at this point?"

For my part, I like having the MIME encapsulation support either, then
we'll see what happens when the developers have at it.