RE: I-D ACTION:draft-maeda-faxwg-fax-processing-status-00.txt

[MAEDA toru <maeda.toru@xxxxxxxxxxx>]

Wing-san

Thank you for comments.
I attached my comments below.

At 07:48 01/03/07 -0800, Dan Wing wrote:
>At 06:04 PM 3/7/01 +0900, MAEDA toru wrote:
>>Tamura-san
>>
>>Please do not mixed up two IDs which are Terminal Mode and 
>>fax-processing-status.
>>
>>EIFAX and FFIPM which will communicate SMTP or POP/IMAP to the mail server,
>>and returns status using DSN and/or MDN.
>>Terminal Mode which will communicate SMTP in end-to-end,
>>and returns the status by DSN and/or MDN.
>>
>>My first proposal was that MDN for fax-processing-status
>>will be returned from EIFAX, FFPIM and Terminal Mode.
>>Tamura-san's idea is that IFAX which communicate in SMTP
>>should return DSN but not MDN for the status.
>>But my understanding is that IFAX which was requested MDN responce in SMTP
>>should return MDN for the status.
>>In this case, IFAX is MTA and the end-point.
>>IFAX returns DSN then returns MDN after processing.
>>
>>
>>We need more discussion about the case of end-to-end communication by 
>>SMTP in Terminal Mode.
>>Tamura-san wanted one DSN confirmation without MDN within the end-to-end 
>>communication.
>
>If an MDN isn't desired:
>
>   *  sender should not request an MDN (don't include
>      Disposition-Notification-To header)


My proposal is requesting processing status to the receiver in email 
environment.
I am not sure what kind of method should be used for requesting processing 
status without MDN.


>or
>
>   *  receiver should ignore Disposition-Notification-To header (if the header
>      was present) if receiver knows that a DSN was generated.

Yes, only if receiver knows that a DSN was generated.
My question is that the processing status is included in DSN or not.


>Of course, the sender could coorelate an MDN and DSN so that the 
>originating device (the attached fax machine) doesn't actually see the two 
>acknowledgements.
>
>>Toyoda-san thought that the confirmation should be returned after the 
>>end-to-end communication.
>>I thought that the confirmation should be returned within the end-to-end 
>>communication using MDN.
>
>
>
>There are I-Ds proposing that the SMTP server guarantee that a POP client 
>(or IMAP client) will retrieve mail in a certain amount of time.
>
>It seems reasonable that if we're going to have this level of integration 
>between a POP client (or IMAP client) and the SMTP server, the SMTP server 
>could also withhold its delivery notification (DSN) until the POP client 
>(or IMAP client) has indicated successful processing.  This means the POP 
>client (or IMAP client) wouldn't need to generate an MDN at all -- 
>everything could be in the DSN and could be generated by this special SMTP 
>server.

How does the server know that the POP client (or IMAP client) has 
successful processing to print ifax image data?


>However, I had understood, from a few years ago, that a requirement for 
>fax-over-smtp was easy insertion into an enterprise's existing mail 
>infrastructure.  If we're really trying to introduce a new SMTP service 
>extension, this will not be implemented in many mailers -- even if it 
>becomes popular -- due to the difficulties of convincing companies to add 
>this new feature.  So I expect this new smtp service extension will only 
>be in specialty devices such as relatively large ifax servers, print 
>servers, and PCs dedicated to fax-over-smtp service.  I'm not saying this 
>is bad, I just want to point this out.

I am not sure that fax-over-smtp means end-to-end smtp protocol in Terminal 
Mode.

>-d
>
>
>
>>Please give me your comments.
>>
>>Toru Maeda

-----------------------------------
キヤノン株式会社
映像事務機MIE推進センター
映像事務機MIE第２開発部
前田　徹
146-8501　東京都大田区下丸子３−３０−２
電話　03-3757-9738、FAX　03-3757-8205
-----------------------------------