[Prev][Next][Index][Thread]

Re: B.1 and B.2 results



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


References: