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

From: [email-masked]
Date: Mon, 6 Jan 1997 13:57:11 -0500

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@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@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: Keith Moore <[email-masked]>
Date: Mon, 06 Jan 1997 16:45:08 -0500

[General note: with all of these mailers out there and their different
ways of quoting the message being replied-to, I'm having a very hard
time sorting out who said what, and in what order.  Please trim
replies so you don't quote more of the previous message than
necessary, use the > convention (or some other prefix character) to
denote text being replied-to, and wrap lines at 72 or so columns.
Thanks!]

Somebody said this:

> 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 performance problems.

Put it this way:

1. If you use full HTTP to define IPP, you have to go through every
feature of HTTP and specify how it interacts with printing, just to
make sure it doesn't cause any problems.  You have to specify how
printers and print clients interact with web cache servers, proxy
servers, and web browsers.  You should probably also define how to
keep Lycos, AltaVista, etc. from indexing your printer.

This is *in addition* to defining the commands that talk to the
printer the format of the responses, the set of printer attributes,
etc.

So I claim that the protocol *specification* will be longer and more
difficult to write if you use HTTP.

I also claim that the resulting protocol will be less reliable.
Having all of those HTTP headers in there just creates more
opportunities for different behavior between client and server.  More
protocol states means more bugs.

2. On the other hand, if you use HTTP-lite, you can avoid the first
step, and keep the protocol simple.

In my mind, HTTP-lite consists of: 

+ a general syntax for commands (or if you prefer, method invocations), 
+ a general syntax for responses,
+ a set of security flavors, and
+ a minimal set of error codes

all of which are borrowed from HTTP, but with none of the methods,
and only a couple of the header fields that are used in HTTP.

The point of HTTP-lite is *minimize* the difficulty of defining and
implementing new application layer protocols, by separating the part
of HTTP that you really want to be able to reuse, from the parts that
are (a) crufty from lack of foresight in HTTP's design, and (b)
heavily optimized for the web.

Even for a box that supports both IPP and HTTP (the latter for
configuration), you should be able to implement HTTP/1.1 on top of
HTTP-lite without adding significant complexity to the HTTP
implementation.

Keith