Has anybody thought about the case that an IPP able printer is not connected
via TCP/IP?
A driver - at least under Windows - has to work independently from the port.
As a matter of fact the port can still be changed at a very late point when
the PDL body of the print file is already rendered.
When the user or system administrator is then changing the port a language
monitor can add an IPP wrapper when the IPP port is identified, but the
driver still has to be able to work with a local port. The minimum effect
that can happen is that the language monitor would leave out the IPP wrapper
with a local port, as the printer may get into serious coughing, when it
sees IPP keywords coming in over a LPT port.
So to avoid a desaster the language monitor would hold back the IPP stuff.
But then the job will loose all its device configuration settings and device
defaults of that time would be used.
Or does anybody want to build a driver (client), which is only able to work
with an IPP port. I'm afraid we are asking for problems in that case.
Norbert