To the Free Standards Organization, printing-driver WG:
cc: IPP WG
The IPP web page on the PWG (Printer Working Group) server is:
http://www.pwg.org/ipp/index.html
The IPP WG has developed an IPP extension to allow a client to query a
printer with a simple filter to determine what Print Support Files it might
want to download from the Printer, including an executable driver.
The down load spec is available from the PWG IPP FTP server at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-04-010717.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-04-010717.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp-install-04-010717.txt
Here is the Abstract:
This document describes an OPTIONAL extension to the Internet
Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911,
RFC2910]. 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 these "Client Print Support Files" varies depending on the
specific client platform, from simple configuration files to highly
sophisticated printer drivers. 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.
What does the FSG printing-driver WG think about this specification?
Comments can be sent to the IPP mailing list with "DRV - " as the first five
characters of the email message subject line:
ipp@pwg.org
(To the IPP WG, the Free Standards Organization has a web site:
http://www.freestandards.org
and a secret page to join any of the 5 printing-xxx WGs at:
http://www.freestandards.org/mailman/listinfo)
The IPP WG has submitted this document to the IETF IESG following the normal
IETF procedures to make it an RFC. However, Ned Fried, the IPP WG's IETF
Area Directory, has raised some significant issues around security. This is
understandable, since IETF standards are for the Internet, not an Intranet.
However, driver down load is very useful on an intranet. There has not been
a lot of support for enhancing this extension to meet the Area Director's
objections in order to make this extension work over the Internet. One
suggestion has been to make the document into a Printer Working Group (PWG)
standard through the IEEE-ISTO, as has been done with four other IPP WG
extensions. As a PWG standard, we can talk about both intranets and the
internet in the specification and write conformance requirements separately
for each.
Should the FSG work with the PWG to come up with a joint FSG/PWG standard
somehow? There is a PWG meeting in Portland OR, June 24-28. Thursday, June
27, is the full day plenary, where they will be discussing all of the PWG
projects in general and which new ones to start. So input on driver
down-load would be useful.
Here are the Area Director's comments on the Internet-Draft:
-----Original Message-----
From: Carl [mailto:carl@manros.com]
Sent: Thursday, April 18, 2002 11:46
To: ipp@pwg.org
Subject: IPP> [from Ned.Freed] IESG review of
draft-ietf-ipp-install-04.txt
Forwarded message from Ned Freed.
Carl-Uno
-----Original Message-----
From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
Sent: Thursday, April 18, 2002 11:01 AM
To: ned.freed@mrochek.com
Cc: ipp@pwg.org; carlmanros@hotmail.com; Carl; ned.freed@mrochek.com;
paf@cisco.com
Subject: IESG review of draft-ietf-ipp-install-04.txt
The security mechanisms described are wrong. Digital signatures support
should be mandatory, with use (as always) optional. The definition of how
to
sign files is inadequate. Probably, what's needed is Secure Multipart,
with
any supported signature algorithm, but that needs to be spelled out much
more
clearly -- the IESG doesn't think that this document gives enough
information
to build interoperable implementations. Files that are digitally signed
need
not be protected during transmission by TLS. But the query function that
returns the client-print-support-files-supported attribute value MUST be
TLS-protected, or the client can't reliably retrieve the security
indicator.
That is, an attacker could spoof that response, and delete the attribute,
thereby telling the client not to expect something secure. Going a step
further, that whole security model is wrong. The client is the one being
exposed to the risk of installing bad code; therefore, it's up to the
*client*
to demand security. The IESG would prefer a situation where the returned
files were self-identifying as to security status (i.e., the same as
email),
and the client makes the decision about whether or not to install the
fiels,
depending on the security status, the signature, the certificate chain (if
any), and the client's security policy. That in turn suggests new filter
attributes, to define what signature formats and algorithms are acceptable
to
the client.
Various acrynyms in the abstract need to be expanded in accordance
with the new RFC Editor policies in this area.
The first paragraph of the introduction talks about this being a
notification extension, not a printer installation extension.
"NEED NOT" is not defined in 2119.
Section 2 talks about using terms from RFC 2911 twice, with two
different lists of terms that it uses.
The end of the first sentence in section 3 is "location\s" - it's
not clear what the backslash is meant to mean.
Section 3.1, talking about the encoding: what if you need a "<" or
a "," in a field name or value? (Presumably only in a value, it's
fair to say that the field names are easy enough to restrict).
The last line of page 8 is duplicated as the first line of page 9,
and the last line of page 10 is duplicated as the first line of
page 11.
The reason described for creating a new cpu-type registry in this
document is that the bit size of a processor needs to be included;
however, e.g. sparc is just represented by "sparc", not "sparc32"
or "sparc64". Is x86 really the only architecture that needs the
bit size?
There's a missing close-quote on m-68000 in the cpu-type field values
at the top of page 9.
Neither "file-type" nor "digital-signature" registries are described
in the IANA considerations, even though from the field name/value table
it looks like this document is creating them (at the bottom of page
9 and 10, respectively).
The second sentence of section 3.1.2 is confusing; the words
"an administrator" may be extraneous.
The second example in section 3.1.3 contains whitespace in the value of
the "client-file-name" field, even though section 3.1 talks a lot about
no whitespace being allowed in this part of the string.
Table 2 in section 3.2.1.1 says what to do if uri-scheme is omitted
by a client, implying that it's optional. (There are some examples
later which don't have a uri-scheme value). However, table 3,
titled "REQUIRED ... fields", lists uri-scheme. Is it optional or
required?
The reference to [xmldsig] needs to be updated to refer to
RFC 3075.
Item 2 in 3.2.1.1.1 talks about case INsensitive matching, but
nowhere else is this mentioned in the document. Is this
item simply obsolete?
That's it!
Ned
This archive was generated by hypermail 2b29 : Fri Jun 14 2002 - 18:22:31 EDT