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