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

From: "Wagner, William" <[email-masked]>
Date: Wed, 11 Feb 1998 10:29:31 -0500

You bring up a point which has, to my mind, been a continuing area of
confusion. IPP was originated, among other things, as a replacement to
LPD/LPR (which is a local, intranet ... thing).  It was, to my
understanding, always intended that IPP serve as an intranet as well as
in internet protocol. I think it would be beneficial to get the
consensus on whether IPP is Internet only, or is intended to be used on
any network supporting IP.

However, the IETF appears to doubt that an intranet exists, and if it
does, believes that it is of no concern to the IETF. Therefore, the IPP
has had many requirements added because of internet type considerations
(such as security).  Because of the Internet focus of the IETF and the
resulting burden the IPP spec places on the IPP server, we have
seriously considered the option to implement, in addition to a full IPP,
an IPP compatible (but perhaps not fully conforming) embedded  server
that was intended for just the intranet.  That is, something that had
the same set of user features and would operate with the same user
interface as the full IPP, but which was intended for the 95% (or
better) of printing that does not involve going outside firewalls.

I agree that an IPP which is intended just as a FAX type message
transmission capability is hardly worth the effort or attention that IPP
has received. If that was the intent, I would agree with those who early
on said that the IETF FAX and IPP efforts should be co-ordinated if not
combined.

	As to whether an intranet protocol should cover "all aspects of
a distributed printing system", that may still be pursued. But the
effort had to start somewhere and a submission/delivery protocol did
seem to be the best place to start.

W. A. Wagner (Bill Wagner)
OSICOM/DPI

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, February 11, 1998 7:56 AM
> To:	[email-masked]
> Subject:	Re: IPP> Does the world need a robust host-to-device
> network
> 
>      
>      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: 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.

> 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.
> 
> >      1.  It does not appear that IPP will have much or any impact on the
> 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.  :-(
>

---

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