IPP Mail Archive: RE: IPP> DRV - What is the relation of Pri

IPP Mail Archive: RE: IPP> DRV - What is the relation of Pri

RE: IPP> DRV - What is the relation of Printer Installation Exten sion and IPP/1.1 printer-driver-installer (uri) Printer attribute?

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Mar 06 2001 - 20:47:03 EST

  • Next message: McDonald, Ira: "RE: IPP> REQ - Input for IPP discussion in PWG [Does IPP meet its goals document?]"

    Hi Tom,

    I'll throw a stone in church here (...grin...) and suggest
    that there is NO relationship between IPP/1.1 attribute
    (which has completely ambiguous semantics) and the well-formed
    IPP Printer Install extension. I believe we should be silent
    on this issue, because I believe the IPP/1.1 opaque attribute
    was a _mistake_.

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, March 06, 2001 4:25 PM
    To: ipp (E-mail)
    Subject: IPP> DRV - What is the relation of Printer Installation
    Extension and IPP/1.1 printer-driver-installer (uri) Printer attribute?

    Here is the definition of the IPP/1.1 "printer-driver-installer" Printer
    Description attribute:
    4.4.8 printer-driver-installer (uri)
    This Printer attribute contains a URI to use to locate the driver installer
    for this Printer object. This attribute is intended for consumption by
    automata. The mechanics of print driver installation is outside the scope
    of this IPP/1.1 document. The device manufacturer may initially populate
    this attribute.

    Should the Printer Installation Extension document mention this attribute
    and the relationship between them, what ever it is?

    Thanks,
    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Saturday, March 03, 2001 10:19
    To: ipp (E-mail)
    Subject: IPP> DRV - IPP Printer Installation Extension document
    down-loaded

    Hugo, Ira, Bob, and I have collaborated on a number of clarifications and a
    few changes to the Internet Printing Protocol (IPP): Printer Installation
    Extension document. It has been submitted as an Internet-Draft on March 1.
    These clarification and changes should be discussed at the upcoming meeting
    and on the mailing list. The biggest change was to add digital signatures
    for improved security, especially when down loaded executable code. The
    Printer SHOULD support at least one digital signature method. We think that
    this version is ready for IPP WG Last Call. It would be good to see if
    others agree.

    The files are in the .zip file for the agenda and in their usual places:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-02-010228-rev.p
    df
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-02-010228-rev.d
    oc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-02-010228.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-02-010228.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-02.txt

    Here is the Abstract:

            Various client platforms require that some setting up take place at
    the workstation before the client can properly submit jobs to a specific
    printer. This setup process is sometimes referred to as printer
    installation. Most clients need some information about the printer being
    installed as well as support files to complete the printer installation.
    The nature of the support files varies depending on the specific client
    platform, from simple configuration files to highly sophisticated printer
    drivers. This document refers to these support files as "Client Print
    Support Files". Traditionally, the selection and installation of the
    correct Client Print Support Files has been error prone. The selection and
    installation process can be simplified and even automated if the workstation
    can learn some key information about the printer and which sets of Client
    Print Support Files are available. Such key information includes: operating
    system type, CPU type, document-format (PDL), natural language, compression
    mechanism, file type, client file name, policy for automatic loading, file
    size, file version, file date and time, file information description, and
    digital signature. This document describes the IPP extensions that enable
    workstations to obtain the information needed to perform a proper printer
    driver installation using IPP, including security for downloading executable
    code and data.

    Change History for Internet Printing Protocol (IPP): Printer Installation
    Extension
    Changes made to the November 7, 2000 version to create the February 28, 2001
    version:
            1. Listed all of the fields in the Abstract and Introduction
    and mentioned security for down-loading code.
            2. Explained that "Printer", "IPP Printer", and "Printer
    object" are interchangeable terms, as in the Model and Semantics (RFC 2911)
    for the software abstraction that accepts IPP operation requests and returns
    IPP operation responses.
            3. "uri" field: Clarified that when the "uri" field contains an
    'ipp' scheme, the URI MUST be a valid URI for the same Printer, i.e., one of
    the values of the Printer's "printer-uri-supported" attribute.
            4. "uri" field: Required that when the "uri" field contains an
    'ipp' scheme, the URI MUST use the query syntax (starts with "?") to
    distinguish among Printer Support Files and the query part MUST NOT exceed
    127 octets.
            5. "os-field" field: added 'unknown' special keyword value.
            6. Changed the "file-name" field name to "client-file-name" to
    clarify that the value is the name that will be used on the client, not the
    file name on the Printer.
            7. "policy" field: changed it from REQUIRED to OPTIONAL and
    removed the 'unknown' value. If the policy is unknown, the field is not
    supplied.
            8. Added the OPTIONAL "file-info" (text(127)) field to give a
    human readable text string to describe each set of Printer Install Files.
            9. Added the REQUIRED "digital-signature" field to describe the
    digital signature used. Valid keyword values are: 'smime', 'pgp', 'dss',
    and 'xmldsig' which are defined in [RFC2634], [RFC1991], [dss], and
    [xmldsig], respectively. In addition, the special keyword value: 'none' is
    valid.
            10. RECOMMENDED that the 'unknown' special keyword value not be
    used when a more meaningful value is possible.
            11. Clarified the Filter matching rules.
            12. REQUIRED the client to use the authentication and security
    policy associated with the Printer URI in the "uri" field, which NEED NOT be
    the same as the one that the client used in the Get-Printer-Attributes
    operation.
            13. Changed the "client-print-support-files-uri" (uri) operation
    attribute to "client-print-support-files-query" (text(127)) where the text
    is only the query part of the "uri" field after the "?" character. This
    change eliminates the possibility that the client supplies an incorrect URI
    (including one to another IPP Printer) and the requirement that the Printer
    check for such an error.
            14. Printer conformance: Added that the Printer SHOULD support
    TLS.
            15. Printer conformance: Added that the Printer SHOULD support
    digitally signed Client Print Support Files.
            16. Client conformance: Added that the client MUST supply the
    proper URI for the "printer-uri" that was returned in the "uri" field.
            17. Client conformance: MUST validate that files that are
    supposed to be digitally signed are done with the indicated mechanism
    indicated in the "digitally-signed" field.
            18. Client conformance: SHOULD support TLS.
            19. Indicated explicitly what IANA will register as the AD has
    requested on previous documents.
            20. Section 9, Security Considerations: Added digitally signed
    mechanism including: 'smime', 'pgp', 'dss', and 'xmldsig' which are defined
    in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively.



    This archive was generated by hypermail 2b29 : Tue Mar 06 2001 - 20:58:38 EST