Michael Sweet wrote:
> The 64k limit is governed by the 16-bit length word. If we change
> this then the major version needs to change, i.e. IPP 2.0.
>> My main point was that 64k is not enough to hold a complete driver.
> Most Windows printer drivers weight in at 4-5 MB *compressed*, so
> really the only printers that would be able to use this functionality
> would be PostScript printers which use PPD files...
Your point is well taken. We probably want to avoid having to rev up the major version number to accommodate 64k+ attributes. So let me submit a slight modification to the original proposal. Instead of returning a printer driver as an attribute value, "Get-Printer-Attributes" returns it as post "end-of-attributes-tag" data in similar fashion to the way "Print-Job" sends the document content.
To accommodate this change, the last field of "printer-driver-supported-coll" is modified as follows:
From: "binary-file" (octetString) /* contains the printer driver */
To: "binary-file-returned" (boolean) /* indicates whether a printer driver is being returned after the "end-of-attributes-tag" */
Just as previously proposed, this data is returned by the printer only when the workstation explicitly requests it and only for the first entry that matches the qualifications specified in "printer-driver-info-request".
> ...
> SSL is not recognized; TLS would be the correct "standard" to quote.
> However, neither is likely to be supported in a typical network
> interface.
IPP currently requires Digest Authentication. Wouldn't this be sufficient?
> ...
> I'm not sure it would; basically, by allowing executable code to be
> served by an IPP object, you're opening up all sorts of security
> holes. They may say that the only way we can do it is to require
> support for TLS, which will pretty much kill its use in embedded
> products that have neither the memory nor the CPU to handle it.
A couple of popular systems I'm familiar with download printer drivers from places on the network much more obscure than the printer users intent to print to. I understand that's not a good enough argument to sell the proposal to the IESG. What I'm saying is that there's a real and pressing need for this functionality and if we don't address the need in the standard, people are going to do it proprietarily (is that a word?), guaranteed. So we require Digest Authentication and/or TLS in the spec and let implementors decide if their target market justifies the cost of including the extra security.
Realize that most users will have already established some level of trust on the printer they intent to download a driver from, as they're willing to submit documents to be printed on that device. This trust might be based on the fact that they're using an IPP url off an internal corporate site, or a url off a well-known web site which they might have already validated using SSL or TLS.
> ...
> > The Collection syntax provides a clean implementation of the
> > proposed functionality. I understand, though, that the jury is
> > still out on Collections. So if someone can propose a *simple*
> > alternative, I'd love to hear it.
>> Well, as I've noted before the easier solution is to add a new
> value tag for specific collections, since (so far) all of the
> collection proposals have had a fixed set of values.
Let's fix collections or embrace an alternative solution that keeps things simple. I strongly disagree with those who think we don't need this functionality in IPP. We can't go on kludging specialized encodings each time we run into this problem (a la "tree amigos" attributes).
> .......
>> Some further thoughts...
>> To avoid the issue of security, and to promote the work being done
> by other groups, we may want to move away from executable drivers
> to driver information files. I'm thinking specifically of the
> existing PPD file specification for PostScript printers and the
> work the UPDF group is doing towards a "universal printer driver".
> While I'm not sure if the UPDF group will succeed (mostly because
> of corporate "politics" with low-end printers), PPD files have
> arguably done the job for PostScript printing devices and can be
> used on any platform. The security issues with PPD and UPDF files
> are significantly less, and if we provide some method of
> authentication of the original data (maybe via HTTP Digest
> authentication? I dunno) then I think the IETF will be more likely
> to embrace the idea.
I like the idea of endorsing other Standards work and we should make sure the solution we choose allows the UPDF (and PPD) technology to be used. But as you point out, the UPDF effort is far from complete and we don't have the luxury to wait another year, to be extremely optimistic, before UPDF reaches any type of critical mass presence. We cannot ignore either the enormous wealth of legacy printer drivers.
>> You may also want to look at the CUPS-Get-PPDs extension that CUPS
> uses for PPD files; it handles the language issue (OS doesn't matter),
> and instead of creating a collection of values it sends each PPD
> file's attributes separately, much like the get-jobs operation.
> Once you have a printer installed, the PPD file is available by
> reading "http://server:631/printers/name.ppd". Unfortunately, since
> most vendors don't want to add a PostScript RIP to support non-PS
> printers, and since Windows and MacOS are not married to PostScript
> like UNIX is, this method probably won't work as a general solution.
Windows clients (in al their incarnations) currently make up the bulk of our market. So PPD is definitely not an answer.
>> My personal opinion is this: if we add better driver support to IPP
> then we need to focus on portability/usability on multiple platforms.
> I really don't think that pushing executable driver code to a client
> is the way to go, and raises too many security issues.
>> I also think we should have a "driver-format" attribute in whatever
> specification we end up with. That will allow future expansion and
> will tell the client what kind of driver is required (e.g. PostScript
> PPD-based driver, UPDF driver, or a vendor-specific driver using a
> special driver info file) and (hopefully) will allow for much better
> cross-platform support. I know from experience that writing drivers
> for multiple platforms sucks, and providing the necessary hooks to
> eliminate that multiple development will go a long way towards making
> IPP attractive "to the masses"... :)