Form-based Device Input and Upload in HTML

W3C NOTE 06 July 1999

This version:
Latest version:
James P. Salsman, Cisco Systems <jsalsman@cisco.com>

Status of this Document

This document is a submission to the World Wide Web Consortium from Cisco Systems (see Submission Request, W3C Staff Comment).

This draft extends an implemented protocol for the Internet World Wide Web community. Distribution of this draft and the use of the information described herein is unlimited. This draft is intended for submission to the World Wide Web Consortium to be considered as a proposed recommendation. This document should be referred to as part of the "device-upload" submission.

This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has had any editorial control in its preparation, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.

Copyright Notice

© Copyright Cisco Systems 1999.

For terms and conditions, see IPR section of the Submission Request.



Currently, HTML forms allow the producer of the form to request information, including files of data, from the operator using the form. However, this capability is limited because HTML forms don't provide a way to ask the operator to submit input from arbitrary sources such as audio devices like microphones. Since input and upload from various devices is a feature that will benefit many applications, this draft proposes an extension to the HTML INPUT type="file" form element. Motivations include language instruction assistance, voice transcription, and high-quality speech transmission under low-bandwidth conditions.


The following protocol extensions to the HTML INPUT type="file" protocol of [RFC 1867] are defined by this draft:


Section 3.1 of [RFC 1867] provides for the presentation of an arbitrary "widget" to specify input for file uploads. When an INPUT tag of type="file" is encountered with a device attribute, the associated value (such as "microphone", or an abbreviation like "mic") should [RFC 2119] select the use of a widget capable of buffering and editing real-time input (such as speech) from the specified device and uploading the buffered file when the form is submitted.

If an accept attribute also has a value in such a device file input element, the browser may constrain the MIME type of uploaded data to match those with the list of types specified as the value of the accept attribute. If the value of the device attribute is "filesystem" (or "files") then the INPUT element may be treated as usual according to RFC 1867 except that the subset of files presented to the operator to choose from may be constrained by the specified list of MIME types instead of a pattern of file names or extensions. Please note that without device="files" the accept attribute should be treated as a filename pattern.

If the value of the device parameter is "any", the operator may be offered a choice of all available supported devices and files, restricted to the choices compatible with the MIME types specified in the accept attribute, if present.

File-upload forms are submitted with enctype="multipart/form-data", an alternate FORM tag specification for sending MIME content. Each part of such a submission, representing the value of each input element in the submitted form, is given a Content-Disposition header, which in the case of Content-Disposition: file, may also have a Content-Type header representing the MIME type of the data being uploaded. Files uploaded using the extensions in this draft should include a Content-Type header when the file type is known or can be accurately determined by the client browser. Since no original filename as specified in section 3.3 of [RFC 1867] will be available for arbitrary peripheral input, parameters of the Content-Disposition: form-data submission headers should include a device parameter with the lowercase value of the device attribute of the associated form input element, unless the device or MIME type(s) specified are unsupported in which case the value of the device header parameter may be unsupported, or unless the device is unavailable in which case the value should be unavailable.

If the MIME types requested are unsupported, an additional parameter alternates may be included with a space-separated list of MIME types of the same primary content-type which may be supported as alternatives for the specified device. The alternates parameter is not intended as a content negotiation feature; merely a way for a server to log upload failures which were constrained by the lack of type conversion facilities. The Content-Disposition header parameter syntax is described in [RFC 2183] that contains, along with [RFC 1867], examples of the protocols extended by this proposal.

There may be significant limitations on the client browser's ability to buffer input for upload. Browsers may provide an estimate of the default maxlength available for device input and upload through the HTTP response header Client-file-maxlength: followed with the ASCII decimal representation of the number of bytes representing the content-length available to the browser for buffering.

A server can also specify information about the largest file size it can accept for upload, by use of the HTML maxlength attribute with a value representing the decimal integer of bytes in the HTML form's device input elements. The minimum of all "maxlength" values specified should take precedence. Additionally, for types with extensions in time (such as audio/* and video/*, but not image/* or text/*) the maxtime="integer seconds" parameter specifies the maximum duration of the file to be uploaded without regard for the underlying number of bytes. The maxlength attribute should take precedence over the maxtime attribute if both are specified.

Furthermore, the value attribute may be used to provide a numeric disambiguation between multiple similar devices when present. Under most conditions the operator should be allowed to select the device from ambiguous sources of input, or re-select it if specified by a value parameter. The value attribute might also be used to specify alternative methods of input when the value of value is nonnumeric.

Because of security concerns discussed below, HTML scripts must not be able to invoke a form submission when the form involves any kind of file upload without explicit instructions from the session operator to the contrary.


