IFX Mail Archive: IFX> IPPFAX/1.0 Section 20 (Appendix A)

IFX> IPPFAX/1.0 Section 20 (Appendix A)

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Fri Jan 11 2002 - 12:56:28 EST

  • Next message: Harry Lewis: "IFX> TIFF-FX viability"

    All,
    Since Tom's PC is currently being upgraded I am sending this out on his
    behalf.
    Pete

    Here is the new Section 20 (Appendix A) comparing IPP and IPPFAX
    as suggested at the telecon. I was surprised at how many
    differences there are, so there may be some discussion as to how
    to remove some of them. I've indicated the differences that
    require conditional code with ** in order to support both IPP
    and IPPFAX in a singe implementation (requiring separate IPP and
    IPPFAX print objects). A number of differences can be handled
    without conditional code, if the IPP protocol implementation
    part doesn't support the IPP OPTIONs that IPPFAX forbids. These
    are indicated by *. Differences without any asterisks can be
    handled without conditional code, if the IPP Printer
    implementation supports the indicated IPPFAX features as part of
    IPP as well.

    Appendix A: Comparison of IPP/1.1 and IPPFAX/1.0
    (Informative)
    This informative appendix compares IPP/1.1 and IPPFAX/1.0 with
    references to the appropriate sections for details. If this
    appendix contradicts or omits any differences, it is a mistake
    and the body of this document still prevails. Most of the
    differences are in conformance requirements only. Therefore,
    for most of the differences, it is possible to implement both
    with the same code (without conditional branches).

    Legend:

    ** Where IPP/1.1 is a must and IPPFAX/1.0 is a MUST NOT
    (indicated below by leading **), would a conditional branch
    be needed in the implementation code in order to support
    both IPP/1.1 and IPPFAX/1.0.

    * Where IPP/1.1 is a may and IPPFAX/1.0 is a MUST NOT
    (indicated below by a leading *), would a conditional
    branch be needed in the implementation code in order to
    support both IPP/1.1 and IPPFAX/1.0, but only if the
    IPP/1.1 part supports the feature.

    Differences between the IPP/1.1 protocol and the IPPFAX/1.0
    protocol:

    1. ** IPP uses the 'ipp' URL scheme with a default port of
    631, while IPPFAX uses the 'ippfax' URL scheme with a
    default port of xxx [TBA by IANA] (section 4.1 and 16).

    2. ** IPP has only one version number parameter, while IPPFAX
    has two version numbers: the "version-number" parameter
    (section 4.2) and the "ippfax-version-number" operation
    attribute (section 4.3).

    Differences between an IPP client and a Sender:

    1. An IPP Client may use any IPP operation, while a Sender
    MUST use at least Get-Printer-Attributes (sections 5 and
    7.1), Validate-Job (section 7.2), and Print-Job operations
    (section 9). A Sender MUST use the Get-Notifications
    operation, unless the Sending User has explicitly indicated
    otherwise (section 9.6).

    2. In the Get-Printer-Attributes request, an IPP Client may
    supply the "document-format" and "uif-profile-requested"
    operation attributes, while a Sender SHOULD (sections 5.1
    and 5.2).

    3. ** In the Job Creation operations and the Validate-Job
    operation, an IPP Client may supply the "ipp-attribute-
    fidelity" operation attribute with either the 'true' or
    'false' value or may omit the attribute entirely, while the
    Sender MUST always supply the attribute and with the 'true'
    value (sections 7.2 and 9.1.1).

    4. In the Job Creation operations and the Validate-Job
    operation, an IPP Client may supply the "document-format"
    operation attribute, while the Sender MUST supply it
    (section 9.1.2).

    5. * An IPP Client may support any MIME Media Type as the
    value of the "document-format" operation attribute, while
    the Sender MUST support at least the 'image/tiff' MIME
    Media Type, MAY support the 'image/tiff-fx' MIME Media
    Type, and MUST NOT support any MIME Media Type unless it
    has the same "blind interchange" guarantee of document
    presentation fidelity as TIFF-FX [tiff-fx] (section 6.6).

    6. In the Job Creation operations and the Validate-Job
    operation, an IPP Client may supply the "media" Job
    Template attribute, while the Sender MUST supply it
    (section 9.2.1).

    7. * An IPP Client may supply any keyword listed in [RFC2911]
    section 14 (Appendix C) for the "media" Job Template
    attribute or the Media Size Self Describing Name keyword
    values defined in the IEEE-ISTO 5101.1 "Media Standardized
    Names" [pwg-media], while the Sender MUST use the keyword
    values from [pwg-media] (section 9.2.1).

    8. There are no requirements for an IPP Client to indicate the
    client or the client user in the document, while the Sender
    MUST supply the "sender-uri" value along with a date and
    time, on at least the cover page (section 9.5).

    9. An IPP Client need not support Event Notification, while
    the Sender MUST support at least the 'ippget' Pull Delivery
    Method (section 9.3), which REQUIRES using the Get-
    Notifications operation (section 9.6).

    10. An IPP Client may support any events, while a Sender
    MUST NOT support the 'job-config-changed' and any Printer
    events (section 9.3.2).

    11. An IPP Client may support Client Authentication, while
    a Sender MUST support at least 'digest' and 'certificate'
    (section 11.2).

    12. An IPP Client may support Data Integrity and Data
    Privacy, while a Sender MUST support with at least the 128-
    bit TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite (section
    11.2).

    Differences between an IPP Printer and a Receiver:

    1. In the Get-Printer-Attributes response, an IPP Printer may
    color the attribute values returned according to the
    "document-format" supplied, while a Receiver MUST color the
    values returned according to both the "document-format" and
    "uif-profile-requested" operation attributes supplied
    (sections 5 and 6), including the "printer-resolutions-
    supported" attribute (section 9.2.2.1).

    2. * An IPP Printer is not required to support any particular
    document formats, while a Receiver MUST support the UIF
    'image/tiff' format with profile uif-s, MAY support
    'image/tiff-fx', and MUST NOT support any others, unless
    they have the same level of "blind interchange" guarantee
    for document presentation fidelity as TIFF-FX (section 6.6)
    .

    3. * An IPP Printer may support 'application/octet-stream'
    (auto-sensing - [RFC2911] 4.1.9.1), while a Receiver MUST
    NOT (section 6.6).

    4. An IPP Printer may support the IPPFAX attributes: "uif-
    profile-requested", "uif-profiles-supported", "uif-profile-
    capabilities", "auto-notify", "sending-user-vcard",
    "receiving-user-vcard", "sender-uri", and "uif-profiles",
    while a Receiver MUST (sections 5.2, 6, 8, and 9.1.3).

    5. ** An IPP Printer MUST NOT support the "ippfax-versions"
    and "ippfax-versions-supported" attributes, while a
    Receiver MUST (sections 4.3 and 6.3).

    6. ** An IPP Printer must support both values of the "ipp-
    attribute-fidelity" operation attribute, while the Receiver
    MUST support only the 'true' value (section 9.1.1).

    7. ** An IPP Printer must assume a value of 'false' if the IPP
    Client omits the "ipp-attribute-fidelity" operation
    attribute, while the Receiver MUST reject the request with
    the 'client-error-bad-request' status code (section 9.1.1).

    8. An IPP Printer is not required to support any particular
    Job Template attributes, while a Receiver MUST support at
    least the "media" and "printer-resolution" Job Template
    attributes, including the "media-ready" Printer attribute
    (section 9.2).

    9. * An IPP Printer may supply any keyword listed in [RFC2911]
    section 14 (Appendix C) for the "media" Job Template
    attribute or the Media Size Self Describing Name keyword
    values defined in the IEEE-ISTO 5101.1 "Media Standardized
    Names" [pwg-media], while the Receiver MUST support a
    subset of the keyword values from [pwg-media] (section
    9.2.1).

    10. * An IPP Printer may support any Job Template
    attribute values, while a Receiver is restricted to a
    single value for many Job Template attributes that would
    alter the appearance of the document or provide a non-FAX-
    like feature (section 9.2).

    11. * An IPP Printer may support Print-URI and Send-URI
    operations, while a Receiver MUST NOT (section 10.1).

    12. An IPP Printer must support Get-Jobs and Get-Job-
    Attributes operations, while a Receiver NEED NOT (section
    10.1).

    13. ** An IPP Printer must support Cancel-Job operation,
    while a Receiver MUST NOT (section 10.2).

    14. An IPP Printer may support administrative operations
    without authentication, while a Receiver MUST authenticate
    administrative operations, if they are supported (section
    10.1).

    15. * An IPP Printer may support the following operations
    from an authenticated operator or administrator: Print-Job,
    Print-URI, Validate-Job, Create-Job, Purge-Jobs, Cancel-
    Current-Job, Send-Document, Send-URI, Cancel-Job, Cancel-
    Subscription, and Schedule-Job-After, while a Receiver MUST
    reject such operations from an authenticated operator or
    administrator.

    16. An IPP Printer may support Event Notification, while a
    Receiver MUST support Event Notification (sections 9.3 and
    10.1) and at least the 'ippget' Delivery Method (section
    9.6), which REQUIRES support for the Get-Notifications
    operation.

    17. If an IPP Printer supports Event Notification, it must
    support the 'job-state-changed' and 'job-created' events
    for Per-Job Subscriptions, while a Receiver NEED NOT
    (section 9.3.2).

    18. ** If an IPP Printer supports Printer Events, then it
    MUST support them for both Per-Job and Per-Printer
    Subscriptions, while a Receiver MUST NOT support them for
    Per-Job Subscriptions (section 9.3.2).

    19. If an IPP Printer supports Event Notification, it may
    support the 'job-progress' event, while a Receiver MUST for
    Per-Job Subscriptions (section 9.3.2).

    20. * If an IPP Printer supports Event Notification, it
    may support the 'job-config-changed' event, while a
    Receiver MUST NOT (section 9.3.2).

    21. If an IPP Printer supports the Set-Printer-Attributes
    operation, then it may support setting the Attribute
    Coloring values according to the "document-format"
    operation attribute, while the Receiver, if it supports the
    Set-Printer-Attributes operation, MUST support setting the
    Attribute Coloring values according to the "document-
    format" and "uif-profile-requested" operation attributes
    (section 10.5).

    22. An IPP Printer should support and may use TLS, while a
    Receiver MUST support and MUST use TLS (section 11.3).

    23. An IPP Printer may support Client Authentication,
    while a Receiver MUST support at least 'digest' and
    'certificate' (section 11.2).

    24. An IPP Printer may support Data Integrity and Data
    Privacy and support them with any cipher suite, while a
    Receiver MUST support both Data Integrity and Data Privacy
    with at least the 128-bit TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    cipher suite (section 11.2).

    If you have any comments about these differences, please send
    them to the mailing list.

    Thanks,
    Tom

                                    Peter Zehler
                                    XEROX
                                    Xerox Architecture Center
                                    Email: PZehler@crt.xerox.com
                                    Voice: (716) 265-8755
                                    FAX: (716) 265-8871
                                    US Mail: Peter Zehler
                                            Xerox Corp.
                                            800 Phillips Rd.
                                            M/S 128-30E
                                            Webster NY, 14580-9701



    This archive was generated by hypermail 2b29 : Fri Jan 11 2002 - 12:57:03 EST