John,
While writing up the minutes I discovered several problems with the
conformance sections in the UIF document:
1. Section 5.5 Image reduction supported talks about the Sender MAY query
the Receiver to see whether or not the Receiver supports Reduction. I
suggest that the Sender MUST query the Receiver, if the Sender is going to
use Reduction, but NEED NOT query the Receiver if the Sender is not going to
use Reduction.
The Receiver MUST indicate whether or not it supports Reduction.
Also the Sender MUST query the Sending User to use Reduction; the Sender
MUST NOT request Reduction unless explicitly indicated by the Sending User.
2. Section 6 is entitled "Sender requirements" and Section 7 is entitled
"Conformance Requirements".
But Section 6 is talking about BOTH Sender and Receiver requirements but
only about regarding reduction (section 6.1) and media selection (section
6.2).
I suggest that section 6.1 Image Reduction be promoted to header1 (and the
current Section 6 header1 "Sender requirements" disappear). It can start
off by stating that Image Reduction is an OPTIONAL feature for Senders and
Receivers.
We agreed on Friday that the Image Reduction that the Sender sends is
"allowing the Receiver" to reduce, rather than tile, if the Receiver
supports reduction. The Receiver MUST support tiling.
3. Intra-job media selection
Section 6.2 "Intra-job media selection" is strongly related to the issue of
not losing data in section 6.1. Section 6.1 talks about saving data either
by tiling (Receiver MUST support) or by Reduction (Receiver MAY support).
Section 6.2 talks about a third way to avoid data loss because a Receiver
could switch to a larger media size than the media that the Sender requests
if there was more data on a page than would fit on the media selected by the
Sender.
Thus there are really three ways that a Receiver can avoid losing data from
images sent by the Sender:
a. The Receiver can tile the image onto a number of sheets (the Receiving
User can tape the sheets together to get the actual result).
b. The Receiver can reduce (but only if the Receiver supports Reduction
AND the Sender grants permission to reduce).
c. The Receiver can select a larger media sheet (if supported by the
Receiver, but probably only if human intervention is not needed). I'm
suggesting that a Receiver MAY support switching media, but NEED NOT. How
does the Receiver indicate whether or not? Perhaps, by the "media-ready"
having larger sizes? How a Sender queries for changing media needs to be
added to UIF and IFX.
4. Precedence of tiff tags versus IPPFAX "media" protocol attribute
In the Friday IFX review (John was not present) we agreed that the tiff tags
would switch media, i.e., take precedence over the "media" attribute in the
IPPFAX protocol. There is the statement in UIF:
"The ImageWidth and ImageLength TIFF tags MUST NOT select the media."
However, I'm not certain which TIFF tags we were talking about on Friday?
What is ImageWidth and ImageLength or some Media tags?
5. Section 7 is a good summary of the overall Conformance Requirements for
Sender and Receiver. However, we probably need separate tables or columns
for what the Sender MUST query BEFORE sending a document versus what the
Sender MUST send when submitting a document.
For example, the last line: "image reduction supported" indicates MAY for
the Sender and MUST for the Receiver. This is correct for queries, but is
not correct for support. The Receiver NEED NOT support reduction. (In IFX
a Receiver indicates that it doesn't support Reduction by not returning the
"reduction-supported" attribute at all.
6. The section numbers in the last column of the table in section 7 are
wrong and/or aren't in the document.
Tom
This archive was generated by hypermail 2b29 : Mon Jul 02 2001 - 19:01:03 EDT