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

From: Don Wright <[email-masked]>
Date: 6 Jan 97 22:26:16 EST

On 1/06/97 08:36:51 PM, Keith Moore said:

>Wide industry support is no guarantee of success.  The trade rags bear 
>witness: dozens of standards efforts, each with apparently wide industry 
>representation, many of which fail miserably.
>(neither is the IETF impramatur any assurance of adoption)
>
>If you want the protocol to succeed, make sure you:
>
>a. solve a problem that needs solving.  if you're going to re-invent
>   the wheel (which you are), make sure the result is obviously much
>   better *to users* than the old wheel.

Printing in internet/intranet environments is a clear user need.  With 
the stated direction of both Microsoft and Netscape to provide a
"browser-based desktop" where local and remote resources are
all accessed in a similar manner, it is clearly imperative that
printers be accessed using the same tools and methods.

>b. facilitate products that are easy to configure (on both client
>   and server ends) and use.

See above -- if browser-based access is the norm for everything
else, printers must use the same set of tools.  Printers have always
been the neglected, ugly step children.  We must clearly not let 
that happen in the future.

>c. write a protocol spec that will implemented consistently from one 
>   platform to another, so that arbitrary clients interoperate with 
>   arbitrary servers

This can be done whether we map it to HTTP, SMTP, FTP or
anything else.  Whatever we do, we are must define error
conditions and responses, boundary conditions and state
transitions.  I believe starting with a blank piece of paper
will take much longer than mapping to an exisitng transport.
Once we open everything up (i.e. a blank sheet of paper), 
everyone will try to get one more little tweek forever.

>d. make sure the protocol works reliably

Of course.  Mapping it onto some transport clearly must be done.
Despite horror stories, HTTP works.

>e. don't significantly increase the cost of the product.

Using existing client tools and servers with IISAPI or CGI 
clearly is a low cost solution.

It seems to me that having major printer vendors like Lexmark
and HP as well as the OS and NOS providers like Microsoft,
IBM and Novell behind an HTTP-based solution will almost
guarantee a commercial success.  While working within the 
IETF to define this would be nice, it is not necessary.  As 
Vice-Chair of the IEEE Computer Society's Microprocessor
Standard Committee, I believe we could be chartered by the
IEEE easily.  If the IETF doesn't want us to create a commercial
success then let's move one and do what we, the printing 
experts, need to do to provide what are customers want and
need.

My two cents worth......

Don

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Jan 1997 18:26:35 -0500

> guarantee a commercial success.  

What I want is a well-designed, reliable, and ubiqutous printing
protocol, that makes life easier for users and system administrators.

If this group produces such a thing, I'm happy.  And if they do, I'm
quite confident that printer vendors will sell them like hotcakes.

The purpose of my earlier rebuttal was to caution against hubris.
I've seen lots of well-supported standards efforts produce really
complicated, expensive, and unreliable protocols.

Yes, the support of these vendors will help a lot.  But it's also
important to do good protocol engineering.

> While working within the IETF to define this would be nice, it is
> not necessary.  As Vice-Chair of the IEEE Computer Society's
> Microprocessor Standard Committee, I believe we could be chartered
> by the IEEE easily.

Yes, I'm sure you could.  But neither IEEE's nor IETF's imprimatur is
any assurance of success.  The quality of the work is also important.
That's what I'm trying to address.

If users get a really good printing protocol out of this effort, I
don't care whose umbrella it happens under!

> If the IETF doesn't want us to create a commercial success then
> let's move one and do what we, the printing experts, need to do to
> provide what are customers want and need.

IETF is interested in producing beneficial results in finite time. 

"Beneficial" means that we try really hard to make sure that our
efforts solve a real problem, that the result works well, is low cost,
is easy to use and manage, etc.

"Finite time" means we have a well-defined time frame, realistic and
narrowly focused goals, and that we try to avoid ratholes.

This is just good engineering common-sense.

Of course, the group needs the wisdom of "printing experts" to produce
beneficial results.  It also needs the wisdom of "networking experts".
The latter group cares very much about minimizing operational
complexity and having things interoperate.

The whole HTTP vs. HTTP-lite debate is about how to minimize
complexity.  

Some people feel that simply reusing HTTP accomplishes this, because
there are already tools and libraries available that can be reused.

I believe that this approach minimizes prototyping complexity and
client implementation complexity on some platforms, at the expense of
implementation complexity on *most* of the target platforms
(especially embedded environments), operational complexity, product
cost, and interoperability.

I've got at least half a dozen groups (in IETF) that want to reuse
HTTP for something besides the web.  I'd much rather give them a small
subset to let them embellish, than give them all of the HTTP/1.1 rope
with which to hang themselves.

But there's no point in having a prolonged discussion about it until
there's a spec for HTTP-lite that people can look at.  So I'll try to
get that going.  Once it materializes, people can see whether they
like it.

Meanwhile, I suggest that the group focus on the payload, rather than
the rpc mechanism.

Keith