Application Working Group                                              M. Ruhl
Internet Draft: Indicating the Presence of a Coverpage           Oct. 21, 1999
Document: draft-ietf-fax-coverpage-03.txt               Expires: Apr. 21, 2000


            Indicating the Presence of a Coverpage in the
                     Fax-over-SMTP Environment

Status of this memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     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."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


Abstract

     In traditional GSTN-based fax, a coverpage is often sent before the
     actual document.  Some of the uses for a coverpage are:

         o routing the document to the correct recipient
         o identifying the sender
         o providing comments to the recipient about the document
         o page count
         o transmission date

     Current fax-over-SMTP aware applications do not have a standard way
     to indicate that a coverpage has been included with a message, or that
     there is a good possibility that a coverpage is part of the message.

     This memo provides a mechanism to indicate that a coverpage has been
     included or has probably included in a message.

0. Changes

Revision 03
     o Changed multipart/fax-message to multipart/related
     o Some general edits.

Revision 02
     o Changed the header name from Content-Coverpage to Content-cover
     o Modified the values for Content-Cover from "Yes" and "Probably" to
       "Explicit", "Embedded", and "Implicit".


1. Background

     In traditional GSTN-based fax, a coverpage is often sent before the
     actual document.  Coverpages typically include information to
     identify the sender, the receiver, the date and time, a comment as
     to what the message contains, page count, and any other data the
     sender deems necessary.

     A fax coverpage contains nearly the same information as the SMTP
     envelope [SMTP1] and headers [SMTP2].

     Fax-over-SMTP applications may or may not include a coverpage when
     sending a message.  There is currently no method to indicate that
     a coverpage has been included with a fax message.  Also,
     fax-over-SMTP applications that receive a message can have the
     ability to generate a coverpage.  Knowing when or if to do this
     is not defined.

     Not knowing if coverpage information has been included can lead to
     several problems.  The most serious of which is that duplicate or
     inconsistent data can be generated.

     This memo provides a method to indicate that a coverpage is indeed
     included or that a coverpage has a good possibility of being part of
     the message.


1.1 Conventions Used in this Document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [KEYWORDS].


2. Current Practices for Coverpage Inclusion

     When a fax-over-SMTP application sends a message, there are several
     methods for including a coverpage in the message.  All of those
     methods are described below:

     1) Include the coverpage in the same MIME [MIME1] part as the
        document.

     2) Include the coverpage in a separate MIME part from the document
        MIME part.

     3) Include recipient information in the recipient address [GSTNADDR].

     4) Not include a coverpage at all.

     There is no standard way to indicate which of these methods are
     being used.  In addition, if the second method is used, there is
     no way to identify the separate [MIME] part as a coverpage.


2.1 Analysis of Current Practices

     An SMTP message sent by a traditional MUA will generally not include
     a coverpage in the message attachment.

     Current practices for fax-over-SMTP allow any coverpage to be
     included with a message.  However, a receiving application has no
     indication that the message includes a coverpage.  If a receiving
     application has the ability to generate a coverpage, there is the
     possibility of duplicate or inconsistent coverpage data being
     generated.  If a message that has a coverpage included is forwarded,
     it may be useful to replace the coverpage.  Since there is no way to
     identify that a coverpage has been included, the replacement would
     require human intervention.


3. Fax-over-SMTP Coverpage Extensions

     From the analysis of the current practices, it is apparent that
     fax-over-SMTP applications require a method to indicate that a
     coverpage may or may not be present.  The following methods use
     new MIME content information to solve this problem.


