Subject: RE: Question on FaxConnect Results..

From: "McIntyre, Lloyd" <[email-masked]>
Date: Thu, 4 Feb 1999 14:26:31 -0800

Please remember that either page headers (i.e. included in the message body)
or a cover page satisfies the FCC requirement for fax.
I personally would prefer to not add headers to the message pages.
I suspect that cover pages may be easily generated at the IFax receiver
based on the mail header information. I do not know whether a cover page
generated at the receiver will have as much credibility as one generated by
the sender and included with the message.
Bottom line, I would recommend a cover page that was generated at the sender
and included as a part of the message.

Lloyd

> -----Original Message-----
> From:	Richard Shockey [SMTP:[email-masked]]
> Sent:	Thursday, February 04, 1999 2:18 PM
> To:	McIntyre, Lloyd; Cancio, Vivian; Michael Spann
> Cc:	[email-masked]
> Subject:	RE: Question on FaxConnect Results..
> 
> At 11:12 AM 2/4/1999 -0800, McIntyre, Lloyd wrote:
> >Vivian,
> >You are absolutely correct.
> >However, if it is our objective to replicate the status of PSTN in IFax
> then
> >we SHOULD.
> 
> >We are trying to elevate IFax above e-mail.
> >
> >Lloyd
> 
> Thank you Lloyd...this is precisely my point. My supposition is that the
> more we attempt to duplicate the general custom and practice or "look and
> feel" of traditional fax than the better off we will all be in marketing
> the forthcoming IFAX products.
> 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey
> Shockey Consulting LLC                  
> 8045 Big Bend Blvd. Suite 110    
> St. Louis, MO 63119
> Voice 314.918.9020
> Fax   314.918.9015
> INTERNET Mail & IFAX : [email-masked]  
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Dan Wing <[email-masked]>
Date: Thu, 4 Feb 1999 15:13:19 -0800 (PST)

> and included as a part of the message.

I disagree.

In email, this coverpage information is already sent in every email
message in the RFC822 headers (To, From, Subject, Date).

There is no need to duplicate this coverpage information in a TIFF-
encoded page --- the information is already there in the RFC822 headers.

There is no need to duplicate this coverpage information in a separate
MIME part, as some products do -- the information is already there in the
RFC822 headers.

There are a multitude of problems created by duplicating the information
that is already present in the RFC822 headers, and nothing is gained by
duplicating this information.

The coverpage is only necessary when offramping to a GSTN-based
fax machine.  The coverpage should be generated by the offramp using the
already-present RFC822 header information, not by relying on a
non-standard inclusion of a coverpage in a separate MIME part or in the
first page of the TIFF-encoded pages.  Additionally, any ifax
device which relies on such non-standard coverpage information is 
non-interoperable because the ifax standards (RFC2305 and soon eifax)
do not require the sender to include a coverpage -- and shouldn't, as
the "coverpage" information is already present in the RFC822 headers.

-Dan Wing

---

From: Richard Shockey <[email-masked]>
Date: Thu, 04 Feb 1999 17:56:16 -0600

>encoded page --- the information is already there in the RFC822 headers.

I agree that cover pages should not be automatically generated based on 822
headers.

But that said... see below.

>first page of the TIFF-encoded pages. 

I would'nt recommend anything like this.  Why? 
We're not going down that rat hole of gateway behavior I hope. If carriers
or some folks want to do this its their business.

 >Additionally, any IFAX

There is no question that cover pages SHOULD be generated by Operators and
included in the TIFF encoded images. IFAX or EIFAX _software_ systems
SHOULD offer cover page generation facilities as is the general custom and
practice with modern fax software. This would be a fine recommendation for
our Implementors guide.

I think we can safely predict that people sending IFAX transactions from
network scanner type devices will continue to manually fill out little
forms and include them in the document transmission that have all of the
required recipient and sender data written in.

People want to send facsimile cover pages with their company logo's, baby
pictures and really long useless legal disclaimers.  This type of cover
page generation is a implementation issue and I agree, should not have any
place in the protocol itself.

Richard Shockey
Shockey Consulting LLC

---

From: Dan Wing <[email-masked]>
Date: Thu, 4 Feb 1999 16:12:33 -0800 (PST)

On Thu, 4 Feb 1999 17:56:16 -0600, Richard Shockey wrote:

...
> place in the protocol itself.

Except that because it is not specified in RFC2305 or eifax, a coverpage
can never be expected by an ifax recipient.

"What isn't in the standard is non-standard."

The whole coverpage issue is a rathole.  The watermarking issue is a
rathole as well, but a smaller rat hole.

Perhaps it needs standardization.  From FaxConnect I it certainly appears
that every company had a different solution to this same problem -- and
many, I expect, relied on a certain MIME type or the first page of the
TIFF being a coverpage, or pre-watermarked TIFF pages, or some
combination.

The goal of this WG was, and I believe continues to be, integration of
email with fax -- while promoting and furthering the quality of faxes sent
over email (as we have done with DSN/MDN support in eifax).

As such, I do not see it is reasonable for a user with a copy of Microsoft
Word, some PS- or Word- or RTF- or ASCII-to-TIFF converter, and a copy of
an off-the-shelf mailer (Eudora, Outlook, Netscape) to somehow watermark
the TIFF pages or create a coverpage in addition to the "To:" field
the user is already typing into her off-the-shelf mailer.

I don't believe we can throw out all existing mailers and XXX-to-TIFF
converters as "non ifax / non eifax compliant" because "compliant"
offramps require some special, non-normal watermark on TIFF pages
or non-normal MIME part which is the coverpage.

