[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MDN usage question.
We are definitely on the same page and I can accept use of "warning" versus
"error" as the modifier.
> -----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
> > 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.
> "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.