IFX Mail Archive: IFX> IPPFAX Protocol spec D0.8 posted for

IFX Mail Archive: IFX> IPPFAX Protocol spec D0.8 posted for

IFX> IPPFAX Protocol spec D0.8 posted for Fri, 12/14, 9-11AM PST (12-2 EST) telecon

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Dec 11 2001 - 19:08:57 EST

  • Next message: Hastings, Tom N: "IFX> RE: Receiver Requirements for Certificate"

    I've down loaded the IPPFAX protocol spec version 0.8 for the Friday
    December 14 telecon. This version has the agreements reached at the IPPFAX
    WG meeting in San Antonio, October 24. See the minutes. The version
    without revisions is 56 pages (one longer than the previous version). The
    files are:


    The telecon details are:

    Friday, December 14, 9-11 AM PDT (12-2 PM EDT)
    Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970

    The agenda for the telecon will be:

    1. The 5 issues embedded in the document (excerpted below).

    2. Also the minutes of the IPP WG meeting indicate that we didn't finish the
    security section.

    3. Review each of the tables which have conformance requirements for each
    attribute and operation. Certain entries that need special attention are
    highlighted (yellow on the screen and color printers, gray on black and
    white printers).

    4. Any issues that attendees raise or have been raised on the mailing list.

    You should all read the entire document, since I think it is pretty close to
    finished, except for any issues that your careful review would raise.
    Please send any comments to the DL before the telecon, especially, if you
    cannot make the telecon.

    The 5 issues are:

    1a. 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
                    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
                    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
           ippfax-uif-profiles (1setOf type2 keyword) Job
    Creation operation attribute

    1b. 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)?

    1c. Page 27, Table 7:
    Repeat of ISSUE 01

    1d. 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).

    1e. 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.

    1f. 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.

    1g. 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?


    This archive was generated by hypermail 2b29 : Tue Dec 11 2001 - 19:09:12 EST