RE: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt
Hiroshi Tamura <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <[email protected]> |
As I suggested before, my company, Ricoh, already a IFAX ***procuct*** that deals with "dispatched" for success and "processed/error" for failure. I am sure most IFAX manufacutures in Japan have the similar one, for product or prototype. They are independent, of course. But, I do not know whether all mandatory features in RFC2298 are supported. So, it may not be enough for Draft Standard process. Also, I add very ***personally***, next month, some IFAX manufacures in Japan will have interoperability tests for only this feature in MDN. About acknowledgement of receipt or decoding of TIFF-FX. -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: [email protected] From: "McIntyre, Lloyd" <[email protected]> Subject: RE: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt Date: Tue, 28 Aug 2001 14:51:18 -0700 > > I do not believe that current level of receivers would do more than alert > the use that there has been a processing error or warning (e.g. via some > form of audio or visual alerting) based upon the processable portion of the > MDN response. An accompanying message to the user may be more verbose and/or > friendly than the text portion of the MDN response. > > One may envision future implementations where the receiver may be > preauthorized to take action based on the nature of the disposition-modifier > and the contained capabilities string. > > Lloyd > > > -----Original Message----- > > From: Dan Wing [mailto:[email protected]] > > Sent: Tuesday, August 28, 2001 1:38 PM > > To: Pete Resnick > > Cc: McIntyre, Lloyd; 'Shibata Tetsuya'; [email protected]; > > [email protected]; [email protected]; [email protected] > > Subject: RE: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt > > > > > > > >Note we need vendors to both send _and_ receive the various > > > >permutations. If all implementations only send and do not parse > > > >or validate or do something on receipt, it doesn't pass muster > > > >for Draft Standard. > > > > > > Eudora (certainly on the Mac and I believe also on Windows) > > displays > > > the disposition values to the user as text. Now, it's not doing any > > > real parsing; it's just displaying the contents of the > > > message/disposition-notification part as text. Shouldn't that be > > > enough to be a "receiving" client? > > > > Yes, good point. We do the same, and expect the user to take some > > action based on what they see. > > > > -d > >