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

From: Graham Klyne <[email-masked]>
Date: Tue, 29 Jun 1999 22:26:11 +0100

Tamura-san,

At 07:56 29/06/99 +0900, Hiroshi Tamura wrote:
[...]
>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.
>
>The other is TIFF-S or TIFF-F.
>These are "image-file-structure".

Yes, I agree that there are two distinct uses of TIFF-S and TIFF-F here.  I
shall try to explain these different uses.

This excerpt from RFC2531 is an attempt to define a named predicate
[RFC2533, section 6.1.1] named (Tiff-S), which reflects a statement of a
range of media features associated with TIFF profile S.

I shall try and express that statement in English:

The named predicate (Tiff-S) is defined to mean:
  an image that conforms to the file structure requirements of TIFF mode S,
AND
  contains a binary (bi-level) image,
AND
  contains an MH coded image,
AND
  does not contain any MRC image structures.

Thus:
1.  (TIFF-S) is a named predicate that is defined to describe a range of
TIFF mode S capabilities;
2.  the statement (image-file-structure=TIFF-S) indicates just that the
image file structure conforms to the constraints of TIFF mode S.

>The "image-file-structure"s are defined in 2.1 and 3.5 of RFC2301.

I think that is right (but here I defer to the TIFF experts).

>The "image-file-structure" is kind of one of capabilities such as
>paper-size or resolution.

I agree.

>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.
>
>Therefore, for example, any combination of "image-file-structure",
>"image-coding", "dpi" is allowed, I think.

In constructing a feature expression, I think that is correct.

(But remember that it is possible to construct feature expressions which
may not reflect valid Internet fax capabilities.)

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Wed, 30 Jun 1999 10:56:26 +0100

Tamura-san,

At 17:23 29/06/99 +0900, Hiroshi Tamura wrote:
[...]
>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.

I would like to reinforce something I think you are saying here.

The T30-mapping draft does not of itself specify anything.  Rather, it is
an informational "how-to" document, based on the specifications of ITU
T.30, RFC 2533, RFC 2531 and others.

So I agree that for the purposes of determining what is to be
interoperable, the other documents you mention should be consulted.

Thank you,

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Wed, 30 Jun 1999 21:33:47 +0100

Tamura-san,

Thank you,

#g

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 30 Jun 1999 15:38:29 -0700

Toyoda-san,
I believe that Rafferty-san has addressed your issues and there is nothing
more that I should add.

Rest regard,
Lloyd

> -----Original Message-----
> From:	KiyoshiToyoda [SMTP:[email-masked]]
> Sent:	Monday, June 28, 1999 9:08 PM
> To:	McIntyre, Lloyd
> Cc:	'Hiroshi Tamura'; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: comment on feature-T30-mapping-01.txt
> 
> McIntyre-san,
> 
> Please see my opinion below.
> 
> "McIntyre, Lloyd" <[email-masked]> wrote：
> >
> >> In short,
> >	[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]. 
> 
> 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