Application Working Group M. Ruhl Internet Draft: Indicating the Presence of a Coverpage Cisco Systems Document: draft-ietf-fax-coverpage-01.txt Feb. 23, 1999 Expires: Aug. 23, 1999 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 possibilty that a coverpage is part of the message. This memo provides a mechanism to indicate that a coverpage has been included or has probably incluced in a message. 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 serveral 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 possibilty 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 serveral 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 SMTP envelope [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 almost never 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 possibilty of duplicate or inconsistant 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 conetent information to solve this problem. The MIME sub type defined in the MIME Sub-type Registrations for Unified Messaging Internet draft [UNIF-MSG], is used as a starting point for this mechanism. 3.1 Coverpage is Known to be Present If a fax-over-SMTP application generates a message that will include a coverpage as part of the message, it MUST generate a message in the following manner: 1) The top level MIME Content-Type MUST be "multipart/fax-message"; 2) The message MUST be a minimum of two MIME parts. The first part MUST contain the coverpage. Subsequent parts will contain the document; 3) The MIME part that contains the coverpage MUST have the header Content-Coverpage with a value of "yes". 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". The parameter filename SHOULD indicate that the MIME part is a coverpage. If a multipart/fax-message enclosure includes more than one MIME part that is identified as a coverpage ("Content-Coverpage: yes"), a receiver SHOULD only use the first part identified as a coverpage. This will allow a sender forwarded messages to prepend a new coverpage to a message without removing older coverpages. 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. On 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 From: Joe Man Subject: Updating the Document Mime-Version: 1.0 Content-Type: multipart/fax-message; bounday="theBoundary" --theBoundary Content-Type: image/tiff; name="coverpage.tiff" Content-Coverpage: yes 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-Transfer-Encoding: base64 Content-Disposition: attachment; filename="document.tiff" AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA --theBoundary-- 3.2 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 Content-Coverpage header MUST be used. The headers value MUST be "probable"; 2) 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.2.1 Examples The following message indicates that a coverpage is possibly part of the document data. Date: Tue, 02 Feb 1999 14:40:32 -0800 To: Joe Man From: The Boss Subject: Updating the Document Mime-Version: 1.0 Content-Type: image/tiff; name="document.tiff"; Content-Coverpage: probable 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 From: The Boss Subject: Updating the Document Mime-Version: 1.0 Content-Type: multipart/fax-message; bounday="theBoundary" This message was generated by Mike's fax to e-mail generator. --theBoundary Content-Type: image/tiff; name="document.tiff" Content-Coverpage: probable Content-Transfer-Encoding: base64 Content-Description: This document probably has a coverpage Content-Disposition: attachment; filename="document.tiff" AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA --theBoundary-- 3.3 Coverpage is NOT Present When a fax-over-SMTP application sends a message with no coverpage, the message MUST NOT use the "Content-Coverpage" header. If the application sends a multipart message, it SHOULD use the "multipart/fax-message" content-type. 3.3.1 Examples The following message does NOT include a coverpage: Date: Tue, 02 Feb 1999 14:40:32 -0800 To: Joe Man From: The Boss Subject: Updating the Document Mime-Version: 1.0 Content-Type: image/tiff; name="document.tiff"; Content-Transfer-Encoding: base64 Content-Description: Picture of the Grand Canyon Content-Disposition: attachment; filename="document.tiff" AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA The following multipart message does NOT have a coverpage: Date: Tue, 02 Feb 1999 14:40:32 -0800 To: Joe Man From: The Boss Subject: Updating the Document Mime-Version: 1.0 Content-Type: multipart/fax-message; bounday="theBoundary" --theBoundary Content-Type: text/plain This message was generated by Mike's fax to e-mail generator. --theBoundary Content-Type: image/tiff; name="document.tiff" Content-Transfer-Encoding: base64 Content-Description: Picture of the Grand Canyon Content-Disposition: attachment; filename="document.tiff" AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA --theBoundary-- 3.4 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/fax-message" content-type will treat the content type as multipart/mixed as per [MIME2]. If the application does not recognize the "Content-Coverpage" header, it will be ignored as per [MIME1]. 4. MIME Syntax 4.1 multipart/fax-message Please see [UINF-MSG] for the multipart/fax-message regristration. 4.2 Content-Coverpage Syntax Using [ABNF] the Content-Coverpage header is defined as: MIME-extension-field := "Content-Coverpage" ":" value value := "yes" / "probable" 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 RFC 2046, November 1996. [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 [UNIF-MSG] Greg Vaudreuil, Glenn Parsons,"MIME Sub-type Registrations for unified messaging", Internet Draft Work in Progress, draft-ema-vpim-um-00.txt, Februrary 1, 1999. 7. Acknowledgements Thanks to Dan Wing for his suggestions and editorial comments. Without his help, this document would not say what it does. Thanks to Larry Masinter for his comments on coverpages and onramps. Thanks to Graham Kline for all of his general comments. 8. Author Information Micheal J. Ruhl Cisco Systems 101 Cooper St. Santa Cruz, CA 95060 Phone: +1-831-457-5423 Fax: +1-831-457-5208 mruhl@cisco.com