Subject: Re: identifying parts

From: MAEDA toru <[email-masked]>
Date: Mon, 05 Mar 2001 20:32:50 +0900

Wing-san

Thank you very much for comments.
I add my comments below

At 15:52 01/02/22 -0800, Dan Wing wrote:
>At 09:29 PM 2/22/01 +0900, MAEDA toru wrote:
>>Wing-san
>>
>>I got data for ifax devices about these Methods during the Ifax 
>>communication test in 1999.
>>There were three types of MIME type usage in the ifax devices.
>>
>>Type-1= Method 4
>>No Multi-part
>>one tiff file
>>
>>
>>Type-2= Method 2
>>Content-Type:Multipart/mixed
>>Multi-part with one tiff file part
>>
>>
>>Type-3= Method 3 (Not completely same in text part)
>>Content-Type:Multipart/mixed
>>Multi-part with one Text part and one tiff file part
>>
>>Some manufacturers want to suppress printing
>>Multi-part Text part in the ifax receiver,
>>since the text is just information to PC client such as;
>>"There is a TIFF file in this mail, which sent from an Internet Facsimile."
>>"An image data has been attached to this E-mail message and image data is 
>>the Tiff file format."
>>"An image data in TIFF-F format has been attached to this email.
>>You can download the TIFF-F Image Viewer from the following URL addresses."
>>etc.
>
>Throwing away parts of an email is a scary assumption.
>
>With almost all mailers supporting MIME today, such boilerplate 
>instructing a user on how to view an attachment seems 
>unnecessary.  Certainly users requiring non-ASCII character sets are going 
>to use MIME-aware mailers -- it's the only standard way to view text 
>without a reader!

When you get email form IFAX device without text pert,
you may feel strange on the display that there is no text in the mail.
A PC user may feel comfortable when he/she received ifax message
and see a boilerplate on the PC display instructing a user on how to view 
an attachment
even seems unnecessary
before display/printing the attached TIFF file.

>>Any way, ifax should send one tiff file, so there will be no confusion
>>of page-by-page confirmation processing one tiff file.
>
>How would an ifax receiver be restricted to only receive this one 
>method?  It seems we need correct behavior for all the valid types of 
>email messages that an ifax may utilize.  If we don't, why use SMTP?

I agree that we need correct behavior for all the valid types of email 
messages that an ifax may utilize.
Issue is how to count pages of TIFF file(s) in the email with multi part.
Is it OK to assume that one page is equivalent as a page in a TIFF file?

Other issue is what is the page sequence of TIFF files in the email.
Is it OK to assume that the first page is the first page of the first TIFF 
file in the email?

Regards.

Toru Maeda

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

---

From: Dan Wing <[email-masked]>
Date: Mon, 05 Mar 2001 15:10:39 -0800

At 08:32 PM 3/5/01 +0900, MAEDA toru wrote:
Some manufacturers want to suppress printing
>>>"An image data has been attached to this E-mail message and image data 
>>>is the Tiff file format."
>>unnecessary.  Certainly users requiring non-ASCII character sets are 
>>going to use MIME-aware mailers -- it's the only standard way to view 
>>text without a reader!
>

Cisco's ifax devices will send every attachment possible, so that the first 
part which is the boilerplate text/plain will be sent, as will the 
image/tiff part.  As there is no way for the ifax device to know if a part 
is boilerplate or part of what the user expects to be transmitted to the 
user, it isn't safe to assume the first part is boilerplate.  Further, 
there is no requirement or recommendation in any standard that boilerplate 
text preface an attachment, so we did not make the assumption that the 
first part is throw-away boilerplate text.

I would support a standard to identify such boilerplate text, but I do not 
agree that throwing away a part of a mail message is okay unless it can be 
clearly identified as throw-away boilerplate text intended for a user on a 
PC versus the destination fax user.

>Is it OK to assume that one page is equivalent as a page in a TIFF file?

Is a legal size (216 × 356 mm) TIFF image one page, or slightly more?  What 
of the whole A4-versus-"US letter" size problem.

This needs to be clarified.  Are ifax devices expected to always behave in 
a certain way: using their own paper size (as loaded in the device), or 
forced to skip scanlines to cause compression, or do something else?

>Is it OK to assume that the first page is the first page of the first TIFF 

It depends on which device generates the coverpage, which will cause the 
count to be off by one.

-d

---

From: MAEDA toru <[email-masked]>
Date: Wed, 07 Mar 2001 18:16:39 +0900

Wing-san

I made another subject for page and page number in the status to make clear 
discussion.

[one page]
The page number in the status should count pages in the TIFF-FX file but 
not sheets printed.
One page in the TIFF-FX file is defined by IFD.
One page in the TIFF-FX file may be printed in more than one sheet.

[page number]
The first page of the first TIFF file in the multi-part is the first page.
The page number consists from TIFF file number and page number in TIFF file.
[TIFF file number] - [page number in TIFF file]
File number 1 may be not shown when there is one file in the mail.
The coverpage generated from the text-part should not be counted as TIFF-FX 
image page.

>Is a legal size (216 ラ 356 mm) TIFF image one page, or slightly 
>more?  What of the whole A4-versus-"US letter" size problem.
>
>>Is it OK to assume that the first page is the first page of the first 
>>TIFF file in the email?
>

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

---

From: Dan Wing <[email-masked]>
Date: Wed, 07 Mar 2001 07:53:41 -0800

At 06:16 PM 3/7/01 +0900, MAEDA toru wrote:
>Wing-san
>
>I made another subject for page and page number in the status to make 
>clear discussion.
>
>
>[one page]

The above sounds good.

>The coverpage generated from the text-part should not be counted as 
>TIFF-FX image page.

I would really prefer we have the ability to indicate, per MIME part, which 
parts were transmitted and how many pages were transmitted.

The last rule above ("The coverpage generated ....") assumes that the 
text-part is not interesting and that it is a coverpage for the TIFF 
attachment.  That means if I sent included a fax offramp in this email 
message, it would be reported as a 0 page transmission because it doesn't 
have a TIFF attachment.  But actually a several-page fax was transmitted!

-d

>>Is a legal size (216 $B%i(B 356 mm) TIFF image one page, or slightly 
>>This needs to be clarified.  Are ifax devices expected to always behave 
>>in a certain way: using their own paper size (as loaded in the device), 
>>or forced to skip scanlines to cause compression, or do something else?
>>>

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 8 Mar 2001 00:26:23 -0500

Work in the VPIM work group addresses this, as we have the same issue for
voice rendering terminals.

Our solution was to let the sending user (agent) annotate which parts are
critical.  In the example below, the "use a TIFF reader to read the message"
is clearly not critical content, and can be safely deleted.

See http://www.ietf.org/internet-drafts/draft-ietf-vpim-cc-03.txt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Dan Wing
> Sent: Monday, March 05, 2001 6:11 PM
> To: MAEDA toru; IETF Internet Fax WG
> Subject: Re: identifying parts
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Mar 2001 22:17:50 -0800

Yep, and your I-D is a good solution to this problem.  How well is it
progressing through VPIM (I'm no longer subscribed to that mailing list)?

-d

> From: Eric Burger [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 9:26 PM
> To: Dan Wing; MAEDA toru; IETF Internet Fax WG
> Subject: RE: identifying parts
>
>

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 9 Mar 2001 10:16:32 -0500

It will probably have a minor -04 and then a WG last call shortly.

> From: Dan Wing [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 1:18 AM
> To: [email-masked]; MAEDA toru; IETF Internet Fax WG