Subject: RE: comment on feature-T30-mapping-01.txt

From: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 28 Jun 1999 16:55:31 -0700

Tamura-san,

Please see my response below.

Lloyd

> -----Original Message-----
> From:	Hiroshi Tamura [SMTP:[email-masked]]
> Sent:	Monday, June 28, 1999 3:57 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: comment on feature-T30-mapping-01.txt
> 
> McIntyre-san,
> 
> I am confused.
> 
> RFC2531(Appendix B) says,
>       (Tiff-S) :-
>            (& (image-file-structure=TIFF-S)
>               (color=Binary)
>               (image-coding=MH) (MRC-mode=0) )
> -- end of quote --
> 
> There are two 'S', two 'F', ,,,
> 
> One is Tiff-S or Tiff-F.
> This 'S' or 'F' means "Profile S" or "Profile F" in RFC2301.
	[McIntyre, Lloyd]  True.

> The other is TIFF-S or TIFF-F.
> These are "image-file-structure".
	[McIntyre, Lloyd]  True. The "image-file-structure" is a subset of
the corresponding TIFF-Profile.

> RFC2531(3.7) says,
>    'image-file-structure' defines how the coded image data is wrapped
>    and formatted.  Options defined here are the various profiles of
>    TIFF-FX, per RFC 2301 [7].  These options apply to overall formatting
>    of the image data (TIFF file format, byte ordering, bit ordering,
>    etc.) and do not define specific image coding issues that are covered
>    by other aspects of the TIFF-FX profile specifications.
> -- end of quote --
> 
> The "image-file-structure"s are defined in 2.1 and 3.5 of RFC2301.
> 
> The "image-file-structure" is kind of one of capabilities such as
> paper-size or resolution.
	[McIntyre, Lloyd]  True. It is possible to use a collection of
capabilities without specifying an "image-file-structure" constraint.

> In short,
> If Profile is 'S', "image-file-structure" should be TIFF-S defined
> in 3.5 of RFC2301.
> Even if "image-file-structure" is "TIFF-S", the image data do not always
> conform to "Profile S" in RFC2301.
	[McIntyre, Lloyd]  This is True in the context of combining
capabilities in a general manner. Please remember that the Schema document
[RFC2531] is a general representation that spans the bounds of many
application spaces, not just fax. Given that your original message began
from T30-mapping, which is IFax specific, I interpreted your comments from
an IFax perspective.  If you are speaking in the context of IFax then you
must conform in total context. In this case "image-file-structure=TIFF-S" is
used in conjunction with the constraints of Profile-S, which limits
compression, resolution and paper size. To use compression other than MH,
resolution other than 200x100 and 200x200 dpi (including metric equivalence)
or paper size other than A4 you must step beyond Profile-S. This is at the
heart of Simple Mode [RFC2305] and Extended [RFC2532]. 

> Therefore, for example, any combination of "image-file-structure",
> "image-coding", "dpi" is allowed, I think.
	[McIntyre, Lloyd]  In a general context yes, see above.

> <snip>
> 
> >> 	[McIntyre, Lloyd]  I am afraid that your cannot be realized,
> >> (image-file-structure=TIFF-F)  must be supported if MR/MMR/B4/A3 are to
> be
> >> supported.
> 
> I don't agree.
	[McIntyre, Lloyd]  See above.

> And,
> To support TIFF-F(image-file-structure) is too burden for manufacuturers,
> in order to just only have MMR, considering the structure of TIFF-F,
> in which the IFD is located in any place.
> 
> If I am wrong, please let me know, everyone.
> 
> Regards,
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> Mail: [email-masked]
> Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)
>

---

From: KiyoshiToyoda <[email-masked]>
Date: Tue, 29 Jun 1999 13:07:32 +0900

McIntyre-san,

Please see my opinion below.

>heart of Simple Mode [RFC2305] and Extended [RFC2532]. 

We want to restrict file structure even if IFAX supports Profile-F 
because IFAX has no mass storage such as hard disk. If IFD is located
at bottom of the file, IFAX has to store entirely the file first but
it can not so unless it has mass-storage.

Properly speaking, we should have request RFC2301 to add a new profile 
which conforms to Profile-F but whose structure is restricted. 

Now, we want to express the profile above in anyhow. So, I support the 
proposal that Tamura-san suggests. 

Best Regards,

--
KiyoshiToyoda  
[email-masked]
M.G.C.S

---

From: Hiroshi Tamura <[email-masked]>
Date: Tue, 29 Jun 1999 17:23:26 +0900

Thank you, McIntyre-san and Toyoda-san.

