- From: Gavin Nicol <gtn@ebt.com>
- Date: Mon, 21 Oct 1996 22:16:00 -0400
- To: gtn@kirk.mit.edu
- CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org
here is the promised text....
---
INTERNET-DRAFT G. Nicol
MIME Header Supplemented File Type EBT, Inc
draft-nicol-mime-header-type-00.txt
Expires in 6 months October 19, 1995
MIME Header Supplemented File Type
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
One of the problems encountered in serving documents over the WWW is
the correct generation of the MIME fields required by the HTTP
protocol, and in particular, generating the correct MIME type for
body content. This memo defines a file format that can be used
to aid in the correct generation of such fields, and how servers
should interpret the file format. Use of this file format can also
benefit other protocols such as FTP.
1. Introduction
The HTTP protocol [1] requires a number of MIME fields to be sent to
the client. Some of these fields specify per-file information that
cannot be easily generated by HTTP servers from the information
available in the file system of the host operating system. One good
example is the MIME content type field, which not only specifies the
content type of the message sent to the client, but also additional
data such as the encoding of the character set used. For example, a
typical specification might look like:
Content-type: text/html
for HTML files that use the ISO-8859-1 encoding. However, if the
HTML file uses a different encoding, for example ISO-2022-JP, then
the field should look like this:
Content-type: text/html; charset=ISO-2022-JP
However, most servers cannot readily generate the extra parameter
from the information in the filesystem, and in fact do not, leading
to many interoperability problems. As such, some method of
supplementing the file system information is required. This memo
outlines one such method.
2. Current practise
To date, various means have been used to supply such additional
information. Some of the current methods of supplying additional
data to the server are:
The <META> tag.
The HTML 2.0 DTD [2] specifies a <META> tag with an HTTP-EQUIV
attribute that can be used to specify HTTP response field
content. To date this has not been widely adopted by servers,
mainly because it requires parsing the HTML in order to get
the field values. This method is also flawed in that one cannot
parse the HTML file without first knowing the coded character
set and encoding used, so for certain field types (the
Content-Type field as shown above, for example), it is either
impossible to use, or redundant.
The ASIS file type.
The Apache server [2] specifies a special file type called
ASIS. ASIS (for as-is) files are sent directly to the client,
and are expected to contain all the fields required by the HTTP
protocol. Specifying all fields can be somewhat cumbersome, and
error-prone.
External file information databases.
Various servers implement a system where a file in the
filesystem supplies information about the files being sent to
clients. Such files are generally used for security, and other
such things, rather than aiding in HTTP MIME field generation.
3. The MIME Header Supplemented File Type
In order to make it practical (from both an implementation, and
management viewpoint) to supplement the information available to
servers, this memo defines a new file type, called the MIME Header
Supplemented File Type, or MIM for short. It is recommended that
files of this type have either a ".mime" or ".mim" extension, though
this is very much affected by the requirements of the native
operating system.
The MIM file type shares much in common with the ASIS file type, in
that HTTP MIME fields appear at the top of the file. Unlike the ASIS
file type, the MIM file type does not require all fields to be
present. An example MIM file might be:
Content-type: text/html; charset=ISO-2022-JP
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.x//EN">
<HTML>
. . .
</HTML>
Where the exact field syntax can be found in the HTTP 1.0
specification [1], with the difference that all fields are
optional.
When an HTTP server recieves a request for a MIM file, it should
generate the HTTP fields as best it can, and then parse the field
definitions of the MIM file to supplement the fields it has
generated. If the MIM file contains a field definition for a field
the server has already generated, the value of the MIM field should
be used to override the value generated by the server. The server
should parse all the header fields of a MIM file, and in doing so,
will parsed to the position in the file which contains the actual
message body, which should be sent verbatim. This leads to a general
requirement that all MIM files contain a Content-Type field
definition, as the server cannot know the correct label for the
content as MIM files can be used to encapsulate many different data
types.
For example, when the server sees a MIM file, it might generate a
content header like:
Content-type: text/plain
but if a file like that shown earlier was requested, the server
would first parse the MIME fields at the top of the file, use the
field specified therein to override, or generate fields, so that the
response sent to the client would contain a content type
specification of:
Content-type: text/html; charset=ISO-2022-JP
providing a simple way of correctly labelling all HTML documents
sent across the WWW.
It is believed that the MIM file type represents a very easy way of
supplementing the data a server has so that it can generate
appropriate field values for content it sends out.
7. Limitations
While the MIM type can be used to specify any MIME header, or value
for a MIME header, a MIM file should not specify headers that the
server can generate correctly, or which might hinder
interoperability. For example, Content-Length is best left to the
server to generate.
8. Applicability to protocols other than HTTP
For protocols other than HTTP, it is recommended that the MIME
headers be sent along with the message body, thereby allowing
client-side processing of the headers. For example, if FTP is being
used, the MIME headers will still provide an easy way for the
content type to be correctly labelled: a client can see that the
file is a MIM file, and process the headers supplied with the
message body.
8. Security considerations
Certain headers, such as WWW-Authenticate, hold information
regarding security. Specifying such fields in the MIM file could
lead to security breaches, or interoperability problems. Servers
should ignore definitions of values for such fields.
9. References
[1] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen.
"Hypertext Transfer Protocol -- HTTP/1.0." Work in Progress
(draft-ietf-http-v10-spec-00.ps), MIT, UC Irvine, CERN,
March 1995.
2] T. Berners-Lee and D. Connolly,
"Hypertext Markup Language - 2.0", Work in progress
(draft-ietf-html-spec-05.txt), MIT/W3C, August 1995.
[3] The Apache HTTP server documentation at
http://www.apache.org/apache/
10. Authors Address
Gavin Thomas Nicol
Technical Consulting Manager
Electronic Book Technologies, KK
4-1-8 Kudan-minami,
Chiyoda-ku,
102 Tokyo, Japan
Tel: +81-3-3230-3861
Fax: +81-3-3230-3863
Email: gtn@ebt.com
Received on Monday, 21 October 1996 22:18:25 UTC