IFX Mail Archive: IFX> Notes from IPP FAX telecon, Wed May 3

IFX Mail Archive: IFX> Notes from IPP FAX telecon, Wed May 3

IFX> Notes from IPP FAX telecon, Wed May 30 and AGENDA for Wed June 6 telecon

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jun 01 2001 - 17:45:20 EDT

  • Next message: Stuart Rowley: "RE: IFX> default conneg & more detailed UIF profile summary"

    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