IFX Mail Archive: IFX> IPPFAX notes from Fri, 12/14, 9-11AM

IFX Mail Archive: IFX> IPPFAX notes from Fri, 12/14, 9-11AM

IFX> IPPFAX notes from Fri, 12/14, 9-11AM PST (12-2 EST) telecon

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Dec 19 2001 - 20:44:26 EST

  • Next message: Hastings, Tom N: "IFX> MOD - Should "operations-supported" values depend on the authenti cated role of the user?"

    Attendees: Ira McDonald, Gail Songer, Marty Joel, John Pulera, Tom Hastings

    I'm sending this to the IPP DL as well, since the agreements include some of
    the important relationships between IPP and IPPFAX.

    We reviewed the 5 issues in the IPPFAX Protocol spec
    (ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.pdf)
    and came to the following agreements. Any comments on these agreements
    should be sent to the mailing list:

    1. Page 8, section 1.3 Namespaces Used:
    ISSUE 01: Why can't all of the "ippfax-xxx" attributes defined in this
    document be supported OPTIONALLY by an IPP Printer as IPP extensions to the
    IPP Protocol as well? This would allow IPP to support UIF document format
    and profiles, along with vCard, and provide a simple way for an anonymous
    user mode. If so, shouldn't we remove the "ippfax-" prefix from all these
    attributes in this document, since they wouldn't be restricted to IPPFAX?
    From the TOC, these attributes are:

      4.2 ippfax-uif-profile-requested (type2 keyword) operation attribute
      5.6 ippfax-uif-profiles-supported (1setOf type2 keyword) Printer
    Description attribute
      5.7 ippfax-uif-profile-capabilities (1setOf text(MAX)) Printer Description
    attribute
      5.8 ippfax-auto-notify (boolean) Printer Description attribute
      6.1 ippfax-sending-user-vcard (text(MAX)) operation/Job Description
    attribute
      6.2 ippfax-receiving-user-vcard (text(MAX)) operation/Job Description
    attribute
      6.3 ippfax-sender-uri (uri) operation/Job Description attribute
      7.2.1.2 ippfax-uif-profiles (1setOf type2 keyword) Job Creation operation
    attribute

    AGREED> That all of these IPPFAX attributes will have the "ippfax-" prefix
    removed and the spec clarified that these attributes MAY also be supported
    by an IPP Printer as OPTIONAL IPP extensions. Using IPP will be the way
    that a Printer can support UIF without having to use TLS.

    2. Page 18, section 6.2 ipp-versions-supported:
    ISSUE 02: OK that the IPP/1.1 "version-number" parameter that contains the
    IPPFAX version number is compared with the (existing) IPP/1.1
    "ipp-versions-supported" Printer Description attributes that contains the
    IPPFAX version number (rather than defining a new
    "ippfax-versions-supported" Printer Description attribute and not using the
    "ipp-versions-supported" attribute)?

    AGREED> We need both of the "ipp-versions-supported" and
    "ippfax-versions-supported" Printer Description attributes, since IPPFAX/1.0
    might use IPP/1.1 or a future IPP/1.2 or IPP/2.0, and/or IPPFAX/1.2 might
    use IPP/1.1, etc. Then the client can validate that the Printer is a
    Receiver by simply checking for the "ippfax-versions-supported", rather than
    the more complicated examination of the values of the
    "printer-uri-supported" and doing a URL comparison (which is complicated,
    including port numbers, case conversion, etc.)

    We didn't discuss whether to reinstate the ippfax-version-number (type2
    keyword) Operation attribute or to overload the "version-number" parameter
    to be for IPP or IPPFAX depending on the URL. However, using the same
    reasoning that it is important to know which versions of IPP a Receiver
    supports for the IPPFAX protocol, it is important to know which version of
    IPP the client is using for its IPPFAX request. Therefore, we should go
    back to the "ippfax-version-number" Operation attribute as in Draft D7.
    Then the presence of the "ippfax-version-number" in the request indicates
    that it is IPPFAX, not IPP.

    The Print Service uses its existing IPP code for validating the IPP version
    number and then uses additional code to validate the IPPFAX version number.

    Then the Print System can determine that the request is IPPFAX, not IPP, by
    looking for the "ippfax-version-number" operation attribute, instead of
    examining the "printer-uri" operation attribute. This means that the
    validation of an IPPFAX request by the Printer is the same as for IPP (since
    RFC 2911 doesn't require that the Printer validate the "printer-uri"
    operation attribute).

    If there are any objections to reinstating the "ippfax-version-number"
    operation attribute to go along with the "ippfax-versions-supported" Printer
    Description attribute, please send comment to the email list.

    3. Page 27, Table 7:
    Repeat of ISSUE 01

    AGREED> We would make all the columns that show RFC 2911 conformance be
    lower case, to clarify that those words are NOT re-stating the conformance
    for an IPP Printer. Also the "ippfax-" attributes that are being changed to
    remove the "ippfax-" prefix, will become "may" for the "IPP/1.1 Printer
    supports" column.

    4. Page 29, Section 9.2, Job Template Attributes, Table 8:
    ISSUE 03: The Sender supply and the Receiver support columns have a lot of
    "MUST NOT". Instead of not allowing these attributes at all, how about a
    MAY but restricted to the obvious default values, i.e., "number-up"=1,
    "job-priority"=50, "insert-sheet"='none', x-image-shift=0, etc. Otherwise,
    there is some interworking problems with a client or forwarding Printers
    that supports both IPP and IPPFAX and supplies these attributes with their
    obvious default values (instead of omitted them).

    AGREED> We agreed that the "MUST NOT" Job Template attributes MAY be
    supported, but only with the single obvious value that will be in the IPPFAX
    spec.

    5. Page 40, section 11.2 uri-authentication-supported, Table 13:
    ISSUE 04: We agreed at the October meeting to make 'none' be "MAY support
    and MAY use" for a Receiver. However, a better way to get public access, is
    to use IPP with UIF and vCard exchange. See ISSUE 01 which suggests that
    IPPFAX attributes be OPTIONAL IPP attributes as well. Then 'none' could go
    back to MUST NOT.

    AGREED> We agreed that when the Printer uses TLS, it is OK for the Printer
    to be configured to support the 'none' for Client Authentication, so Table
    13 'none' row stays as "MAY support and MAY use", but Table 15 'none' should
    be changed from MAY to MUST NOT.

    FUTURE> We discussed that there is a need to add a 'kerberos' keyword for
    use in IPP and IPPFAX in the "uri-security-supported" attribute (Table 15,
    not Table 13). There are systems that use Kerberos, instead of TLS, for a
    security protocol. That should be done for both IPP and IPPFAX separately
    from the IPPFAX spec.

    6. Page 42, section 11.4 Using IPPFAX with TLS:
    ISSUE 05: OK that we deleted the "ippfax-sending-user-certificate-uri (uri)
    operation/Job Description attribute? The client MUST pass the certificate,
    whether by value or by reference in the TLS record layer.

    AGREED> Yes, unless the Printer supports the 'none' for Client
    Authentication, in which case the client doesn't pass a certificate at all.

    7. Page 42, section 11.5 Access Control:
    ISSUE 04 (repeated): Why not use IPP, instead of IPPFAX for anonymous user
    access, if we agree to allow all IPPFAX attributes as OPTIONAL extensions to
    IPP as well?

    AGREED> The "public mode" in section 11.5, probably means on the Internet
    without the client needing a certificate. So our agreement to allow 'none'
    in Table 13 for Client Authentication ("uri-authentication-supported")
    allows this so-called "public mode".

    8. Other agreements

    a. Clarify that this version of the spec is for IPPFAX/1.0, not just IPPFAX.

    b. We'll add an informative appendix that lists any differences from IPP to
    help implementers that are supporting both. The differences are mainly
    changes in conformance requirements.

    c. Section 11.1 Privacy, 2nd paragraph, change:

    The Receiver MAY have a TLS certificate.

    to:

    The Receiver MUST have a TLS certificate.

    d. In the tables which say NEED NOT, should say MAY, which means the same
    thing and is shorter and less confusing.

    Send any comments to the mailing lists.

    I'll produce an updated version the beginning of the new year.

    Tom



    This archive was generated by hypermail 2b29 : Wed Dec 19 2001 - 20:44:46 EST