Subject: RE: Page and page number in the status

From: "McIntyre, Lloyd" <[email-masked]>
Date: Thu, 8 Mar 2001 11:40:25 -0800

Please see my views below

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 7:54 AM
> To: MAEDA toru; IETF Internet Fax WG
> Cc: fax=[email-masked]
> Subject: Re: Page and page number in the status
> 
> 
> 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 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.
> >
> 
> The above sounds good.
This is the behavior expected of TIFF-FX.
> 
> >[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.
> 
> I would really prefer we have the ability to indicate, per 
> MIME part, which 
> parts were transmitted and how many pages were transmitted.
This appears to be calling for a "Content-IDs" summary (i.e. an equal number
of comma separated distinct IDs to the number of contents) to be included in
the MIME header summary and the corresponding "Content-IDs" included with
the

    Mime-Version: 1.0
      Content-Type: multipart/alternative; boundary="break"
      Content-IDs: AIT3750837,IE39PH89YOEH,367Y376378
      Content-features: (& (Type="text/plain") (charset=US-ASCII) )
      Content-features:
        (& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
      Content-features:
        (& (Type="text/html") (charset=ISO-8859-1) (color=binary) )

      --break
      Content-IDs: AIT3750837
      Content-type: "text/plain";charset=US-ASCII
      Content-features: (color=binary)

       :
      (data)
       :
      --break
      Content-IDs: IE39PH89YOEH
      Content-type: "text/plain";charset=US-ASCII
      Content-features: (color=limited)

       :
      (data)
       :
      --break
      Content-IDs: 367Y376378
      Content-type: text/html;charset=iso-8859-1
      Content-features: (color=limited)

       :
      (data)
       :
      --break--
> 
> 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!
I could not support a proposal that makes render/no-render decisions based
on assumed significance of a message part.

Lloyd
> 
> -d
> 
> 
> 
> 
> >>>>>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?
> >>
> >>Is a legal size (216 $B%i(B 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?
> >>>
> >>>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?
> >>
> >>It depends on which device generates the coverpage, which 
> will cause the 
> >>count to be off by one.
> >
> >--------------------
> >MAEDA TORU
> >MIE Development Div. 2
> >CANON Inc.
> >--------------------
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Mar 2001 13:03:16 -0800

See below.

> the MIME header summary and the corresponding "Content-IDs" included with

I don't think the original message needs to be different at all, except to
include Content-ID on each MIME part.  No need for a summary at the top at
all.

The returned MDN would need some way to indicate which Content-ID it
transmitted, and how many pages of each part were transmitted.

The MDN could be something like this.  I haven't reviewed the MDN spec in
about a year, so bear with me.  The following is line numbered for ease of
discussion.

  1  message-status: succeeded
  2  message-part-status-1: content-id=1234@abc; message-status=succeeded;
           pages=1
  3  message-part-status-2: content-id=859@abc; message-status=succeeded;
           pages=8
  4  message-part-status-3: content-id=2895@abc; message-status=failed;
           pages=0; reason=no-support-on-sender

Above, the first line is from a normal MDN (using the existing MDN spec) and
lines 2, 3, and 4 are the new detail which describe the specific MIME parts
which were transmitted.

-d