Subject: RE: MDN usage question.

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

> -----Original Message-----
> From: Mark Fraser [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 3:50 PM
> To: McIntyre, Lloyd
> Cc: 'Dan Wing'; Kassmann, Gary; [email-masked]
> Subject: Re: MDN usage question.
> 
> 
> Will the legal profession have a field day with this?  What is or 
> is not a facsimile?  Should there be a warning watermark superimposed 
> on a rendering that is different? To what degree?
Rendering the image and providing notice that it was not rendered as
intended - should address this concern. The MDN disposition error modifier
is that warning, it removes any question as to whether the rendering is
being passed off as a true facsimile of the image.
> 
> I think there's a threat of erosion of the legal status of fax in 
> general if "alternative rendering" methods are permitted without
> absolutely strict and detailed definitions.  It's been pointed out 
> far too often to me that pivotal precedents are established with 
> decisions on technology issues made by "Judges with Arts degrees".
> /Mark Fraser / POPstar Communications / Vancouver
Agree.
> 
> "McIntyre, Lloyd" wrote:
> > 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:[email-masked]]
> > > Sent: Monday, March 12, 2001 1:46 PM
> > > To: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> > > Cc: Kassmann, Gary
> > > Subject: RE: MDN usage question.
> > >
> > >
> > > > -----Original Message-----
> > > > 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
> > > > Subject: RE: MDN usage question.
> > > >
> > > >
> > > > Dan you may have some misunderstandings, see below.
> > >
> > > Wouldn't be the first time.  Comments 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.
> > >
> > > Agreed.
> > >
> > > > 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.
> > >
> > > 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.
> > 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.
> > >
> > > > > 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: Mark Fraser <[email-masked]>
Date: Mon, 12 Mar 2001 16:54:53 -0800

> being passed off as a true facsimile of the image.
<snips>

Agreed / thanks.