Subject: Communication from SG 8 on the Use of Extended Internet Fax for T.37 Full Mode

From: "Herman R. Silbiger" <[email-masked]>
Date: Sun, 04 Apr 1999 11:16:43 +0200

TO:   IETF Internet Fax Working Group
APPROVAL: Approved by ITU-T Study Group 8
TITLE:   Comments on the Use of Extended Internet Fax for T.37 Full Mode

FOR:   Action

CONTACT: Herman R. Silbiger (Rapporteur, ITU-T Q.4/8) Tel: +1 732 542
1916
   APPLICOM (for Lucent Technologies)  Fax: + 1 732 542 5041
   24 Mulberry Lane     Email: [email-masked]
   Tinton Falls, NJ 07724
   USA

Summary:

The Question 4 Rapporteur’s meeting of Study Group 8 met on 24 March - 1
April and reviewed several Internet Drafts from the IETF Fax working
group for in realising the "Full Mode" of T.37 Recommendation.  We
welcomed the participation of representatives from ISOC/IETF in
presenting the latest RFCs for Internet Fax and had a productive
meeting.  We have reviewed following documents RFC2530, RFC2531 and
RFC2532 and would like to make the following observations:

1.   The existing text in RFC2530, RFC2531 and RFC2532 meets our
requirements at the present time and they will be referenced in the
amended version of T.37.

 2.   In the future in order to meet evolving requirements, we would
like to request the addition of some features.  Details are as follows:

2.1    In RCC2532, the MDN/DSN request has no means to indicate
precisely to the receiver, that the sender desires to have capabilities
returned with MDN/DSN response.  This situation is difficult for the
facsimile application, since the capabilities of the receiver is
required for the Full Mode sender before transmitting a TIFF-FX file.
Since the existing capabilities exchange mechanism uses MDN and DSN
facilities, further enhancements to this method are high priority for
us.

2.2    The fax processed status information in RCF2530 needs to be
enhanced. We need a facility to enable the total number of pages and
pages in error to be returned to the sender in a MDN to indicate
successful processing.  We need further precision on the fax status
information using DSN and/or MDN.

2.3    Similary the specification within RFC2298 for the value processed
need to be enhanced. We need further precision to ensure that the
specific MDN response that is generated clearly indicates that the MIME
body part(s) has been successfully processed (i.e. printed or
displayed).

2.4   We request further study and a more complete solution on
mechanisms for capabilities request and indication that can be used to
meet  the Internet fax requirements for capability exchange.

__________________

---

From: Dan Wing <[email-masked]>
Date: Tue, 6 Apr 1999 13:21:03 -0700 (PDT)

On Sun, 4 Apr 1999 11:16 +0200, Herman R. Silbiger wrote:

> returned with MDN/DSN response. 

The receiver can safely send its capabilities in any DSN/MDN -- there
is no need for the sender to explicitly request the capabilities.

> This situation is difficult for the facsimile application, since the
> capabilities of the receiver is required for the Full Mode sender
> before transmitting a TIFF-FX file. Since the existing capabilities
> exchange mechanism uses MDN and DSN facilities, further enhancements
> to this method are high priority for us.

Using MDN/DSN to aquire capabilities causes a round-trip delay before
the sender can obtain the recipient's capabilities.  There is no way
to avoid this.

The only way to avoid the round-trip delay to obtain capabilities is to
use a different mechanism that is out-of-band of SMTP itself.

> information using DSN and/or MDN.

RFC2530 is not intended to show fax processed status at all.  RFC2530
only indicates the supported media features.

The format of the RFC2530 document could certainly be used to create
another Standards Track RFC which describes successful / unsuccessful
pages.  I would certainly welcome someone to take over editing duties
for such a document!  I am swamped with work.

However -- I have a concern here.  What is "success" and "failure"?
For example, if only 1 page out of a 10 page fax succeeds, should this
be indicated as a successful DSN (or MDN) message, or a failure?

> body part(s) has been successfully processed (i.e. printed or

My expired document draft-ietf-fax-mdn-multipart-01.txt, available at
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-mdn-multipart-01.txt>,
can provide a basis for such an extension.  It currently applies only to
multipart/alternative but could be changed to apply to any multipart
subtype.

I have a similar question, though: if two out of three parts were
successfully processed, but the third part failed (or no processing
was attempted at all), what should the 'status' be:  successful?
unsuccessful?

It should be noted, too, that it is impossible for a typical MUAs to
provide such information.  An MUA does not usually know if a launched
application successfully processed an attachment.  Of course, special
MUAs, such as those in a fax machine, could do this, but it can never be
expected that all MUAs will have such functionality.

-Dan Wing