>> proposal that Tamura-san suggests. 

I partly understand what McIntyre-san thinks, but not completely.

If some implementation conform to this draft(fax-feature-T30-mapping),
you may be right.

Please forget this draft and think of only RFC2532,2531,2530.

Capability information can be described in MDN and DSN as extentions.
For example, the following can be possbile. This is not prohibited.

Media-Accept-Features:
     (& (color=binary)
        (image-file-structure=TIFF-S)
        (image-coding=[MH,MR,MMR])
        (MRC-mode=0)
        (| (& (dpi=20320/100) (dpi-xyratio=20320/9779) )
           (& (dpi=20320/100) (dpi-xyratio=20320/19558) )
           (& (dpi=200) (dpi-xyratio=200/100) )
           (& (dpi=200) (dpi-xyratio=1) )
           (& (dpi=300) (dpi-xyratio=1) ) )
        (size-x<=2150/254)
        (Paper-size=[A4,B4,A3,Letter]) )

Therefore, It is possible that IFax-device has the combination
of "image-file-structure=TIFF-S" and "image-coding=[MH,MR,MMR]",
if capability information is properly indicated.

For clarification, Toyoda-san's proposal can be one of options,
I think.

Regards,

---

From: James Rafferty <[email-masked]>
Date: Wed, 30 Jun 1999 17:03:20 -0400

Dear Mr. Toyoda,  

I have some comments, especially with respect to the F profile, for which you
seem to have a different interpretation than what is stated in the RFC 2301
specifications for Profile F.  

At 01:07 PM 6/29/99 +0900, KiyoshiToyoda wrote:
>"McIntyre, Lloyd" <[email-masked]> wrote$B!'(J
>>

>it can not so unless it has mass-storage.
Well, the F profile strongly recommends against this practice-->  i.e. IFD at
the bottom of the file; the F profile has a SHOULD condition on Ifax Profile F
writers placing the IFD in front of each page of image  data.   

Within RFC 2301, the section on guidelines for reading and writing F profile
files (section states:    

"A third simplifying guideline is that each IFD SHOULD be placed in
the TIFF-F file structure at a point which precedes the image which
the IFD describes.

In addition, a fourth simplifying guideline for TIFF-F writers and
readers is to place the actual image data in a physical order within
the TIFF file structure which is consistent with the logical page
order. "

So, placing the IFD in advance of the data, is a SHOULD practice for TIFF-F
writers, per RFC 2301.    

However, as is customary in the IETF AND with normal TIFF practice, readers
generally need to be more liberal in what they will accept than writers, so
the
section goes on to state:   

"In practice, TIFF-F readers will need to use the strip
offsets to find the exact physical location of the image data,
whether or not it is presented in logical page order."

>which conforms to Profile-F but whose structure is restricted. 
The WG very reluctantly accepted the profile S restrictions, which only
resulted after a difficult negotiation and was a compromise.   So, the
addition
of another profile with such restrictions (which very much violate the spirit
of TIFF) would have met with strong resistance.   

>proposal that Tamura-san suggests. 
I have concerns about this, because I believe this could cause
interoperability
problems for Ifax systems that support MMR.    In practice, I believe these
devices need to support the F profile.   
So, let's review what is meant by this.

At the latest Fax Connect, there were 4 implementors who supported the F
profile .    So, it does not 
appear that difficult to do.   

Since the F profile strongly recommends the use of the IFD/image data order
(same as Profile S), the main difference between the recommended practice for
the two profiles is that TIFF F (and all of the other profiles after this),
permit support of either fill order or byte order.    In addition, TIFF-F
readers should have some kind of handling  of exceptions to the recommended
practice for IFD/image data order ((the exact handling is not specified in RFC
2301).   So, this handling of such exceptions is up to the manufacturer.   

If a device has enough capability to handle MMR or JBIG or the other higher
profiles, I have to believe that handling EITHER byte or bit order will
also be
very easy for it and therefore they should be able to do this, consistent with
the F and higher profile requirements.    

For Ifax devices that can support MMR files, IFD/Image data order and handle
both byte and bit orders (plus some kind of exception handling is they
received
files with a different IFC/Image order), I'd be really surprised if they did
not consider this to be compliance with the F profile image structure.    

If you or Tamura-san, have a different interpretation of the RFC 2301 text for
Profile F, please explain.   

Is it really going to be that difficult to have IFax terminal devices support
Profile F when they want to offer MMR support? 

Best Regards, 

James

*------------------------------------------------*
James Rafferty			
President, Human Communications LLC	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email/Internet Fax:  [email-masked]
	 [email-masked]
     [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------