RE: IPP> IPP and the IESG

[Rich Gray <[e-mail]>]

Although I have come late to this list and have to wonder about the 
overhead of putting an http server into printers, I must also express
my sense of wonderment at the IESG's stance on ipp: instead of http:.

I guess the main beauty of ipp over straight http: can be summarized 
best in two words: BOLT IN.   Put the appropriate software in the 
client and add a CGI or similar to any reasonable web server and you 
have implemented a printing system without breaking anything in 
between.  No special ipp: needed, no special port# (and no PRINT 
either!)  This is simple, clean modularity.  This I believe is what 
layered protocols strive to achieve.  Why muck this up?

By forcing ipp:, you potentially break a lot of infrastructure.  Web 
servers, firewalls, etc. may need to be upgraded to understand "ipp:".
The SMTP does not become something else when one does an FTP file 
retrieval via e-mail. As many have asked, why should http: change 
because the content is application/ipp?  Should every other application 
protocol that comes along on top of http also cause the same breakage 
instead of just bolting in cleanly??  This just seems rather clumsy and 
disruptive.  It will inhibit deployment because infrastructure upgrades 
will be required to make it work.  What is gained by doing this??  
Filtering?  A simpler URI for the user?

I do not believe "ipp:" provides any filtering which cannot be
achieved in other ways.  As been pointed out, the application/ipp
MIME type is there as a generic check for incoming and outgoing traffic.
Aside from that, while a company might be inclined to prevent it's
users from coping a peek at www.hotporno.com, I really doubt that it
will care as much about users coping a print to some external site.
Mostly, folks will want to protect their printers from incoming
requests.
This would seem to be easily accomplished by protecting the printer's
address from external access or by running the ipp service at a non-80
port# and filtering on whatever that is.   Ultimately, authentication 
techniques will handle this.

As to URI simplification, I don't see where most users are going to 
ever come into contact with the address, except maybe once as yet
another
incantation to be said when configuring the print facility on their
client.
Thereafter, they will just click [PRINT].  Or the address will be buried
in 
the web page/java script/applet or whatever directory service thingy the

user clicks on to invoke requests.  The user will not/should not see it.
My printer's address on my business card??  No thanks.  Maybe on my web 
page and that might embed the printer address if I care to.  (I'd just
as 
soon forward their e-mail to the printer myself...)  As I hinted above, 
I see no reason why the ipp service cannot hang on port 80 along with
the 
other http traffic.  Simplicity!   Even if the user does manage to get
and 
enter an ipp printer address into a browser, what's the worst which can 
happen??  An error message??  So?


So IESG, show some reasons for breaking/complicating the world
for each new application protocol which wants to ride on an existing
transport protocol.

Guess I'm largely echoing things others have said, but what the hey,
it's my possibly off-base $.02,

Rich


Richard B. Gray, Sr. Software Egr.| Tel: [phone] ext. 2405
Digital Controls Corporation      | Fax: [phone]
305 South Pioneer Blvd.           | Net: [e-mail]
Springboro OH 45066-1100, USA     | Http://lpplus.digital-controls.com