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

From: Paul Moore <[email-masked]>
Date: Wed, 11 Feb 1998 19:51:28 -0800

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.

You misunderstand me (Or I misunderstand you). I completely agree with this
thread about needing a robust host-to-device protocol. My main complaint
from day one has been that people are trying to make IPP into 'all things
for all people' and have failed because this cannot be done. This is still
my position and one that I still continue to make. I think that the group as
a whole IS targetting it as the 'all-in-one' solution (it re-affirmed this
at the last WG) - but I dont think it should be. 

I.e dont confuse my analysis of what the WG as a whole has decided IPP
should be with what I think is the right thing to do - they are
diametrically opposed.

This ' all-in-one' approach has several bad effects 

1. People are trying to cram stuff in that does not really fit

2. The is a lack of focus on what real value the IPP could have in its core
space (printing over the public internet)

3. Nobody will look at a device level protocol because 'we can make IPP do
that'. Hence we get into the wierd suggestion that device alerts should be
sent via email!

Regarding the 'value' or otherwise of IPP. I can see some scenarios where it
will be genuinley useful

- printing to service shops that have faster/more functional printers
- printing to your neighbors printer (simpler than sneakernet)
- printing when on the road (hotel business centre for example)

But this is less value than the need I have for a protocol that addresses
the real, actual, support desk pain in the *ssing, end user confusing, money
draining problems that exist in corporates, small businesses and soon in
homes. I doubt that IPP can do it, but (and this is the one change of stance
here) I have decided to see if IPP COULD be pushed into doing it. Having
spent some cycles I am 40/60 (yes/no) on this. Even if it could do it it
would be a huge kludge but something is better than nothing. The other
alternative is to do a different protocol - which I am totally in favor of. 

This sounds like a topic for an Austin BOF.

> -----Original Message-----
> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Wednesday, February 11, 1998 8:23 AM
> To:	Philip Thambidurai
> Cc:	[email-masked]
> Subject:	Re: IPP> Does the world need a robust host-to-device network
> 
> Philip,
> 
> Many thanks for your supporting comments.
> 
> >      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).
> 
> 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.
> 
> 
> >      2.  Lack of a ***complete*** standard printing solution within the
> LAN
> >      environment (Intranets included). Today we have to use proprietary
> >      solutions.
> 
> 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.  :-(
> 
> ----------------------------------------------------------------------
> --  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: Roger K Debry <[email-masked]>
Date: Thu, 12 Feb 1998 07:56:54 -0500

It seems to me that the **ONLY** real value a new printing
standard can add is simply the fact that it is a standard
and supported across a broad set of products that thereby
achieve interoperability.

---

From: Carl Kugler <[email-masked]>
Date: Thu, 12 Feb 1998 15:16:41 -0500

> For one thing, such a protocol would be one heck of a lot more
> efficient than IPP-over-HTTP.  Anytime you frame bulk data within
> a transaction protocol, you lose bigtime in terms of performance.

Then why is file transfer via HTTP typically faster than with FTP?

Also, TCP does provide a mechanism for out-of-band messages within a single
connection.  (Not that HTTP makes any use of it, but telnet does.) "The
asynchronous or "out-of-band" notification will allow the application to go
into 'urgent mode', reading data from the TCP connection. This allows control
commands to be sent to an application whose normal input buffers are full of
unprocessed data."

 -Carl

[email-masked] on 02/12/98 12:40:15 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: Re: IPP> Does the world need a robust host-to-device network

Randy,

> I'm curious how this host-to-device protocol for printing would differ
> from IPP 1.0?

Excellent question.  Right off the top of my head...

For one thing, such a protocol would be one heck of a lot more
efficient than IPP-over-HTTP.  Anytime you frame bulk data within
a transaction protocol, you lose bigtime in terms of performance.

The CPAP designers learned this many years ago; the implementation
of an FTP-like side-band "data channel" is one of the big features
of CPAP v2.  Also note that IEEE 1284.1 (aka "TIPSI", aka "NPAP")
added similar support for a separate data-only channel near the
end of that protocol's development.

In addition to the significant increase in performance, we found
that implementing such a protocol was a lot easier in terms of
structure and complexity.  Always a nice win, to be sure.

Another way the protocol would differ from IPP is in the area
of async messages during the transaction.  As the client submits
a job, the server can inform the client of any number of events
that occur during the transaction, such as device alerts and
other things the client may (or may not, granted) be interested
in.

Using CPAP as an example of this kind of protocol, CPAP has the
ability for the server to convey to the client that the client's
job was terminated (either via the front panel, or by a remote
management app communicating with the server).  Furthermore,
the "job kill" message to the client can include exactly WHO
killed the job, thereby allowing the client to provide an
excellent level of detail to the job submitter as to why the
job failed.

There's more I can say here, but this is at least a start.
I anxiously await comments from others, particularly from you,
Randy!  I'd really like to get this kind of thread rolling.

 ...jay