Re: request for new forms submission consensus
kevin@scic.intel.com (Kevin Altis)
X-Delivered: at request of secret on dxcern.cern.ch
Message-id: <9310111937.AA18283@rs042.scic.intel.com>
X-Sender: kevin@rs042.scic.intel.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Oct 1993 12:33:45 -0800
To: sanders@bsdi.com, www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
Subject: Re: request for new forms submission consensus
At 1:27 PM 10/11/93 -0500, Tony Sanders wrote:
>[on forms submission]
>> too long from now one of those forms will be "type=audio" :), and when
>Very good point. I second the vote to use MIME encodings. However, this
>doesn't preclude using the encoding we have now under POST with a simple
>MIME header. Then we can easily move to more complex forms like
>multipart/mixed (example below).
I "third" the vote for MIME encodings, I think we will we in great shape
for the future. Not only can we do complex types such as audio, video...
but we can also do complex encodings, including encryption when standards
become available. The current MIME standard explicitly forbids use of
encodings other than 7bit, 8bit, or binary with content types that
recursively include other content-type fields (multipart and message); I
think Tony's example was illegal. However, a multi-part query could be sent
which includes some encrypted content-types within a multi-part message.
Multi-part messages should also clean up requests so we don't get a lot of
gopher looking strings between the client and server. Did I just go off the
deep end and lose everyone or is the text above clear?! MIME experts please
speak up.
ka