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

From: Graham Klyne <[email-masked]>
Date: Thu, 08 Jul 1999 11:56:02 +0100

Tamura-san,

Please forgive my delay in responding.  I have been thinking about your
comments and trying to understand the range of issues involved.

At 07:53 02/07/99 +0900, Hiroshi Tamura wrote:
>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.

[...]
>It largely depends on the orignal architecure, with which
>people will newly make Ifax device or software.
>
>I am still wating for other comments.

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.

I think there are, at heart, two competing issues here:

(1) fax machines and other "embedded" or "dedicated" systems have limited
memory, and therefore cannot process large documents with unconstrained IFD
placement.

(2) TIFF is a long-established framework, with a substantial body of
deployed software for writing TIFF image files that may be sent in e-mails.

I think these are both legitimate positions that should be accommodated to
the maximum extent possible.  A goal of this fax WG, asserted some time
ago, is to maximize interoperability between existing e-mail systems and a
new generation of Internet fax systems.

I observe there is NO standard we could write that will guarantee
interoperability between all presently deployed TIFF writers and
limited-memory fax machines.  But clearly, we wish to strongly encourage
any new system that is likely to communicate with Internet fax systems to
use a suitably constrained IFD placement.

Thus, I suggest:

(a) not to change anything in the TIFF specification.

(b) in the Internet fax master document(s), emphasize the SHOULD
exhortation in RFC 2301 about IFD ordering, briefly explain why it is
important (i.e. buffering in low-memory systems) and point out that some
receivers may not be able to process large messages that do not conform to
this requirement.

(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.

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.

(e) add a new feature tag:

    (image-buffer-size<=n)            {maximum TIFF 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 would be that the IFD
placement must follow the recommendations in RFC2301 if the image is to be
processable by the recipient.  (But senders should still allow arbitrary
placement as long as the buffering capability is not exceeded.)

In making this proposal, I have tried to take account of what I see as
being the legitimate concerns of all parties.  I hope you find this input
helpful.

#g

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 09 Jul 1999 15:33:01 +0900

Klyne-san,

Thank you for your suggestion and proposal.

>> being the legitimate concerns of all parties.  I hope you find this input

You message may be the clue.
I need time to consider and I would like to hear other opinions.

I'm sorry I don't respond well.
Today I'm busy and sooner or later I must go back home,
because tomorrow I am going to Oslo.

(It took time to write another message to this ML.)

We may talk about it outside the meeting in Oslo.

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: Sun, 11 Jul 1999 06:53:26 +0200

Klyne-san,

> issues of bit- and byte- ordering are not really a problem.

Not TIFF-S, but Profile S.

> memory, and therefore cannot process large documents with unconstrained IFD

Right.
 
> (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.

> receivers may not be able to process large messages that do not conform to

OK.
 
> receiver, and allow for failures due to IFD placement to be clearly

I do not understand this part well("allow for .....").
 
> Other TIFF-x values for this feature tag would be deleted.

Certainly, other structure except for TIFF-S may be meaningless.

>From modified one: 
>    (image-buffer-size<=n)            {maximum image buffer size}
>
>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 ?
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.

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

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

Anyway, I would like to continue this discussion.
Thank you for your idea.

I'm still wating for other comments.

Regards,