home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1049 < prev    next >
Text File  |  1991-04-21  |  18KB  |  451 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           M. Sirbu
  8. Request for Comments:  1049                                          CMU
  9.                                                               March 1988
  10.  
  11.            A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES
  12.  
  13. STATUS OF THIS MEMO
  14.  
  15.    This RFC suggests proposed additions to the Internet Mail Protocol,
  16.    RFC-822, for the Internet community, and requests discussion and
  17.    suggestions for improvements.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. ABSTRACT
  21.  
  22.    A standardized Content-type field allows mail reading systems to
  23.    automatically identify the type of a structured message body and to
  24.    process it for display accordingly.  The structured message body must
  25.    still conform to the RFC-822 requirements concerning allowable
  26.    characters.  A mail reading system need not take any specific action
  27.    upon receiving a message with a valid Content-Type header field.  The
  28.    ability to recognize this field and invoke the appropriate display
  29.    process accordingly will, however, improve the readability of
  30.    messages, and allow the exchange of messages containing mathematical
  31.    symbols, or foreign language characters.
  32.  
  33.                              Table of Contents
  34.  
  35.    1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 1
  36.    2. Problems with Structured Messages . . . . . . . . . . . . . . . 3
  37.    3. The Content-type Header Field . . . . . . . . . . . . . . . . . 5
  38.         3.1. Type Values  . . . . . . . . . . . . . . . . . . . . . . 5
  39.         3.2. Version Number . . . . . . . . . . . . . . . . . . . . . 6
  40.         3.3. Resource Reference . . . . . . . . . . . . . . . . . . . 6
  41.         3.4. Comment. . . . . . . . . . . . . . . . . . . . . . . . . 7
  42.    4. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  43.  
  44. 1. Introduction
  45.  
  46.    As defined in RFC-822, [2], an electronic mail message consists of a
  47.    number of defined header fields, some containing structured
  48.    information (e.g., date, addresses), and a message body consisting of
  49.    an unstructured string of ASCII characters.
  50.  
  51.    The success of the Internet mail system has led to a desire to use
  52.    the mail system for sending around information with a greater degree
  53.    of structure, while remaining within the constraints imposed by the
  54.    limited character set.  A prime example is the use of mail to send a
  55.  
  56.  
  57.  
  58. Sirbu                                                           [Page 1]
  59.  
  60. RFC 1049                   Mail Content Type                  March 1988
  61.  
  62.  
  63.    document with embedded TROFF formatting commands.  A more
  64.    sophisticated example would be a message body encoded in a Page
  65.    Description Language (PDL) such as Postscript.  In both cases, simply
  66.    mapping the ASCII characters to the screen or printer in the usual
  67.    fashion will not render the document image intended by the sender; an
  68.    additional processing step is required to produce an image of the
  69.    message text on a display device or a piece of paper.
  70.  
  71.    In both of these examples, the message body contains only the legal
  72.    character set, but the content has a structure which produces some
  73.    desirable result after appropriate processing by the recipient.  If a
  74.    message header field could be used to indicate the structuring
  75.    technique used in the message body, then a sophisticated mail system
  76.    could use such a field to automatically invoke the appropriate
  77.    processing of the message body.  For example, a header field which
  78.    indicated that the message body was encoded using Postscript could be
  79.    used to direct a mail system running under Sun Microsystem's NEWS
  80.    window manager to process the Postscript to produce the appropriate
  81.    page image on the screen.
  82.  
  83.    Private header fields (beginning with "X-") are already being used by
  84.    some systems to affect such a result (e.g., the Andrew Message System
  85.    developed at Carnegie Mellon University).  However, the widespread
  86.    use of such techniques will require general agreement on the name and
  87.    allowed parameter values for a header field to be used for this
  88.    purpose.
  89.  
  90.    We propose that a new header field, "Content-type:"  be recognized as
  91.    the standard field for indicating the structure of the message body.
  92.    The contents of the "Content-Type:"  field are parameters which
  93.    specify what type of structure is used in the message body.
  94.  
  95.    Note that we are not proposing that the message body contain anything
  96.    other than ASCII characters as specified in RFC-822.  Whatever
  97.    structuring is contained in the message body must be represented
  98.    using only the allowed ASCII characters.  Thus, this proposal should
  99.    have no impact on existing mailers, only on mail reading systems.
  100.  
  101.    At the same time, this restriction eliminates the use of more general
  102.    structuring techniques such as Abstract Syntax Notation, (CCITT
  103.    Recommendation X.409) as used in the X.400 messaging standard, which
  104.    are octet-oriented.
  105.  
  106.    This is not the first proposal for structuring message bodies.
  107.    RFC-767 discusses a proposed technique for structuring multi-media
  108.    mail messages.  We are also aware that many users already employ mail
  109.    to send TROFF, SCRIBE, TEX, Postscript or other structured
  110.    information.  Such postprocessing as is required must be invoked
  111.  
  112.  
  113.  
  114. Sirbu                                                           [Page 2]
  115.  
  116. RFC 1049                   Mail Content Type                  March 1988
  117.  
  118.  
  119.    manually by the message recipient who looks at the message text
  120.    displayed as conventional ASCII and recognizes that it is structured
  121.    in some way that requires additional processing to be properly
  122.    rendered.  Our proposal is designed to facilitate automatic
  123.    processing of messages by a mail reading system.
  124.  
  125. 2. Problems with Structured Messages
  126.  
  127.    Once we introduce the notion that a message body might require some
  128.    processing other than simply painting the characters to the screen we
  129.    raise a number of fundamental questions.  These generally arise due
  130.    to the certainty that some receiving systems will have the facilities
  131.    to process the received message and some will not.  The problem is
  132.    what to do in the presence of systems with different levels of
  133.    capability.
  134.  
  135.    First, we must recognize that the purpose of structured messages is
  136.    to be able to send types of information, ultimately intended for
  137.    human consumption, not expressable in plain ASCII.  Thus, there is no
  138.    way in plain ASCII to send the italics, boldface, or greek characters
  139.    that can be expressed in Postscript.  If some different processing is
  140.    necessary to render these glyphs, then that is the minimum price to
  141.    be paid in order to send them at all.
  142.  
  143.    Second, by insisting that the message body contain only ASCII, we
  144.    insure that it will not "break" current mail reading systems which
  145.    are not equipped to process the structure; the result on the screen
  146.    may not be readily interpretable by the human reader, however.
  147.  
  148.    If a message sender knows that the recipient cannot process
  149.    Postscript, he or she may prefer that the message be revised to
  150.    eliminate the use of italics and boldface, rather than appear
  151.    incomprehensible.  If Postscript is being used because the message
  152.    contains passages in Greek, there may be no suitable ASCII
  153.    equivalent, however.
  154.  
  155.    Ideally, the details of structuring the message (or not) to conform
  156.    to the capabilities of the recipient system could be completely
  157.    hidden from the message sender.  The distributed Internet mail system
  158.    would somehow determine the capabilities of the recipient system, and
  159.    convert the message automatically; or, if there was no way to send
  160.    Greek text in ASCII, inform the sender that his message could not be
  161.    transmitted.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Sirbu                                                           [Page 3]
  171.  
  172. RFC 1049                   Mail Content Type                  March 1988
  173.  
  174.  
  175.    In practice, this is a difficult task.  There are three possible
  176.    approaches:
  177.  
  178.       1. Each mail system maintains a database of capabilities of
  179.          remote systems it knows how to send to.  Such a database
  180.          would be very difficult to keep up to date.
  181.  
  182.       2. The mail transport service negotiates with the receiving
  183.          system as to its capabilities.  If the receiving system
  184.          cannot support the specified content type, the mail is
  185.          transformed into conventional ASCII before transmission.
  186.          This would require changes to all existing SMTP
  187.          implementations, and could not be implemented in the case
  188.          where RFC-822 type messages are being forwarded via Bitnet or
  189.          other networks which do not implement SMTP.
  190.  
  191.       3. An expanded directory service maintains information on mail
  192.          processing capabilities of receiving hosts.  This eliminates
  193.          the need for real-time negotiation with the final
  194.          destination, but still requires direct interaction with the
  195.          directory service.  Since directory querying is part of mail
  196.          sending as opposed to mail composing/reading systems, this
  197.          requires changes to existing mailers as well as a major
  198.          change to the domain name directory service.
  199.  
  200.    We note in passing that the X.400 protocol implements approach number
  201.    2, and that the Draft Recommendations for X.DS, the Directory
  202.    Service, would support option 3.
  203.  
  204.    In the interest of facilitating early usage of structured messages,
  205.    we choose not to recommend any of the three approaches described
  206.    above at the present time.  In a forthcoming RFC we will propose a
  207.    solution based on option 2, requiring modification to mailers to
  208.    support negotiation over capabilities.  For the present, then, users
  209.    would be obliged to keep their own private list of capabilities of
  210.    recipients and to take care that they do not send Postscript, TROFF
  211.    or other structured messages to recipients who cannot process them.
  212.    The penalty for failure to do so will be the frustration of the
  213.    recipient in trying to read a raw Postscript or TROFF file painted on
  214.    his or her screen.  Some System Administrators may attempt to
  215.    implement option 1 for the benefit of their users, but this does not
  216.    impose a requirement for changes on any other mail system.
  217.  
  218.    We recognize that the long-term solution must require changes to
  219.    mailers.  However, in order to begin now to standardize the header
  220.    fields, and to facilitate experimentation, we issue the present RFC.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Sirbu                                                           [Page 4]
  227.  
  228. RFC 1049                   Mail Content Type                  March 1988
  229.  
  230.  
  231. 3. The Content-type Header Field
  232.  
  233.    Whatever structuring technique is specified by the Content-type
  234.    field, it must be known precisely to both the sender and the
  235.    recipient of the message in order for the message to be properly
  236.    interpreted.  In general, this means that the allowed parameter
  237.    values for the Content-type:  field must identify a well-defined,
  238.    standardized, document structuring technique.  We do not preclude,
  239.    however, the use of a Content-type:  parameter value to specify a
  240.    private structuring technique known only to the sender and the
  241.    recipient.
  242.  
  243.    More precisely, we propose that the Content-type:  header field
  244.    consist of up to four parameter values.  The first, or type parameter
  245.    names the structuring technique; the second, optional, parameter is a
  246.    version number, ver-num, which indicates a particular version or
  247.    revision of the standardized structuring technique.  The third
  248.    parameter is a resource reference, resource-ref, which may indicate a
  249.    standard database of information to be used in interpreting the
  250.    structured document.  The last parameter is a comment.
  251.  
  252.    In the Extended Backus Naur Form of RFC-822, we have:
  253.  
  254.    Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]
  255.  
  256. 3.1. Type Values
  257.  
  258.    Initially, the type parameter would be limited to the following set
  259.    of values:
  260.  
  261.    type:=           "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
  262.                     "DVI"/"X-"atom
  263.  
  264.    These values are not case sensitive.  POSTSCRIPT, Postscript, and
  265.    POStscriPT are all equivalent.
  266.  
  267.    POSTSCRIPT      Indicates the enclosed document consists of
  268.                    information encoded using the Postscript Page
  269.                    Definition Language developed by Adobe Systems,
  270.                    Inc. [1]
  271.  
  272.    SCRIBE          Indicates the document contains embedded formatting
  273.                    information according to the syntax used by the
  274.                    Scribe document formatting language distributed by
  275.                    the Unilogic Corporation. [6]
  276.  
  277.    SGML            Indicates the document contains structuring
  278.                    information to according the rules specified for
  279.  
  280.  
  281.  
  282. Sirbu                                                           [Page 5]
  283.  
  284. RFC 1049                   Mail Content Type                  March 1988
  285.  
  286.  
  287.                    the Standard Generalized Markup Language, IS 8879,
  288.                    as published by the International Organization for
  289.                    Standardization. [3] Documents structured according
  290.                    to the ISO DIS 8613--Office Docment Architecture and
  291.                    Interchange Format--may also be encoded using SGML
  292.                    syntax.
  293.  
  294.    TEX             Indicates the document contains embedded formatting
  295.                    information according to the syntax of the TEX
  296.                    document production language. [4]
  297.  
  298.    TROFF           Indicates the document contains embedded formatting
  299.                    information according to the syntax specified for the
  300.                    TROFF formatting package developed by AT&T Bell
  301.                    Laboratories. [5]
  302.  
  303.    DVI             Indicates the document contains information according
  304.                    to the device independent file format produced by
  305.                    TROFF or TEX.
  306.  
  307.    "X-"atom        Any type value beginning with the characters "X-" is
  308.                    a private value.
  309.  
  310. 3.2. Version Number
  311.  
  312.    Since standard structuring techniques in fact evolve over time, we
  313.    leave room for specifying a version number for the content type.
  314.    Valid values will depend upon the type parameter.
  315.  
  316.    ver-num:=      local-part
  317.  
  318.      In particular, we have the following valid values:
  319.  
  320.      For type=POSTSCRIPT
  321.  
  322.    ver-num:= "1.0"/"2.0"/"null"
  323.  
  324.      For type=SCRIBE
  325.  
  326.    ver-num:= "3"/"4"/"5"/"null"
  327.  
  328.      For type=SGML
  329.  
  330.    ver-num:="IS.8879.1986"/"null"
  331.  
  332. 3.3. Resource Reference
  333.  
  334.    resource-ref:=  local-part
  335.  
  336.  
  337.  
  338. Sirbu                                                           [Page 6]
  339.  
  340. RFC 1049                   Mail Content Type                  March 1988
  341.  
  342.  
  343.    As Apple has demonstrated with their implementation of the
  344.    Laserwriter, a very general document structuring technique can be
  345.    made more efficient by defining a set of macros or other similar
  346.    resources to be used in interpreting any transmitted stream.  The
  347.    Macintosh transmits a LaserPrep file to the Laserwriter containing
  348.    font and macro definitions which can be called upon by subsequent
  349.    documents.  The result is that documents as sent to the Laserwriter
  350.    are considerably more compact than if they had to include the
  351.    LaserPrep file each time.  The Resource Reference parameter allows
  352.    specification of a well known resource, such as a LaserPrep file,
  353.    which should be used by the receiving system when processing the
  354.    message.
  355.  
  356.    Resource references could also include macro packages for use with
  357.    TEX or references to preprocessors such as eqn and tbl for use with
  358.    troff.  Allowed values will vary according to the type parameter.
  359.  
  360.      In particular, we propose the following values:
  361.  
  362.      For type = POSTSCRIPT
  363.  
  364.    resource-ref:=  "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
  365.                    "laserprep4.0"/local-part
  366.  
  367.      For type = TROFF
  368.  
  369.    resource-ref:=  "eqn"/"tbl"/"me"/local-part
  370.  
  371. 3.4. Comment
  372.  
  373.    The comment field can be any additional comment text the user
  374.    desires.  Comments are enclosed in parentheses as specified in
  375.    RFC-822.
  376.  
  377. 4. Conclusion
  378.  
  379.    A standardized Content-type field allows mail reading systems to
  380.    automatically identify the type of a structured message body and to
  381.    process it for display accordingly.  The strcutured message body must
  382.    still conform to the RFC-822 requirements concerning allowable
  383.    characters.  A mail reading system need not take any specific action
  384.    upon receiving a message with valid Content-Type header field.  The
  385.    ability to recognize this field and invoke the appropriate display
  386.    process accordingly will, however, improve the readability of
  387.    messages, and allow the exchange of messages containing mathematical
  388.    symbols, or foreign language characters.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Sirbu                                                           [Page 7]
  395.  
  396. RFC 1049                   Mail Content Type                  March 1988
  397.  
  398.  
  399.    In the near term, the major use of a Content-Type:  header field is
  400.    likely to be for designating the message body as containing a Page
  401.    Definition Language representation such as Postscript.
  402.  
  403.    Additional type values shall be registered with Internet Assigned
  404.    Numbers Coordinator at USC-ISI.  Please contact:
  405.  
  406.                    Joyce K. Reynolds
  407.                    USC Information Sciences Institute
  408.                    4676 Admiralty Way
  409.                    Marina del Rey, CA  90292-6695
  410.  
  411.                    213-822-1511    JKReynolds@ISI.EDU
  412.  
  413.                                 REFERENCES
  414.  
  415.    1.  Adobe Systems, Inc.  Postscript Language Reference Manual.
  416.        Addison-Wesley, Reading, Mass., 1985.
  417.  
  418.    2.  Crocker, David H.  RFC-822:  Standard for the Format of ARPA
  419.        Internet Text Messages.  Network Information Center,
  420.        August 13, 1982.
  421.  
  422.    3.  ISO TC97/SC18.  Standard Generalized Markup Language.
  423.        Tech. Rept. DIS 8879, ISO, 1986.
  424.  
  425.    4.  Knuth, Donald E.  The TEXbook.  Addison-Wesley, Reading, Mass.,
  426.        1984.
  427.  
  428.    5.  Ossanna, Joseph F. NROFF/TROFF User's Manual.  Bell
  429.        Laboratories, Murray Hill, New Jersey, 1976.  Computing Science
  430.        Technical Report No.54.
  431.  
  432.    6.  Unilogic.  SCRIBE Document Production Software.  Unilogic, 1985.
  433.        Fourth Edition.
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Sirbu                                                           [Page 8]
  451.