Carlos,

On Feb 26, 2014, at 9:33 PM, Carlos Rimola <[email protected]> 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: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Kernelnewbies mailing list
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to