Re: request for new forms submission consensus

"William M. Perry" <>
To: (Marc Andreessen)
Subject: Re: request for new forms submission consensus 
In-reply-to: Your message of "Mon, 11 Oct 1993 05:48:22 MST."
Date: Mon, 11 Oct 1993 06:42:22 -0500
Message-id: <>
From: "William M. Perry" <>
In response to your message dated: Mon, 11 Oct 1993 05:48:22 MST
>Can we come to a consensus on a forms submission method that uses
>HTTP/1.0 to deliver the contents of large forms (including multiline
>edit fields) to smart servers in the next week or two?  (Unless we
>already have and I missed it...)
>All things being equal, I think I'd be happy with the current
>encoding method (name=value&name=value with escaping) just slapped
>into the body of an HTTP/1.0 'SUBMIT' request -- keeps things simple
>and straightforward, avoids creating a new syntax, is known to
>properly handle escaping issues, and servers and code already exist
>for decoding/handling it.

  What about issuing a real MIME-message?  multipart/text or something
like that (not a MIME guru, so somthing else might be more
appropriate).  Each variable could have its own 'part'.  Would this be
too much of a pain on the server side?  (Imagine it would)

>To be honest, the idea of encoding it in some kind of SGML format
>does not excite me in the least -- what would be the added value?
>Also, I'd like to suggest that multiline text fields have a different
>type (e.g. "textarea") than single-line fields ("text"), as they
>really are different types of things, and imply different issues
>(semantics) for client-side handling.

  Definitely agree with this!  I'm going to have a few hours of coding
ahead of me to add all the forms options you guys put into Mosaic2p5
into my emacs browser.

  Popup lists are great, but as I said in an earlier message, I think
we need to stay away from things like sliders and knobs.

  Looking forward to playing with pre5 when I get to my xterm!

-bill p