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

What would be useful from these tests is to know which products send MDNs
other than (1) or (2), below, and the behavior of the products if they
receive (1), (2), or (3), below.

 1.  Disposition: automatic-action/MDN-sent-automatically; dispatched
 2.  Disposition: automatic-action/MDN-sent-automatically; processed/error
 3.  Disposition: automatic-action/MDN-sent-automatically; processed/xyzzy

Our implementation will transmit (1) or (2).  We will receive any form of
MDN - we actually only look for the Disposition line and send something
around up to 160 characters or the first CRLF sequence to the other fax
machine -- so we accept (1), (2), and (3), but we don't parse any of them.
(3) is as meaningful to us as (2).

As Greg mentioned, though, the MDN doesn't need to be computer parsed for it
to be useful to include in the Draft Standard.

-Dan Wing

> -----Original Message-----
> From: Hiroshi Tamura [mailto:[email protected]]
> Sent: Tuesday, August 28, 2001 4:03 PM
> To: [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: RE: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt
>
>
> 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
> > >