Subject: RE: MDN usage question.

From: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 12 Mar 2001 16:18:22 -0800

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 3:31 PM
> To: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> Cc: Kassmann, Gary
> Subject: RE: MDN usage question.
> 
> 
> > No debate or request for immediate feedback intended.
> > Given SMTP and provision for attribute exchange, including 
> caching, prior to
> > document transmission then the encoding should not be sent if it is
> > understood that the receiver cannot render.
> > Gary's specific concern addresses a case where, for 
> whatever reason, a
> > sender transmits an encoding set which the receiver cannot 
> render, however,
> > the receiver is able to process and transform to a renderable set of
> > encodings. Under this condition, what should be the 
> disposition status in
> > the MDN? My proposal of disposition = processed/error:image 
> rendered AT
> > LOWER QUALITY strives for maximum interoperability.
> 
> 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.
> 
> It will be years before there is a widely deployed mechanism 
> to learn an
> arbitrary recipient's capabilities, and such a feature will have to be
> deployed in popular MUAs (Microsoft Outlook, Qualcomm Eudora, 
> AOL Netscape,
> etc.).
No issue.
> 
> The sending of a higher-than-processable format implies the 
> sender doesn't
> know (or has forgotten) the receipient's capability and that 
> the recipient
> capability information was incorrect.  
Agree.
> Following the 
> Internet's mantra of "be
> liberal in what you accept, be conservative in what you send" 
> (J. Postel), the
> proper thing to do is accept the message and convert it as 
> best you can. 
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
> propose this is the best situation for interoperability and 
> by providing a
> hint to compliant senders (indicating that fidelity was lost) 
> the sender can
> be reconfigured or can obtain fresher information about the 
> recipient from
> whatever source (LDAP server, user, some magic CONNEG database, etc.).
> 
> 
> Let me pose an example which I considered:
> 
> Question and background: At what degree should a message not 
> be translated
> into a different format?  Remember rfc2305 requires handling 
> both image/tiff
> and text/plain.  Text/plain support is necessary because 
> error messages and
> bounces are in text/plain.
Agree.
> 
> 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"
> 
> -d
> 
> > >
> > > > > Perhaps better business-class fax machines behave differently
> > > > > and refuse to
> > > > > send a fax if the sender selected 'super fine' but the
> > > > > receiving machine is
> > > > > incapable of 'super fine'?
> > > > They all behave in a similar manner. The machine assumes
> > > that the user is
> > > > giving permission to downgrade the image quality
> > > appropriately in order to
> > > > deliver the document. The downgrade decision and processing
> > > is NOT left up
> > > > to the receiver.
> > >
> > > There are lots of reasons it isn't sent to the reciver:
> > >
> > >   * the receiver can't understand the higher-quality format
> > >   * the sender is paying for the phone call, which is
> > > possibly long distance
> > >   * there is no use in sending something the receiver cannot
> > > process, as it
> > >     won't be processed (this goes without saying, but I'm
> > > going to say it
> > >     anyway).
> > >
> > > All of the above information is knowable to the sender
> > > because the sender is
> > > communicating directly with the receiver.
> > >
> > > With SMTP, unless you have obtained information elsewhere, it
> > > is impossible to
> > > know if a receiver can successfully process your message --
> > > because you aren't
> > > directly connected to the receiver.
> > >
> > > We've been discussing this for years on this mailing list and this
> > > straightforward fact will not change with the current
> > > store-and-forward model
> > > of SMTP.  Introducing a "terminal mode" which connects a
> > > sender directly to a
> > > receiver is interesting, but is not the normal model of SMTP.
> > >  I argue it
> > > never will be the standard model.  I don't want arbitrary 
> hosts on the
> > > Internet connecting with arbitrary hosts in my network to
> > > exchange what are
> > > claimed to be faxes!  The security risks here are too 
> great.  Direct
> > > connection is simply not going to happen in large deployments
> > > on the Internet.
> > > It could certainly happen on Intranets today -- and often does.
> > >
> > > -d
> > >
> > > > > [I know many machines don't interoperate with 'super fine',
> > > > > but the gist of my
> > > > > question remains if you replace 'super fine' with 'fine',
> > > > > which is well
> > > > > standardized]
> > > > >
> > > > > -d
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On
> > > > > > Behalf Of McIntyre, Lloyd
> > > > > > Sent: Monday, March 12, 2001 11:49 AM
> > > > > > To: Kassmann, Gary; [email-masked]
> > > > > > Cc: McIntyre, Lloyd; Kassmann, Gary
> > > > > > Subject: RE: MDN usage question.
> > > > > >
> > > > > >
> > > > > > Please see my thoughts below.
> > > > > >
> > > > > > Lloyd
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kassmann, Gary
> > > > > > > Sent: Monday, March 12, 2001 8:21 AM
> > > > > > > To: [email-masked]
> > > > > > > Cc: McIntyre, Lloyd; Kassmann, Gary
> > > > > > > Subject: MDN usage question.
> > > > > > >
> > > > > > >
> > > > > > > All,
> > > > > > > My name is Gary Kassmann and I am a Systems Engineering
> > > > > > > Manager at Xerox Corporation.  I have been a long 
> time reader
> > > > > > > of this DL but this is my first post.  I have a question
> > > > > > > about the usage of MDN's which I don't think has been
> > > > > addressed here.
> > > > > > >
> > > > > > > The recent DSN & MDN discussions makes me wonder about the
> > > > > > > case of receiving TIFF-FX Profile C on an IFax 
> device which
> > > > > > > is capable of interpreting the file but only 
> prints B&W.  In
> > > > > > > interest of increasing interoperability, I can 
> envision a B&W
> > > > > > > device having the ability to read and a color 
> file.  Does the
> > > > > > > ability to read the file invoke a positive MDN or does the
> > > > > > > inability to process the file in color invoke a 
> negative MDN?
> > > > > > >  What is the recommended MDN usage to support this case?
> > > > > > You are poking at a GRAY area<-:)
> > > > > > My desirable black-and-white answer would be an MDN with
> > > > > >     disposition= processed/error: image rendered as gray
> > > > > > This implies registration of a new disposition type
> > > > > modifier of "error:
> > > > > > image rendered as gray", conveying the message that the
> > > > > image was not
> > > > > > processed faithfully.
> > > > > >
> > > > > > If the receiver had informed the sender of its ability to
> > > > > only render gray
> > > > > > and the sender chose to send color, assuming consent of the
> > > > > user to have
> > > > > > gray rendered, then there is an argument for
> > > > > >     disposition= dispatched
> > > > > >
> > > > > > With this said, if we were to follow the T.30 model
> > > > > faithfully then the
> > > > > > sender should always send an image encoding that is
> > > > > consistent with what the
> > > > > > receive consumes and is capable of rendering. The receive
> > > > > should not take on
> > > > > > the task of image transformations since the delivered image
> > > > > is no longer a
> > > > > > facsimile (faithful representation) of what was
> > > > > transmitted. An appropriate
> > > > > > MDN would contain
> > > > > >     disposition= processed/error
> > > > > >
> > > > > > This is a very good question for which a consensus position
> > > > > is needed.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Gary
> > > > > > >
> > > > > > > ____________________
> > > > > > > Gary Kassmann   [email-masked]
> > > > > > > Xerox Corporation
> > > > > > > GMO/OSG/CDDU - System Architecture & Technology Delivery
> > > > > > >
> > > > >
> > >
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2001 16:48:01 -0800

