Subject: RE: MDN usage question.

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

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 4:05 PM
> To: Mark Fraser; McIntyre, Lloyd
> Cc: Kassmann, Gary; [email-masked]
> Subject: RE: MDN usage question.
> 
> 
> 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.
This is correct.
> 
> Which means it falls to case law to decide what is and isn't 
> a "facsimile".
I interpreted this to be Fraser's intent.

> 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!
No issue from me.
> 
> -d
> 
> > -----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?
> >
> > 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:[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: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 12 Mar 2001 17:21:26 -0800

We are definitely on the same page and I can accept use of "warning" versus
"error" as the modifier.

Lloyd

> Sent: Monday, March 12, 2001 4:48 PM
> > > I disagree it provides maximum interoperability.  It causes a
> > > message to be
> > > rejected, and encourages vendors to not support file
> > > conversions at the
> > > offramp gateway.
> > I am confused by your objection here, when you seem to agree below.
> >    processed/error:image rendered AT LOWER QUALITY
> > This disposition is intended to state that the message was 
> processed,
> > however, the quality is less than that which was 
> transmitted. If anything it
> > encourages gateways or receiving clients to be liberal in 
> what they accept.
> 
> My mistake, I had mispoken (miswritten, rather).
> 
> ...
> > This is precisely as I recommended.
> > Given that the rendered image is of lower quality than the 
> transmitted, a
> > disposition of "dispatched" would be a misrepresentation. A 
> disposition of
> > "processed/error:image rendered AT LOWER QUALITY" informs 
> the sender that it
> > was processed and rendered, however, there was mismatch - 
> giving the sender
> > an opportunity to make adjustments the next time.
> > I don't see where we are in disagreement.
> 
> 
> I'm looking at RFC2298 in detail, and I feel 
> "dispatched/warning" is the most
> appropriate for what we're describing -- where an offramp 
> gateway is forced to
> "downgrade" to a lower quality because the PSTN recipient 
> cannot process the
> higher quality.
> 
> From RFC2298:
> 
>    "displayed"    The message has been displayed by the UA to someone
>                               reading the recipient's 
> mailbox.  There is
>                               no guarantee that the content has been
>                               read or understood.
> 
> 
>    "dispatched"   The message has been sent somewhere in some manner
>                               (e.g., printed, faxed, 
> forwarded) without
>                               necessarily having been previously
>                               displayed to the user.  The user may or
>                               may not see the message later.
> 
>    "processed"    The message has been processed in some manner (i.e.,
>                               by some sort of rules or server) without
>                               being displayed to the user.  
> The user may
>                               or may not see the message 
> later, or there
>                               may not even be a human user associated
>                               with the mailbox.
> 
> and:
> 
>    "error"                            An error of some sort occurred
>                                       that prevented successful
>                                       processing of the message.
>                                       Further information is contained
>                                       in an Error field.
> 
>    "warning"                          The message was successfully
>                                       processed but some sort of
>                                       exceptional condition occurred.
>                                       Further information is contained
>                                       in a Warning field.
> 
> 
> If the TIFF (or ASCII) was translated to a lower-fidelity 
> version, it was
> successfully processed, so I think "error" is overkill and excessively
> negative in its description of the event.
> 
> ...
> > > Example:  if an offramp gateway receives a "text/plain;
> > > charset=iso-8859-1"
> > > message but the fax offramp is only capable of US-ASCII, you
> > > would want the
> > > message rejected?  What if the message contained all ASCII
> > > characters (that
> > > is, no characters that weren't in both US-ASCII and ISO-8859-1?
> >
> > Again I would recommend processing and rendering with the 
> resident charset,
> > however, a notice should be returned to the sender notifying that
> > information may have been lost due to the mismatch. This is 
> what is realized
> > with the proposal, in this case the disposition modifier 
> could be something
> > like
> >   disposition=processed/error:image rendered with different 
> character set"
> 
> I'm leaning towards "warning" instead of "error", though.  I mean, the
> likelyhood of really losing something important with color->grayscale,
> grayscale->B&W, or ISO-8859->US-ASCII is pretty minor 
> compared to things that
> are really and truly errors:  unable to parse TIFF, invalid 
> destination phone
> number, etc.
> 
> -d
>

---

From: MAEDA toru <[email-masked]>
Date: Thu, 15 Mar 2001 13:35:22 +0900

Gray-san

I attached my comments below.
I feel happy that many fax experts read and comment the current topic.

Regards.

Toru Maeda

At 09:45 01/03/13 -0500, Kassmann, Gary wrote:
>Jim,
>I believe the requirements you are referring to are no longer PTT
>requirements.  Several years ago, the introduction and acceptance of CTR21
>(harmonized European PTT requirements), removed alarm requirements such as
>this one.  The alarms were to provide informational feedback, and in some
>cases operator confirmation, that resolution, document size (example: A3 to
>A4 reduction), or communication speed needed to change to support the remote
>machine capabilities.  It is no longer necessary to implement these alarms
>in order to obtain PTT approvals.  Most fax venders I am aware of have now
>removed these alarms from their designs.  Sending fax machines today will
>automatically downgrade resolution, size or communication speed without
>operator intervention.  The machine will inform the user of the actual
>transmitted resolution, size and speed via a confirmation report, if
>requested by the operator.

I wrote it "There were some facsimile terminals".

>With Store and Forward SMTP, our case is slightly different.  The sender is
>not forced to downgrade prior to sending (no real time capabilities
>exchange) and therefore MAY send using image attributes beyond the receiving
>machines capability.  In the case of sending color to a B&W receiver, if the
>receiver can process the image (render to B&W), then I believe it should be
>processed to the best capability the receiver has.

I am proposing page-by-page status in fax-processing-status-01.txt for this 
reason
that it MAY send using image attributes beyond the receiving
machines capability.

>The suggestion of "disposition = processed/warning: image rendered AT LOWER
>QUALITY" emulates the traditional fax model very well.  It allows the
>message to be processed and rendered, and provides an appropriate
>disposition status back to the sender and ultimately the sending operator.

If the down grade is automatic and no display on the transmitter,
then the message may not be required.

>From: Jim Dahmen [mailto:[email-masked]]
>Sent: Tuesday, March 13, 2001 7:24 AM
>To: 'Dan Wing'; 'MAEDA toru'; 'Mark Fraser'
>Cc: 'McIntyre, Lloyd'; 'Kassmann, Gary'; [email-masked]
>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
>
>
> > Behalf Of Dan Wing
> > Sent: Tuesday, March 13, 2001 2:21 AM
> > To: MAEDA toru; Mark Fraser
> > Cc: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> > 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
> >
> >
> > > Behalf Of MAEDA toru
> > > Sent: Monday, March 12, 2001 10:31 PM
> > > To: Dan Wing; Mark Fraser
> > > Cc: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> > > 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
> > > >
> > > > > Sent: Monday, March 12, 2001 4:53 PM
> > > > > To: Dan Wing
> > > > > Cc: McIntyre, Lloyd; Kassmann, Gary; [email-masked]
> > > > > 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:
> > > > > >
> > > > > > 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
> > > > > > 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
> > > > > >
> > > > > > > > Gary's specific concern addresses a case where,
> > for whatever
> > > > reason, a
> > arbitrary
> > > > > hosts on the
> > > > > > > > > > > > > Manager at Xerox Corporation.  I have
> > been a long
> > > > > time reader
> > > > > > > > > > > > > is capable of interpreting the file but
> > only prints
> > > > B&W.  In
> > > > > > > > > > > > > device having the ability to read and a
> > color file.
> > > > >  Does the
> > > --------------------
> > > MAEDA TORU
> > > MIE Development Div. 2
> > > CANON Inc.
> > > --------------------

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------

---

From: "Kassmann, Gary" <[email-masked]>
Date: Thu, 15 Mar 2001 07:21:08 -0500

Maeda san,
I understand your comments, thank you very much.  I also am very happy that
many fax experts have provided comments regarding MDN use.  This is a very
good forum to discuss and resolve questions.  I think we have a very good
resolution to my question now.

Regards,
Gary

-----Original Message-----
From: MAEDA toru [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 11:35 PM
To: Kassmann, Gary; [email-masked]'; 'Dan Wing'; 'Mark
Fraser'

Gray-san

Regards.

Toru Maeda