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

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 30 Jun 1999 17:18:28 -0700

Tamura-san,
Please see my responses below.

Lloyd

> -----Original Message-----
> From:	Hiroshi Tamura [SMTP:[email-masked]]
> Sent:	Wednesday, June 30, 1999 5:10 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:	RE: comment on feature-T30-mapping-01.txt
> 
> McIntyre-san,
> Rafferty-san,
> 
> Thank you for your explanation.
> 
> >> 	[McIntyre, Lloyd]  This is true from the perspective of RFC2531,
> >> however, RFC 2305 and 2532 dictate the IFax rules (context for
> compliance).
> 
> Would you please show the specific places in RFC 2305 and 2532,
> in which the IFax rules are described ?
	[McIntyre, Lloyd]  RFC2532 section 3, paragraph 2 states that any
combination of RFC2301 profiles may be used. It does not make provision for
using combination of features between profiles, as per your proposal.

> >> > 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.
> >> 	[McIntyre, Lloyd]  See RFC2532 and Rafferty-san's message for IFax
> >> context.
> 
> Excuse me for my lack of understanding. Would you please specify it,
> especially the sentences in RFCs ?
	[McIntyre, Lloyd]  See above.

> Concerning the file structure and Profile-F, I will mail at the next time.
> Before clarifing this capability combination, I cannot go into the
> details.
> 
> Regards,
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> Mail: [email-masked]
> Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 01 Jul 1999 09:57:41 +0900

McIntyre-san,

Thanks for quick response.

>> using combination of features between profiles, as per your proposal.

RFC2532 section 3, paragraph 2
--- begin quote ---
   A recipient MAY support any or all (or any combination) of the TIFF
   profiles defined in RFC 2301, in addition to profile S.  A recipient
   which supports additional profiles SHOULD indicate this support as
   per section 3.2 or 3.3 of this document.  As a consequence, a sender
   MAY use those additional TIFF profiles when sending to a recipient
   with the corresponding capabilities.
--- end qoute ---

Do these mean 
  "Ifax capabilities are thought as the unit of Profile defined in RFC2301." ?

Is it not possbile to indicate image-file-structure=TIFF-S and MMR ?
In order to support only MR + Profile S, do we have to the superior profile to 
Profile S ?

It seems to me that they are very strict rules,
comparing with capability exchange in G3/G4 facsmile.
There would be small combinations.

If capablity exchange can be done properly, no strict rules are necessary,
I think.
Capablity exchange can be done for each of feature tags defined in RFC2531,
although some combinations may be meaningless.

I would like to confirm if McIntyre-san's thinking is
common understanding in this WG or not.

I know lots of subscriber are very busy. 
But I welcome lots of comments, regardless of yes or no.

Someone probably would like to indicate image-file-structure=TIFF-S and MMR.
Maybe, it is true of fax manufacturers, especially in Japan, I believe.

Regards,

---

From: Yukikazu Mori <[email-masked]>
Date: Thu, 01 Jul 1999 11:30:26 +0900

Hi all ;

It is very good to have heated discussion.

At first, I made a very simple question to ask
"Is it possible to indicate a capability of
TIFF-S file structure + MMR?".

The first response from Grahams who should be
deeply involved in this activity was, I think after all
"YES" and I was satisfied.

Then Lloyd who are also deeply involved expressed a
different view.

Then Tamura san who are also involved said "YES"
quoting some texts of RFC2351 and Toyoda-san supported.

Then Lloyd together with James repeated the same view
quoting some texts of RFC2532.

(And while I was writing this mail, I received one more from 
Lloyd.)

I think what it all means is there is an ambiguity
in RFCs we are concerned.

So I think we sould make some amendment to clarify.

But before doing that, we should agree on the direction of
clarification and so I come back to my first question.

James asked "Is it really difficult?".
The answer is obvious. IT IS REALLY DIFFICULT.
Please bear in mind that our product range is very wide
from low end to high end. It is not appropriate to
judge this by seeing some limited PC-BASED implementations.
We have NO paticular intent to exclude TIFF-F structure. 
Our opinion is purely from the implementation viewpoints.

James also raised a concern of interoperability problem.
Why???

We intend to express such capability. 
When the sender receives TIFF-S structure + MMR capability
from the receiver, the sender shall send according to its capability.
It is a matther of course that sending TIFF-F structure + MMR 
to such machine will cause an error.
Do you call this an interoperability problem?

Lloyd raised an example of MMR/JBI G + ECM restriction.
Yes, it is true and there is technical rationale for that.
Evey technical person knows MMR or JBIG requires error free
comunication environment.

Now what about this case we are discussing?  No rationale.
Why not agree on accepting this capability expression and
amend the standard as necessary.

Thank you.
Best regards,
Yukikazu MORI

***************************************************************
RICOH COMPANY, LTD.  Toda Technical Center
Yukikazu MORI
TEL:+81-462-28-1743
FAX:+81-462-28-7500(Subaddress(SUB) 5720)
Email:[email-masked]
***************************************************************