RE: AD review comments on

> In our effort to make email emulate fax, we have been trying to balance 
> between two sides of an information dilemma.
> 
> Regular DSN provides information about a stage that is earlier than a T.30 
> confirmation. 

Your statement is true if the ifax is implemented using POP (or IMAP).

Your statement is false if the ifax is implemented using SMTP (that is,
as an SMTP server).

This is part of the problem:  my ifax implementation is done using
an SMTP server.  So I don't have to consider modifying the semantics
of SMTP "delivery".

> MDN provides information about an event that is 
> later.  "Timely" is trying to use a middle event.
> 
> There is an argument that a T.30 confirmation is actually pretty close to a 
> regular DSN.  It is generated when received by the recipient's "sphere of 
> influence".
> 
> There was a strong constituency in the fax community that wanted something 
> closer to the user than DSN, yet still having hop-by-hop enforcement.  MDN 
> is closer to the user, but does not have the desired enforcement.  It also 
> is generated later than necessary.  Hence, Timely uses a middle event.
> 
> Besides providing a much better emulation of T.30 confirmation that regular 
> DSN, I believe that Timely makes email match the postal return receipt 
> construct. That makes it inherently useful.  Postal return receipt is an 
> extremely important function in the real word.  Email needs to have an 
> equivalent, if email is to be useful for more, and more formal, 
> communication activities.

To be sure, I don't see how TIMELY is much better than DSN.  

One of the complaints about DSN is that it isn't available everywhere,
can't be known a priori if it's available end-to-end to a recipient's
mailer, and ifax vendors don't want to dictate a customer have a 
DSN-aware mailer.

How are these complaints about DSN going to be addressed for TIMELY,
which is also an SMTP Service Extension?

> > > POP has exactly the right name, for the service it provides.  It is used
> > > when picking up mail from a place that is equivalent post office box.
> >
> >Using POP to indicate receipt extends the current state-of-the-art of
> >T.30 fax confirmation.
> 
> Perhaps.  Perhaps not.  I think it depends on the precise language one uses 
> to describe the nature of the feature.

The lack of language precision is part of the problem.

> > > This event is important in the paper world.  Simply knowing that the post
> > > office has deposited the mail into your mailbox is NOT deemed
> > > noteworthy.
> >
> >So I have been wasting my money with return-receipt-requested?
> 
> In fact, return receipt is extremely important for legal verification of 
> delivery.  There is a human that is accountable for the receipt.   Timely 
> does not require human involvement but it does pertain to an action that is 
> much more directly under control of the recipient.
> 
> 
> >Some ifax devices decided to use POP, instead of SMTP, to implement their
> >ifax retrieval function.  I have stated for years that this is a faulty
> >implementation decision, as it requires extending the semantics of
> >message "delivery".
> 
> There is a serious, real world constraint, involving connectivity.  Some 
> recipients can only have occasional connectivity.  SMTP is not really 
> viable in that scenario, in spite of 20 years of trying to get it to be 
> useful for such "polling" environments.  POP/IMAP are the only practical 
> choice.
> 
> While it would be procedurally better to use SMTP, the choice simply is not 
> available for some operational situations.

It's not just a matter of "procedurally better" -- SMTP already has the
correct behavior.

> So, we can create facilities that do not match real world constraints, 
> instead shooting for some sort of ideal.  Or we can be practical.

If you're requiring a customer buying an ifax device to use a 
service provider's mailer that implements DSN+TIMELY and the
UA has MDN enhancements and changes the SMTP delivery paradigm,
you honestly view this as more practical than DSN+TIMELY+ATRN or
DSN+TIMELY+ETRN?

-d