* Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-25 17:01 ` Till Kamppeter 0 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-25 17:01 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-25 17:01 ` Till Kamppeter 0 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-25 17:01 UTC (permalink / raw) To: Greg KH, Open Printing, Ubuntu Kernel Team, kernelnewbies, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <CA+55aFx=5ubeSTcWVcM1bxnjG72fV0vwzTktuqccy1h4-aMScg@mail.gmail.com>]
* Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel [not found] ` <CA+55aFx=5ubeSTcWVcM1bxnjG72fV0vwzTktuqccy1h4-aMScg@mail.gmail.com> @ 2014-02-25 17:26 ` Till Kamppeter 0 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-25 17:26 UTC (permalink / raw) To: kernelnewbies On 02/25/2014 06:20 PM, Linus Torvalds wrote: > On Tue, Feb 25, 2014 at 9:01 AM, Till Kamppeter > <till.kamppeter@gmail.com> wrote: >> >> 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 certainly sounds like a worthy thing, but wasn't the deadline for > GSoC last Friday? I know both Subsurface and X.org did that, and got > accepted early this week. No, the deadline was only for mentoring org applications (and as mentoring org we, the LF, are accepted). Project ideas can be added until the student application deadline, only the earlier they get posted, the more potential student candidates will read them and consider them for their applications. In addition, project ideas get posted on the project's sites, not at Google. Also they can get posted at more than one place. So we should determine ASAP who could mentor this project and post the project on our idea lists. Till ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-25 17:26 ` Till Kamppeter 0 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-25 17:26 UTC (permalink / raw) To: Linus Torvalds; +Cc: Open Printing, Greg KH, Ubuntu Kernel Team, kernelnewbies On 02/25/2014 06:20 PM, Linus Torvalds wrote: > On Tue, Feb 25, 2014 at 9:01 AM, Till Kamppeter > <till.kamppeter@gmail.com> wrote: >> >> 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 certainly sounds like a worthy thing, but wasn't the deadline for > GSoC last Friday? I know both Subsurface and X.org did that, and got > accepted early this week. No, the deadline was only for mentoring org applications (and as mentoring org we, the LF, are accepted). Project ideas can be added until the student application deadline, only the earlier they get posted, the more potential student candidates will read them and consider them for their applications. In addition, project ideas get posted on the project's sites, not at Google. Also they can get posted at more than one place. So we should determine ASAP who could mentor this project and post the project on our idea lists. Till ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-25 17:01 ` [Printing-architecture] " Till Kamppeter @ 2014-02-25 18:42 ` Michael Sweet -1 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-25 18:42 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140225/bf60a090/attachment-0001.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-25 18:42 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-25 18:42 UTC (permalink / raw) To: Till Kamppeter Cc: printing-architecture, Greg KH, Ubuntu Kernel Team, Linus Torvalds, kernelnewbies [-- Attachment #1: Type: text/plain, Size: 2521 bytes --] 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 [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-25 18:42 ` Michael Sweet (?) @ 2014-02-26 1:47 ` Greg KH 2014-02-26 1:56 ` Michael Sweet -1 siblings, 1 reply; 28+ messages in thread From: Greg KH @ 2014-02-26 1:47 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-26 1:47 ` Greg KH @ 2014-02-26 1:56 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-26 1:56 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140225/46bbd396/attachment.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-26 1:56 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-26 1:56 UTC (permalink / raw) To: Greg KH Cc: printing-architecture, Ubuntu Kernel Team, kernelnewbies, Linus Torvalds, Till Kamppeter [-- Attachment #1: Type: text/plain, Size: 1347 bytes --] 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 [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-26 1:56 ` Michael Sweet @ 2014-02-26 17:37 ` Till Kamppeter -1 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-26 17:37 UTC (permalink / raw) To: kernelnewbies I have posted this project on our project ideas list now: https://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2014 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-26 17:37 ` Till Kamppeter 0 siblings, 0 replies; 28+ messages in thread From: Till Kamppeter @ 2014-02-26 17:37 UTC (permalink / raw) To: Michael Sweet, Greg KH Cc: printing-architecture, Ubuntu Kernel Team, Linus Torvalds, kernelnewbies I have posted this project on our project ideas list now: https://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2014 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-26 1:56 ` Michael Sweet (?) (?) @ 2014-02-26 23:02 ` Greg KH 2014-02-27 0:05 ` Michael Sweet -1 siblings, 1 reply; 28+ messages in thread From: Greg KH @ 2014-02-26 23:02 UTC (permalink / raw) To: kernelnewbies 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? > > http://www.usb.org/developers/devclass_docs 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-26 23:02 ` Greg KH @ 2014-02-27 0:05 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 0:05 UTC (permalink / raw) To: kernelnewbies 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? >> >> http://www.usb.org/developers/devclass_docs > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140226/c94867cd/attachment.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-27 0:05 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 0:05 UTC (permalink / raw) To: Greg KH Cc: printing-architecture, Ubuntu Kernel Team, kernelnewbies, Linus Torvalds, Till Kamppeter [-- Attachment #1: Type: text/plain, Size: 1328 bytes --] 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? >> >> http://www.usb.org/developers/devclass_docs > > 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 [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 0:05 ` Michael Sweet (?) @ 2014-02-27 1:35 ` Greg KH -1 siblings, 0 replies; 28+ messages in thread From: Greg KH @ 2014-02-27 1:35 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 0:05 ` Michael Sweet @ 2014-02-27 2:33 ` Carlos Rimola -1 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-02-27 2:33 UTC (permalink / raw) To: kernelnewbies 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 at gmail.com 408-508-8339 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140226/e66c5340/attachment-0001.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-27 2:33 ` Carlos Rimola 0 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-02-27 2:33 UTC (permalink / raw) To: printing-architecture, Ubuntu Kernel Team, kernelnewbies; +Cc: Till Kamppeter [-- Attachment #1: Type: text/plain, Size: 2709 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 9588 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 2:33 ` Carlos Rimola @ 2014-02-27 15:37 ` Michael Sweet -1 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 15:37 UTC (permalink / raw) To: kernelnewbies Carlos, On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: > 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". > Correct. > 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. > Correct (a port number can be passed by the "client" over USB to allow gateways/proxies to work...) > 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? > While you might get away with that for simple IPP messages, that wouldn't work for document data since IPP by itself has no framing or other niceties - you'd never know when the data ended. Also, the HTTP portion is used for the embedded web server, doing firmware updates, and so forth. > 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 via any 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)? > No, each interface is an independent channel to the printer. The reason for this requirement is to prevent having an IPP USB endpoint just for printing, and another just for scanning, and so forth. Effectively IPP USB defines an interface protocol that allows arbitrary HTTP and IPP requests to be performed. > 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? > Here is the latest list we have from HP: Deskjet 3520 Envy 120 Envy 4500 Envy 5530 Officejet 3620 Officejet 4630 Officejet 7610 Officejet Pro 276 MFP Officejet Pro X576 dw Photosmart 5520 Photosmart 6520 Photosmart 7520 I know of four other manufacturers that either have shipping products or will soon be shipping - will post here when I can do so publicly... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140227/693cf830/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140227/693cf830/attachment-0001.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-27 15:37 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 15:37 UTC (permalink / raw) To: Carlos Rimola Cc: printing-architecture, Ubuntu Kernel Team, Till Kamppeter, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 3894 bytes --] Carlos, On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: > 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". > Correct. > 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. > Correct (a port number can be passed by the "client" over USB to allow gateways/proxies to work...) > 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? > While you might get away with that for simple IPP messages, that wouldn't work for document data since IPP by itself has no framing or other niceties - you'd never know when the data ended. Also, the HTTP portion is used for the embedded web server, doing firmware updates, and so forth. > 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 via any 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)? > No, each interface is an independent channel to the printer. The reason for this requirement is to prevent having an IPP USB endpoint just for printing, and another just for scanning, and so forth. Effectively IPP USB defines an interface protocol that allows arbitrary HTTP and IPP requests to be performed. > 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? > Here is the latest list we have from HP: Deskjet 3520 Envy 120 Envy 4500 Envy 5530 Officejet 3620 Officejet 4630 Officejet 7610 Officejet Pro 276 MFP Officejet Pro X576 dw Photosmart 5520 Photosmart 6520 Photosmart 7520 I know of four other manufacturers that either have shipping products or will soon be shipping - will post here when I can do so publicly... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair [-- Attachment #1.2: Type: text/html, Size: 12342 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 15:37 ` Michael Sweet @ 2014-02-27 19:23 ` Carlos Rimola -1 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-02-27 19:23 UTC (permalink / raw) To: kernelnewbies Michael, Thanks for the comprehensive response to my questions on IPP USB and confirming my assumptions. The only remaining question I have for the list at this time is - are there any Hosts, including model, OS and OS version (or other S/W requirements), presently available on the market (or otherwise) which support IPP USB as per the Specification? Thanks again, Carlos Rimola On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: > > 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". > > Correct. > > 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. > > > Correct (a port number can be passed by the "client" over USB to allow > gateways/proxies to work...) > > 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? > > While you might get away with that for simple IPP messages, that wouldn't > work for document data since IPP by itself has no framing or other niceties > - you'd never know when the data ended. > > Also, the HTTP portion is used for the embedded web server, doing firmware > updates, and so forth. > > 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USBcapable > 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 via any 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)? > > No, each interface is an independent channel to the printer. > > The reason for this requirement is to prevent having an IPP USB endpoint > just for printing, and another just for scanning, and so forth. > Effectively IPP USB defines an interface protocol that allows arbitrary > HTTP and IPP requests to be performed. > > 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? > > Here is the latest list we have from HP: > > Deskjet 3520 > Envy 120 > Envy 4500 > Envy 5530 > Officejet 3620 > Officejet 4630 > Officejet 7610 > Officejet Pro 276 MFP > Officejet Pro X576 dw > Photosmart 5520 > Photosmart 6520 > Photosmart 7520 > > I know of four other manufacturers that either have shipping products or > will soon be shipping - will post here when I can do so publicly... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140227/f914bdf8/attachment-0001.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-27 19:23 ` Carlos Rimola 0 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-02-27 19:23 UTC (permalink / raw) To: Michael Sweet Cc: printing-architecture, Ubuntu Kernel Team, Till Kamppeter, kernelnewbies [-- Attachment #1: Type: text/plain, Size: 4430 bytes --] Michael, Thanks for the comprehensive response to my questions on IPP USB and confirming my assumptions. The only remaining question I have for the list at this time is - are there any Hosts, including model, OS and OS version (or other S/W requirements), presently available on the market (or otherwise) which support IPP USB as per the Specification? Thanks again, Carlos Rimola On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: > > 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". > > Correct. > > 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. > > > Correct (a port number can be passed by the "client" over USB to allow > gateways/proxies to work...) > > 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? > > While you might get away with that for simple IPP messages, that wouldn't > work for document data since IPP by itself has no framing or other niceties > - you'd never know when the data ended. > > Also, the HTTP portion is used for the embedded web server, doing firmware > updates, and so forth. > > 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USBcapable > 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 via any 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)? > > No, each interface is an independent channel to the printer. > > The reason for this requirement is to prevent having an IPP USB endpoint > just for printing, and another just for scanning, and so forth. > Effectively IPP USB defines an interface protocol that allows arbitrary > HTTP and IPP requests to be performed. > > 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? > > Here is the latest list we have from HP: > > Deskjet 3520 > Envy 120 > Envy 4500 > Envy 5530 > Officejet 3620 > Officejet 4630 > Officejet 7610 > Officejet Pro 276 MFP > Officejet Pro X576 dw > Photosmart 5520 > Photosmart 6520 > Photosmart 7520 > > I know of four other manufacturers that either have shipping products or > will soon be shipping - will post here when I can do so publicly... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > [-- Attachment #2: Type: text/html, Size: 12781 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 19:23 ` Carlos Rimola @ 2014-02-27 19:29 ` Michael Sweet -1 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 19:29 UTC (permalink / raw) To: kernelnewbies Carlos, Any Mac running OS X 10.9 supports IPP USB; note that we have a bunch of pending bug fixes (sorry, can't say when the fixes will be released...) that address issues found in testing with multiple vendors' implementations of IPP USB, but the current 10.9.2 will work with all of the HP printers mentioned below. On Feb 27, 2014, at 2:23 PM, Carlos Rimola <crimola@gmail.com> wrote: > Michael, > > Thanks for the comprehensive response to my questions on IPP USB and confirming my assumptions. > > The only remaining question I have for the list at this time is - are there any Hosts, including model, OS and OS version (or other S/W requirements), presently available on the market (or otherwise) which support IPP USB as per the Specification? > > Thanks again, > > Carlos Rimola > > > On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: >> 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". >> > Correct. >> 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. >> > > Correct (a port number can be passed by the "client" over USB to allow gateways/proxies to work...) >> 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? > > While you might get away with that for simple IPP messages, that wouldn't work for document data since IPP by itself has no framing or other niceties - you'd never know when the data ended. > > Also, the HTTP portion is used for the embedded web server, doing firmware updates, and so forth. >> >> 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 via any 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)? >> > No, each interface is an independent channel to the printer. > > The reason for this requirement is to prevent having an IPP USB endpoint just for printing, and another just for scanning, and so forth. Effectively IPP USB defines an interface protocol that allows arbitrary HTTP and IPP requests to be performed. >> 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? >> > Here is the latest list we have from HP: > > Deskjet 3520 > Envy 120 > Envy 4500 > Envy 5530 > Officejet 3620 > Officejet 4630 > Officejet 7610 > Officejet Pro 276 MFP > Officejet Pro X576 dw > Photosmart 5520 > Photosmart 6520 > Photosmart 7520 > > I know of four other manufacturers that either have shipping products or will soon be shipping - will post here when I can do so publicly... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140227/b4784ea3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140227/b4784ea3/attachment-0001.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-02-27 19:29 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-02-27 19:29 UTC (permalink / raw) To: Carlos Rimola Cc: printing-architecture, Ubuntu Kernel Team, Till Kamppeter, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 5009 bytes --] Carlos, Any Mac running OS X 10.9 supports IPP USB; note that we have a bunch of pending bug fixes (sorry, can't say when the fixes will be released...) that address issues found in testing with multiple vendors' implementations of IPP USB, but the current 10.9.2 will work with all of the HP printers mentioned below. On Feb 27, 2014, at 2:23 PM, Carlos Rimola <crimola@gmail.com> wrote: > Michael, > > Thanks for the comprehensive response to my questions on IPP USB and confirming my assumptions. > > The only remaining question I have for the list at this time is - are there any Hosts, including model, OS and OS version (or other S/W requirements), presently available on the market (or otherwise) which support IPP USB as per the Specification? > > Thanks again, > > Carlos Rimola > > > On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: >> 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". >> > Correct. >> 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. >> > > Correct (a port number can be passed by the "client" over USB to allow gateways/proxies to work...) >> 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? > > While you might get away with that for simple IPP messages, that wouldn't work for document data since IPP by itself has no framing or other niceties - you'd never know when the data ended. > > Also, the HTTP portion is used for the embedded web server, doing firmware updates, and so forth. >> >> 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 via any 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)? >> > No, each interface is an independent channel to the printer. > > The reason for this requirement is to prevent having an IPP USB endpoint just for printing, and another just for scanning, and so forth. Effectively IPP USB defines an interface protocol that allows arbitrary HTTP and IPP requests to be performed. >> 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? >> > Here is the latest list we have from HP: > > Deskjet 3520 > Envy 120 > Envy 4500 > Envy 5530 > Officejet 3620 > Officejet 4630 > Officejet 7610 > Officejet Pro 276 MFP > Officejet Pro X576 dw > Photosmart 5520 > Photosmart 6520 > Photosmart 7520 > > I know of four other manufacturers that either have shipping products or will soon be shipping - will post here when I can do so publicly... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair [-- Attachment #1.2: Type: text/html, Size: 14963 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-27 19:29 ` Michael Sweet @ 2014-03-04 22:28 ` Carlos Rimola -1 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-03-04 22:28 UTC (permalink / raw) To: kernelnewbies Hello All, I have a couple of "simple" follow-up questions on IPP USB (IPP-over-USB) "Host device" support: Is IPP USB designed to support connecting and printing from a device like a tablet or smartphone (e.g., iPad, iPhone, Etc.) directly connected to a printer over USB? If the answer is yes - is there any device that currently supports this? I imagine a special cable or converter would be needed? Or is IPP USB designed only for Hosts like Linux or Mac acting as print servers/gateways for these, and other, devices? Thanks, Carlos On Thu, Feb 27, 2014 at 11:29 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > Any Mac running OS X 10.9 supports IPP USB; note that we have a bunch of > pending bug fixes (sorry, can't say when the fixes will be released...) > that address issues found in testing with multiple vendors' implementations > of IPP USB, but the current 10.9.2 will work with all of the HP printers > mentioned below. > > > On Feb 27, 2014, at 2:23 PM, Carlos Rimola <crimola@gmail.com> wrote: > > Michael, > > Thanks for the comprehensive response to my questions on IPP USB and > confirming my assumptions. > > The only remaining question I have for the list at this time is - are > there any Hosts, including model, OS and OS version (or other S/W > requirements), presently available on the market (or otherwise) which > support IPP USB as per the Specification? > > Thanks again, > > Carlos Rimola > > > On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > >> Carlos, >> >> On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: >> >> 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". >> >> Correct. >> >> 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. >> >> >> Correct (a port number can be passed by the "client" over USB to allow >> gateways/proxies to work...) >> >> 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? >> >> While you might get away with that for simple IPP messages, that wouldn't >> work for document data since IPP by itself has no framing or other niceties >> - you'd never know when the data ended. >> >> Also, the HTTP portion is used for the embedded web server, doing >> firmware updates, and so forth. >> >> >> 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USBcapable >> 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 via any 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)? >> >> No, each interface is an independent channel to the printer. >> >> The reason for this requirement is to prevent having an IPP USB endpoint >> just for printing, and another just for scanning, and so forth. >> Effectively IPP USB defines an interface protocol that allows arbitrary >> HTTP and IPP requests to be performed. >> >> 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? >> >> Here is the latest list we have from HP: >> >> Deskjet 3520 >> Envy 120 >> Envy 4500 >> Envy 5530 >> Officejet 3620 >> Officejet 4630 >> Officejet 7610 >> Officejet Pro 276 MFP >> Officejet Pro X576 dw >> Photosmart 5520 >> Photosmart 6520 >> Photosmart 7520 >> >> I know of four other manufacturers that either have shipping products or >> will soon be shipping - will post here when I can do so publicly... >> >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >> >> > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140304/68b3db88/attachment-0001.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-03-04 22:28 ` Carlos Rimola 0 siblings, 0 replies; 28+ messages in thread From: Carlos Rimola @ 2014-03-04 22:28 UTC (permalink / raw) To: Michael Sweet, printing-architecture, Ubuntu Kernel Team, kernelnewbies, Till Kamppeter [-- Attachment #1: Type: text/plain, Size: 5715 bytes --] Hello All, I have a couple of "simple" follow-up questions on IPP USB (IPP-over-USB) "Host device" support: Is IPP USB designed to support connecting and printing from a device like a tablet or smartphone (e.g., iPad, iPhone, Etc.) directly connected to a printer over USB? If the answer is yes - is there any device that currently supports this? I imagine a special cable or converter would be needed? Or is IPP USB designed only for Hosts like Linux or Mac acting as print servers/gateways for these, and other, devices? Thanks, Carlos On Thu, Feb 27, 2014 at 11:29 AM, Michael Sweet <msweet@apple.com> wrote: > Carlos, > > Any Mac running OS X 10.9 supports IPP USB; note that we have a bunch of > pending bug fixes (sorry, can't say when the fixes will be released...) > that address issues found in testing with multiple vendors' implementations > of IPP USB, but the current 10.9.2 will work with all of the HP printers > mentioned below. > > > On Feb 27, 2014, at 2:23 PM, Carlos Rimola <crimola@gmail.com> wrote: > > Michael, > > Thanks for the comprehensive response to my questions on IPP USB and > confirming my assumptions. > > The only remaining question I have for the list at this time is - are > there any Hosts, including model, OS and OS version (or other S/W > requirements), presently available on the market (or otherwise) which > support IPP USB as per the Specification? > > Thanks again, > > Carlos Rimola > > > On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet@apple.com> wrote: > >> Carlos, >> >> On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola@gmail.com> wrote: >> >> 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". >> >> Correct. >> >> 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. >> >> >> Correct (a port number can be passed by the "client" over USB to allow >> gateways/proxies to work...) >> >> 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? >> >> While you might get away with that for simple IPP messages, that wouldn't >> work for document data since IPP by itself has no framing or other niceties >> - you'd never know when the data ended. >> >> Also, the HTTP portion is used for the embedded web server, doing >> firmware updates, and so forth. >> >> >> 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USBcapable >> 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 via any 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)? >> >> No, each interface is an independent channel to the printer. >> >> The reason for this requirement is to prevent having an IPP USB endpoint >> just for printing, and another just for scanning, and so forth. >> Effectively IPP USB defines an interface protocol that allows arbitrary >> HTTP and IPP requests to be performed. >> >> 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? >> >> Here is the latest list we have from HP: >> >> Deskjet 3520 >> Envy 120 >> Envy 4500 >> Envy 5530 >> Officejet 3620 >> Officejet 4630 >> Officejet 7610 >> Officejet Pro 276 MFP >> Officejet Pro X576 dw >> Photosmart 5520 >> Photosmart 6520 >> Photosmart 7520 >> >> I know of four other manufacturers that either have shipping products or >> will soon be shipping - will post here when I can do so publicly... >> >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >> >> > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > [-- Attachment #2: Type: text/html, Size: 15179 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-03-04 22:28 ` Carlos Rimola @ 2014-03-05 1:00 ` Michael Sweet -1 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-03-05 1:00 UTC (permalink / raw) To: kernelnewbies Carlos, On Mar 4, 2014, at 5:28 PM, Carlos Rimola <crimola@gmail.com> wrote: > Hello All, > > I have a couple of "simple" follow-up questions on IPP USB (IPP-over-USB) "Host device" support: > > Is IPP USB designed to support connecting and printing from a device like a tablet or smartphone (e.g., iPad, iPhone, Etc.) directly connected to a printer over USB? Honestly, no. Who would want to tether their mobile device to print something? Wi-Fi (and soon Wi-Fi Direct) offer ways of printing from mobile devices to these same printers (most of which already have Wi-Fi and/or Ethernet interfaces...) > ... > Or is IPP USB designed only for Hosts like Linux or Mac acting as print servers/gateways for these, and other, devices? It is mainly for existing desktop/portable/personal server/NAS/other-embedded usage that currently relies on the old USB printer class protocol and printer drivers. The (hopefully not too) long term goal is to eliminate the need for printer drivers, much as today you don't need a special driver for a USB keyboard or mouse. (and like keyboards and mice you might still get some software from the vendor to provide additional functionality, but generally you'll be able to just plug a printer in and print something without installing extra software...) For IPP USB in particular I think we'll see adoption by NAS and other network boxes that already provide primitive printer sharing. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140304/dc9a4092/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4881 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140304/dc9a4092/attachment.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel @ 2014-03-05 1:00 ` Michael Sweet 0 siblings, 0 replies; 28+ messages in thread From: Michael Sweet @ 2014-03-05 1:00 UTC (permalink / raw) To: Carlos Rimola Cc: printing-architecture, Ubuntu Kernel Team, Till Kamppeter, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 1567 bytes --] Carlos, On Mar 4, 2014, at 5:28 PM, Carlos Rimola <crimola@gmail.com> wrote: > Hello All, > > I have a couple of "simple" follow-up questions on IPP USB (IPP-over-USB) "Host device" support: > > Is IPP USB designed to support connecting and printing from a device like a tablet or smartphone (e.g., iPad, iPhone, Etc.) directly connected to a printer over USB? Honestly, no. Who would want to tether their mobile device to print something? Wi-Fi (and soon Wi-Fi Direct) offer ways of printing from mobile devices to these same printers (most of which already have Wi-Fi and/or Ethernet interfaces...) > ... > Or is IPP USB designed only for Hosts like Linux or Mac acting as print servers/gateways for these, and other, devices? It is mainly for existing desktop/portable/personal server/NAS/other-embedded usage that currently relies on the old USB printer class protocol and printer drivers. The (hopefully not too) long term goal is to eliminate the need for printer drivers, much as today you don't need a special driver for a USB keyboard or mouse. (and like keyboards and mice you might still get some software from the vendor to provide additional functionality, but generally you'll be able to just plug a printer in and print something without installing extra software...) For IPP USB in particular I think we'll see adoption by NAS and other network boxes that already provide primitive printer sharing. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair [-- Attachment #1.2: Type: text/html, Size: 3339 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 4881 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel 2014-02-25 17:01 ` [Printing-architecture] " Till Kamppeter ` (2 preceding siblings ...) (?) @ 2014-02-26 22:31 ` Valdis.Kletnieks at vt.edu -1 siblings, 0 replies; 28+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2014-02-26 22:31 UTC (permalink / raw) To: kernelnewbies 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... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140226/a6d536fe/attachment.bin ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2014-03-05 1:00 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-25 17:01 Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel Till Kamppeter 2014-02-25 17:01 ` [Printing-architecture] " Till Kamppeter [not found] ` <CA+55aFx=5ubeSTcWVcM1bxnjG72fV0vwzTktuqccy1h4-aMScg@mail.gmail.com> 2014-02-25 17:26 ` Till Kamppeter 2014-02-25 17:26 ` [Printing-architecture] " Till Kamppeter 2014-02-25 18:42 ` Michael Sweet 2014-02-25 18:42 ` Michael Sweet 2014-02-26 1:47 ` Greg KH 2014-02-26 1:56 ` Michael Sweet 2014-02-26 1:56 ` Michael Sweet 2014-02-26 17:37 ` Till Kamppeter 2014-02-26 17:37 ` Till Kamppeter 2014-02-26 23:02 ` Greg KH 2014-02-27 0:05 ` Michael Sweet 2014-02-27 0:05 ` Michael Sweet 2014-02-27 1:35 ` Greg KH 2014-02-27 2:33 ` Carlos Rimola 2014-02-27 2:33 ` Carlos Rimola 2014-02-27 15:37 ` Michael Sweet 2014-02-27 15:37 ` Michael Sweet 2014-02-27 19:23 ` Carlos Rimola 2014-02-27 19:23 ` Carlos Rimola 2014-02-27 19:29 ` Michael Sweet 2014-02-27 19:29 ` Michael Sweet 2014-03-04 22:28 ` Carlos Rimola 2014-03-04 22:28 ` Carlos Rimola 2014-03-05 1:00 ` Michael Sweet 2014-03-05 1:00 ` Michael Sweet 2014-02-26 22:31 ` Valdis.Kletnieks at vt.edu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.