The third document will be reviewed at the next telecon, one week hence:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04.doc>
Time: Wednesday, June 6, 10-12 PDT (1-3 EDT).
Phone: (712) 271-3216 (Xerox folks: 8*534-6413)
Passcode: 74584# (confirmation #: 1457475)
Here are the agreements from last Wednesday's telecon:
IPP Fax Telecon - 5/30/01
Notes by John Pulera and Tom Hastings
File:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-010530-telecon-minutes.pdf
, .doc
Participants:
Bob Herriot
Tom Hastings
Ira McDonald
John Pulera
Gail Songer
Bill Wagner
We reviewed the first two of the three papers on the agenda:
1. Review John Pulera's updated UIF spec with changes highlighted:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-04.doc>
2. Review John Pulera's white paper on additions to the UIF spec with my
comment/issues interspersed:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheets/default_conneg_etc-th-comme
nts.doc>
3. Review the updated IFX spec. It is just editorial improvements on the
IFX spec:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04.doc>
Next telecon:
The third document will be reviewed at the next telecon, one week hence:
Time: Wednesday, June 6, 10-12 PDT (1-3 EDT).
Phone: (712) 271-3216 (Xerox folks: 8*534-6413)
Passcode: 74584# (confirmation #: 1457475)
Issues discussed
New issues:
* ISSUE A: (Ira) Should we change "Sender" to "IPPFAX client"
and change "Receiver" to "IPPFAX Printer" (which is short for IPPFAX Printer
object), i.e., the software that accepts IPPFAX requests and returns IPPFAX
responses, everywhere in the UIF spec? Ira felt that using "Sender" and
"Receiver" is too vague and that IPP Printer means the software entity, not
necessarily the hardware, in IPP, so why not continue this precedence in
IPPFAX.
* Resolution: Leave for a larger group to decide.
'uif-spec-04.doc' issues:
* ISSUE B: Should we use the MIME media type: 'image/tiff;
application=faxbw' to indicate support for monochrome and both values
'image/tiff; application=faxbw', image/tiff; application=faxcolor' to
indicate support for both monochrome AND color?
* Resolution: It seems like there is consensus on doing so.
If the value of the "uif-profiles-supported" Printer Description attribute
is one of the profiles, this would indicate support for the heightened
requirements of the UIF spec (vs. TIFF-FX) .
* ISSUE C: Change "uif-scale" attribute name to "uif-reduce"?
* Resolution: Group agreed it is not good practice to scale
up, as the image quality is degraded, so a 'true' value reduces the image,
if necessary, but MUST NOT increase the image size. A 'false' value MUST
tile the image on as many sheets as necessary to preserve all parts of the
image, including the side and bottom, if necessary. Re-iterate that the
aspect ratio MUST be preserved (reject related change in section 4.1 of UIF
spec). We also agreed that reducing or increasing by 2% (the A versus A4
factor) would not be considered scaling, as long as the aspect ratio is
maintained.
* ISSUE D: (Lloyd) We should clarify the "uif-scale" (now to
be called "uif-reduce") attribute to reflect proper "default" behavior
(i.e., a printer MUST NOT apply scaling unless the client explicitly allowed
it).
* Resolution: There was consensus that the printer MUST be
configurable to allow reducing to occur by default AND that the Sender MUST
query the "uif-reduce" Printer Description attribute and warn the user so
that the user never gets reduction without a warning before sending the
document and a chance to indicate that no reduction is to take place.
* ISSUE E: Should the "ImageWidth" and "ImageLength" TIFF tags
choose the media size? If not, then how should we choose paper sizes in the
middle of a job (e.g., pages 1-75 are Size A and page 76 is Size B)? TIFF
(unlike Postscript or other PDLs) does not have a means of indicating media.
Relegate media selection to IPP page-level overrides?
* Resolution: We agreed that for now, the TIFF "ImageWidth"
and "ImageLength" tags do NOT select the media, but that the IPPFAX "media"
Job Template attribute does. This decision works fine for documents where
the image size is the same for all pages in the document. For documents
that have differing image sizes within the same document, we'll wait for a
future requirement/extension to see whether to add another Job Template
attribute so that the client can request that the TIFF image tags be used to
select media (or not). We also agreed NOT to bring in the IPP
"page-overrides" attribute to allow the protocol to select media on a page
by page basis (though an IPP Printer implementation might support such a
thing).
* ISSUE F: Rename "uif-conneg" IPP attribute to
"uif-receiver-capabilities"?
* Resolution: There was consensus that we should.
* ISSUE G: It is not clear to me whether or not variable
drawing surfaces are supported by TIFF-FX. For example can I say that I
support 2000x3000 pixels? We have definitely agreed that we need to be able
to do this as well as to include the TIFF-FX defined, named set of drawing
surfaces. It is not supported by TIFF-FX and we need to create a profile
that does support it. Profile U was added to this document, but we need to
confirm with Lloyd if this is the best way to proceed.
* Resolution: Still need to discuss with Lloyd.
white paper issues:
* ISSUE01: Or is it so easy for a Receiver to support the
"uif-conneg" Printer attribute (its just a canned constant string) that the
UIF spec should REQUIRE an IPP FAX Receiver to support the "uif-conneg"
Printer attribute?
* Resolution: Receiver support of "uif-conneg" (to be renamed
"uif-receiver-capabilities") is already mandatory. Make note in UIF spec
that any well-formed CONNEG string (rather than just the canonical form) is
acceptable.
* ISSUE02: Should the UIF spec be made independent of IPP FAX
by moving the discussion about an IPP attributes to the IFX spec? Then UIF
could be used with any protocol.
* Resolution: There was consensus that the UIF spec should be
made independent of IPP FAX by moving the discussion about IPP attributes to
the IFX spec so that UIF can be used with any protocol. The UIF should still
include a description of how the capabilities discovery should take place
(only the details on IPP attributes and its specific usage will be moved to
an Appendix of the IFX spec).
* Now the IPPFAX document will include two levels of
conformance: 'uif-only' and 'authenticated'. The level being used needs to
be reflected in a Printer Description attribute, and we should allow for
more than just levels in the future. So change "ippfax-receiver" (integer)
to "ippfax-receiver" (1setOf type2 keyword) with values 'none', 'uif-only',
and 'authenticated'.
* ISSUE03: Should IPPFAX use the Media Size Self Describing
Names from the PWG Media Standardized Names standard somehow?
* Resolution: There was consensus that IPP-Fax SHALL require
EXCLUSIVE support for Media Size Self Describing Names from the PWG Media
Standardized Names standard for the keyword values of the "media" attribute.
Then all "media" keyword values will contain the explicit dimensions as well
as the name.
* ISSUE04: Moot.
* ISSUES 05-10: Resolution requirements for the B&W UIF
profiles.
* Resolution: There was consensus on the following:
Support for the following XResolution values SHALL be
mandatory for Profiles S, F, and J: 200, 300, 600
Support for the following YResolution values SHALL be
mandatory for Profiles S, F, and J: 200, 300, 600.
* ISSUES 11-12: Resolution requirements for the color UIF
profiles
* Resolution: There was consensus on the following:
Support for the following XResolution values SHALL be
mandatory for Profiles C and L: 200, 300
Support for the following YResolution values SHALL be
mandatory for Profiles C and L: 200, 300
* ISSUE 13-14: Resolution requirements for the UIF Profile
M binary mask layer
* Resolution: There was consensus for the following:
For the binary mask layer, support for XResolution = 200,
300 and YResolution = 200, 300 SHALL be required. All other mask layer
XResolution and YResolution values are optional.
* ISSUE 15: Resolution requirements for the UIF Profile M
foreground and background layers.
* Resolution: There was consensus for the following:
For the foreground and background layers, support for the
following XResolution values SHALL be mandatory for Profile M: 200, 300
For the foreground and background layers, support for the
following YResolution values SHALL be mandatory for Profile M: 200, 300
* ISSUE L1: There was consensus for changing the default
coding method for Profile F to MMR. The image-coding values shown in the
CONNEG strings for each profile should be changed to reflect this.
* ISSUE L2: There was consensus for changing the default color
space for Profile C to 'full' (instead of 'gray'). The 'color' tag values
shown in the Profile C default Conneg string should be changed to reflect
this.
* ISSUE TH: The term "default conneg" is a different meaning
for "default", than used in IPP. In IPP, "default" means what the Printer
does if the client doesn't supply some attribute. The "default conneg" is
what the implementation MUST support for a given profile if the implementer
doesn't choose do to more.
Resolution: Agreed that we need a new term to describe the
CONNEG Strings that an implementation MUST support for each profile that it
supports. John and Tom to come up with a new term. Possibilities include:
"Basic" or "Required" or "Minimum". Suggestions welcome.
This archive was generated by hypermail 2b29 : Fri Jun 01 2001 - 17:45:48 EDT