RE: Error, failure, warning fields.

Greg,

> 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.

Yes, we use the Error field only in this case:

        sprintf(buffer + strlen(buffer),
                "Disposition: automatic-action/MDN-sent-automatically;
%s\r\n",
                level == RECIPIENT_LEVEL_OK ?
"dispatched":"processed/error");
        if (level != RECIPIENT_LEVEL_OK) {
            sprintf(buffer + strlen(buffer), "Error: %s %s\r\n",
                    statusCode, messageStr);
        }

"level" would be unequal to RECIPIENT_LEVEL_OK if the TIFF reader or BASE64
decoder reported an error to the SMTP server.  The value of statusCode
and messageStr are set by the TIFF reader or BASE64 decoder to help diagnose
the problem.

-d

> 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