Classification:
Prologue:
Epilogue:
Alex, I am desparately trying to get beyond what seem to me to be emotional
arguments. I have heard a number of people decry the use of http as an
underlying protcol for intenet printing, but have not yet been able to get to
any substantive reasons why using http is a bad choice. I may come across as
an HTTP bigot, but the fact of the matter is that the original proposal that we
(IBM) made to the Printer Working Group was to develop a brand new protocol.
It was only after many people suggested that using HTTP would be easier that we
agreed to pursue that direction.
I think that Jay Martin hit on a significant point when he said that the
protocol needed the buy-in of the platform vendors, and that the solution
needed to be ubiquitous. It is critical that we agree on an approach that will
lead to wide-spread (easy) implementations, will be supported on the dominant
industry computing platforms, and will not create performance or security
problems in existing networks. I have not heard anything yet that suggests
that defining a new protocol on TCP/IP makes the implemetation easier (Angelo's
comments only say it is no harder -- and once he has written an imbedded
server, why not reuse it as opposed to yet creating something new again?), will
get us support on the dominant platforms quicker, or solve security or perform
ance problems.
Based on your experience, if you can provide real, concrete arguments for not
using HTTP, I think that we would all be willing to listen to those arguments.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 11:05
AM ---------------------------
abochann @ cisco.com
01/06/97 09:55 AM
To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org at internet
Subject: Re: IPP> What is it we really need?
Well, I think it became quite clear from Angelo's email, that the
largest number of implementors (the folks who write the printer code)
will most likely not have the option of using anything even close to a
"stock HTTP server". They probably have better tools to write code
straight to a socket API than to their own HTTP server
implementation. And I can tell you from very recent experience that
printing directly to a printer, circumventing the intermediate step of
a print server, is not only something that small shops do since at a
certain point, print severs just don't scale anymore.
As far as the argument "existing system services", I am somewhat
concerned that this is oversimplified. One would have to look at this
on a case by case and protocol by protocol basis to see if this is
something that is applicable to IPP.
Lastly, from a router vendor's perspective, it is almost mandatory
that a new service is also implemented on a new port number if you
want to have any chance of filtering, prioritizing, or accounting for
it.
Alex.
> Alex, in order to get a better handle on this issue, I'd appreciate some input
> from
> you that speaks to the implementation issues here. I think that Babek makes
> some
> compelling arguments in his responses to your note when he says that (my
> paraphrasing)
>> 1) He's rather use CGI and ASAPI tools than low-level sockets programming
>> 2) Basing IPP on HTTP (at least on Microsoft platforms) lets programmers take
> advantage of many existing APIs and systems services, e.g. security.
>> As someone who represents a developer of network dexices, can you illuminate
> the rest of us on
> the pros and cons of an HTTP based protocol -- from an IMPLEMENTOR'S point of
> view?
> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97
06:45 > AM --------------------------- > > ipp-owner @ pwg.org >
01/04/97 08:25 PM > > > To: jkm @ underscore.com at internet > cc: ipp @
pwg.org at internet > Subject: Re: IPP> What is it we really need? > > > Let's
focus on a simple network printing protocol based on > > the IP protocol suite.
Then, let's address the larger domain > > of "Internet Printing"...whatever that
may mean. > > Jay, > > I am very glad to see you summarizing the current
situation like you > did. I certainly feel supported by you and Harald that a
straight TCP > client-server model would be a better approach. > > One comment I
would like to make about people chanting the "Stock HTTP > Server" mantra: > >
"The Common Gateway Interface, or CGI, is a standard for external > gateway
programs to interface with information servers such as HTTP > servers." > > This
is the definition to be found on the NCSA Web pages. And from all > the
implementation suggestions, it sure sounds like HTTP is only going > to be used
for hand-through to the "external gateway program". Not > much benefit in using
the "Stock HTTP Server". > > Babak from Microsoft has pretty much made the same
point in his mail > from a couple of days ago. > > -- > Alex Bochannek
Phone & Fax : +1 408 526 51 91 > Senior Network Analyst Pager : +1
408 485 90 92 > Engineering Services Alpha Pager : (800) 225-0256 PIN
104536 > Cisco Systems, Inc. Email : abochannek at cisco.com > 170
West Tasman Drive, Bldg. E Pager Email : abochannek at beeper.cisco.com > San Jose,
CA 95134-1706, USA >