>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 propose=
d
>something called SIMPLE web printing based on what we were building - =
that
>just did job submission. That eventually evolved into what we have tod=
ay.
... and other job related issues that could be addressed (i.e. Monitori=
ng and
Management).
>Now we move on to address the issues that were lurking in the backgrou=
nd -
>printer discovery, feature dicsovery , configuration discovery, managm=
ent,
>notification, flow control, peer queuing,.... (things for s/w to print=
er
>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 acheiveab=
le
>(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 tha=
t there
has been a sideband approach to job monitoring in co-development for ov=
er two
years.
When the SNMP Job MIB project started, we promptly acknowledged the nee=
d for
submission standards. In late 1995, I lobbied for a job submission "wra=
pper" to
encapsulate submission attributes (i.e. job submission standard) to fac=
ilitate
monitoring via the MIB. This was ill received and it wasn't until submi=
ssion
via the Internet became an issue that we had the opportunity, finally, =
to
correlate the monitoring channel with submission. At first, I was conce=
rned
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 i=
nternet
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 r=
elates
to print jobs. Most of the criticism relates to the unreliable nature o=
f UDP
and the lack of registration and trap direction. SNMPv3 begins to addre=
ss 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 h=
ave
remained for the Friday JMP meeting. Most of the interested parties hav=
e
indicated that their private implementations or prototypes of the stand=
ard have
ALL resorted to some proprietary event mechanism (i.e. Job Traps) to ge=
t 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, co=
rrelated
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 c=
learly
NOTIFICATION!
Harry Lewis
=