Subject: RE: Decode-error case in Eifax(RFC2532)

From: Geoff <[email-masked]>
Date: Wed, 16 Jun 1999 05:29:20 -0400

Conclusion

RFC 2532 fails to meet it's main objective, reliable, simple, authorative IFax receipt confirmation.

Geoff

----------
From: 	Dan Wing
Sent: 	Tuesday, June 15, 1999 1:15 PM
To: 	IETF Internet Fax WG
Cc: 	Hiroshi Tamura; Geoff
Subject: 	Re: Decode-error case in Eifax(RFC2532) 

>CASE A
>domain.com is a fax gateway which delivers the IFAX direct to a PSTN fax
>machine and reports 'delivered'
>
>CASE B
>domain.com is a normal MTA. The MTA delivers the IFAX to mailbox <fax no>
>and reports 'delivered' BUT the IFAX is never retrieved by 'fax no' and
>the server deletes the message after (say) 30 days.
>
>In both cases DSN has reported 'delivered'.

Case A indicates it was offramped in the DSN text in the implementation I
am most familiar with.

>A tad misleading

Likewise, a FedEx or USPS return receipt is misleading -- I don't know if
the recipient will actually read my letter.  

As MDNs are entirely optional, DSNs are the only thing that can be relied
upon.

You state that 50% of mailers support DSNs.

What percentage of MUAs support MDNs, and what percentage of those are
configured to always respond to MDN requests?

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Wed, 16 Jun 1999 08:19:30 -0700 (PDT)

> authorative IFax receipt confirmation.

In fact, interoperability with the installed base of mailers was its main
objective, beyond everything else.

If we were able to start with clean slate and a new protocol we could
easily have acheived the above objectives.

However, all of the above objectives (reliable, simple, authoritative
receipt confirmation) are already met with T.38 (realtime fax).

-Dan Wing

---

From: Richard Shockey <[email-masked]>
Date: Wed, 16 Jun 1999 10:48:46 -0500

>receipt confirmation) are already met with T.38 (realtime fax).

Or the Internet Print Protocol ... :-)

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 
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 16 Jun 1999 11:18:53 PDT

> authorative IFax receipt confirmation.

The goals for RFC 2532 are stated in RFC 2542 ("Terminology and
Goals for Internet Fax"). If there are main objectives, they
are identified with "{1}". The main objective for confirmation
is in Section 4.3:

                                            The 'Internet Fax'
   application must {1} define the mechanisms by which a sender may
   request notification of the completion of transmission of the
   message, and receive a determinate response as to whether the message
   was delivered, not delivered, or that no confirmation of delivery is
   possible.

RFC 2532 meets this objective.

As for your desirata of "reliable, simple, authorative":

"reliable": the main goal for reliability (section 4.8) is:

   The Internet Fax protocol should {2} operate reliably over a variety
   of configurations and situations.

This includes a reliable confirmation mechanism even when the
recipient is an ordinary email user. Note that reliability is
not a primary {1} goal.

"simple": the goal of simplicity in section 4.6 primarily focuses
on allowing small-footprint implementations, and even then, these
are identified as "{2}" (highly desirable) rather than "{1}" (mandatory).
I believe that a small-footprint implementation could deal with
just printing out the delivery status response, and that a slightly
larger footprint implementation can special-case common responses.
Since there are so many possibilities for failure and success in each of
the possible contexts for IFax delivery, there are a wide variety
of possible return messages. Implementations that want to special-case
all of them will be, of necessity, complex, but at least a simple
implementation is possible.

"authorative": The requirement for authoritative response to a
request for confirmation is captured by the word "determinate" in
the quote from Section 4.3 above. I believe that RFC 2532 meets
the requirement for determinate responses.

Regards,

Larry