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

From: Babak Jahromi <[email-masked]>
Date: Sun, 5 Jan 1997 17:44:10 -0800

>
>"stock" Internet software like web browsers, web servers, and web client
>libraries don't seem particularly helpful for a printing application.

They are helpful. People are doing it.
>
>Yes, it's easy to prototype new protocols using http, but when you try to
>productize those prototypes, you may find there are more features in 
>http 1.1 than you wanted to support in your product.  

HTTP 1.0 and 1.1 support will be on standard "stock" web servers and web
clients, regardless of what IPP is implemented on. We don't have to use
all features of HTTP 1.1 if we don't need to.
>
>I hate to see products and protocols saddled with baggage that nobody needs.
>
>(or are there some other kinds of "stock Internet software" that I'm
>not thinking about?)
Yes. For example, Interent Explorer just uses the underlying Win32
Internet APIs that all others applications could use as well. So each
Windows client machine contains the "stock" Interenet client software
everyone can code to. Notice that by using these APIs, many other issues
like security, encryption, etc. are taken care of as a side effect.

Babak

---

From: Keith Moore <[email-masked]>
Date: Sun, 05 Jan 1997 22:41:39 -0500

> They are helpful. People are doing it.

People are doing lots of useful things with the web.  That doesn't
make them appropriate for standardization.

> all features of HTTP 1.1 if we don't need to.

No, but the features you don't want or need may get in the way
and cause operational difficulties or subtle incompatibilities.

Telnet's NVT protocol was reused for FTP, but the telnet option 
negotiation (which was built-in to the telnet/NVT code on some 
platforms) got in the way.  For this reason, some FTP clients 
had to roll their own NVT code rather than using the built-in 
telnet code.

> Internet APIs that all others applications could use as well. 

This is the same thing I was talking about.

If nothing else, printing protocols and the web each need to evolve 
separately; we need to be very careful about how we tie them together.

Keith

---

From: Randy Turner <[email-masked]>
Date: Mon, 06 Jan 1997 09:51:53 -0800

Keith Moore wrote:
> ..snip..snip.. 

I think we need to decide whether or not we are doing IPP or WPP
(Internet Printing Protocol or Web Printing Protocol)

The statement made by Keith (included in this msg above) I think is
crucial. I haven't thought about the ramifications (and permutations)
of tying a printing protocol to another N-numbered set of technologies
like HTTP, LDAP, CGI, and HTML (if we decide to use forms). It looks
like it might be more than we want to get into, at least from an
interoperability and maintenance standpoint.

At any rate, we need to think about someone that wants to do
printing across the internet, but does not want to be burdened with
the cost of implementing HTTP (or even HTTP-lite).

In this same vein, it would be very difficult to account for IPP
usage if we "hide" the IPP protocol within a set of HTTP accesses,
using the HTTP TCP port number, for example. This echoes the
ideas expressed by Alex earlier, and would also allow net-admins to
create policies that enable/disable HTTP and/or printing as 
separate applications, something that sounds desirable IMHO.

Randy
(Good luck sorting this out in New Mexico ;)

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]