Subject: RE: IPP> Submission vs. Monitoring and Management

From: Paul Moore <[email-masked]>
Date: Mon, 9 Feb 1998 14:09:29 -0800

My primary division ('this thing' and 'the other thing') is - 
- client/app talking to printing subsystem (thing #1)
- printing subsystem talking to printing device (thing #2).

It is not a submission/end-user vs. admin/managment. Bits of these issues
live in both of the interfaces above.

Note that I am not necessarily talking about 3 separate boxes, merely three
separate logical entities. 

I beleive that any printing model that refuses to recognized the existence
of printer servers or other software other than the client app is bound to
ultimately break down.

Note also that we should not confuse end-user experience with protocols.
There does not need to be a one to one mapping between the user feature set
and the protocol. 

For example the argument goes - the user does not distinguish between a
printer and a server therefore we should only have one endpoint. Perfectly
true that this is desirable from a user experience viewpoint, but that does
not mean that what goes on under the hood has to be built that way. 

The current notifcation debate is a perfect example - we all agree that it
should be possible for a user to ask for email telling him that his job has
printed. This does not mean that the protocol has to support that feature,
just that something has to do it. It is perfectly possible to implemnt that
without any modification to the existing protocol (the client polls the
printer for the job, when the job has gone the client send email to the user
- I am not suggesting that this is the right solution, merely that it is a
possibility). Another possibility is that a SNMP trap-like message is sent
to something (we dont have a word for it in the current model) that then
goes 'ahha the job is finished I must send email'.

We now reach the situation that beacuse we want to send notifications one
way, and because we want the user to get email , then all notifications
should go via email, and this is what the protocol should say. So we
effectively have a proposal to replace SNMP traps by human readable email.
This going from one extreme to another.

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.

I dont know if thats clear or not - probably just made things more obscure
:-)

> -----Original Message-----
> From:	Harry Lewis [SMTP:[email-masked]]
> Sent:	Monday, February 09, 1998 12:03 PM
> To:	[email-masked]
> Subject:	IPP> Submission vs. Monitoring and Management
> 
> I'm confused about part of the thread which was "IPP> Consensus on sending
> our
> drafts to the IESG". Here, Paul Moore makes a distinction between job
> submission, for which, in the context of IPP, Microsoft proposed SWP...
> 
> >I saw two problems with two , potentially different, solutions (hence my
> >double vote). I rolled with what I saw as the simple solution (HTTP -
> >interesting that you percieve them the opposite way round) and proposed
> >something called SIMPLE web printing based on what we were building -
> that
> >just did job submission. That eventually evolved into what we have today.
> 
> ... and other job related issues that could be addressed (i.e. Monitoring
> and
> Management).
> 
> >Now we move on to address the issues that were lurking in the background
> -
> >printer discovery, feature dicsovery , configuration discovery,
> managment,
> >notification, flow control, peer queuing,.... (things for s/w to printer
> >interface) and billing, quotas, access control, server managemnt, job
> >redirection, ... (things for client to print subsystem interface).
> 
> In that thread, Paul said:
> 
> >The WG is DETERMINED that this will be done by one protocol - I have
> >expressed (with you and others) my opionion that this is not acheiveable
> >(its desirability is understandable) many times.
> 
> I guess it could be perceived, at this juncture, that the PWG is only
> interested in one, "soup to nuts", printing protocol, but I contest that
> there
> has been a sideband approach to job monitoring in co-development for over
> two
> years.
> 
> When the SNMP Job MIB project started, we promptly acknowledged the need
> for
> submission standards. In late 1995, I lobbied for a job submission
> "wrapper" to
> encapsulate submission attributes (i.e. job submission standard) to
> facilitate
> monitoring via the MIB. This was ill received and it wasn't until
> submission
> via the Internet became an issue that we had the opportunity, finally, to
> correlate the monitoring channel with submission. At first, I was
> concerned
> that the IPP group was going "whole hog", beyond submission, but I was
> reassured that correlation with JMP was paramount (for accounting and
> administration) even if the IETF had rejected the notion of a Job MIB
> internet
> standard. Indeed, Tom (especially), Scott, and others have done a great
> job
> helping see to it.
> 
> I know there is distaste, among some, regarding the use of SNMP as it
> relates
> to print jobs. Most of the criticism relates to the unreliable nature of
> UDP
> and the lack of registration and trap direction. SNMPv3 begins to address
> these
> issues and SENSE goes even farther, with the edition filter. While most of
> the
> IPP people go home Thursday night, there are a substantial number who have
> remained for the Friday JMP meeting. Most of the interested parties have
> indicated that their private implementations or prototypes of the standard
> have
> ALL resorted to some proprietary event mechanism (i.e. Job Traps) to get
> the
> job done. Standardization of job traps is on the Austin agenda.
> 
> So, when I hear the statement
> 
> >The problem is that nobody wants to do the other thing!
> 
> I'm wondering:
> 
> A. What is the other thing?
> B. Is this really true?
> 
> If the other thing is a side band for job monitoring and management,
> correlated
> with the submission protocol in terms of objects and attributes, then I
> think
> there ARE people in the PWG who have demonstrated their desire to do it.
> AND, I
> think the common point between submission and effective monitoring is
> clearly
> NOTIFICATION!
> 
> Harry Lewis

---

From: Jay Martin <[email-masked]>
Date: Tue, 10 Feb 1998 17:52:46 -0500

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

> 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: James Walker <[email-masked]>
Date: Wed, 11 Feb 1998 13:41:20 -0600

Jay Martin wrote:
> ...

No, Jay, you are not "along" (sic).  I would like to second (or third
or fourth) the idea of an industrial-strength host-to-device protocol
as *exactly* what I need.  As others have mentioned, it would *have*
to be widely implemented to do any good (whether it is a standard or
not, I could care less; little good that did for TIPSI).

You know, I will have to admit being slow to come around to this view.
Like many, I was intrigued with the idea of this *inter*net printing
protocol that could be implemented on servers and printers alike, and
solve all the world's printing problems.  However, I have become more
and more disillusioned with the comprimises that we make to try and
satisfy both ends of the spectrum (embedded printers all the way up
to fat print servers).  Also, like some, I do not believe that HTTP
has been the Holy Grail that we all thought it would be.

There have been two observations that have led to some deeper insight
for me on this issue.  The first is that most of the prints in the
world go from a client to a print server, or process of some kind,
and then to the printing device.  There are very few (any?) cases of
a client application talking directly to a printing device.  So what,
you ask?  Well, I say that this implies that there is no requirement
for a single protocol that solves both the client->server and
server->printer cases.  That was one of the things that we were trying
to do with IPP.

The second observation has to do with deployment.  How many of us
really believe that people are going to be hooking up raw printing
hardware (i.e., printers) directly to the internet for people to
print to?  If an *inter*net printing protocol is going to be deployed,
ya' gotta' believe that it is going to be on a high-powered print
server/spooler of some kind.  Although only a very small sample, I
confirmed this with several system administrators (and a marketeer
or two ;-).  Once again, I think that this argues for separate
requirements for the client->server and server->printer protocols.

I would love to see a simple *intra*net printing protocol for driving
printing hardware.  Is it IPP?  No, I do not believe that it is IPP
as it stands; I think that if people were to look at this as an
*intra*net protocol to drive print hardware, there would probably be
some thinning and some changes.  I think that there are at least two
"new" and important concepts coming out of IPP that I would like to
see in a server->printer protocol: the separation of job control
instructions (attributes) from the print data stream, and, in a
related fashion, the ability for the printer to override instructions
in the print data stream with the job control instructions.

What else would be in that protocol?  Would it be just job submission
(and modification/cancellation?), or would it include job and printer
monitoring?  Well, there are at least a couple of vendors that have
already implemented monitoring via SNMP, and if that is what the printer
vendors want to use, then (gulp) us print servers will just have to be
happy with that.  Would it be built on top of HTTP?  I do not care;
once again, if that is what the printer vendors want to do, so be it.
The important point is that it just be a single protocol that becomes
ubiquitous.

One final point about this ubiquity.  It does not do us any good to
design something that nobody builds.  I do not know much about the
history of TIPSI, but it seems a valid case in point.  Although it
is not necessarily a "pretty" protocol, it at least seems to address
these issues of a host->device protocol (in a transport-independent
fashion, to boot!).  But nobody built it (sorry, Don), so who cares?

Sorry about the length of this reply... I guess I had
more to say than I thought!

ramblin'...
...walker

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