In this short form, the HTML author has requested the upload of sampled microphone input from the operator upon form submission:
     <FORM enctype="multipart/form-data" method="post" action="_URL_">
       Say something:  <INPUT name="speech1" type="file" device="mic">
       <INPUT type="submit" value="Send Speech">

Below, MIC is not used as an abbreviation. The author of the HTML has requested that the data input from the microphone be encoded as either the MIME type Audio/L16 -- sixteen bit signed linear audio samples (most-significant byte first) -- as specified in [RFC 2586] with a single (monaural) channel and a sample rate of 11,025 samples per second, or an unspecified extended MIME Audio type named x-cepstral-voc. Please note that MIME types are separated by spaces except when the following character is a semicolon, in which case the following non-space string should be of the form ;parameter=value which modifies the preceding MIME type. Space before such MIME type parameters is optional.

     <INPUT name="speech2" type="file" device="microphone"
       accept="audio/L16;rate=11025 ;channels=1 audio/x-cepstral-voc">

Below, the form element may be used to upload a file as usual, except that the files to select from may be constrained to text files, without explicit regard of their filename or extensions. Please note that "/*" after "text" is optional.

     <INPUT name="file1" type="file" device="files" accept="text/*">

The next two examples show how these extensions may be used to request input from other kinds of devices, such as the second of two or more cameras connected to the system running the browser. Please note that the VALUE is only a suggestion, and the browser operator should still be offered to select from multiple devices, with the only difference being the default selection.

     <INPUT name="picture1" type="file" device="camera" value="2">

For this next example only, if there is only one keyboard, the operator's preferred editor may be invoked, but the filename should be unique and not influenced in any way by the string "EMACS". If that value influences the selection of an editor, it should do so with a pre-specified table (such as a "mailcap" file) and should not be used as any part of the command string of the editor executed.

     <INPUT name="essay1" type="file" device="keyboard" value="emacs">

The final example below requests the operator to select images from any device, including the filesystem, for upload to the server, as long as they are less than 100 KB.

     <INPUT name="picture2" type="file" device="any" accept="image"

Compatibility with earlier forms of audio input

Audio input in HTML forms was proposed in late 1993. To accommodate the syntax of these earlier extensions, a browser might interpret an HTML statement such as
     <INPUT type="audio" ...>
as the device input form
     <INPUT type="file" device="microphone" ...>
with all other attribute/value pairs of the original INPUT element kept the same as specified. This would retain compatibility for all implementations of which the author of this draft is aware.

HTML Document Type Description changes

Along with the extension to the HTML InputType entity described in the previous section, this proposal makes an addition to the HTML DTD for the INPUT element ATTLIST of an #IMPLIED attribute device of type CDATA, and reserves an #IMPLIED attribute CONNEG, also of type CDATA, for a to-be-specified content negotiation protocol.

Contemporary revisions of HTML are being defined as XML modules called XHTML, which involves a different DTD structure. The preceding paragraph was written with the HTML 3.2 and 4.0 DTDs in mind. Note that in XML and thus XHTML all attribute values must be quoted, and empty tags (unitary elements which are not used to contain text) must end with space followed by a slash before the closing angle bracket. For example:

     <input type="file" device="camera" accept="video/mpeg" />
Registration of new device names not suggested in this draft will be administered by the W3C HTML activity. The official definition of the assigned device values should be reflected in the comments of the HTML DTD after approval, immediately following the device attribute.


The primary motivation for these extensions is to add the capability of speech input to Web-based educational systems. [LISTEN, ORDINATE] Other motivations include the development of "dictation servers" [CYBERTRANSCRIBER] capable of transforming spoken audio uploaded though an HTTP session to the corresponding text suitable for sending in email or including in another document, for example. Natural language continuous speech recognition software conforming to standard APIs for automatic dictation is as of this writing available for free in small quantity so there is ample reason to believe that transcription servers might soon become commonplace on the Web with these extensions. These extensions could also be a help to hearing-impaired people who could use a "phonology server" to practice improving pronunciation.

Larry Masinter, author of RFC 1867, and member of the IETF Content Negotiation Working Group, has indicated that graphical paper scanners could be used for applications such as OCR and bar-code upload.

Finally, it is important to note that the addition of this proposal will allow web-enabled devices, such as radio telephones, to transmit high-quality asynchronous content, such as voicemail, under low-bandwidth conditions.

User interface usability and quality concerns for audio

An audio sample is customarily recorded on computer equipment with a dialog routine capable of allowing the user to record, pause, play back, erase, or otherwise edit the recording. Browsers may provide the operator with the same kind of dialog routine for audio device input. And if a maxlength has been specified or a Client-file-maxlength is in force because of limited buffer size, a display of the buffer size used and remaining may be displayed as a dynamic bar graph (or as a percentage if graphics are unavailable.) A display of time in seconds used and remaining in the buffer may also be provided.

