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
>