Hi Harry,
The Xerox community agrees with you that mapping between a CLIENT
generated job submission ID and the managed devices LOCAL job ID
is critical - thus the ClientIdMapTable in the Xerox Job Monitoring
MIB (which Tom Hastings posted to the PWG server over a year ago).
We also agree that it is desirable to register one (or probably
several) 'well-known' forms of client job ID. We have a form
(really a family of forms) which has worked well and has been
in product for over two years. If the JMP folks are interested,
we'll be glad to show them.
Although Xerox (like most of the JMP members) is cautious about
announcing future product plans, I can say for certain that
truly open, standards-based, network management of network
connected products is the end objective of the Xerox community.
Thanks for your efforts prototyping the IETF Job Mon MIB. I
reviewed your very interesting slides last week. Good work!
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
>------------------------ Included Message ----------------------<
Return-Path: <jmp-owner at pwg.org>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA05161; Mon, 31 Mar 97 10:52:16 EST
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA18933; Mon, 31 Mar 97 10:49:48 EST
Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <15431(6)>; Mon, 31 Mar 1997 07:50:22 PST
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA17024 for <imcdonal at eso.mc.xerox.com>; Mon, 31 Mar 1997 10:46:10 -0500 (EST)
Received: by pwg.org (bulk_mailer v1.5); Mon, 31 Mar 1997 10:45:33 -0500
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16932 for jmp-outgoing; Mon, 31 Mar 1997 10:45:27 -0500 (EST)
From: Harry Lewis <harryl at us.ibm.com>
To: <jmp at pwg.org>
Subject: Re: JMP> Calling all Job Monitoring MIB prototypers...
Message-Id: <5030100001059019000002L092*@MHS>
Date: Mon, 31 Mar 1997 07:42:11 PST
Mime-Version: 1.0
Content-Type: text/plain; name="MEMO 03/31/97 10:46:03"
Sender: jmp-owner at pwg.org
Status: R
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