RE: Error, failure, warning fields.

I just checked our implementation, and we transmit an MDN that
says either "dispatched" or "processed/error".  The "/error" is a
disposition modifier.

On reception of an MDN we don't parse at all -- we merely relay up to two
lines of text to the fax machine and leave it to the user to decipher
the meaning.

So I don't care if we eliminate the disposition-modifier field.

If it's retained, I would certainly like the list of disposition-
modifiers reduced to just "error" and "warning".

-d

> -----Original Message-----
> From: Vaudreuil, Greg M (Greg) [mailto:[email protected]]
> Sent: Tuesday, August 28, 2001 8:03 AM
> To: Tony Hansen; McIntyre, Lloyd
> Cc: [email protected]; [email protected]; [email protected]
> Subject: MDN: Error, failure, warning fields.
>
>
>
> Are there any implementations of the error, warning, or failure fields?  I
> have not personally seen any or heard of any.  Unless someone can identify
> two or more implementations of these fields, I will delete them.
>
> These fields are distinct from the disposition modifiers discussed in the
> attached message.
>
> Note also that the intent of these fields is to provide additional textual
> description of the MDN exception case.  It seems this purpose can be met by
> supplying X- extension fields or text in the first part of the
> multipart/report structure.
>
> Greg V.
>
> -----Original Message-----
> From: Tony Hansen [mailto:[email protected]]
> Sent: Monday, August 27, 2001 9:24 PM
> To: McIntyre, Lloyd
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [VPIM] RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt
>
>
> Absolutely. If there ARE two (or more) implementations of anything we
> removed, we'll put them back in to the updated MDN document.
>
> So, just let us know of the implementations.
>
> 	Tony Hansen
> 	[email protected]
>
> "McIntyre, Lloyd" wrote:
> >
> > My understanding is that the "dispatched" feature may be retained if
> > information can be provided to verify that there are interoperable
> > implementations.
> > Tamura-san is it possible to have two or more manufacturers document
> > interoperability of sending and receiving MDN with the
> dispatched feature?
> >
> > Lloyd
> >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:[email protected]]
> > > Sent: Monday, August 27, 2001 4:22 PM
> > > To: Hiroshi Tamura; [email protected]
> > > Cc: [email protected]; [email protected]; [email protected]
> > > Subject: RE: FW: I-D ACTION:draft-vaudreuil-mdnbis-00.txt
> > >
> > >
> > >
> > > > > Note that the requirements for draft standard are explicit that
> > > > all features
> > > > > and options need to have at least two, interoperable
> > > implementations.  If
> > > > > they are still useful, the unimplemented dispositions
> > > deleted from this
> > > > > document may be standardized at a later date as an MDN extension.
> > > >
> > > > I do not read all, but I say,
> > > >
> > > > Some Ifax devices already use:
> > > > "dispatched" or "processed" without modifiers
> > > >   when succesfully decoding the received TIFF-FX file
> > > > "processed/error" in the case of the failure.
> > >
> > > Those devices will remain compliant with the Proposed
> > > Standard RFC2298,
> > > but won't be compliant with the Draft Standard that Greg is authoring.
> > >
> > >
> > > As soon as Greg's document becomes an RFC, I'll ask our development
> > > group here in Cisco to bring our implementation in line with his
> > > new Draft Standard.
> > >
> > > -d
> > >
> > ----------------------------------------------------------
> > This message was sent to you, since you are subscribed to
> > [email protected]. You can manage your subscription at
> > http://www.neystadt.org/cgi-bin/majordomo
> ----------------------------------------------------------
> This message was sent to you, since you are subscribed to
> [email protected]. You can manage your subscription at
> http://www.neystadt.org/cgi-bin/majordomo