3.1 Explicit Coverpage is Known to be Present

     If a fax-over-SMTP application generates a message that will include
     a coverpage as distinct part of the message, it MUST generate a
     message in the following manner:

     1) The fax message MUST be encapsulated within a MIME Content-Type
        of "multipart/related" [MIME3];

     2) The message MUST be a minimum of two MIME parts.  The MIME part
        that contains the coverpage MUST be the first part, or the part
        indicated by the "start" parameter as described by [MIME3].
        Subsequent parts will contain the document;

     3) The MIME part that contains the coverpage MUST have the header
        Content-Cover with a value of "explicit".  This part MUST contain
        coverpage information only;

     4) The MIME part that contains the coverpage SHOULD have the header
        Content-Description.  The text SHOULD describes the MIME part as
        a coverpage;

     5) The MIME part that contains the coverpage SHOULD have the header
        Content-Disposition.  The disposition-type SHOULD be "attachment".

     6) The multipart/related MUST NOT include more than one part that
        is described as "Content-Cover: explicit."

     The Content-Disposition header will allow traditional MUAs to
     decide if the coverpage should be displayed inline, or as an
     attachment.

     The Content-Description and filename will allow a user to identify
     an undisplayed attachment as a coverpage.  One issue that should be
     noted about the Content-Description, is that it is "human readable"
     text.  This can cause problems for internationalization and
     localization.


3.1.1 Example

     The following message include a MIME part which is a coverpage and
     a MIME part which is the document being sent.

         Date: Tue, 02 Feb 1999 14:40:32 -0800
         To: The Boss <FAX=+14445556666@cisco.com>
         From: Joe Man <joeman@cisco.com>
         Subject: Updating the Document
         Mime-Version: 1.0
         Content-Type: multipart/related; bounday="theBoundary";
                       start="<messageId1>";
                       type="image/tiff"

         --theBoundary
         Content-Type: image/tiff; name="coverpage.tiff"
         Content-ID: <messageId1>
         Content-Cover: explicit
         Content-Transfer-Encoding: base64
         Content-Description: This part is a coverpage
         Content-Disposition: attachment; filename="coverpage.tiff"

         0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
         AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
         --theBoundary
         Content-Type: image/tiff; name="document.tiff"
         Content-ID: <messageId2>
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename="document.tiff"

         AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
         GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
         --theBoundary--


3.2 Embedded Coverpage is Known to be Present

     If a fax-over-SMTP application generates a message that will embed a
     coverpage as part of the message, it MUST generate a message in the
     following manner:

     1) The fax message SHOULD be encapsulated within a MIME Content-Type
        of "multipart/related";

     2) Any MIME part that contains coverpage information MUST have the
        header Content-Cover with a value of "embedded";

     3) Any MIME part that contains coverpage information SHOULD have the
        header Content-Description.  The text SHOULD describe the MIME part
        as containing embedded coverpage information;

     One issue that should be noted about the Content-Description, is that
     it is "human readable" text.  This can cause problems for
     internationalization and localization.


3.2.1 Example

     The following message include a MIME part which contains coverpage
     information a MIME part which does not.

         Date: Tue, 02 Feb 1999 14:40:32 -0800
         To: The Boss <FAX=+14445556666@cisco.com>
         From: Joe Man <joeman@cisco.com>
         Subject: Updating the Document
         Mime-Version: 1.0
         Content-Type: multipart/related; bounday="theBoundary";
                       type="image/tiff"

         --theBoundary
         Content-Type: image/tiff; name="document.tiff"
         Content-Cover: embedded
         Content-Transfer-Encoding: base64
         Content-Description: This document contains embedded coverpage info.
         Content-Disposition: attachment; filename="document.tiff"

         0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
         AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
         --theBoundary
         Content-Type: image/tiff; name="document2.tiff"
         Content-Transfer-Encoding: base64
         Content-Description: This document does not have coverpage info.
         Content-Disposition: attachment; filename="document2.tiff"

         AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
         GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
         --theBoundary--


3.3 Implicit Coverpage is Possibly Present

     When a fax-over-SMTP application receives a message that might have
     a coverpage, it MUST generate the message in the following manner.

     1) The fax message SHOULD be encapsulated within a MIME Content-Type
        of "multipart/related";

     2) Any MIME part that is included within the "multipart/related"
        encapsulation MUST have the header Content-Cover with a value of
        "implicit";

     3) A Content-Description header SHOULD be used.  The text SHOULD
        indicate that the MIME part might contain a coverpage.

     When a fax message is "onramped" (converting a fax message received
     from the GSTN network to an SMTP message), there is no way to
     determine if coverpage information has been included.  However,
     because GSTN fax users usually include coverpage information with fax
     transmissions, it is very likely that an onramped message will
     include a coverpage information as part of the message.
     Note: it is entirely possible for coverpage information to be a
     separate page, or included with the first page of the message.


