>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