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

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 02 Jul 1999 07:53:38 +0900

Raffery-san,

I have read your message.

I know the rules of Profile F.
Your explanation about RFC2301 is completely right.
Your interpretation about SENTENCES in RFC2301 is the same as mine.

But the interpretation about implementation is a little different.

If the combination of "image-file-structure=TIFF-S" and "MMR"
could not TECHNICALLY be possible
 or
this combination would cause the interoperabilty problem
with capability exchange(negotiation),

I could agree with you.

But, in fact, there are no problems, if capability exchange
can be done. McIntyre-san also says, it is possbile
according to RFC2531, which other applications may use.

The matter is the Ifax-rule that McIntyre-san says, in which
Profile-F is necessary in order to use MR/MMR, B4/A4, 400dpi,,,

In my memory, before RFC2532 is standardized, there were no
disucussions like that.

Why is it necessary to limit some combination that is
technically and logically possible for only Ifax ?
although it is ok in other applications.

Would you please explain the reason, McIntyre-san or Rafferty-san ?

If the sender and the receiver support the "image-file-structure=TIFF-F"
or Profile F, they indicate the capability and the trasmitted
image data will be "image-file-structure=TIFF-F", of course.

>> >Now, we want to express the profile above in anyhow. So, I support the 
>> >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.

If capability exchange is done, no interoperability problems.
Without it, of course, it will be the problems.

It is other matters about easiness of implementation of Profile-F.
In fact, Writer is not difficlut, but Reader may be difficult
in order to cope with all possbilities of encodings. It may need
lots of resources in machine.

It largely depends on the orignal architecure, with which
people will newly make Ifax device or software.

I am still wating for other comments.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)

---

From: Graham Klyne <[email-masked]>
Date: Mon, 12 Jul 1999 12:52:55 +0100

At 06:53 11/07/99 +0200, Hiroshi Tamura wrote:

>> If I understand correctly, your real concern is to be able to use
>> higher-level media capabilities than are provided by TIFF-S, without being
>> forced to handle arbitrary IFD placement within a TIFF file.  I think the
>> issues of bit- and byte- ordering are not really a problem.
>
>Not TIFF-S, but Profile S.

Yes (I tend to use those terms interchangeably, but I do mean Profile S of
TIFF as defined by RFC 2301).

[...]
>> Thus, I suggest:
>> 
>> (a) not to change anything in the TIFF specification.
>
>Does it mean the original TIFF(version 6) or RFC2301 ?
>Of course, the former cannot be changed.

I was referring to both.  I don't have a very strong view about whether the
changes I suggest would be applied to RFC2301, RFC2532, or both.  But I was
thinking the changes would be applied to RFC2532 since I perceive that as
the "master" document for Internet fax extended mode.

I can see maybe some advantage to giving more prominence to the
recommendations about IFD placement in a revision of RFC2301.

>> (c) pursuant to (b), document precisely how a receiver should report any
>> failure to process that is due to insufficient image buffer memory.
>> 
>> What this would do is establish the conditions on an Internet fax sender
>> that would effectively guarantee TIFF file interoperability with a fax
>> receiver, and allow for failures due to IFD placement to be clearly
>> identified.
>
>I do not understand this part well("allow for .....").

Is it clearer if those words are replaced by "provide that ..."?

I mean that when failure to process is caused by lack of buffer memory, the
condition is reported in a well-documented way, so that senders who do not
conform to the recommendations get a clear indication of the reason.

>> NOTE: what follows is not an essential part of my suggestion.
>> 
>> A possible additional step might be to use the capability identification
>> framework to identify receivers that may be limited in their abaility to
>> handle IFD placement, but which otherwise can handle a wider range of TIFF
>> capabilities than specified for TIFF-S.  This could be achieved through
>> some small revisions to the fax feature schema, along the lines of:
>> 
>> (d) modify the image-file-structure definition:
>> 
>>     (image-file-structure=TIFF-S)    {as now}
>>     (image-file-structure=TIFF)      {full TIFF, no IFD ordering,
>>                                       byte or bit ordering constraints}
>> 
>> Other TIFF-x values for this feature tag would be deleted.
>
>Certainly, other structure except for TIFF-S may be meaningless.

I think this would be worthwhile to help reduce the confusion we have
already seen here.

>>From modified one: 
>>(e) add a new feature tag:
>>
>>    (image-buffer-size<=n)            {maximum image buffer size}
>>
>>The idea here is that use of the image-buffer-size tag would indicate that
>>the receiver has limits on the amount of image data it can buffer:
>>effectively, in the context of a TIFF image, this would describe a
>>limitation on the separation between image data and IFD that can be
>>handled.  A simple interpretation of this feature by senders would be
>>..................................................^^^^^^^^^^
>>that the IFD placement must follow the recommendations in RFC2301 if the
>>image is to be processable by the recipient.  (But recipients should still
>>...................................................^^^^^^^^^^
>>allow arbitrary placement as long as buffering capability is not exceeded.)
> 
>How do a sender use this feature and judge the structure ?

Well, I think this is an implementation issue.

If, as a sender, I write
   IFD1,page-data-1,IFD2,page-date2,...
then I believe I would be entitled to ignore the image-buffer-size since no
buffering is required by the receiver.

>For example,
>if n == 100Mbyte, does a receiver accept full TIFF ?
>if n == 1Mbyte, TIFF-S structure ?
>Data size of one page depends on the image itself.
>There is a big difference between character data and photo one.

Yes, of course this is true.

The presence of this tag would indicate that there is some constraint,
however large it might be.  The absence of this tag, or its presence in the
form:
    (image-buffer-size>0)
would indicate that the receiver can handle unconstrained TIFF.

As a rough guide, I would suggest that:
    (image-buffer-size<=100000)
would indicate that the receiver can buffer a page of ordinary fax image data.

>If a receiver may do multi-receiving, there will be little
>buffer size.

I think it might indicate how much memory resource the receiver is prepared
to dedicate to any active receive operation.

>This idea is not too bad. I don't think it is enough.
>Another diagnostic-code or disposition-type or something
>may be necessary.

Indeed:  further discussion is clearly needed if the basic idea approach to
be workable.

#g

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