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: 513/746-8118 ext. 2405
Digital Controls Corporation | Fax: 513/743-8575
305 South Pioneer Blvd. | Net: rich.gray at digital-controls.com
Springboro OH 45066-1100, USA | Http://lpplus.digital-controls.com