Subject: draft-ietf-fax-coverpage.txt

From: "Michael J. Ruhl" <[email-masked]>
Date: Wed, 17 Feb 1999 10:39:32 -0800

Howdy,

I would like to submit the following as an internet draft for the
Internet FAX working group.

The suggested filename is:

draft-ietf-fax-coverpage.txt

Thanks,

Mike

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=[email-masked]>
         From: Joe Man <[email-masked]>
         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 <[email-masked]>
         From: The Boss <FAX=[email-masked]>
         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 <[email-masked]>
         From: The Boss <FAX=[email-masked]>
         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 <[email-masked]>
         From: The Boss <FAX=[email-masked]>
         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 <[email-masked]>
         From: The Boss <FAX=[email-masked]>
         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
    [email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Thu, 18 Feb 1999 10:55:13 -0600

>     [SMTP1] and headers [SMTP2].

I think this is going to be a valuable addition to our document suite
..especially for those devices, like PDA's that have limited capabilities
but need to satisfy the legal requirements and general end user
expectations for sender identification.

One suggestion Mike.. you might want to consider some support for vCard
data as well as 822 header data.  The SMTP envelope does not contain, IMHO,
detailed information that fax end users are used to seeing on cover pages
such as snail mail address, phone numbers etc.

You consider a paragraph that says something like if the application ( I
assume a offramp) that wishes to generate a cover page detects the presence
of vCard data in the multi-part MIME message than that application SHOULD
incorporate that data into the cover page.

We have lots of mail clients that send a vCard...its a standard part of
VPIM and I've suggested vCard support to the IPP folks as well.

Richard Shockey
Shockey Consulting LLC                  
8045 Big Bend Blvd. Suite 110    
St. Louis, MO 63119
Voice 314.918.9020
Fax   314.918.9015
INTERNET Mail & IFAX : [email-masked]
eFAX 815.333.1237  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Michael J. Ruhl" <[email-masked]>
Date: Thu, 18 Feb 1999 09:12:59 -0800

> VPIM and I've suggested vCard support to the IPP folks as well.

Funny thing.  I was just thinking about vCards this morning. :)

One thing I am trying to avoid is specifing how a coverpage
should be generated.  I really believe that that belongs in
a separate document.  There has been lots of talk about an
implemenetors guide, and I think that is a real good place
for that to go.

In one of my earlier drafts for the coverpage indication, I had
written a suggested way to generate a coverpage from the headers.
Another section could be on the use of vCards.

I don't know who is working on the implementors guide, but I have
lots of words to add too it. :)

Mike

---

From: Claudio Allocchio +39 040 3758523 <[email-masked]>
Date: Fri, 19 Feb 1999 14:54:22 +0100

Hallo,
I have some minor comments to the proposed draft.

Do we really need to specify for which recipient we wish the cover page 
to be disclosed? in manu cases probably it will be an off-ramp device to 
generate anyhow a cover page, starting from some set of available data, 
and the enclosed one will be an additional cover page generated by the 
originator. Wouldn't it be preferrable to make then a choice, i.e. to 
have a mechanism that, in case the originator-specified cover page is 
present, can determine which of the two to send? If I undertand 
correctly, there are legal issues involved, too.

Technically speaking, with the revised version of 
draft-ietf-fax-fulladdr-05.txt, the eventual definition of the 
qualif-type1 parameter (it cannot be a qualif-type2) should anyhow be:

         cover = "/COVERPAGE=" param

         cover-param = "YES" / "NO"

With a relative IANA registration form:

---------------------------------------------------------------------------

   To: [email-masked]
   Subject: Registration of new values for the GSTN address
            qualif-type1 element "COVERPAGE"

   qualif-type1 "keyword" name:

      COVERPAGE

   qualif-type1 "value" ABNF definition:

      cover-param = "YES" / "NO"

   Description of Use:

      To specify if the recipient should receive the embedded cover
      page or not. See <this RFC> for further details.

   Use Restriction:

      The use is restricted to "FAX" service-selector, and it can only
      be used within recipient addresses.

   Security Considerations:

      <the appropriate security condiserations>

   Person & email address to contact for further information:

      <the author's contact data>

---------------------------------------------------------------------------

I would, however, suggest a shorter keyword and value. Keeping addresses 
short is always a good practice.

    cover = "/COVER="

    cover-param = "Y" / "N"

What about also defining the default action, in case the "cover" parameter is
not given? I suppouse the default should be "/COVER=N"

regards
Claudio

---

From: "Michael J. Ruhl" <[email-masked]>
Date: Fri, 19 Feb 1999 13:12:18 -0800

> correctly, there are legal issues involved, too.

Hmm.  Good questions.  Neither Dan nor I were very happy with this
section yet.  Dan isn't convinced that it is useful (in its present
form), and the more I think about it the more I am tending to agree.

I will mull over your comments, and see if I can come up with
something better.

> With a relative IANA registration form:

I knew that I didn't have all of the right stuff.  Thank you for
giving me the answer. :)

> not given? I suppouse the default should be "/COVER=N"

That makes a lot of sense.  I will modify my draft to reflect these
comments.

Thank you for your comments!

Mike

---

From: Yukikazu Mori <[email-masked]>
Date: Tue, 23 Feb 1999 16:40:24 +0900

This is Mori of Ricoh.

Concerning the issue of coverpage, let me raise my concern 
from the position of the STAND ALONE internet fax. 
 ( I mean the internet fax with scanner and printer)

In my experience of FaxConnect1 almost all vendors send some text part like ;

>          This message was generated by Mike's fax to e-mail generator.
in addition to its tiff image.
For the stand alone machine which is designed to print out the received 
text part as it is, this part leads to anytime use one sheet of paper and
in most cases it is only wasting a paper.

My point is that we should make some provision by which the 
receiving machine can recognize whether this information 
is really from the originator or from anywhere else like Offramp gateway.
This should apply to any type of information (not only to coverpage).

Then we can prepare a kind of software switch, when it is ON, the machine
does not print that part out.
Also we can solve the following inconvenience ;
 the journal report at the sending side says 5 page transmission
 the journal report at the receiving side says 6 page reception.

Sorry I can not make a specific proposal. But I am happy if the draft 
text reflects my concern.

Thank you.

***************************************************************
RICOH COMPANY, LTD.  Toda Technical Center
Yukikazu MORI
TEL:+81-462-28-1743
FAX:+81-462-28-7500(Subaddress(SUB) 5720)
Email:[email-masked]
***************************************************************

---

From: "Michael J. Ruhl" <[email-masked]>
Date: Tue, 23 Feb 1999 11:37:33 -0800

Hi Mori,

I don't think that this is a coverpage issue.  The extra text in
the example is not a coverpage, it is just extra text inserted into
a message.

I do agree that you have a point, but I think that this is another
topic that could go in the implementors guide.  It could be something
like this:

"If a message is received that contains MIME parts other than image/tiff
an implementor should provide the ability to accept or reject those
parts.  If a message contains a MIME part that indicates a coverpage,
that MIME part should be processed first."

Please note, the above comments have not gone through much thought,
they are just my impressions from your comments.

To indicate that something added a part while the message was in
transit, is not what this ID was trying to address.  I am not sure
that it should.

Thanks,

Mike