Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel
Hi, a new standard not yet supported under Linux but starting to penetrate the market is IPP-over-USB (Internet Printing Protocol over USB). IPP, the Internet Printing Protocol from the Printing Working Group (PWG, http://www.pwg.org/) is a standard protocol for network printers (and also used by CUPS, the standard printing environment on practically all non-Windows operating systems). IPP network printers have a lot of advantages compared to USB printers (letting the ability of several computers on a network being able to access them aside): - Encrypted job transfer - Possibility to request printer status and printer capabilities - Web interface to configure the printer All this works with standard protocols and without any requirement of printer manufacturer/model specific software. For printers which also understand standard languages for the jobs themselves (PostScript, PDF, PWG Raster, PCL, JPG, TIFF) this means completely driverless printing (IPP Everywhere). Unfortunately, this is a network protocol for network printers. Fortunately, the PWG has added a standard to make it also go into USB printers, IPP-over-USB. Problem is that there is no Linux support for that. First, I want to make a feature request to the kernel to add it. Second, I want to suggest this as a Google Summer of Code project, asking for mentors on the kernel side. Mentoring Organization will be the Linux Foundation, hosting projects for both OpenPrinting and the kernel. It should not be too complex. Probably one can start on the driver for USB Ethernet or WLAN sticks, as they are also USB devices which introduce a network interface to the system. What one has to do is to create a driver for another, probably similar device, the IPP-over-USB printer. The driver should not be specific to the printer model (it is an open standard protocol) and it also should provide a network interface to the system under which there is only found the printer. The printer should be accessible under this interface via port 80 (web interface), 631 (IPP), and 443 (encrypted). There are already HP printers available which do IPP-over-USB. I will try to make arrangements for developers/students to get samples. WDYT? Is this a viable project? Should we post it on the ideas lists? Who would mentor it? Till
Till, Some comments inline... On Feb 25, 2014, at 12:01 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
Hi,
a new standard not yet supported under Linux but starting to penetrate the market is IPP-over-USB (Internet Printing Protocol over USB). ... Fortunately, the PWG has added a standard to make it also go into USB printers, IPP-over-USB. Problem is that there is no Linux support for that.
Actually, it was the USB Implementers Forum (USB-IF) that defined and published the IPP USB specification, not the PWG.
First, I want to make a feature request to the kernel to add it.
I don't think the kernel is the right place for this. IPP USB isn't like IP-over-USB, and you'll want the interface to provide arbitration and multiplexing of HTTP requests over the available IPP USB interfaces.
Second, I want to suggest this as a Google Summer of Code project, asking for mentors on the kernel side. Mentoring Organization will be the Linux Foundation, hosting projects for both OpenPrinting and the kernel.
This will make an excellent SoC project, but you'll need someone familiar with Avahi, libusb, HTTP, systemd, and general networking for this. This isn't a kernel project.
It should not be too complex. Probably one can start on the driver for USB Ethernet or WLAN sticks, as they are also USB devices which introduce a network interface to the system. What one has to do is to create a driver for another, probably similar device, the IPP-over-USB printer. The driver should not be specific to the printer model (it is an open standard protocol) and it also should provide a network interface to the system under which there is only found the printer. The printer should be accessible under this interface via port 80 (web interface), 631 (IPP), and 443 (encrypted).
OK, let's be clear on this - you DO NOT do SSL/TLS over IPP USB. As there is no connection management, you would never be able to safely do a TLS negotiation or session management, and once encrypted you would not be able to multiplex access to the limited number of USB interfaces that are provided by the printer. Conceptually you might want to support encryption to the IPP USB "proxy" (assuming you allow remote access to the local USB printer), but communications from the proxy to the USB printer need to be unencrypted. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
On Tue, Feb 25, 2014 at 01:42:00PM -0500, Michael Sweet wrote:
Till,
Some comments inline...
On Feb 25, 2014, at 12:01 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
Hi,
a new standard not yet supported under Linux but starting to penetrate the market is IPP-over-USB (Internet Printing Protocol over USB). ... Fortunately, the PWG has added a standard to make it also go into USB printers, IPP-over-USB. Problem is that there is no Linux support for that.
Actually, it was the USB Implementers Forum (USB-IF) that defined and published the IPP USB specification, not the PWG.
First, I want to make a feature request to the kernel to add it.
I don't think the kernel is the right place for this. IPP USB isn't like IP-over-USB, and you'll want the interface to provide arbitration and multiplexing of HTTP requests over the available IPP USB interfaces.
So you want to do this as a userspace library talking directly to the USB device through usbfs/libusb? Or should the kernel provide a basic "pipe-like" functionality to the hardware to make it easier for things to be queued up to the device? Is there a pointer to the spec somewhere so that I can see what is needed here?
Second, I want to suggest this as a Google Summer of Code project, asking for mentors on the kernel side. Mentoring Organization will be the Linux Foundation, hosting projects for both OpenPrinting and the kernel.
This will make an excellent SoC project, but you'll need someone familiar with Avahi, libusb, HTTP, systemd, and general networking for this. This isn't a kernel project.
That's a non-trivial set of experience to try to find, good luck :) And why systemd? What is needed from it for this? thanks, greg k-h
Greg, On Feb 25, 2014, at 8:47 PM, Greg KH <greg@kroah.com> wrote:
... So you want to do this as a userspace library talking directly to the USB device through usbfs/libusb? Or should the kernel provide a basic "pipe-like" functionality to the hardware to make it easier for things to be queued up to the device?
libusb is enough.
Is there a pointer to the spec somewhere so that I can see what is needed here?
http://www.usb.org/developers/devclass_docs
Second, I want to suggest this as a Google Summer of Code project, asking for mentors on the kernel side. Mentoring Organization will be the Linux Foundation, hosting projects for both OpenPrinting and the kernel.
This will make an excellent SoC project, but you'll need someone familiar with Avahi, libusb, HTTP, systemd, and general networking for this. This isn't a kernel project.
That's a non-trivial set of experience to try to find, good luck :)
Agreed.
And why systemd? What is needed from it for this?
Just for the launch-on-demand functionality. Not absolutely required, but it helps to minimize the overall "weight" of the OS when you aren't printing constantly... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
I have posted this project on our project ideas list now: https://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-co... Feel free to do corrections on the posting. I have also announced our participation in the GSoC on our front page: https://www.linuxfoundation.org/collaborate/workgroups/openprinting Till On 02/26/2014 02:56 AM, Michael Sweet wrote:
Greg,
On Feb 25, 2014, at 8:47 PM, Greg KH <greg@kroah.com> wrote:
... So you want to do this as a userspace library talking directly to the USB device through usbfs/libusb? Or should the kernel provide a basic "pipe-like" functionality to the hardware to make it easier for things to be queued up to the device?
libusb is enough.
Is there a pointer to the spec somewhere so that I can see what is needed here?
http://www.usb.org/developers/devclass_docs
Second, I want to suggest this as a Google Summer of Code project, asking for mentors on the kernel side. Mentoring Organization will be the Linux Foundation, hosting projects for both OpenPrinting and the kernel.
This will make an excellent SoC project, but you'll need someone familiar with Avahi, libusb, HTTP, systemd, and general networking for this. This isn't a kernel project.
That's a non-trivial set of experience to try to find, good luck :)
Agreed.
And why systemd? What is needed from it for this?
Just for the launch-on-demand functionality. Not absolutely required, but it helps to minimize the overall "weight" of the OS when you aren't printing constantly...
_________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
On Tue, Feb 25, 2014 at 08:56:23PM -0500, Michael Sweet wrote:
Greg,
On Feb 25, 2014, at 8:47 PM, Greg KH <greg@kroah.com> wrote:
... So you want to do this as a userspace library talking directly to the USB device through usbfs/libusb? Or should the kernel provide a basic "pipe-like" functionality to the hardware to make it easier for things to be queued up to the device?
libusb is enough.
Is there a pointer to the spec somewhere so that I can see what is needed here?
In reading the spec, it looks like some kernel code will have to be written, as the default configuration for the printer device will cause the usblp driver to bind to the device. Are you thinking that libusb will just unbind the printer driver and take over from there? Why not just use the kernel driver to expose another device node and have cups talk to that? thanks, greg k-h
Greg, We already unload the usblp driver - it isn't compatible with most of the multifunction printers out there today... On Feb 26, 2014, at 6:02 PM, Greg KH <greg@kroah.com> wrote:
On Tue, Feb 25, 2014 at 08:56:23PM -0500, Michael Sweet wrote:
Greg,
On Feb 25, 2014, at 8:47 PM, Greg KH <greg@kroah.com> wrote:
... So you want to do this as a userspace library talking directly to the USB device through usbfs/libusb? Or should the kernel provide a basic "pipe-like" functionality to the hardware to make it easier for things to be queued up to the device?
libusb is enough.
Is there a pointer to the spec somewhere so that I can see what is needed here?
In reading the spec, it looks like some kernel code will have to be written, as the default configuration for the printer device will cause the usblp driver to bind to the device. Are you thinking that libusb will just unbind the printer driver and take over from there? Why not just use the kernel driver to expose another device node and have cups talk to that?
thanks,
greg k-h
_________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
On Wed, Feb 26, 2014 at 07:05:46PM -0500, Michael Sweet wrote:
Greg,
We already unload the usblp driver - it isn't compatible with most of the multifunction printers out there today...
Really? That's why we haven't had any bug reports in years, and here I was thinking the code was working just fine :) Ok, then nevermind from the kernel side, nothing's needed here, I agree. greg k-h
Hi All, I have some quick and general questions regarding IPP over USB ("IPP USB" for short). Some are related to Till's proposed project "Google Summer of Code 2014 - IPP-over-USB printer support". Any help and feedback will be greatly welcomed. I should mention that I am in favor of the proposed project for this event. Assumptions (please confirm or correct): 1) This first one may be obvious but to be sure - I am assuming that we are referring to IPP USB as defined in the "USB Print Interface Class IPP Protocol Specification Revision 1.0" dated 12/5/2012 and published by USB-IF and authored by HP's Smith Kennedy and Andrew R. Mitchell. I'll refer to it as the "IPP USB Spec". 2) As I understand the IPP USB Spec, there is NO network interface, NOR TCP/IP involved. The Communication Protocol to be used between Host and Device (Printer) is *purely HTTP + IPP directly over USB*. A place where this is noted is section 6.2 - "HTTP Headers" which states the following: *Since there is NO network interface connection, NO DNS hostnames or IP addresses, and NO TCP port numbers associated with USB connection, the requirements of the HTTP Host field is addressed by requiring that the value of this header MUST be "localhost".* Please correct me if I am wrong on either of these assumptions. Questions: 1) I know the Spec is already cast in stone but I would like to understand what function HTTP serves and if it is only used for identifying "Host: localhost" and the "/ipp/printer" path? In other words, could pure IPP Requests/Responses and IPP expected format "Print Data" have sufficed? 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USB capable Print class interfaces provided by a device MUST be functionally equal from an IPP operation or HTTP perspective. In other words, any IPP operation or resource path that is valid over one IPP USB interface MUST be reachable viaany and all of the IPP USB interfaces." Does this imply that, for example, a Request from the host can be sent over one interface (I/F #1) and the response received over a different interface (e.g., I/F #2)? 3) The last question is much simpler but would be helpful to an implementor - what specific printers (manufacturer, line and model) *on the market*support IPP USB? I have seen references to HP Photosmart and OfficeJet but no model given. Similarly, what Host(s) on the market, including OS and version, support the IPP USB protocol with these Printers? Knowing this would be helpful to implement and test either device and/or host support. I look forward to your reply and discussing the project further. Thanks! Carlos Rimola Software Developer crimola@gmail.com 408-508-8339
On Tue, 25 Feb 2014 18:01:07 +0100, Till Kamppeter said:
all non-Windows operating systems). IPP network printers have a lot of advantages compared to USB printers (letting the ability of several computers on a network being able to access them aside):
- Encrypted job transfer
I'll merely point out that encrypted transfer doesn't mean much for a USB transfer - if an attacker is able to play with your USB you have far greater problems than that to worry about...
participants (5)
-
Carlos Rimola -
Greg KH -
Michael Sweet -
Till Kamppeter -
Valdis.Kletnieks＠vt.edu