RE: MDN usage question.

["McIntyre, Lloyd" <Lloyd.McIntyre@xxxxxxxxxxxxxx>]

We are definitely on the same page and I can accept use of "warning" versus
"error" as the modifier.

Lloyd

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx]
> Sent: Monday, March 12, 2001 4:48 PM
> To: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> Cc: Kassmann, Gary
> Subject: RE: MDN usage question.
> 
> 
> > > I disagree it provides maximum interoperability.  It causes a
> > > message to be
> > > rejected, and encourages vendors to not support file
> > > conversions at the
> > > offramp gateway.
> > I am confused by your objection here, when you seem to agree below.
> >    processed/error:image rendered AT LOWER QUALITY
> > This disposition is intended to state that the message was 
> processed,
> > however, the quality is less than that which was 
> transmitted. If anything it
> > encourages gateways or receiving clients to be liberal in 
> what they accept.
> 
> My mistake, I had mispoken (miswritten, rather).
> 
> ...
> > This is precisely as I recommended.
> > Given that the rendered image is of lower quality than the 
> transmitted, a
> > disposition of "dispatched" would be a misrepresentation. A 
> disposition of
> > "processed/error:image rendered AT LOWER QUALITY" informs 
> the sender that it
> > was processed and rendered, however, there was mismatch - 
> giving the sender
> > an opportunity to make adjustments the next time.
> > I don't see where we are in disagreement.
> 
> 
> I'm looking at RFC2298 in detail, and I feel 
> "dispatched/warning" is the most
> appropriate for what we're describing -- where an offramp 
> gateway is forced to
> "downgrade" to a lower quality because the PSTN recipient 
> cannot process the
> higher quality.
> 
> From RFC2298:
> 
>    "displayed"    The message has been displayed by the UA to someone
>                               reading the recipient's 
> mailbox.  There is
>                               no guarantee that the content has been
>                               read or understood.
> 
> 
>    "dispatched"   The message has been sent somewhere in some manner
>                               (e.g., printed, faxed, 
> forwarded) without
>                               necessarily having been previously
>                               displayed to the user.  The user may or
>                               may not see the message later.
> 
>    "processed"    The message has been processed in some manner (i.e.,
>                               by some sort of rules or server) without
>                               being displayed to the user.  
> The user may
>                               or may not see the message 
> later, or there
>                               may not even be a human user associated
>                               with the mailbox.
> 
> and:
> 
>    "error"                            An error of some sort occurred
>                                       that prevented successful
>                                       processing of the message.
>                                       Further information is contained
>                                       in an Error field.
> 
>    "warning"                          The message was successfully
>                                       processed but some sort of
>                                       exceptional condition occurred.
>                                       Further information is contained
>                                       in a Warning field.
> 
> 
> If the TIFF (or ASCII) was translated to a lower-fidelity 
> version, it was
> successfully processed, so I think "error" is overkill and excessively
> negative in its description of the event.
> 
> ...
> > > Example:  if an offramp gateway receives a "text/plain;
> > > charset=iso-8859-1"
> > > message but the fax offramp is only capable of US-ASCII, you
> > > would want the
> > > message rejected?  What if the message contained all ASCII
> > > characters (that
> > > is, no characters that weren't in both US-ASCII and ISO-8859-1?
> >
> > Again I would recommend processing and rendering with the 
> resident charset,
> > however, a notice should be returned to the sender notifying that
> > information may have been lost due to the mismatch. This is 
> what is realized
> > with the proposal, in this case the disposition modifier 
> could be something
> > like
> >   disposition=processed/error:image rendered with different 
> character set"
> 
> I'm leaning towards "warning" instead of "error", though.  I mean, the
> likelyhood of really losing something important with color->grayscale,
> grayscale->B&W, or ISO-8859->US-ASCII is pretty minor 
> compared to things that
> are really and truly errors:  unable to parse TIFF, invalid 
> destination phone
> number, etc.
> 
> -d
>