Re: Paul Burchard on HTML 2.0 FORMs

"Daniel W. Connolly" <connolly@oclc.org>
Date: Mon, 11 Jul 94 14:03:55 EDT
Message-id: <9407111803.AA14855@ulua.hal.com>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@oclc.org>
To: Multiple recipients of list <html-ig@oclc.org>
Subject: Re: Paul Burchard on HTML 2.0 FORMs 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group (Private)
In message <94Jul11.103311pdt.2760@golden.parc.xerox.com>, Larry Masinter write
s:
>With type = SCRIBBLE or AUDIO, in what format is the value to be
>returned? URL-encoded binary?

Short answer: I don't know and for the purpose of the HTML 2.0 spec, I
don't care. The only thing happining in current practice is
	ACTION="http:..." ENCTYPE="application/x-www-form-urlencoded"
	and METHOD="GET" or METHOD="PUT"

Long Answer:

SCRIBBLE and AUDIO are only proposed. I guess you're pointing out that
the proposals are incomplete. Such is life.

This stuff from Paul Burchard's description covers it pretty well:

>In general, the METHOD attribute selects
>variations in the protocol, while the ENCTYPE attribute
>specifies the format of the submitted data, in case the
>protocol does not impose a format itself.  This standard only
>defines and requires support for the HTTP access protocol.
>
><P>When the ACTION is an HTTP URL, the METHOD must be an
>HTTP <EM>method</EM> as defined in the IETF draft HTTP standard
>(see the <A
>HREF="http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Methods.html"
>HTTP method specification</A>).
>The default method is GET, although for many applications,
>the POST method will be preferred.  In the latter case,
>the ENCTYPE attribute is a MIME type
>specifying the format of the POSTed data
>(by default <CODE>application/x-www-form-urlencoded</CODE>).


Note that the ENCTYPE doesn't correspond to the encoding of an
individual INPUT value, but rather the format for the encoding of the
whole set of name/value bindings.

The application/x-www-form-urlencoded format only allows character
strings as values. If I wanted to allow multimedia values, I'd make up
a new name/value set encoding, like a compressed tar file where a
name/value pair corresponds to a file with that name and the value as
its contents. A designated file gives the MIME content types of all
the others. (tar is somewhat inefficient for small values, but with
gzip compression, it probably wouldn't make much difference.)

For example, If I were actually implementing a system that allowed
folks to submit audio and such, I'd probably write my forms like:

	<FORM METHOD="PUT" ACTION="http://myserver/my-form-inbox"
		ENCTYPE="application/x-multimedia-tar">
	<p>Enter voice identification: <input name="voiceid" type="audio">
	</FORM>

and I'd expect the HTTP request to look something like:

	PUT /my-form-inbox HTTP/1.0
	Content-Type: application/x-multimedia-tar; toc="toc";
			conversions="x-gzip"
	Content-Length: nnnn

	...body is gzip'd tar file...

	...tar header block for file named toc containing...
	# mapping from filenames to content types
	voiceid	audio/basic

	...tar-file named "voiceid"...
	... voiceprint data in audio/basic format...



Dan