> encourages gateways or receiving clients to be liberal in what they accept.

My mistake, I had mispoken (miswritten, rather).

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

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

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Wed, 14 Mar 2001 01:03:16 -0500

At 16:18 -0800 on 03/12/2001, McIntyre, Lloyd wrote about RE: MDN 

>   disposition=processed/error:image rendered with different character set"

ONLY if there is one or more High-ASCII Characters in the message. So 
long as the ACTUAL Character set is US-ASCII (ie: Only x00-x7F 
codepoints occur in the message) just claiming to be ISO-8859-1 (or 
even UTF-8 <g>) is NOT IMO a reason to send this erroneous error 
message.

---

From: MAEDA toru <[email-masked]>
Date: Thu, 15 Mar 2001 15:06:15 +0900

Hi,

Why do not we put the supported Character set
in the capabilities of receiver and transmitter.

Regrads,

Toru Maeda

At 01:03 01/03/14 -0500, Robert A. Rosenberg wrote:
>At 16:18 -0800 on 03/12/2001, McIntyre, Lloyd wrote about RE: MDN usage 
>question.:
>
>ONLY if there is one or more High-ASCII Characters in the message. So long 
>as the ACTUAL Character set is US-ASCII (ie: Only x00-x7F codepoints occur 
>in the message) just claiming to be ISO-8859-1 (or even UTF-8 <g>) is NOT 
>IMO a reason to send this erroneous error message.

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Mar 2001 12:57:40 -0800

Good idea.
-d

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of MAEDA toru
> Sent: Wednesday, March 14, 2001 10:06 PM
> To: Robert A. Rosenberg; McIntyre, Lloyd
> Cc: 'Dan Wing'; McIntyre, Lloyd; Kassmann, Gary; [email-masked]