One document matched: draft-ietf-fax-coverpage-00.txt
Application Working Group M. Ruhl
Internet Draft: Indicating the Presence of a Coverpage Cisco Systems
Document: draft-ietf-fax-coverpage-00.txt Feb. 12, 1999
Expires: Aug. 12, 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
to request that a coverpage be generated.
This memo provides a mechanism to indicate that a coverpage has
been included in a message, and a mechanism to request coverpage
generation.
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 and page count, etc., 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
included,
or that one needs to be generated.
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
information and extend the [GSTNADDR] addressing 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 Content-Type of the MIME part that contains the coverpage
MUST
have a parameter of "fax-coverpage=yes";
4) A Content-Description header SHOULD be used. The text SHOULD
describes the MIME part as a coverpage;
5) A Content-Disposition header SHOULD be used. The
disposition-type
SHOULD be "attachment". The parameter filename SHOULD indicate
that
the MIME part is a coverpage.
If a message includes more than one MIME part that is identified as
a
coverpage ("fax-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 <FAX=+14445556666@cisco.com>
From: Joe Man <joeman@cisco.com>
Subject: Updating the Document
Mime-Version: 1.0
Content-Type: multipart/fax-message; bounday="theBoundary"
--theBoundary
Content-Type: image/tiff; fax-coverpage=yes;
name="coverpage.tiff"
Content-Transfer-Encoding: base64
Content-Description: This part is a coverpage
Content-Disposition: attachment; filename="coverpage.tiff"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAA
AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////
--theBoundary
Content-Type: image/tiff; name="document.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
--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-Type of the MIME part that contains the coverpage
MUST
have a parameter of "fax-coverpage=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 a
coverpage has been included. However, because GSTN fax users
usually
include a coverpage on fax transmissions, it is very likely that an
onramped message includes a coverpage as part 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 <joeman@cisco.com>
From: The Boss <FAX=+14445556666@cisco.com>
Subject: Updating the Document
Mime-Version: 1.0
Content-Type: image/tiff; fax-coverpage=probable;
name="document.tiff";
Content-Transfer-Encoding: base64
Content-Description: The following document could contain a
coverpage
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
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/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; fax-coverpage=probable;
name="document.tiff"
Content-Transfer-Encoding: base64
Content-Description: This document probably has a coverpage
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
--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 "fax-coverpage=" parameter. 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 <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-Transfer-Encoding: base64
Content-Description: Picture of the Grand Canyon
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
The following multipart message does NOT have a coverpage:
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/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"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
--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 "fax-coverpage=" parameters, they will be ignored as
per
[MIME1].
4. Extension to the GSTN address format in Internet Mail
In addition to identifying the coverpage, it is desirable to be
able
to indicate which recipients should get a coverpage. For instance,
if a message is going to multiple recipients, and the sender knows
which recipients will be receiving the message as a fax, and which
will be receiving the message as an e-mail, the sender can
selectively
send the message with the coverpage to the fax recipients.
For example, a mailing list would know which recipients are a fax
offramp or a normal mail recipient.
To this end, using [ABNF] this memo extends the [GSTNADDR] docment
with
the following qualifier:
qaulif-type2 := "/" "COVERPAGE" "=" param
param := "YES"
/ "NO"
The qualifier and the parameter are case insensitive. The
parameters are
defined as the following:
"YES" use a coverpage if specified, or generate one from the
[SMTP2]
headers.
"NO" Do not use or generate a coverpage.
This qualifier is separate from the Content-Dispostion. If it is
present, it take precidence over the header.
This qualifier is part of the [SMTP1] envelope to header. Because
of
this, the qualifier will be lost if the message is delivered to a
POP
or IMAP mailbox.
This qualifier is not a header that is generated by a sending
application. Instead it is part of the recipients address.
Because of
this, fax-over-SMTP senders that are not compliant with this memo,
can
request coverpage generation.
5. IANA Registration
5.1 multipart/fax-message
Please see [UINF-MSG] for the multipart/fax-message regristration.
5.2 Disposition parameter
Using [ABNF] this adds a new parameter to the Contenet-Type header
field [CDISP]:
parameter := fax-coverpage "=" value
value := "yes"
/ "probable"
[this registration needs to be done correctly.]
6. Security Considerations
This does not add additional security considerations beyond those
which already apply to the Content-Disposition header field
[CDISP].
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).
7. References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.
[CDISP] Troost, Dorner, Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
[GSTNADDR] C. Allocchio, "GSTN address element extensions in e-mail
Services", Internet Draft Work in Progress, September 1998.
[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.
[TIFF-FX] L. McIntyre, S. Zille, R. Buckley, D. Venable, G.
Parsons,
J. Rafferty, File Format for Internet Fax, March 1998.
8. 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.
9. 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
--------------FABBAEC1154CB82119B3FE83
Content-Type: text/x-vcard; charset=us-ascii;
name="mruhl.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Michael J. Ruhl
Content-Disposition: attachment;
filename="mruhl.vcf"
begin:vcard
n:Ruhl;Michael J.
tel;fax:(831) 457-5208
tel;work:(831) 457-5423
x-mozilla-html:FALSE
url:http://www.employee.org/~mruhl
org:Cisco Systems;Cisco by the Sea
adr:;;101 Cooper St.;Santa Cruz;California;95060;U.S.A.
version:2.1
email;internet:mruhl@cisco.com
title:Tall Blond Guy
x-mozilla-cpt:;0
fn:Michael J. Ruhl
end:vcard
| PAFTECH AB 2003-2026 | 2026-04-23 17:36:26 |