[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-maeda-faxwg-fax-processing-status-00.txt
(BThank you for comments.
(BI attached my comments below.
(BAt 07:48 01/03/07 -0800, Dan Wing wrote:
(B>At 06:04 PM 3/7/01 +0900, MAEDA toru wrote:
(B>>Please do not mixed up two IDs which are Terminal Mode and
(B>>EIFAX and FFIPM which will communicate SMTP or POP/IMAP to the mail server,
(B>>and returns status using DSN and/or MDN.
(B>>Terminal Mode which will communicate SMTP in end-to-end,
(B>>and returns the status by DSN and/or MDN.
(B>>My first proposal was that MDN for fax-processing-status
(B>>will be returned from EIFAX, FFPIM and Terminal Mode.
(B>>Tamura-san's idea is that IFAX which communicate in SMTP
(B>>should return DSN but not MDN for the status.
(B>>But my understanding is that IFAX which was requested MDN responce in SMTP
(B>>should return MDN for the status.
(B>>In this case, IFAX is MTA and the end-point.
(B>>IFAX returns DSN then returns MDN after processing.
(B>>We need more discussion about the case of end-to-end communication by
(B>>SMTP in Terminal Mode.
(B>>Tamura-san wanted one DSN confirmation without MDN within the end-to-end
(B>If an MDN isn't desired:
(B> * sender should not request an MDN (don't include
(B> Disposition-Notification-To header)
(BMy proposal is requesting processing status to the receiver in email
(BI am not sure what kind of method should be used for requesting processing
(Bstatus without MDN.
(B> * receiver should ignore Disposition-Notification-To header (if the header
(B> was present) if receiver knows that a DSN was generated.
(BYes, only if receiver knows that a DSN was generated.
(BMy question is that the processing status is included in DSN or not.
(B>Of course, the sender could coorelate an MDN and DSN so that the
(B>originating device (the attached fax machine) doesn't actually see the two
(B>>Toyoda-san thought that the confirmation should be returned after the
(B>>I thought that the confirmation should be returned within the end-to-end
(B>>communication using MDN.
(B>There are I-Ds proposing that the SMTP server guarantee that a POP client
(B>(or IMAP client) will retrieve mail in a certain amount of time.
(B>It seems reasonable that if we're going to have this level of integration
(B>between a POP client (or IMAP client) and the SMTP server, the SMTP server
(B>could also withhold its delivery notification (DSN) until the POP client
(B>(or IMAP client) has indicated successful processing. This means the POP
(B>client (or IMAP client) wouldn't need to generate an MDN at all --
(B>everything could be in the DSN and could be generated by this special SMTP
(BHow does the server know that the POP client (or IMAP client) has
(Bsuccessful processing to print ifax image data?
(B>However, I had understood, from a few years ago, that a requirement for
(B>fax-over-smtp was easy insertion into an enterprise's existing mail
(B>infrastructure. If we're really trying to introduce a new SMTP service
(B>extension, this will not be implemented in many mailers -- even if it
(B>becomes popular -- due to the difficulties of convincing companies to add
(B>this new feature. So I expect this new smtp service extension will only
(B>be in specialty devices such as relatively large ifax servers, print
(B>servers, and PCs dedicated to fax-over-smtp service. I'm not saying this
(B>is bad, I just want to point this out.
(BI am not sure that fax-over-smtp means end-to-end smtp protocol in Terminal
(B>>Please give me your comments.