RE: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt

Hiroshi Tamura (tamura@toda.ricoh.co.jp)
Wed, 29 Aug 2001 08:03:28 +0900 (JST)

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: tamura@toda.ricoh.co.jp

From: "McIntyre, Lloyd" <Lloyd.McIntyre@pahv.xerox.com>
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:dwing@cisco.com]
> > Sent: Tuesday, August 28, 2001 1:38 PM
> > To: Pete Resnick
> > Cc: McIntyre, Lloyd; 'Shibata Tetsuya'; tony@att.com;
> > receipt@cs.utk.edu; vpim@lists.neystadt.org; ietf-fax@imc.org
> > 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
> >

This archive was generated by hypermail 2.0b3 on Wed Aug 29 2001 - 02:07:46 IDT