Subject: Re: draft-ietf-fax-timely-delivery-01.txt

From: Graham Klyne <[email-masked]>
Date: Tue, 13 Feb 2001 16:04:11 +0000

Tamura-san,

This is mainly to acknowledge your comments, which were made a long time 
ago now, but not forgotten or ignored.  I did use your comments when 
editing the -02 draft.  There was a lot of change to make the latest (-02) 
version, and I think that most of your comments are indirectly incorporated.

At 02:32 PM 12/4/00 +0900, Hiroshi Tamura wrote:
>Personal comments.
>
>There are mainly two pending issues, I think.
>Section 4 "Compliance-required ESMTP extension" and
>Section 5 "DSN extension".
>
>The Key issue is Compliance-required(section 4).
>If my undestanding is correct, this must be dealt with UA
>like POP/IMAP4 device. If so, how about considering the time
>interval by POP/IMAP4 device?
>
>If the thing that comforms to timely delivery is a POP/IMAP4 device
>and I-fax device, is it possible to recommend the short interval time?
>Specific value is difficult to define, but, I think the value
>for guidance can be described like Section 3.4(Timely confirmation).
>If it is the I-fax device(not PC mailer software), it runs 24-hours.
>It may be feasible.
>
>This is just at idea level.

The various extensions have been folded into an enhancement of the "Deliver 
by" proposal, and some small extensions to the DSN report format.

I think the receiver timing issue is covered by saying that report must be 
sent before the deliver-by time expires.

>The next is DSN extension(section 5).
>Yes, it would be better to have the extension. But, we can use
>the existing definitions. There are "delayed" action-value
>with status code 4.4.7 and "failed" with 5.4.7, which are
>written in section 4.1.3 of RFC2852. There are other dscriptions.

Well, I've proposed some specific extensions -- I guess we'll see how they 
go down.

>Also, how about separating requirement parts and guidance parts?
>For example, Section 3.4(Timely confirmation) is for guidance.

I've rearranged this material, but I did think it was important to say 
something about timing in the normative sections.

>Minimum requirements should be decided, but, it is no problems
>that the rests are guidances or implementation issues, I think.
>Because, there are some items that are difficult to solve completely.

Yes.  I think that's what the latest version tries to do.

>I hope it helps you.

Thank you, yes, it did.

#g