Form-based Device Input and Upload in HTML
W3C NOTE 06 July 1999
- This version:
- http://www.w3.org/1999/07/NOTE-device-upload-19990706
- Latest version:
- http://www.w3.org/TR/device-upload
- Editors:
- James P. Salsman, Cisco Systems <jsalsman@cisco.com>
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 Cisco Systems 1999.
For terms and conditions, see IPR section of the Submission Request.
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.
<FORM enctype="multipart/form-data" method="post" action="_URL_">
Say something: <INPUT name="speech1" type="file" device="mic">
<INPUT type="submit" value="Send Speech">
</FORM>
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"
maxlength="100000">
<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.
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.
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.
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.
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.