Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Tom wrote:
>Is it some of the remaining issues, such as how a client can find
>a particular job that passes through a server to a Printer with the MIB?
>Does it take proprietary solutions to solve this problem, so that that
>is why implementors are doing something based on the spec, but not
>actually implementing the spec. Perhaps the proprietary solutions
>can be separate MIBs that merely augments a conforming IETF Job Monitoring
>MIB? Or can we come up with an agreed means that doesn't require any
>proprietary solutions?
Yes, tying together print job submission and print job monitoring
is definitely still an issue. We didn't really have a firm grasp on the
difficulties with the current PWG Job Group until we started
prototyping. The Job ID Group that I propose will accommodate registered forms
of client generated job identification. While I can devise proprietary job ID's
to operate with this MIB, I'd rather engage in open discussion about
feasibility and likelihood of the industry adopting standard formats.
I anticipate 2 areas of "controversy" with respect to my latest proposal. First
is the pwgjmJobSubmissionID (as I've called it), how it gets generated and
whether it is feasible to seek a standard. Second is in the Job State Table ...
the use of a single object pwgjmJobStateValue which has different meaning
depending on the value of another object (pwgjmJobState).
I'm telling you this "up-front" to be completely open and honest about my
proposal and it's potential shortcomings. I think the rest of my Job MIB tracks
the PWG effort closely, as it should, since what I'm presenting is the result
of our attempt to prototype the PWG Job MIB.
Harry Lewis - IBM Printing Systems