I stick by my guns that while the message is traversing over email it
should conform to email.  When it is traversing over GSTN as a fax it
should conform to fax.  When traversing over email, I see no need for the
TIFF images to be occluded with sender identification or for any style of
coverpage information to duplicate what is already present in the RFC822
headers.

-Dan Wing

---

From: Richard Shockey <[email-masked]>
Date: Thu, 04 Feb 1999 20:14:59 -0600

>"What isn't in the standard is non-standard."

Fine but there is nothing in United States law that requires fax software
vendors to provide pretty little cover page generators either. Legally they
could just watermark the pages and they would be done.

>rathole as well, but a smaller rat hole.

Maybe a mouse hole .. certainly something to consider for a Implementers
guide and I hope as we reach the "end game" that work item gets high priority.

>over email (as we have done with DSN/MDN support in eifax).

Well...you have said the magic word.. so long as we think of IFAX and EIFAX
as "fax" we have created a whole suite of end user expectations and those
expectations include the generation of cover pages and watermarking of the
files transmitted. This is not a protocol issue..its  ..dare I say it a
marketing issue.

What we are doing, IMHO ,is abstracting the sending of "facsimile
documents" from the underlying transport layer or addressing scheme.

People want to send a "fax" from here to there..now they have a choice.. do
I send this "fax" via the GSTN to this phone number ..or do I send this
'"fax" to this e mail address or do I send this "fax" to this IPP address..etc.

>the user is already typing into her off-the-shelf mailer.

We'll see but it seems perfectly reasonable to assume that the GSTN fax
software industry will do exactly what it has always done. Especially if
what is happening is a simple change of addressing and transport mechanism.

>or non-normal MIME part which is the coverpage.

Realistically I agree..this looks like a "SHOULD" issue to me that will
almost certainly be driven by end user perceptions and marketing pressure.

>should conform to fax.  

Well ... as I have said before ..if it looks like a Duck... and you keep
calling it a Duck.. people are going to expect a Duck.

Richard Shockey
Shockey Consulting LLC

---

From: Dan Wing <[email-masked]>
Date: Thu, 4 Feb 1999 18:43:07 -0800 (PST)

> could just watermark the pages and they would be done.

Yep.  I think that's a great solution -- but, again, it is only needed
on GSTN fax.  Not on a TIFF-encoded image being sent over SMTP -- that
is not GSTN fax -- the SMTP headers provide all the same legally-required
identification strings, and more, than are available with GSTN fax.

> People want to send a "fax" from here to there..now they have a
> choice.. do I send this "fax" via the GSTN to this phone number ..or
> do I send this '"fax" to this e mail address or do I send this "fax"
> to this IPP address..etc.

From what I know, these are the reasons for watermarks:

*  Count pages.  

A sender carefully counts the number of pages they are going to transmit,
writes this on the coverpage (don't forget to count the coverpage!), puts
that into their fax machine and hits Send.

The receiver gets the pages and dutifully verifies the number of pages
they have received is the same as the number the sender wrote on the
coverpage.

Sometimes it's off by one -- is that because the sender didn't include
the coverpage?  Is it because the sender's fax machine stuck two pages
together?  The receiver has to decide, call the sender, have a page
retransmitted, etc.

I have NEVER encountered such a situation with email.  The worst I have
encountered is someone saying "See the attached document, which describes
..." and they neglected to attach the document.  No big deal - I reply,
ask them to attach the document, they do that and resend the mail message
to me.  I've never received a partial mail message, never received a
message with pages or parts of it out-of-order, etc.

* Identify sender.  

The sending fax machine has no way of knowing if the sender is using a
coverpage with this transmission. The fax machine could automatically
generate a coverpage which is sent before the documents (my home fax
machine can be configured to do this).

However, not knowing if the sender is using a manually-generated
coverpage, the fax machine wants the user to comply with the law
(actually, the fax machine has to comply with the law, because
I believe the requirement is that each fax machine identify itself
using user-programmed settings).

The easiest way to do this, and the least obtrusive, is a watermark.
A coverpage is too intrusive, doesn't send a cute company logo, uses
another sheet of paper on the recipient end, etc.

With IPP and with SMTP, the sender is already identified with fields
present in IPP and SMTP.

* Datestamp

The time the sender transmitted the fax.

IPP and SMTP have mechanisms to get this same information.

In summary, I see no need to include a watermark on the data that
is being transmitted over IPP or SMTP.

> what is happening is a simple change of addressing and transport mechanism.

Of course - each industry will do it the way they have always
done it.  The existing MUA companies will use a mail model, the existing
GSTN fax software companies will use a fax model.

The fax model of a coverpage in the document is redundant when the
coverpage inforamtion (sender, receipient, date, subject) is already in
the SMTP header.  If the fax-over-smtp message is ever offramped, the
coverpage and watermark information could be useful.  But if the
fax-over-smtp message is never offramped, the coverpage and watermark
information is redundant and potentially damaging to the (first 1/2" of
the document).

And don't you suppose there would be confusion if someone sent an email
with a coverpage that was incorrect?  With email this is obvious when you
forward a message -- message/rfc822 is used.  And a computer can parse
that.  But a computer can't parse a coverpage to determine it is, in fact,
a coverpage.

> almost certainly be driven by end user perceptions and marketing pressure.

Sure -- and will surely depend on the company doing the development.

> calling it a Duck.. people are going to expect a Duck.

The Duck is T.38.

Fax-over-SMTP is not exactly the same as fax over GSTN.  It never can
be due to the "store" in store-and-forward.  The new Deliver-By gives
us a new hope that we can set an upper bound to the time allowed
to "store" a message.

-Dan Wing