Subject: RE: MDN usage question.

From: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 12 Mar 2001 13:30:05 -0800

Dan you may have some misunderstandings, see below.

Lloyd
> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 1:00 PM
> To: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> Cc: Kassmann, Gary
> Subject: RE: MDN usage question.
> 
> 
> I don't understand your comment about being faithful to the 
> T.30 model.
> 
> On my work and home fax machines (which are from different 
> manufacturers) if I
> select 'photo' or 'super fine' as the resolution it will be 
> transmitted
> successfully even if the receiving machine can only accept a 
> lower-quality
> image.
Your machine does NOT send photo or superfine resolution to the remote if
the remote indicates that it cannot consume it. What happens is that your
sending machine, acting on your behalf, downgrades the resolution to a level
that is consistent with the attributes announced by the receiving machine. -
This is the T.30 model I referenced, where the sending machine is
responsible for any encoding transformations. The result being, what is
rendered at the receiver is a facsimile of that which was outputted by the
sender. 
> 
> 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.
> 
> [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 13:45:43 -0800

> From: McIntyre, Lloyd [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 1:30 PM
> To: 'Dan Wing'; McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> Cc: Kassmann, Gary

Wouldn't be the first time.  Comments below.

> the remote indicates that it cannot consume it.

Agreed.

> What happens is that your

That works great over PSTN where there is direct, immediate feedback from the
receiving machine.  There is no such direct, immediate feedback available over
stored-and-forward SMTP.  If such direct and immediate feedback is required, I
will ask the question:  why are we using SMTP?  Other protocols, including
IPP, are more well suited for direct and immediate feedback of capabilities
than SMTP.  In fact, SMTP is probably one of the poorer protocols if direct
and immediate feedback of capabilities is needed.

> deliver the document. The downgrade decision and processing is NOT left up

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