Subject: Re: IPP> What is it we really need?

From: [email-masked]
Date: Mon, 6 Jan 1997 09:16:25 -0500

Classification:
Prologue:
Epilogue:

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@internet
cc: ipp @ pwg.org@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       : [email-masked]
170 West Tasman Drive, Bldg. E Pager Email : [email-masked]
San Jose, CA 95134-1706, USA

---

From: Alex Bochannek <[email-masked]>
Date: Mon, 06 Jan 1997 08:51:24 -0800

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.