Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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

Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Greg KH]

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

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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
> 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Till Kamppeter]

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
> 

Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Valdis.Kletnieks at vt.edu]

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 

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Greg KH]

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

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Greg KH]

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

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Carlos Rimola]

[-- 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 --]

[Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

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 

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel

[Michael Sweet]

[-- 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 --]