RE: MDN usage question.

["Dan Wing" <dwing@xxxxxxxxx>]

Germany used to require approval for connecting answering machines
and fax machines too, as recently as 1986 (when I lived there).  The
US used to require such approval too, of course.

Is this still a requirement?  If so, does anyone have a cite to the
law?

-d

> -----Original Message-----
> From: Jim Dahmen [mailto:jdahmen@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, March 13, 2001 4:24 AM
> To: 'Dan Wing'; 'MAEDA toru'; 'Mark Fraser'
> Cc: 'McIntyre, Lloyd'; 'Kassmann, Gary'; ietf-fax@xxxxxxx
> Subject: RE: MDN usage question.
>
>
> 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.
> > > --------------------
> >
>