Re: MDN usage question.

[Mark Fraser <mfraser@xxxxxxxxxxxx>]

Time delay presents (according to lore) an opportunity to alter a faxed
doc, and while there are rumored precedents based on this, the real 
issue is *actual* alteration.  Granted, scan errors, line noise etc.
are alterations, but they're presumably obvious.  I'm more concerned
about loss of detail which (like vocoder "urgency" nuances) could be 
claimed to affect the interpretation of content.  The G2 density 
detail in the fax report takes care of one variation on this theme;
I think we need to provide means to report a loss of detail for future
transmission methods, as well. / Mark Fraser


Dan Wing wrote:
> 
> The only law regarding fax in the US, as far as I'm aware, concerns limits on
> spamming via fax and the requirement the sender be identified.
> 
> Which means it falls to case law to decide what is and isn't a "facsimile".
> It is impossible to add technical features -- ability to store and forward
> over a service provider's or corporate network (such as we're doing with
> fax-over-SMTP) and maintain the same exact behavior of PSTN facsimile.  Even
> T.38 which functions realtime isn't the same exact behavior:  the two modems
> are never directly communicating with each other, and the T.38 termination
> devices on each end have to both support all the capabilities one might wish
> to transmit!
> 
> -d
> 
> > -----Original Message-----
> > From: Mark Fraser [mailto:mfraser@xxxxxxxxxxxx]
> > Sent: Monday, March 12, 2001 3:50 PM
> > To: McIntyre, Lloyd
> > Cc: 'Dan Wing'; Kassmann, Gary; ietf-fax@xxxxxxx
> > 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?
> >
> > 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
> >
> > "McIntyre, Lloyd" wrote:
> > >
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:dwing@xxxxxxxxx]
> > > > Sent: Monday, March 12, 2001 1:46 PM
> > > > To: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> > > > Cc: Kassmann, Gary
> > > > Subject: RE: MDN usage question.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: McIntyre, Lloyd [mailto:Lloyd.McIntyre@xxxxxxxxxxxxxx]
> > > > > Sent: Monday, March 12, 2001 1:30 PM
> > > > > To: 'Dan Wing'; McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> > > > > 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:dwing@xxxxxxxxx]
> > > > > > Sent: Monday, March 12, 2001 1:00 PM
> > > > > > To: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> > > > > > 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: owner-ietf-fax@xxxxxxxxxxxx
> > > > > > [mailto:owner-ietf-fax@xxxxxxxxxxxx]On
> > > > > > > Behalf Of McIntyre, Lloyd
> > > > > > > Sent: Monday, March 12, 2001 11:49 AM
> > > > > > > To: Kassmann, Gary; ietf-fax@xxxxxxx
> > > > > > > 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: ietf-fax@xxxxxxx
> > > > > > > > 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   gary.kassmann@xxxxxxxxxxxxx
> > > > > > > > Xerox Corporation
> > > > > > > > GMO/OSG/CDDU - System Architecture & Technology Delivery
> > > > > > > >
> > > > > >
> > > >