Subject: Re: IPP> Does the world need a robust host-to-device network

From: [email-masked] (Philip Thambidurai)
Date: Wed, 11 Feb 1998 07:56:04 -0500

I would strong argue in favor of such a protocol (what people are 
     referring to as host-to-device), specifically for the Intranet 
     environment, where we have to support several different proprietary 
     protocols/standards today. This new protocol should cover all aspects 
     of a distributed printing system (mananagement, queues/spooling, 
     etc.). IPP is fine for the Internet. But the majority of print jobs 
     will be local (Intranet). I believe this Intranet printing protocol 
     will be far more significant than IPP, if it covers all aspects of 
     printing, not just job submission.  Of course, this might be a 
     difficult proposition because of the "entrenched" 
     protocols/interests/vendors.

     We could always consider this "total printing system" as the focus or 
     central thrust of IPP Version 2. I think the existing IPP Requirements 
     spec is general enough.

     In summary, two issues stand out to me:

     1.  It does not appear that IPP will have much or any impact on the 
     multitude of printing solutions in use today (for the Intranet).
     
     2.  Lack of a ***complete*** standard printing solution within the LAN 
     environment (Intranets included). Today we have to use proprietary 
     solutions.

        Philip Thambidurai

______________________________ Reply Separator _________________________________
Subject: IPP> Does the world need a robust host-to-device network pri
Author:  Jay Martin <[email-masked]> at INTERNET
Date:    2/10/98 5:52 PM

Paul Moore wrote in the "Submission vs. Monitoring and Management"
thread:

> Now if somebody wants to have a separate debate about writing a really
> robust protocol for interfacing to printers (and I mean the real hardware
> not some logical abstraction) then that will suit me fine. Lets start a new
> track and call it, say, NLS (Not LPD and SNMP). This is what I initially
> wanted to do but could not persuade enough people.

Paul, what people were you unable to persuade?  Internal Microsoft
folks, or PWG folks, or both or what?

For fear of sounding as if I'm beating a dead horse to death:

  Enterprise environments desparately need a fully functional
  host-to-device protocol for network printing.

Am I alone in this belief???  (I know for a fact I am NOT along.)

Will others in the PWG share their views using this new thread?
If this belief turns out to be a minority view, then I'd certainly
like to know (so I can drop the subject once and for all, if so).

        ...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Wed, 11 Feb 1998 11:22:39 -0500

Philip,

Many thanks for your supporting comments.

>      multitude of printing solutions in use today (for the Intranet).

I concur completely.  This observation is in diametric opposition to
the position stated by Paul Moore, namely, that IPP is being targeted
as the "all-in-one" protocol for network printing in the future,
whether it be INTERnet or INTRAnet.

Over the last few weeks, several people have contacted me privately
asking me the same sort of question:

  "What (or who) on earth is IPP really good for, anyway?"

This is a question that really needs to be answered, given the
many people who believe IPP adds very, very little value in the
Intranet (aka, enterprise) environment.  Someone is supposed to
be starting a thread for this kind of discussion Real Soon Now.

>      environment (Intranets included). Today we have to use proprietary

Exactly.  Again, people's comments to me come out as:

  "When compared to existing (proprietary/defacto) network printing
   protocols, IPP adds so little that it does not provide the impetus
   to change existing infrastructures in the Intranet environment."

Sure, we can certainly extend IPP in the future (and extend it,
and extend it...), but one critical design flaw exists in IPP (IMHO)
that prevents a clean and simple design:

  IPP is based on HTTP

In the early days of IPP, these assumptions made HTTP the obvious
choice for an INTERnet printing protocol:

  1. We get a free "hole" through the firewall

  2. We get to leverage external work on security models and related
     infrastructure so that we didn't have to do that ourselves

  3. With support from browser vendors, "native" support for IPP
     could be shipped with all standard browsers, thereby offering
     the holy grail of "no client-side software installation"

Sadly, one by one, these critical core assumptions have fallen.

So, why did we stick with HTTP?  Momentum within the group?
(ie, "I already have time and code invested, and I don't
want to throw it away")

IMHO, the only real redeeming value of using HTTP at all
is the ability to leverage common server-side program
invocation services (ie, CGI).  This appears, though, to
only help server-side developers coding for "general purpose"
servers, and not embedded environments.

Comments are welcome and encouraged here.  Feel free to flame
as necessary...  ;-)

	...jay

PS: I realize these comments should be directed to the IESG
    as part of the Last Call period, but I don't know how to
    post comments to the IESG.  :-(

---

From: James Walker <[email-masked]>
Date: Thu, 12 Feb 1998 17:02:38 -0600

Jay Martin wrote:
> ...

I think that this is the nut.  If a print hardware vendor is only going
to embed *one* more protocol into their printer, would it be IPP?  Is
it enough of a good thing to build it?  If you build it, will they come?

To say it another way, is this *the* protocol that all of the print
vendors are going to implement so that, now, I, an application writer,
can migrate to this one protocol to drive all the latest and greatest
print hardware.

On the other hand, if you, Mr. printer vendor, are happy as a clam
to keep embedding protocols until the cows come home, then it does
not matter.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX