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

weber@eit.COM (Jay C. Weber)
Date: Wed, 6 Apr 1994 18:48:49 --100
Message-id: <9404061646.AA01982@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: 1337

I got a response that said separate MIME parts per form entry was too
much overhead for text values, while not just use SGML?

The reason we are discussing the use of MIME is because we see form
values soon extending to relatively complex media clips (signatures,
files, snapshots, etc. -- some already supported by ViolaWWW, by
the way).  SGML is not suitable for that but MIME is.

So if the multipart/www-form overhead for simple fields is too much,
we need some hybrid.  Here's a suggestion:

 each part in a multipart/www-form is interpreted as a form field
 whose name appears in the Content-id, and value is the part's body
 of type specified by an optional Content-type UNLESS the content-type
 is an ENCTYPE other than multipart/www-form, which is interpreted as
 containing additional form name/value pairs.


COntent-type: multipart/www-form

Content-type: application/www-form-url-encoded

Content-id: comments

This is supposed to be some long block of text,
e.g. from a TEXTAREA or file inclusion

Content-id: sig
Content-type: image/xpm

<lots of bits here>

(I said that "catch-all" parts should be an ENCTYPE *other than
multipart/www-form* to reserve the use of recursive multipart/www-forms
for hierarchical forms with hiearchical name spaces.)