Most MIME types defined for audio do not provide high-quality audio encodings [RFC 2586]. The type audio/basic and other types which use a sample rate of 8,000 samples per second truncate the audio spectrum at 4,000 Hz according to the Nyquist theorem, discarding information important for determining consonants. Also, audio/basic and other MIME Audio types use a sample size of eight bits, which does not usually provide enough dynamic range for accurate automatic speech recognition. If sixteen-bit unsigned audio encodings are used as according to [RFC 2586], the sample rate -- specified as the rate parameter of the MIME type audio/l16 -- may be at least 11,025 or 16,000 to adequately provide sufficient information for automatic speech recognition. Otherwise, the audio feature extraction encoding of the speech recognition algorithm may be used to provide a more compact representation to shorten the upload.

Scaling considerations

The protocol proposed in this draft has been proven to scale for very large files, but is not intended for open-ended uploads of content of indeterminate length. Real-time protocols such as RTP (RFC 1889) are much more appropriate for such open-ended transmission of device input, and when real-time interactions are required.

Security considerations

Browser operators may not want to send their files, recordings, pictures, video, or other device inputs to arbitrary sites without their explicit permission and direction. Therefore, browser authors are encouraged to disallow the submission of forms which include any kind of file upload by any means other than the standard HTML operator-controlled buttons for form submission without explicit instruction from the session operator to the contrary. Accordingly, the size attribute, style sheets, and document layers should be prevented from obscuring any kind of file upload widget if they are capable of accepting a default filename. Furthermore, just as the operator may take direct action to initiate, terminate, review and edit recording as described in the previous section, browser authors are encouraged to prevent HTML scripts from taking those and similar actions, unless for example the operator has specifically enabled such script actions with a security option. Even then, such preferences may be specified by the operator to reset after an interval or at the end of the browsing session. Finally, explicit information should be provided by the browser to the operator to insure that the operator is fully informed when files are being uploaded.


Larry Masinter and Ernesto Nebel laid the foundation for this proposal. Harald Alvestrand contributed excellent advice and the larger part of coauthoring RFC 2586. Ed Tecot of Microsoft's Macintosh Internet Explorer team contributed the means of device and media independence. David McMillian, of the Stanford Center for the Study of Language and Information, specified the capabilities of audio input widgets. Companies such as DynEd international provided a great deal of inspiration, as did Jack Mostow, Greg Aist, and their colleagues at CMU's Project LISTEN. Dave Raggett helped integrate the proposal into the W3C process. Keith Moore provided comments and assistance from the Internet Engineering Task Force. Gavin McKenzie of the W3C HTML working group forms sub-group helped with device names. John Whitehead, the Cisco W3C AC Representative, reviewed and provided several helpful improvements.

Perpetual unlimited permissions and disclaimer

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. This document may be modified as needed for the purpose of developing W3C and Internet standards or as required to translate it into languages other than English. These permissions are granted perpetually and will not be revoked by the author or his successors or assigns. Moreover, the author will not make any effort to restrict the use of the information contained in this document.

This document and the information contained herein is provided on an "as is" basis and the author disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe on any rights or any implied warranties of merchantability or fitness for a particular purpose. In the opinion of the author, use of the information contained in this document does not infringe on any rights.


[HTML+ Forms]
HTML+ Fill-out Forms and Input fields, D. Raggett, November 1993. http://www.w3.org/MarkUp/HTMLPlus/htmlplus_41.html
literacy instruction from a reading tutor that listens, J. Mostow, et alli, CMU Project LISTEN. http://www.cs.cmu.edu/~listen
over-the-phone automated testing of English fluency, listening, and vocabulary, Ordinate Corporation. http://www.ordinate.com
automatic transcription from spoken dictation, Speech Machines Corporation. http://www.cybertranscriber.com
[RFC 1867]
Form-based File Upload in HTML. E. Nebel & L. Masinter, November 1995. http://www.ietf.org/rfc/rfc1867.txt
[RFC 1890]
RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, January 1996. http://www.ietf.org/rfc/rfc1890.txt
[RFC 2068]
Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, January 1997. http://www.ietf.org/rfc/rfc2068.txt
[RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, March 1997. http://www.ietf.org/rfc/rfc2119.txt
[RFC 2183]
Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost, S. Dorner, K. Moore, August 1997. http://www.ietf.org/rfc/rfc2183.txt
[RFC 2586]
The Audio/L16 MIME content type. J. Salsman, H. Alvestrand, May 1999. http://www.ietf.org/rfc/rfc2586.txt

Copyright © 1997-1999

James P. Salsman, Cisco Systems and Bovik Research Inst.
draft references renamed 7 July 1999; MAXLENGTH DOM problem corrected 19 July 1999.