Subject: RE: MDN usage question.

From: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 12 Mar 2001 14:58:57 -0800

> -----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: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2001 15:31:21 -0800

> LOWER QUALITY strives for maximum interoperability.

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.

It will be years before there is a widely deployed mechanism to learn an
arbitrary recipient's capabilities, and such a feature will have to be
deployed in popular MUAs (Microsoft Outlook, Qualcomm Eudora, AOL Netscape,
etc.).

The sending of a higher-than-processable format implies the sender doesn't
know (or has forgotten) the receipient's capability and that the recipient
capability information was incorrect.  Following the Internet's mantra of "be
liberal in what you accept, be conservative in what you send" (J. Postel), the
proper thing to do is accept the message and convert it as best you can.  I
propose this is the best situation for interoperability and by providing a
hint to compliant senders (indicating that fidelity was lost) the sender can
be reconfigured or can obtain fresher information about the recipient from
whatever source (LDAP server, user, some magic CONNEG database, etc.).

Let me pose an example which I considered:

Question and background: At what degree should a message not be translated
into a different format?  Remember rfc2305 requires handling both image/tiff
and text/plain.  Text/plain support is necessary because error messages and
bounces are in text/plain.

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?

-d

---

From: Mark Fraser <[email-masked]>
Date: Mon, 12 Mar 2001 15:50:14 -0800

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2001 16:04:59 -0800

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

> 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.
>
>

---

From: Mark Fraser <[email-masked]>
Date: Mon, 12 Mar 2001 16:52:54 -0800

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2001 17:01:45 -0800

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]

---

From: MAEDA toru <[email-masked]>
Date: Tue, 13 Mar 2001 15:31:00 +0900

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

> > > > > > > > > This is a very good question for which a consensus position

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2001 23:21:00 -0800

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

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of MAEDA toru
> Sent: Monday, March 12, 2001 10:31 PM
> To: Dan Wing; Mark Fraser

---

From: "Jim Dahmen" <[email-masked]>
Date: Tue, 13 Mar 2001 07:24:19 -0500

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
> > > > > 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
> > > > > 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
> > > > > > > the MDN? My proposal of disposition =
> processed/error:image
> > > > rendered AT
> > > > > > > > never will be the standard model.  I don't want
> 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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Mar 2001 08:21:59 -0800

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

> From: Jim Dahmen [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2001 4:24 AM
> To: 'Dan Wing'; 'MAEDA toru'; 'Mark Fraser'
> Cc: 'McIntyre, Lloyd'; 'Kassmann, Gary'; [email-masked]

---

From: [email-masked]
Date: Tue, 13 Mar 2001 09:28:02 -0800 (PST)

> issue is *actual* alteration.

Actually, the present-day reality appears to be that both analysis and
alterations can be done in real time. The timing constraints of FAX may have
been enough to prevent this at the time the protocol was defined, but hardware
performance has caught up since then.

I found out about this stuff by reading some literature for a company that used
to build this sort of stuff strictly for the US government, but now has to look
to the private sector for financing. Makes me wonder what they have that they
cannot even talk about...

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 13 Mar 2001 19:16:10 +0100

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

In all EU countries since 1998 the situation is of full deregulation. 
This also implied the abolition of this kind of "approval".

The only remains of the telco's monopoly is tha "devices" must obtain a 
techncial "approval" not on a single useer basis, but on vendor one.

For example my ISDN PCMCIA card which I'm using just now states:

EURO ISDN Terminal Adapter, Ministry of Telecomunication Administrative
Approval no. 97/003/DGCA

which means it conforms to technical specification an can be connected to 
the ISDN service. Bit this certification was done by the producer.

Claudio

PS: hem.... please, e-mail netiquette: "do not quote whole bunches of 
messages unless needed"

:-)

---

From: "George Pajari" <[email-masked]>
Date: Tue, 13 Mar 2001 10:35:31 -0800

> alterations can be done in real time....

I continue to find it surprising how many people who ought to know better
(not referring to any members of this list) seem to think that a fax message
has any intrinsic reliability as to origin or content. It would be truly
depressing to learn that any court had put any degree of reliance upon a fax
message without considerable supporting circumstantial evidence.

Spoofing the origin and content of a fax message (including what appears to
be a signature) is only slightly more difficult than forging a plaintext
email message.

Caveat Acceptator

---

From: "Jim Dahmen" <[email-masked]>
Date: Tue, 13 Mar 2001 16:15:15 -0500

> PS: hem.... please, e-mail netiquette: "do not quote whole bunches of 
Claudio and all,

Sorry, it was early and brain cells weren't working.........

---

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

Jim-san

Thank you very much additional information to my mail.

Regards.

Toru Maeda

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