RE: MDN usage question.

["Jim Dahmen" <jdahmen@xxxxxxxxxxxxxxxx>]

Dan,

I believe Maeda-san is referring to a requirement by the German PTT. To
obtain protocol approval (Class A???), you had to have a switch on your
machine which would allow a downgrade. In addition, you had to have a
warning system to inform the operator that the receiver was not capable of
rendering in the manner selected by the sender. If the send operator did not
elect to change within a certain time, the communication was aborted.
You could avoid this requirement by going for a Class B (???) approval, but
it limited your marketplace.

Best regards,
Jim


> -----Original Message-----
> From: owner-ietf-fax@xxxxxxxxxxxx
> [mailto:owner-ietf-fax@xxxxxxxxxxxx]On
> Behalf Of Dan Wing
> Sent: Tuesday, March 13, 2001 2:21 AM
> To: MAEDA toru; Mark Fraser
> Cc: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> Subject: RE: MDN usage question.
>
>
> Thank you.
>
> Was this a legal requirement?  If so, do you have a cite to the
> regulation that requires this behavior?  Without a cite it is
> impossible to understand the reason for this behavior, or if
> such behavior is required if the transmission isn't over the
> PSTN.
>
> Or was this a human factors decision by the manufacturers of
> fax devices sold to those countries?
>
> -Dan Wing
>
>
> > -----Original Message-----
> > From: owner-ietf-fax@xxxxxxxxxxxx
> [mailto:owner-ietf-fax@xxxxxxxxxxxx]On
> > Behalf Of MAEDA toru
> > Sent: Monday, March 12, 2001 10:31 PM
> > To: Dan Wing; Mark Fraser
> > Cc: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> > Subject: RE: MDN usage question.
> >
> >
> > Hi,
> >
> > There was a lot of discussion to read for this subject.
> > Just a comment:
> >
> > There were some facsimile terminals
> > which degrade the quality of transmitting image **manually**,
> > to be approved by the PTT regulation in the outside of US.
> > You have to watch a warning LED on it during the document
> transmission
> > and to press an acknowledge key for degrade of image within
> a few seconds
> > during the LED on.
> > If you fail to press the key in time, you will get an error
> of transmission.
> >
> >
> > Toru Maeda
> >
> >
> > At 17:01 01/03/12 -0800, Dan Wing wrote:
> > >I completely agree the sender should know about a reduction of
> > their intended
> > >quality, and I had misunderstood Lloyd's previous comments
> on the subject.
> > >
> > >One thing to keep in mind is that all fax machines I have
> > experience with will
> > >automatically degrade the quality to whatever is available
> on the receiving
> > >machine.  It is only during transmission itself (on the LCD panel)
> > and on the
> > >paper confirmation (printed after the transmission) are you told
> > the image was
> > >transmitted at a lower-than-requested quality.
> > >
> > >The behavior of MDNs, at Lloyd has proposed, can mimics
> this existing fax
> > >behavior pretty well.
> > >
> > >-d
> > >
> > > > -----Original Message-----
> > > > From: Mark Fraser [mailto:mfraser@xxxxxxxxxxxx]
> > > > Sent: Monday, March 12, 2001 4:53 PM
> > > > To: Dan Wing
> > > > Cc: McIntyre, Lloyd; Kassmann, Gary; ietf-fax@xxxxxxx
> > > > Subject: Re: MDN usage question.
> > > >
> > > >
> > > > 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
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> >
> > --------------------
> > MAEDA TORU
> > MIE Development Div. 2
> > CANON Inc.
> > --------------------
>