3.3.1 Examples

     The following message indicates that a coverpage is possibly part
     of the document data.  Note: it does not encapsulate the message in
     a multipart/related.

         Date: Tue, 02 Feb 1999 14:40:32 -0800
         To: Joe Man <joeman@cisco.com>
         From: The Boss <FAX=+14445556666@cisco.com>
         Subject: Updating the Document
         Mime-Version: 1.0
         Content-Type: image/tiff; name="document.tiff";
         Content-Cover: implicit
         Content-Transfer-Encoding: base64
         Content-Description: This document might contain coverpage info
         Content-Disposition: attachment; filename="document.tiff"

         AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
         GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA

     The following message contains more than one body part, and
     indicates that a coverpage could be part of the document data.

         Date: Tue, 02 Feb 1999 14:40:32 -0800
         To: Joe Man <joeman@cisco.com>
         From: The Boss <FAX=+14445556666@cisco.com>
         Subject: Updating the Document
         Mime-Version: 1.0
         Content-Type: multipart/related; bounday="theBoundary";
                       type="image/tiff"

         This message was generated by Mike's fax to e-mail generator.

         --theBoundary
         Content-Type: image/tiff; name="document1.tiff"
         Content-Cover: implicit
         Content-Transfer-Encoding: base64
         Content-Description: This document probably has a coverpage
         Content-Disposition: attachment; filename="document.tiff"

         AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
         GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA

         --theBoundary
         Content-Type: image/tiff; name="document2.tiff"
         Content-Cover: implicit
         Content-Transfer-Encoding: base64
         Content-Description: This document probably has a coverpage
         Content-Disposition: attachment; filename="document2.tiff"

         AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
         GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
         --theBoundary--


3.4 Coverpage is NOT Present

     When a fax-over-SMTP application sends a message with no coverpage,
     the message MUST NOT use the "Content-Cover" header.


3.5 Ramifications to Non-Compliant Applications

     If a fax-over-SMTP application is not compliant with the above described
     mechanism, there should be no impact.  An application that does not
     recognize the "multipart/related" content-type will treat the content
     type as multipart/mixed as per [MIME2].  If the application does not
     recognize the "Content-Cover" header, it will be ignored as per
     [MIME1].


4. MIME Syntax


4.1 Content-Cover Syntax

     Using [ABNF] the Content-Cover header is defined as:

         MIME-extension-field := "Content-Cover" ":" value

         value = "explicit"  /
                 "embedded"  /
                 "implicit"


5. Security Considerations

     A coverpage can be easily created to mislead the recipient.  [SMTP2]
     headers can easily be forged.  Because of this neither method
     should be used as a security measure.  Both methods are useful as
     informational data about the message.

     A cover page might reveal information about the sender and their
     activities (sending fax number, time of sending).

     Please see [MIME2] for further security considerations.


6. References

     [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, November 1997.

     [GSTNADDR] C. Allocchio, "GSTN address element extensions in e-mail
     Services", Internet Draft Work in Progress, September 1998.

     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March 1997.

     [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions",
     RFC 2045, November 1996.

     [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions",
     RFC 2046, November 1996.

     [MIME3] E. Levinson,"The MIME Multipart/Related Content-type",
     RFC 2387, August 1998.

     [SMTP1] Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821,
     August 1982.

     [SMTP2] David H. Crocker, "Standard for the Format of ARPA Internet Text
     Messages, RFC 822, August 13, 1982


7. Acknowledgements

     Thanks to Dan Wing for his suggestions and editorial comments.  Without
     his help, this document would not have been started.
     Thanks to Larry Masinter for his comments on coverpages and onramps.
     Thanks to Graham Klyne for all of his general comments, and his help in
     presenting this document when I could not.  He has helped to make this
     document more concise and readable.

8. Author Information

    Michael J. Ruhl
    1538 Pacific Avenue
    Santa Cruz, CA 95060
    Phone: +1-831-460-3800 ext. 3872
    Fax: +1-831-460-3801
    mruhl@network-alchemy.com