From rbergma at dpc.com Thu Jan 2 22:35:56 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Recommended Changes to JMP Objects Message-ID: <199701030335.TAA18583@gate.dpc.com> The Job Monitor MIB project passed a critical test at the IETF meeting in San Jose, thanks to the coordination and scheduling performed by Chris Wellens and the great presentation by Tom Hastings. As a result, the object set, IMHO, should now be developed into a formal IETF MIB document. I hope we can have the first draft document available at the February meeting. In the mean time I would like to present the following changes for consideration and/or discussion. 1. The issue of an index to allow for multiple printer support was discussed in New Orleans. The use of hrDeviceIndex was agreed to be a bad decision for the Printer MIB and should not be propagated in the Job MIB. Tom has proposed jmMIBInstanceIndex for this purpose. While I agreed with the decision from the November meeting to not use hrDeviceIndex, my current opinion has changed. The Job MIB will, most likely, be used in conjunction with the Printer MIB. For the case where the SNMP Agent supports multiple printers, it seems that the use of a common index is essential to correlate the data between the two MIBs. If the use of hrDeviceIndex is really that serious, it should be changed in the Printer MIB. I guess it would be possible to include in the definition that the object jmMIBInstanceIndex and hrDeviceIndex were equivalent, but it would be less confusing to just use the same object. 2. The object jmJobIndex (from my previous proposal as a name change for jmJobLocalId) should be used in place of jmCompletedIndex. This will allow a common identification of jobs between the Job Group and the Completed group. I cannot see any need for a new index for the Completed Group. 3. The object jmJobSourceChannelInformation should be eliminated. The Printer MIB should be used to obtain all required information concerning the selected channel. This information should not be repeated in the Job Monitor MIB. ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com From rbergma at dpc.com Sat Jan 4 13:17:35 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Use of hrDeviceIndex in the Jobs MIB Message-ID: <199701041817.KAA21966@gate.dpc.com> Jay, On 3 Jan 1997, Jay Martin wrote: > Ron, > > Thanks for moving the Job Monitoring MIB along. Some comments > for consideration: > >> 1. The issue of an index to allow for multiple printer support was >> discussed in New Orleans. The use of hrDeviceIndex was agreed to >> be a bad decision for the Printer MIB and should not be propagated >> in the Job MIB. Tom has proposed jmMIBInstanceIndex for this >> purpose. >> >> While I agreed with the decision from the November meeting to not >> use hrDeviceIndex, my current opinion has changed. The Job MIB >> will, most likely, be used in conjunction with the Printer MIB. >> For the case where the SNMP Agent supports multiple printers, it >> seems that the use of a common index is essential to correlate the >> data between the two MIBs. If the use of hrDeviceIndex is really >> that serious, it should be changed in the Printer MIB. >> >> I guess it would be possible to include in the definition that the >> object jmMIBInstanceIndex and hrDeviceIndex were equivalent, but >> it would be less confusing to just use the same object. > > I don't believe I was able to attend the part of the last JMP meeting > during which it was stated: > > "The use of hrDeviceIndex was agreed to be a bad decision for the > Printer MIB and should not be propagated in the Job MIB." > > As I have stated several times before, originally I was not a supporter > of the design approach in which the Printer MIB was "embedded" within > the Host Resources MIB. However, after many, many months of studying > the "big picture", it seems obvious that this must be done IF we need > to manage printers directly attached to a server machine (as is very > often the case with NetWare, Windows/NT and even some Unix server > environments). > > If we are now saying that this approach is a mistake, then we must be > implying that only network-attached printers can "play" with the Printer > MIB. Is this clear to everyone? If the PWG wants to declare that only > network printers are the intended application environment for the Printer > MIB, then so be it...as long as the rest of the world has a clear > understanding of the decision and the rationale behind it. > > Now things get even stickier when we start to say things like: > > "The Job MIB will, most likely, be used in conjunction with the > Printer MIB." > > Is this really true? It certainly is true if a (network) printer > wants to expose its own internal print queue(s). > > But what about the Job MIB being used to generally monitor printing > systems (without regard for the associated printers)? Underscore's > interest in the Job MIB has revolved around exposing the state of > Unix printing systems (LPD, etc), and not just internal printer queues. > If the hrDeviceIndex is required for the Job MIB, will monitoring > native printing systems be precluded? > > I certainly hope not! > > Therefore, I would like to see the Job MIB and the Printer MIB decoupled > as much as possible. It certainly would be nice, however, to have a > nice, clean way to tie a print queue to a printer containing Printer MIB > support. Would it be possible to design a Job MIB object that provides > such a reference? Such an object could be used to provide the value of > the associated printer's hrDeviceIndex (if available), or the object would > contain a "non-applicable" or "unknown" value if no such association is > known or defined. You are 100% correct! My point applies only to the network printer and this index needs to be independent of hrDeviceIndex to be applicable to the general case. I agree that an object needs to be added to define the associated hrDeviceIndex value for the network printer case. ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com From hastings at cp10.es.xerox.com Mon Jan 6 07:29:35 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> Job Monitoring MIB/MIF spec and list, Version 0.5 posted Message-ID: <9701061232.AA02431@zazen> Sorry for the last minute distribution, but I was on vacation for the last two weeks. I've updated and posted version 0.5 of the complete Job Monitoring MIB spec (jmp-spec.*) and version 0.5 of the list of objects by group (jmp-list.*) with the agreements reached at the November JMP meeting in New Orleans. See the minutes (/pub/pwg/minutes/jm961108.doc) for the list of those agreements. Version 0.4 of the jmp-list.* was posted shortly after the November meeting. Version 0.5 has a few changes suggested at the IETF meeting (see below). I've moved all of the ISO DPA specification text to Appendix A as agreed. Appendix B has the comparison with each of the job submission protocols, but probably needs some updating, since we've added some objects to the MIB. The actual specifications of each object needs line-by-line review. We did not have time for such review at the 11/08/96 meeting as indicated in the minutes. Rather we spent the time organizing the objects into groups and tables. We need to do the line-by-line review of the object specifications. There are 15 issues listed in jmp-spec.*. See the end of the table of contents for the list of issues and page numbers. We should process the issues as well at the meeting this week. I forgot to include the issue of directed traps that Jeff Case suggested that we invent on our own, following the example of the RMON MIB. I've posted the files in: ftp://ftp.pwg.org/pub/pwg/snmpmib/jobs-mib/ -rw-r--r-- 1 pwg pwg 42496 Jan 6 11:48 jmp-list.doc -rw-r--r-- 1 pwg pwg 62657 Jan 6 11:49 jmp-list.pdb -rw-r--r-- 1 pwg pwg 55873 Jan 6 11:49 jmp-list.pdf -rw-r--r-- 1 pwg pwg 63670 Jan 6 11:49 jmp-list.pdr -rw-r--r-- 1 pwg pwg 288256 Jan 6 11:49 jmp-spec.doc -rw-r--r-- 1 pwg pwg 392614 Jan 6 11:50 jmp-spec.pdb -rw-r--r-- 1 pwg pwg 332997 Jan 6 11:51 jmp-spec.pdf -rw-r--r-- 1 pwg pwg 397616 Jan 6 11:51 jmp-spec.pdr The .pdf has no revision marks, .pdr has red revision marks and the .pdb has black revision marks. All have line numbers, so use the .pdb or .pdr files, rather than printing from WORD using the .doc file so that we all have the same line numbers. I'll bring 20 copies of the spec and list files with red revision marks (.pdr) The revision marks don't make it too difficult to read, so lets use the .pdr or .pdb versions. In addition to the agreements from the New Orleans meeting, I've made three changes that were suggested at the IETF meeting where I presented all the objects. So these changes are changes since version 0.4 that I posted after the 11/08/96 meeting: 1. I combined jmQueuing and jmQueuingAlgorithm into a single jmGeneralQueuingAlgorithm enum that already includes the "none(3)" value, so we don't need the jmQueuing Boolean. 2. I added the jmDeviceIndex so that a management application can determine the hrDeviceIndex for the associated Printer MIB instance that this job was submitted to or is to be printed on without having to scan the entire jmResourcesTable thereby resolving ISSUE 04. 3. I removed the jmJobSourceChannelInformation, since it can now be obtained easily from the Printer MIB using the jmDeviceIndex object. 4. In reviewing the minutes of the 11/08/96 meeting in New Orleans, I see that I also failed to add the table of MIB instances (see point number 1 in the minutes under Scott's proposal). So the totals are the same: 36 mandatory objects and 7 conditionally mandatory objects 5. The suggestion made at the IETF meeting to count jobs in K, instead of octets, would allow us to combine two 32-bit integer object/attributes into a single object/attribute. I have added this idea as an issue for the group to decide. See jmp-spec.doc. See you in New Mexico. Tom P.S. Sorry to send this to both the JMP and PWG lists, but the JMP list isn't very heavily subscribed yet. I didn't subscribe until a few minutes ago myself. I suspect that after this week, we can avoid duplicate mailings. From hastings at cp10.es.xerox.com Fri Jan 10 03:27:56 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> Template to be filled out with comparson of your Job Message-ID: <9701100830.AA14550@zazen> I've posted the template for each of you to fill in with the comparison of your job monitoring implementations whether they use MIBs or not with our currently agreed list of Job Monitoring MIB objects: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/mono-map.doc ******************************************************************************* Please fill in the comparison with your job monitoring implementations. Please fill out the template by Friday, 17-Jan, and re-post and send e-mail that you've done so. ******************************************************************************* This list reflects that changes agreed at the 8-Jan-1997 JMP meeting. 1. Please fill out each of the three columns provided using MS-WORD: a. obj/attr name - the name of the MIB object or attribute that has the same semantics as the JMP MIB object. b. data type - the data type of your implementation c. any notes on differences, etc. 2. Change the title to reflect your implementation. 3. Add your name 4. Then rename your file to something to reflect your implementation and upload into the following directory: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/ 5. Finally send mail to the jmp DL that you've posted the file and what its name is. Thanks, Tom P.S. I also posted the updated jmp-list.doc .pdf .pdr and .pdb files (.pdf is without revision marks, .pdr is with red revison marks, and .pdb is with black revisions marks.) in: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/jmp-list.* From harryl at vnet.ibm.com Mon Jan 13 14:17:46 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Enterprise Job MIB information Message-ID: <199701131933.OAA07167@lists.underscore.com> As minutes taker for PWG, PMP and JMP last week, I will try to get the package out by tomorrow... meanwhile, I want to bring to everyone's attention one particular action item which was for Tom Hastings to provide a table of Job MIB objects and everyone who has, or is working on, an enterprise Job MIB to (voluntarily) share their set of objects and groupings. This effort was suggested by Lloyd Young following HP's lead as Bob Pentecost shared the Mopier Job MIB with us at the meeting. Our submissions are due Friday so, at least, we need to begin organizing the information now. Harry Lewis - IBM Printing Systems From harryl at vnet.ibm.com Wed Jan 15 10:07:21 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> January Minutes Message-ID: <199701151521.KAA14622@lists.underscore.com> I have posted 3 sets of minutes: pub/pwg/snmpmib/minutes/pwg-0197.doc,ps,txt --- the PWG minutes pub/pwg/pmp/minutes/pmp-0197.doc,ps.txt --- the PMP minutes pub/pwg/jmp/minutes/jmp-0197.doc,ps,txt --- the JMP minutes My minutes probably read more like notes - that's basically what they are. I tried to capture important decisions or assignments either in summary form in the overall PWG minutes (as I did for JMP) or within the specific project minutes (as I did for JMP and PMP). In all cases, I highlighted resolutions and actions in bold italic (.doc and .ps versions). Sorry, I do not have an Acrobat writer. If you find something unintelligible in my notes, please don't hesitate to ask me about it. Happy reading Harry Lewis - IBM Printing Systems From bpenteco at boi.hp.com Wed Jan 15 11:10:00 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:01 2009 Subject: JMP> HP Job Monitoring Solution Message-ID: <01BC02C3.E4A491C0@hpb15767.boi.hp.com> I have uploaded the slides I used for the presentation on HP's Job Monitoring Solution that I gave at the PWG meeting on 8 Jan. You can find the file at: ftp://ftp.pwg.org/pub/pwg/snmpmib/jobs-mib/implementations/hpjob.pdf The slides don't look very good when viewed, but they seem to print okay. Bob Pentecost HP From bwagner at digprod.com Wed Jan 15 18:34:50 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:01 2009 Subject: JMP> February Meetings Message-ID: <00005785.1337@digprod.com> In reading through Harry's minutes (thank you Harry) and my own notes, I am unclear on the actual dates of meetings for February, and would appreciate clarification. 1. PWG notes indicate meeting from 3 to 7 Feb in San Jose PMP interoperability testing 3-5 Feb IPP 6 Feb JMP 7 Feb 2. PMP notes suggest that compatibility test is four days, that it is concerned with testing performed by a maximum of three people from each printer (and management system) vendor. The implication is that testing is concerned with the individual testing of each candidate system/application. 3. There is no mention of a PMP meeting to discuss either the currently active items (explanation and justification of changes from RFC1759), or the results/significance of the compatibility test. Such a meeting may be considered to follow and be independent of the testing itself, being of interest to all PMP participants. 4. Is the intent therefore not to have a PMP meeting in February? What about other PWG projects? Bill Wagner, DPI From walker at dazel.com Thu Jan 16 11:01:07 1997 From: walker at dazel.com (Jim Walker) Date: Wed May 6 14:00:01 2009 Subject: JMP> Re: PMP> Re: IPP> Question about April IPP meeting In-Reply-To: Re: IPP> Question about April IPP meeting> Message-ID: <32DE50C3.12DD@dazel.com> (Sorry about the wide cross-posting, but it seems that this issue *does* effect everybody.) Larry Stein wrote: > > I'll suggest the last week in March. This should'nt interfere with spring > break, IETF, WinHEC or Thanksgiving. If anyone has a problem with this then > send a note to me. This applies to P1284.4, 1394PWG, PWG, IPP? Ahh, but it does interfere with Easter, which is a problem for some! My recollection from the PWG meeting in Albuquerque was that we did discuss both, (1) adding another IPP meeting between the February/San Jose meeting and the April/Austin/Memphis meeting(s), and/or (2) adjusting the April meeting so that either, (a) we scrapped the Austin meeting, and just met in Memphis, or (b) we met some week other than April 2/3. Many permutations of the above were discussed, and the basic decision was to leave things as they were. Was I just amoking and inhaling, or does anybody else remember this? BTW, the PWG minutes do not show discussion of this particular issue, but does suggest that the April meeting be extended to three days (April 2/3/4, presumably in Austin). -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From hastings at cp10.es.xerox.com Thu Jan 16 17:20:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> RESEND: Template to be filled out with comparson of your Message-ID: <9701162222.AA00387@zazen.cp10.es.xerox.com> Reminder that your comparisons of your Job Monitoring implementations with the Job Monitoring MIB objects are due tommorrow. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Fri, 10 Jan 1997 00:27:56 PST >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> Template to be filled out with comparson of your Job > Monitoring implementations with the Job Monitoring MIB objects >Sender: jmp-owner@pwg.org > >I've posted the template for each of you to fill in with the comparison >of your job monitoring implementations whether they use MIBs or not >with our currently agreed list of Job Monitoring MIB objects: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/mono-map.doc > > >******************************************************************************* >Please fill in the comparison with your job monitoring implementations. >Please fill out the template by Friday, 17-Jan, and re-post and send e-mail >that you've done so. >******************************************************************************* > >This list reflects that changes agreed at the 8-Jan-1997 JMP meeting. > >1. Please fill out each of the three columns provided using MS-WORD: > > a. obj/attr name - the name of the MIB object or attribute that has the >same semantics as the JMP MIB object. > > b. data type - the data type of your implementation > > c. any notes on differences, etc. > >2. Change the title to reflect your implementation. > >3. Add your name > >4. Then rename your file to something to reflect your implementation and >upload into the following directory: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/ > >5. Finally send mail to the jmp DL that you've posted the file and what its >name is. > >Thanks, >Tom > >P.S. I also posted the updated jmp-list.doc .pdf .pdr and .pdb files >(.pdf is without revision marks, .pdr is with red revison marks, and >.pdb is with black revisions marks.) in: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/jmp-list.* > > > > From mabry at rd.qms.com Fri Jan 17 15:32:57 1997 From: mabry at rd.qms.com (mabry@rd.qms.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Template to be filled out with comparson of your Jo In-Reply-To: Template to be filled out with comparson of your Jo> Message-ID: <9700178535.AA853540377@rdccout.rd.qms.com> I have posted a file: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/qms-map.doc which contains my feeble attempts at filling out the tables in the template. I understood that we were to describe *any* method that we currently use to monitor jobs, so there is some stuff at the bottom of the file that may or may not be interesting. I did include a portion of our vendor specific MIB for reference. There are several of the objects in the job mib that can be deduced from the objects that QMS supports, I still left them as N/A. I hope this helps, I am still a relatively newcomer to this project, and probably do not understand all of the objects (yet). Mabry --------------------------------------------------------------------------- Mabry Dozier ################################## ######### mabry@rd.qms.com # ## ##### ## # ########: (334) 633-4300 x-1533 # ##### ## ### ## ####### # .: # ## # ## # # # ## # ## .:: # ### ## ## ## ######## # ## .::: QMS Incorporated # _ ## ####### ## # ## .::::: One Magnum Pass ################################## #.::::::: R Mobile, AL 36618 ..Where Imagination Leads http://www.qms.com --------------------------------------------------------------------------- ______________________________ Reply Separator _________________________________ Subject: JMP> Template to be filled out with comparson of your Job Author: Tom Hastings at smtplink-rd Date: 1/10/97 2:28 AM I've posted the template for each of you to fill in with the comparison of your job monitoring implementations whether they use MIBs or not with our currently agreed list of Job Monitoring MIB objects: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/mono-map.doc ******************************************************************************* Please fill in the comparison with your job monitoring implementations. Please fill out the template by Friday, 17-Jan, and re-post and send e-mail that you've done so. ******************************************************************************* This list reflects that changes agreed at the 8-Jan-1997 JMP meeting. 1. Please fill out each of the three columns provided using MS-WORD: a. obj/attr name - the name of the MIB object or attribute that has the same semantics as the JMP MIB object. b. data type - the data type of your implementation c. any notes on differences, etc. 2. Change the title to reflect your implementation. 3. Add your name 4. Then rename your file to something to reflect your implementation and upload into the following directory: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/ 5. Finally send mail to the jmp DL that you've posted the file and what its name is. Thanks, Tom P.S. I also posted the updated jmp-list.doc .pdf .pdr and .pdb files (.pdf is without revision marks, .pdr is with red revison marks, and .pdb is with black revisions marks.) in: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/jmp-list.* From harryl at vnet.ibm.com Fri Jan 17 16:23:56 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> IBM Job MIB mapping Message-ID: <199701172127.QAA29711@lists.underscore.com> I posted the IBM comparison, as requested, to \snmpmib\jobs-mib\mono-map. It's called MONO-IBM.DOC (sorry, I used drop and drag from W95 in my Netscape browser and it made it all caps). I see Jeff (or someone) has setup a similar subdirectory under \jmp which is a better place, but I followed Tom's instructions. Perhaps they will all be moved? Harry Lewis From lpyoung at lexmark.com Fri Jan 17 17:00:26 1997 From: lpyoung at lexmark.com (Lloyd Young) Date: Wed May 6 14:00:01 2009 Subject: JMP> Lexmark's implementation on Job Monitoring Message-ID: <199701172201.AA25712@interlock.lexmark.com> I have posted Lexmark's implementation on Job Monitoring in the following directory: ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map The file name is lex-map with file types of .doc and .pdf. Lloyd Young Phone: (606) 232-5150 Lexmark International Inc. Fax: (606) 232-6740 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40511 From kcarter at VNET.IBM.COM Fri Jan 17 19:02:05 1997 From: kcarter at VNET.IBM.COM (kcarter@VNET.IBM.COM) Date: Wed May 6 14:00:01 2009 Subject: JMP> OS/2 Warp Job MIB Mapping Available Message-ID: <199701180005.TAA02024@lists.underscore.com> JMP Team, Files os2-map.doc and os2-map.ps are in /pub/pwg/snmpmib/jobs-mib/mono-map/. File os2warp-assessment.ps is in /pub/pwg/jmp/slides which is the presentation I made in November to the PWG on the OS/2 Warp Assessment of the Job MIB. I'll post the pdf file on Monday. Enjoy, Keith From rbergma at dpc.com Mon Jan 20 22:35:59 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Job MIB Mapping Conference Call Message-ID: <199701210336.TAA04820@gate.dpc.com> Lloyd Young has set up a JMP conference call to discuss the current private MIB Job Monitoring implementation comparisons to the JMP MIB. There have been 4 mappings posted as of this afternoon. I have the mappings for Dataproducts but have not been successful in logging on to the server. I will try again tonight from home. Mappings have been posted from: QMS IBM (printer) IBM (OS/2 Warp) Lexmark We are still missing HP and Xerox! The conference call details are: Phone number: 423-673-6717 Access code: 820010 Date: Thursday 1/23 Time: 4:00 pm EST (1:00 pm PST) # of lines reserved: 20 --------------------------------------------------------------------- Ron Bergman Dataproducts Corp. rbergma@dpc.com (805)578-4421 From hastings at cp10.es.xerox.com Wed Jan 22 02:26:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> I've posted Printxchange mapping to Job Monitoring MIB Message-ID: <9701220727.AA01503@zazen.cp10.es.xerox.com> In /ftp://ftp.pwg.org/pub/pwg/snmpmib/jobs-mib/mono-map/ -rw-r--r-- 1 pwg pwg 38912 Jan 22 07:22 xeroxmap.doc -rw-r--r-- 1 pwg pwg 58423 Jan 22 07:23 xeroxmap.pdf Tom From rbergma at dpc.com Wed Jan 22 12:11:24 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Dataproducts Job MIB Mapping Message-ID: <199701221711.JAA09285@gate.dpc.com> I have successfully loaded the Dataproducts Job MIB mapping to the PWG server. The document can be found at - ftp://ftp.pwg.org/pwg/jmp/jobs-mib/mono-map/dpc-map.doc Don't forget the conference call on Thursday at 4:00 pm EST (1:00 pm PST) --------------------------------------------------------------------- Ron Bergman Dataproducts Corp. rbergma@dpc.com (805)578-4421 From kcarter at VNET.IBM.COM Thu Jan 23 15:03:31 1997 From: kcarter at VNET.IBM.COM (kcarter@VNET.IBM.COM) Date: Wed May 6 14:00:01 2009 Subject: JMP> JMP telecon Message-ID: <199701232004.PAA26366@lists.underscore.com> JMP Team, FYI. I will participate in the JMP telecon today (1/23) from 3-4 Central Time. I have a "hard stop" at 4 at which time I'll quietly go away. Keith From bogus@does.not.exist.com Thu Jan 23 15:20:34 1997 From: bogus@does.not.exist.com () Date: Wed May 6 14:00:01 2009 Subject: No subject Message-ID: <> Tom & JMP, I'm trying to ftp my file, but no success so far. I've attached a copy in order to try to get it out before the phone conference. Bob ---------- From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] Sent: Thursday, January 23, 1997 11:37 AM To: bpenteco@boi.hp.com Cc: rbergma@dpc.com; THast@cp10.es.xerox.com Subject: JMP> Template to be filled out with comparson of your Job Monitoring implementations with the Job Monitoring MIB objects Bob, Thanks for posting your slides on the HP Mopier Job Monitoring MIB. Any chance you could fill out the form with your implementation? We will be discussing this afternoon at 1:00 pm PST Thanks, Tom >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Fri, 10 Jan 1997 00:27:56 PST >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> Template to be filled out with comparson of your Job > Monitoring implementations with the Job Monitoring MIB objects >Sender: jmp-owner@pwg.org > >I've posted the template for each of you to fill in with the comparison >of your job monitoring implementations whether they use MIBs or not >with our currently agreed list of Job Monitoring MIB objects: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/mono-map.doc > > >*********************************************************************** ******** >Please fill in the comparison with your job monitoring implementations. >Please fill out the template by Friday, 17-Jan, and re-post and send e-mail >that you've done so. >*********************************************************************** ******** > >This list reflects that changes agreed at the 8-Jan-1997 JMP meeting. > >1. Please fill out each of the three columns provided using MS-WORD: > > a. obj/attr name - the name of the MIB object or attribute that has the >same semantics as the JMP MIB object. > > b. data type - the data type of your implementation > > c. any notes on differences, etc. > >2. Change the title to reflect your implementation. > >3. Add your name > >4. Then rename your file to something to reflect your implementation and >upload into the following directory: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/mono-map/ > >5. Finally send mail to the jmp DL that you've posted the file and what its >name is. > >Thanks, >Tom > >P.S. I also posted the updated jmp-list.doc .pdf .pdr and .pdb files >(.pdf is without revision marks, .pdr is with red revison marks, and >.pdb is with black revisions marks.) in: > > ftp://ftp.pwg.org/pub/snmpmib/jobs-mib/jmp-list.* > > > > begin 600 hp-map.doc MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M````2 ``````````$ ``20````$```#^____`````$<```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________ ``Y ,``"QX````````$'P` M```````0? ```````!!\```0````('P``"(```!"? ``B ```"QX```````` MF8L``)4```#*? ``! ```,Y\```6````Y'P```````#D? ```````.1\```` M````Y'P```````#D? ```````.1\````````?H<```(```" AP```````("' M````````@(<``$\```#/AP``U@$``*6)``#6`0``>XL``!X````NC ``6 `` M`(:,``!D````F8L`````````````````````````````8G<```````#D? `` M````````&0`>``4`%@#D? ```````.1\```````````````````````````` M`.1\````````Y'P```````"9BP```````*:%````````8G<```````!B=P`` M`````.1\`````````````````````````````,I\````````IH4```````"F MA0```````*:%````````Y'P``,((``!B=P```````.1\````````8G<````` M``#D? ```````'Z'``````````````````#@3==C9@F\`79W``!$````NG<` M`'(```"L=@``1 ```/!V``!R````8G<```````!B=P```````.1\```````` M?H<```````"FA0``V $``*:%```````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````!#;VUP87)I2!O9B!T:&4@:FU*;V)3971%;G1R>2!W M:&EC:"!I&5D(&)Y.@UJ;4IO8E-E=$EN9&5X("T@(&$@"!O9B!*;V(@4V5T(&EN7!E!T]B:B]A='1R(&YA;64'1&%T82!T>7!E!TYO=&5S!P=J;4IO8E-E=$EN M9&5X("T@82!R=6YN:6YG(&EN9&5X(&]F($IO8B!3970@:6YS=&%N8V5S('-U M<'!O2!T:&ES('!R:6YT97(@;W(@2!T:&ES('!R:6YT M97(@;W(@7!E!T]B M:B]A='1R(&YA;64'1&%T82!T>7!E!TYO=&5S!P=J;4IO8E-E=$EN9&5X("T@ M82!R=6YN:6YG(&EN9&5X(&]F($IO8B!3970@:6YS=&%N8V5S('-U<'!O2!T:&ES('!R:6YT97(@;W(@&EM=6T@;G5M8F5R(&]F(&IO8CL@*"TQ*2!M M96%N,S$M,2D'!P<'!VIM1V5N M97)A;$-U2!A;F0@&5D(&)Y.@UJ;4IO8E-E=$EN M9&5X("T@(&$@"!O9B!*;V(@4V5T(&EN,S$M,2D'!P<'!VIM475E=65);F1E>" M('1H M92!J;V*22!T:&4@<')I;G1E,S$M,2D'!P<'!VIM2F]B4')I;W)I='D@+2!*;V(@<')I M;W)I='D'26YT96=E2!O9B!T:&4@:FU# M;VUP;&5T961486)L92!W:&EC:"!I&5D(&)Y.@UJ;4IO8E-E=$EN9&5X("T@ M(&$@"!O9B!*;V(@4V5T(&EN" M(&$@"!O9B!T:&4@:F]B7!E!T]B:B]A='1R(&YA;64'1&%T82!T>7!E!TYO=&5S!P=J;4IO8E-E=$EN M9&5X("T@82!R=6YN:6YG(&EN9&5X(&]F($IO8B!3970@:6YS=&%N8V5S('-U M<'!O2!T:&ES('!R:6YT97(@;W(@" M(&$@"!O9B!T:&4@:F]B,S$I!P<'!P=J;4IO8DEN9&5X("T@=&AE(&IO M8I)S(&ED96YT:69I97(@9V5N97)A=&5D(&)Y('1H92!P2!O9B!T:&4@:FU*;V)486)L92!W:&EC:"!I M&5D(&)Y.@UJ;4IO8E-E=$EN9&5X("T@(&%N(&EN2!T:&ES('!R:6YT97(@;W(@" M('1H92!J;V*2,S$M,2D' M!P=!(&IO8B!)1"!I71H:6YG('1H870@:&5L<',@:61E;G1I M9F5R('1H92!J;V(@=&\@=&AE(&IO8B!S=6)M:71T97(L(&EN8VQU9&EN9R!T M:&4@;F%M92!O9B!T:&4@<75E=64@9G)O;2!W:&EC:"!T:&4@:F]B('=A2!T:&4@3D%-13T@<&%R86UE=&5R(&]F('1H92! 4$I,($I/0B!C M;VUM86YD!P=J;4IO8DYU;6)E2!T:&4@:F]B('-U8FUI='1I;F<@2!A(&IO8B!I9&5N=&EF:65R(&YU;6)E,S$M,2D'2F]B240':6YT96=E<@=02DP@2F]B($%T=')I8G5T92 + M2F]B(&YU;6)E2!S=6)M:71T960@<')I;G0@:F]B*0=/0U1%5"!35%))3D2!T:&4@"!O9B!C:&%N;F5L(')O=R!I;B!T:&4@4')I;G1E =J;V(M:6YF;RUI;RUS;W5R8V4'26YT96=E<@<'!VIM M2F]B4W5B;6ES7-T96TH M,2DL"V-$97-T:6YA=&EO;E-U8G-YF4'26YT M96=E<@<'!P<'!P<'!VIM2F]B4W1A2!J;V(@2!O M9B!T:&4@:FU297-O=7)C951A8FQE('=H:6-H(&ES(&EN9&5X960@8GDZ#6IM M2F]B4V5T26YD97@@+2 @86X@:6YS=&%N8V4@:6YD97@@=&\@9&ES=&EN9W5I M2!T:&4@2!T:&ES('!R:6YT97(@;W(@2!T:&4@7!E!P<'!P=D;V-U;65N=$YA;64H,RD@+2!$;V-U;65N="!N86UE M*',I("AO,S$M,2D':F]B+6EN9F\M0<'!P<' M<&AY7-I8V%L(&1E=FEC97,@ <'!P<'9F%X4&AO;F5.=6UB97(H,3 I M("T@1D%8('!H;VYE(&YU;6)E,S$M,2D' M:F]B+6EN9F\M<&%G97,M<')I;G1E9 =I;G1E9V5R!P<'2!G96YE2!P2X'!W!A9V5S0V]M<&QE=&5D0W5R2X'26YT96=E,S$M,2D':F]B+6EN9F\M<&%G92UC;W5N M="UC=7)R96YT+6]R:6=I;F%L!VEN=&5G97('!P=P7-I8V%L(&]U='!U="!B:6YS(&]F(&]P=&EO M;F%L(&]U='!U="!D979I8V4N!P=J;5)E!8``*D6``#\%@``_A8` M``T7``#-%P``\1<``%,8``!=& ``NA@``-T8``#?& ``Z1@``/X`_@#^`/X` M_@#^`/X`_@#\_@#^`/S^`/X`_@#^`/X`_@#^`/KW_@#^`/X`_@#^`/X`_@#U M`/X`_@#^`/X`_@#^`/KW_@#^`/X`_@#^`/X`_@#^`/[S`/X`_@#^`/X`_@`` M`UT#``)6@0`%58%=`@`#8Q@``UT"``)5@6#I& ``,AD``%X9``!R&0``AQD` M`)H9``"S&0``!1H``!\:```@&@``+QH``/\:```7&P``&1L``"L;``"&&P`` ML1L``+,;``#&&P``\AL``!$<```D' ``,!P``#\<``!8' ``91P``'<<``"> M' ``GQP``+(<``#Z' ``(!T``#,=```T'0``.!T``#D=```Z'0``11T``&$= M``!B'0``B1T``(H=``";'0``J1T``+ =``"R'0``O!T``+X=``#''0``SQT` M`%$>```U'P``1A\``.<``L A" '&``+ (0@!P@`!P"$(`;\``>(+4 &_ M``)@`R !OP`"% 0@`;\``10$( &_``'7!2 !HP`!UP4@`7\`!.(+" %W```` M````=P`!% 0(`7<``10$" %W``'7!0@!ZP`!UP4(`7\`!N(+" %W```````` M=P`!% 0(`7<``10$" $````'```5% `8`0\%``'\````(P``#0H1: $3F/X5 M% `8`0PT```!" ```8 ```$`: $````````N```````````````````````` M````````````````````&P``& $9`;AL`+D!N@&[&0`9`!D`&0`)``D`O@X` M!93_3@R&$'(57AH-(;\*``P`# `,``P`# `"$@`8`0`#```1T (``" ```T* M$3@$$YC^##0```$(```!@ ```0!H`0```````"X````````````````````` M``````````````````````$````!`@``% ``& $9`;AL`+D!NQD`&0`9`!D` M"0`)`+X.``64_TX,AA!R%5X:#2$5(0@``"((```C" ``;@@``(,(``"$" `` MA0@``(8(``"'" ``\P@```@)```)"0``"@D```L)```,"0``=@D``(H)``"+ M"0``C D``(T)``"."0``CPD``* )``!_"P``^ `!UP4(`>,``=<%" &_``/B M"P@!N@```````+H``10$" &Z``$4! @!N@`!UP4(`>,``=<%" &_``7B"P@! MN@```````+H``10$" &Z``$4! @!N@`!UP4(`>,``=<%" &6``3B"P@!N@`` M`````+H``10$" &Z``$4! @!N@`!UP4(`>,``=<%" &4``' (0@!D@`````` M`) `!L A" $``````````````````````````````````````````0````$" M```!$ ``(P``#0H1: $3F/X5% `8`0PT```!" ```8 ```4`: $````````N M````````````````````````````````````````````! ``%10`& $``",` M``T*$6@!$YC^%10`& $,- ```0@```& ```!`&@!````````+@`````````` M`````````````````````````````````!0``!@!&0&X; "Y`;L9`!D`&0`9 M``D`"0"^#@`%E/].#(80&@TA``<``!44`!@!#P4``?P``!=_"P``V@L` M`"@,```I# ``.@P``$,,``!1# ``6PP``&$,``!B# ``O P``,\,``#0# `` MT0P``-(,``#3# ``(0T``#8-```W#0``. T``#D-```Z#0``WP`"P"$(`=\` M`< A" '=``' (0@!V@`!X@M0`=H``F #( ':``(4!" !V@`!% 0@`=H``=@% M( &^``'8!2 !F@`$X@L(`9(```````"2``$4! @!D@`!% 0(`9(``=@%" %] M``'8!0@!F@`#X@L(`9(```````"2``$4! @!D@`!% 0(`9(``=@%" %]``'8 M!0@!````````````````````% ``& $9`;AL`+D!NQD`&0`9`!D`"0`)`+X. M``64_TX,AA!R%5X:#B$`!P``%10`& $/!0`!_ ```",```T*$6@!$YC^%10` M& $,- ```0@``/__```!`&@!````````+@`````````````````````````` M`````````````````!L``!@!&0&X; "Y`;H!NQD`&0`9`!D`"0`)`+X.``64 M_TX,AA!R%5X:#B&_"@`,``P`# `,``P``A(`& $``1 ``" ```T*$3@$$YC^ M##0```$(```!@ ```0!H`0```````"X````````````````````````````` M````````````%3H-``":#0``KPT``+ -``"Q#0``L@T``+,-``#\#0``$0X` M`!(.```3#@``% X``!4.```R#@``1 X``$4.``!&#@``1PX``$@.``!S#@`` M@PX``(0.``"%#@``A@X``(<.``#7#@``[PX``-P`!.(+" '7````````UP`! M% 0(`=<``10$" '7``'8!0@!P@`!V 4(`=P``^(+" &Z````````N@`!% 0( M`;H``10$" &Z``'8!0@!P@`!V 4(`=P``>(+" '7````````UP`!% 0(`=<` M`10$" '7``'8!0@!P@`!V 4(`9@``N(+" &5````````E0`!% 0(`94``10$ M" &5``'8!0@!P@`!V 4(`9@``^(+" &5``1@`P@!```````````"```8`0`A M```-"A%H`1.8_A@!##0```$(```!@ ```0!H`0```````"X````````````` M``````````````````````````````<``!44`!@!#P4``?P````4```8`1D! MN&P`N0&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(0`$```5% `8`0`` M(P``#0H1: $3F/X5% `8`0PT```!" ```8 ```$`: $````````N```````` M```````````````````````````````````:[PX``/ .``#Q#@``\@X``/,. M``#T#@``"0\``+$/```,$ ``6A ``%L0``!P$ ``>1 ``(<0``"1$ ``EQ ` M`)@0``#R$ ``!Q$```@1```)$0``"A$``/T```````#]``$4! @!_0`!V 4( M`>@``=@%" 'F``' (0@!Y ```````.(``L A" '!``+ (0@!P0`!P"$(`>8` M`< A" &^``'B"U !O@`"8 ,@`;X``A0$( &^``$4!" !O@`!V 4@`:(``=@% M( %^``3B"P@!=@```````'8``10$" %V``$4! @!=@`!V 4(`0`'```5% `8 M`0\%``'\````(P``#0H1: $3F/X5% `8`0PT```!" ``__\```$`: $````` M```N````````````````````````````````````````````&P``& $9`;AL M`+D!N@&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(;\*``P`# `,``P` M# `"$@`8`0`@```-"A$X!!.8_@PT```!" ```8 ```$`: $````````N```` M```````````````````````````````````````!`````0(```$0```4```8 M`1D!N&P`N0&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(0`"```8`14* M$0``"Q$``%D1``!L$0``;1$``&X1``!O$0``L``=@%" &;``3B"P@!E@```````)8``10$ M" &6``$4! @!E@`!UP4(`8$``=<%" %_````````?0`#P"$(`5P``L A" $` M````( ``#0H1. 03F/X,- ```0@```& ```!`&@!````````+@`````````` M`````````````````````````````````0````$"```4```8`1D!N&P`N0&[ M&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH-(0`$```5% `8`0``(P``#0H1 M: $3F/X5% `8`0PT```!" ```8 ```$`: $````````N```````````````` M````````````````````````````!P``%10`& $/!0`!_ ```",```T*$6@! M$YC^%10`& $,- ```0@``/__```!`&@!````````+@`````````````````` M`````````````````````````!0``!@!&0&X; "Y`;L9`!D`&0`9``D`"0"^ M#@`%E/].#(80&@XA$$03``"H$P``J1,``,D3``#2$P``X!,``.H3``#P M$P``\1,``$P4``!A% ``8A0``&,4``!D% ``910``,44``#:% ``VQ0``-P4 M```'%0``"!4```D5``#?``+ (0@!W0`!P"$(`=H``N(+4 ':``)@`R !V@`" M% 0@`=H``10$( ':``'8!2 !O@`!V 4@`9H`!.(+" &2````````D@`!% 0( M`9(``10$" &2``'8!0@!?0`!V 4(`9H`!.(+" %X````````> `!% 0(`7@` M`10$" %X``/8!0@!?0`#V 4(`7@``>(+" $```````0``!44`!@!```4```8 M`1D!N&P`N0&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(0`'```5% `8 M`0\%``'\````(P``#0H1: $3F/X5% `8`0PT```!" ``__\```$`: $````` M```N````````````````````````````````````````````&P``& $9`;AL M`+D!N@&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(;\*``P`# `,``P` M# `"$@`8`0`!$ ``( ``#0H1. 03F/X,- ```0@```& ```!`&@!```````` M+@`````````````````````````````````````````5"14```H5```+%0`` M#!4```T5```.%0``6A4``'$5``!R%0``18``) 6``"> M%@``J18``/T6``#^%@``SA<``.,7``#I%P``\1<``%(8``!3& ``NA@``-L8 M``#<& ``W1@``-X8``#[````````^P`!% 0(`?L``10$" '[``'8!0@!Y@`! MV 4(`<(``^(+" '[````````^P`!% 0(`?L``10$" '[``'8!0@!Y@`!V 4( M`9X`"N(+" '[````````^P`"% 0(`?L``10$" '[``?8!0H!Y@`'V 4*`9X` M".(+" '[````````^P`!% 0(`?L``10$" '[``C8!0@!Y@`(V 4(`9X`!.(+ M" '[````````^P`!% 0(`?L``10$" '[``'8!0@!`````",```T*$6@!$YC^ M%10`& $,- ```0@``/__```!`&@!````````+@`````````````````````` M`````````````````````",```T*$6@!$YC^%10`& $,- ```0@```& ```# M`&@!````````+@```````````````````````````````````````````!0` M`!@!&0&X; "Y`;L9`!D`&0`9``D`"0"^#@`%E/].#(80&@XA``0``!44 M`!@!`!S>& ``WQ@``#(9``!)&0``4AD``%X9``!Q&0``L``M@%" '"````````P@`! M8 ,(`<(``A0$" '"``$4! @!P@`"V 4(`>L``M@%" &>``7B"P@!P@`````` M`,(``10$" '"``$4! @!P@`!V 4(`>L``=@%" ''``CB"P@!P@```````,(` M`10$" '"``$4! @!P@`!V 4(`>L``=@%" ''``7B"P@!P@```````,(``A0$ M" $`````(P``#0H1: $3F/X5% `8`0PT```!" ```8 ```@`: $````````N M````````````````````````````````````````````! ``%10`& $``",` M``T*$6@!$YC^%10`& $,- ```0@``/__```!`&@!````````+@`````````` M`````````````````````````````````!0``!@!&0&X; "Y`;L9`!D`&0`9 M``D`"0"^#@`%E/].#(80&@XA'*D;``"Q&P``LAL``+,;``#R&P``_AL` M``D<```1' ``(QP``"0<```_' ``5AP``%<<``!8' ``61P``%H<``!;' `` M=QP``( <``".' ``F!P``)X<``"?' ``^P```````/L``=@%" 'F``'8!0@! MP@`#X@L(`?L```````#[``(4! @!^P`!% 0(`?L``M@%" 'F``+8!0@!P@`" MX@L(`?L```````#[``$4! @!^P`!% 0(`?L``=@%" 'F``'8!0@!P `!P"$( M`;T``N(+4 &]``)@`R !O0`"% 0@`;T``10$( &]``'7!2 !H0`!UP4@`0`` M```````````````````````````````````````````````````````````` M```````````````````````````````````````;```8`1D!N&P`N0&Z`;L9 M`!D`&0`9``D`"0"^#@`%E/].#(80&@TAOPH`# `,``P`# `,``(2`!@! M``$````C```-"A%H`1.8_A44`!@!##0```$(``#__P```0!H`0```````"X` M```````````````````````````````````````````4```8`1D!N&P`N0&[ M&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH.(0`$```5% `8`0`6GQP``/L< M```0'0``&!T``" =```S'0``-!T``#4=```V'0``-QT``#@=```Y'0``.AT` M`#L=``!B'0``:QT``'D=``"#'0``B1T``(H=``#/'0``VAT``-X`!.(+" '; M````````VP`!% 0(`=L``10$" ';``+7!0@!Q@`"UP4(`=L```````#;``%@ M`P@!VP`!% 0(`=L``10$" ';``'7!0@!Q@`!UP4(`<0``< A" &_``/B"U ! MO `"8 ,@`;P``A0$( &\``$4!" !O `!UP4@`: ``=<%( %\``/B"P@!=P`" M8 ,(`0````0``!44`!@!```C```-"A%H`1.8_A44`!@!##0```$(```!@ `` M#0!H`0```````"X````````````````````````````````````````````; M```8`1D!N&P`N0&Z`;L9`!D`&0`9``D`"0"^#@`%E/].#(80&@TAOPH` M# `,``P`# `,``(2`!@!``02`!"^`A@!```!````% ``& $9`;AL`+D!NQD` M&0`9`!D`"0`)`+X.``64_TX,AA!R%5X:#2$``@``& $`(0``#0H1: $3F/X8 M`0PT```!" ```8 ```P`: $````````N```````````````````````````` M`````````````!7:'0``\1T```8>```7'@``*QX``$4>``!1'@``M1X``/T> M```T'P``-1\``.8`!=<%" '"``CB M"P@!^P`%8 ,(`?L``10$" '[``$4! @!^P`!UP4(`>8``=<%" '"``3B"P@! M^P`#8 ,(`?L``A0$" '[``$4! @!^P`!UP4(`>8``=<%" '[``'B"P@!^P`! M8 ,(`?L``10$" '[``$4! @!^P`!UP4(`>8``=<%" '"``/B"P@!^P`"8 ,( M`?L``10$" '[``$4! @!^P`!UP4(`>8``=<%" $`````````````(P``#0H1 M: $3F/X5% `8`0PT```!" ```8 ``! `: $````````N```````````````` M````````````````````````````% ``& $9`;AL`+D!NQD`&0`9`!D`"0`) M`+X.``64_TX,AA!R%5X:#2$`! ``%10`& $`(@TA``!2(0``7B$``%\A``!@ M(0``82$``&(A``""(0``F2$``)HA``";(0``G"$``)TA``">(0``GR$``*4A M``"P(0``U2$``.(A``#C(0``Y"$``.4A``#S(0``_R$``#0B```U(@``-B(` M`#(+" &=``%@`P@!G0`"% 0(`9T``10$" &=``77!0@!Q@`% MUP4(`9T``>(+" &=``%@`P@!G0`!% 0(`0``! ``%10`& $``",```T*$6@! M$YC^%10`& $,- ```0@```& ```0`&@!````````+@`````````````````` M`````````````````````````!0``!@!&0&X; "Y`;L9`!D`&0`9``D`"0"^ M#@`%E/].#(80&@TA``(``!@!`"$```T*$6@!$YC^& $,- ```0@```& M```0`&@!````````+@`````````````````````````````````````````< M/"(``$@B``"K(@``K"(``*TB``"N(@``MB(``,$B``#E(@``YB(``.&@TA``0``!44`!@!`"!X)0``>24``-0E``#>)0``WR4``. E``#A)0`` MXB4``$@F``!7)@``6"8``%DF``!:)@``6R8``+ F``"Z)@``NR8``+PF``"] M)@``Y `!UP4@`< `!.(+" &Z``)@`P@!L@```````+(``10$" &H``'7!0@! MDP`!UP4(`6\`!.(+" &Z``)@`P@!:@```````&H``10$" &Z``'7!0@!DP`! MUP4(`< `!.(+" &Z``)@`P@!L@```````+(``10$" &H``'7!0@!```````` M``````0``!44`!@!```C```-"A%H`1.8_A44`!@!##0```$(```!@ ```@!H M`0```````"X````````````````````````````````````````````4```8 M`1D!N&P`N0&[&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH-(0`)```5% `6 M% `8`0\%``'\``````<``!44`!@!#P4``?P````%```5% `6% `8`0`C```- M"A%H`1.8_A44`!@!##0```$(``#__P```0!H`0```````"X````````````` M```````````````````````````````;```8`1D!N&P`N0&Z`;L9`!D`&0`9 M``D`"0"^#@`%E/].#(80&@TAOPH`# `,``P`# `,$KTF``"^)@``\"8` M`/\F````)P```2<```(G```#)P``-B<``$ ``=<%" &\``3B"P@!]0`# M8 ,(`?L```````#[``$4! @!]0`!UP4(`> ``=<%" &\``3B"P@!]0`"8 ,( M`?L```````#[``$4! @!]0`!UP4(`> ``=<%" &\``+B"P@!]0`#8 ,(`?L` M`10$" '[``$4! @!]0`!UP4(`> ``=<%" &\``/B"P@!]0`"8 ,(`?L``10$ M" '[``$4! @!]0`!UP4(`> ``=<%" &\``3B"P@!]0`#8 ,(`?L``10$" '[ M``$4! @!]0`!UP4(`0```````````",```T*$3@$$YC^%10`& $,- 0``0@` M``& ```!`&@!````````*0`````````````````````````````````````` M`````!0``!@!&0&X; "Y`;L9`!D`&0`9``D`"0"^#@`%E/].#(80&@TA M``4``!44`!84`!@!``0``!44`!@!`"%7*@``6"H``)$J``"F*@``O2H``,4J M``#&*@``QRH``/LJ```0*P``$2L``!(K```3*P``%"L``$HK``!?*P``8"L` M`&$K``!B*P``8RL``* K``"U*P``SBL``-8K``#\*P``_2L``$,L``!8+ `` M62P``%HL``!;+ ``7"P``)8L``"K+ ``ZP`!UP4(`<<``^(+" '!``-@`P@! MO ```````+P``10$" '!``'7!0@!ZP`!UP4(`<<``^(+" '!``-@`P@!O `! M% 0(`;P``10$" '!``'7!0@!ZP`!UP4(`<<``^(+" '!``-@`P@!O `!% 0( M`;P``10$" '!``'7!0@!ZP`!UP4(`<<``^(+" '!``-@`P@!O ```````+P` M`10$" '!``/7!0@!ZP`#UP4(`<<`!.(+" '!``-@`P@!O ```````+P``10$ M" '!``'7!0@!ZP`!UP4(`<<``^(+" '!``-@`P@!````````````! ``%10` M& $```4``!44`!84`!@!`",```T*$3@$$YC^%10`& $,- 0``0@```& ```! M`&@!````````*0```````````````````````````````````````````!0` M`!@!&0&X; "Y`;L9`!D`&0`9``D`"0"^#@`%E/].#(80&@TA(:LL``"L M+ ``K2P``*XL``"O+ ``L"P``+$L``#,+ ``U"P```$M```"+0``3RT``&0M M``")+0``D2T``)(M``"3+0``ORT``-0M``#5+0``UBT``- M+@``7RX``'XN``")+@``Q"X``,4N``#S+@``!R\``!$O```2+P``$R\``!0O M```5+P``22\``%DO``!:+P``6R\``%PO``!=+P``G2\``*8``>(+" '@``%@`P@!Y@`#% 0(`>8``10$" '@ M``/7!0@!ZP`#UP4(`>8``>(+" '@``%@`P@!Y@```````.8``10$" '@``37 M!0@!ZP`$UP4(`;P``N(+" '@````````X `"8 ,(`>8```````#F``$4! @! MX `!UP4(`>L``=<%" &\``+B"P@!X `#8 ,(`>8```````#F``$4! @!X `! MUP4(`>L``=<%" &\``/B"P@!X `"8 ,(`>8```````#F``$4! @!X `!UP4( M`>L``=<%" $``````````````````````````",```T*$6@!$YC^%10`& $, M- ```0@```& ```%`&@!````````+@`````````````````````````````` M``````````````4``!44`!84`!@!``0``!44`!@!```4```8`1D!N&P`N0&[ M&0`9`!D`&0`)``D`O@X`!93_3@R&$'(57AH-(2"K+P``K"\``*TO``#R+P`` M\R\``/\O````, ```3 ```(P```#, ``UP`!P"$(`=4```````#3```````` MTP```````,T```````#)````````R0```````-4```````#7``' (0@!```` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````#$0`0: $```41`!U@&OC_&P$` M``$2```!````* ``!P$(`17P``PT```!! ```8 ```$```"0```````N```` M``````````````````````````````````````\.``0:`Z<$- ;!!P`````` M"0X`1P`(``$`2P`/````! `@``!@\?\"`" `!DYO``- `0`"`%X`"4AE M861I;F<@,P``/P`#``@!#0,5\ `,- `!``0```& ```!````D ``````+@`` M````````````````````````````````````````!0!5@6,8``!<``1 `0`" M`%P`"4AE861I;F<@- ``/P`$``@!#005\ `,- `!``0```& ```!````D `` M````+@``````````````````````````````````````````! !5@5:!9 `% M0 $`\@!D``E(96%D:6YG(#4``$8`!0`'`0@!#044\ ```!5X``PT``$`! `` M`8 ```$```"0```````N```````````````````````````````````````` M``8`704`:Q0`7@`&0 $``@!>``E(96%D:6YG(#8``#T`!@`-!A7P``PT``$` M! ```8 ```$```"0```````N```````````````````````````````````` M```````(`%:!70(`8Q8`7 `'0 $``@!<``E(96%D:6YG(#<``#T`!P`-!Q7P M``PT``$`! ```8 ```$```"0```````N```````````````````````````` M```````````````&`%T"`&,4`%X`"$ !``(`7@`)2&5A9&EN9R X```]``@` M#0@5\ `,- `!``0```& ```!````D ``````+@`````````````````````` M````````````````````" !6@5T"`&,4`%X`"4 !``(`7@`)2&5A9&EN9R Y M```]``D`#0D5\ `,- `!``0```& ```!````D ``````+@`````````````` M````````````````````````````" !6@5T"`&,2`"(`06#R_Z$`(@`61&5F M875L="!087)A9W)A<&@@1F]N= ``````````````'@!"0 $`\@`>``E";V1Y M(%1E>'0```4`#P`6> `````8`"A H@`!`1@`"TQI;F4@3G5M8F5R`````" ` M($ !`!(!( `&1F]O=&5R``P`$0`/" `"X!# (0$"```P`!] `0`B`3 `!DAE M861E<@`4`!(`!0$/#@`$BP/Q$E4BX"4``0("" !5@6$)"&,<`"X`_D\!``(` M+@`&1FEG=7)E`!D`$P`4$/\``!6-`1;0`B8)""<)""@)""D)" ```"H`_D_Q M_T(!*@`+'0``#<`%@`'`1'X`100_P``%0``#R8`#(L#<@18 M!3 &PP?C"/4)%0LU#$8-9@Z&#P`````````````````(`%6!70<`8Q(`( #^ M3P$`<@$@``Q6=&%B;&4@:6YT0`*`!D`%!#_```5`````%@`_D_Q_Z(!6 `& !#PX`!!H#IP0T M!L$'```````%`%6!8Q0``"0`_D\!``(`) `):&5A9%]F;V]T```$`"<`!0,( M`&$)"&(&8P@`+@#^3_'_@@(N``YF=6QL('!A9V4@=&5X= `,`"@`!0,4^/X` M`!9X``8`70``80D$)@#^3V$"D@(F``E296-?25-/7R,```X`*0`/"@0:`Z<$ M- ;!!P```" `_D^1`J("( `+4F5C7T-#25147R,```4`*@`5``````!"`/Y/ MP0*R`D(`"7)E9F5R96YC90``)@`K``4`'0`1V D3D/<4^/X``!L``#$``"4` M#PL#T (X!* %`=@)``,`80D$`$ `_D\!`,("0 `(96YU;6QE=C$`) `L``4# M'2 1T (3F/X55@`;`0`QNP`E`@\+``/0`C@$H 4````&`&$)"&,4`$(`_D_Q M_]("0@`49G5L;"!P86=E(&1A `/!0`!' $```8`708`80D$- #^3_'_X@(T``=F;W)M=6QA```4`"X`%!#_ M```6> `/" `"P@;@$ `""0!=!@!A"01C& ``,@#^3_'_\@(R`!1L:6YE(&9O M `/!0`! M-P(```8`708`80D$0@#^3_'_$@-"`!1F=6QL('!A9V4@6T```X`,@`%`Q6(``\%``$T!@`#`&,4```<`/Y/P0(R`QP`"&5N M=6UL978R``4`,P`1. 0````<`/Y/,0-"`QP`"&5N=6UL978S``4`- `1H 4` M```R`/Y/`0!B`S(`"4%N;F5X7U)E9@``% `U``4!#PX`!!H#IP0T!L$'```` M``8`80D(8Q0`/ #^3P$``@`\``M!;FYE>%]4:71L90``&@`V``4!%8@`%D0` M#PX`!!H#IP0T!L$'``````@`58%A"0AC' `V`/Y/`0!R`S8`"$5Q=6%T:6]N M`!H`-P`%`Q7!`!;P``\.``0:`S0&\1+@)0```0(&`&$)"&,4`#@`_D\!`)(# M. `%05-.+C$``!<`. `%`Q6(``\.``0:`Z<$- ;!!P``````"P!5@5T"`&$) M"&,2```B`/Y/@0.2`R(`"T%33BXQ($-O;G0N```'`#D`!0`5```````X`/Y/ M`0"2`S@`"D%33BXQ(&ET86P`% `Z``4##PX`!!H#IP0T!L$'``````L`5H%= M`@!A"0AC$@``%@#^3W$"P@,6``1H96%D``(`.P`"`&((% #^3[$#$@`4``1F M;V]T``(`/ ```" `_D]A`](#( `+26YD97A?5&ET;&4```8`/0`'`0@!```R M`/Y/`0#B`S(`!E9T86)L90`8`#X`!0,0R/L4$/\``"8)""<)""@)""D)" 8` M80D(8Q0`,@#^3P$``@`R``]4=&P@0FQO8VL@3&%B96P```X`/P`'`0@!%/S^ M```5: $%`%6!70@``"H`$T !``(`*@`%5$]#(#$```P`0 `5: $/!0`!P"$* M"@!5@5N!70<`8Q0`( `40 $``@`@``543T,@,@``"0!!``\%``' (0H``@!5 M@6(`,$ Q!"($8@`+3&ES="!"=6QL970``$<`0@`%`PT+$- "$= "%/ ````, M-/\!``@```$````!`&@!````````MP`````````````````````````````` M```````````````:`"] `0`R!!H`!$QI0 $` M0@0N``]!;FYO=&%T:6]N(%1E>'0```L`1 `%`P M``!B'@``G1X``.,>```U'P``K!\``.8?``#L'P``4" ``&0@```C(0``FR$` M`/\A```\(@``/2(``'DB``#B(@``6R,``+XC```#) ``G"0```\E``!^)0`` MV"4``# F``"%)@``Q28```TG``!8)P``QR<``!0H``!C* ``_2@``%PI``"O M*0```BH``),J``#8*@``&2L``%TK``#%*P``%2P``%TL``"K+ ``K"P``*TL M```#+0``F `2`)@```"8````F ```)@```"8````! `!`!0``@"<````F `` M`)@```"9`!(`F0```!0``@"8````F ```)@```"9`!(`F0```)D```"9```` MF0```)D```"8`! `% `"`)@```"8````F ```)@`$ "9`!(`F0```)D```"9 M````F0```)D```"9````F0```)@`$ `4``(`F ```)@```"8````F `0`)D` M$@"9````F0```)D````4``(`F ```)@```"8````F `0`)D`$@"9````F0`` M`)D```"9````F0```)D```"9````F0```)D```"9````F0```)D```"9```` MF0```)@```"9`!(`F0```)D```"8````F0`2`)D```"9````F0```)D```"9 M````F0```)D```"=````G0```)T```"=````G0```)T````4``(`F ```)@` M``"8````F ```)@```"9`!(`F0```)D```"9````F0```)D```"9````F0`` M`)D```"9````F0```)D```"9````F0```)D```"9````F0```)D```"9```` MF0```)D```"9````F0```)D```"9````F0```)D```"9````F0```)P```"< M````G ````````!&````5 ```%<``````P``.@T``.D8```[)0``/"X``"\P M```9`!H`&P`<`!T```,``,@%```A" ``?PL``#H-``#O#@``"A$``$03```) M%0``WA@``*D;``"?' ``VAT```TA```\(@``>"4``+TF``#4* ``5RH``*LL M```8+@``JR\```,P```>`!\`( `A`"(`(P`D`"4`)@`G`"@`*0`J`"L`+ `M M`"X`+P`P`#$`,@`S``,M``!&````30```% ```!7````$R$4_Q6 `````)$` M``#+````$P$``!X!``!X`0``A0$``)\!``"L`0``P@$``,\!```>`@``*P(` M`# "```X`@``.0(``#P"```]`@``00(``%@"``!E`@``WP(``.T"```Q`P`` M/P,``%D#``!G`P``?0,``(H#``#9`P``YP,``.P#``#T`P``]0,``/@#``#Y M`P``_0,``!0$```A! ``AP0``*($``#3! ``W00``.8$``#V! ``(P4``#L% M``"'!0``HP4```P&```E!@``=@8``(D&``"D!@``L 8``,P&``#8!@``(P<` M`"\'``"%!P``D0<```4(```1" ``.P@``%0(``!C" ``;P@``'\(``"," `` MV@@``.8(```I"0``-0D``#H)``!""0``0PD``$8)``!'"0``2PD``&()``!O M"0``TPD``-\)```Z"@``1@H``+,*``#1"@``%0L``"(+``!("P``70L``',+ M``"""P``APL``)T+```-# ``'0P``#<,``!'# ``D0P``*$,``"Q# ``O@P` M``P-```<#0``6PT``&L-``!P#0``> T``'D-``!\#0``?0T``($-``"8#0`` MI0T```L.```;#@``< X``'H.``#T#@``_@X``(@/``"2#P``K \``+8/``#, M#P``V0\``$00``!.$ ``J1 ``+,0``#)$ ``T1 ``-(0``#5$ ``UA ``-H0 M``#Q$ ``_A ``&41``!O$0``#A(``!<2``!U$@``@!(```\3```8$P``+!,` M`#43``"4$P``F!,``/X3```+% ``G!0``*44``#C% ``Z!0``%,5``!=%0`` MNA4``,,5``#&%0``RA4``-\5``#I%0``218``%$6``!T%@``?A8``)L6``"S M%@``(1<``"X7```9& ``*Q@``(88``"5& ``EA@``*@8``"S& ``QA@``/(8 M``#]& ``_A@```@9```)&0``$!D``"09```P&0``6QD``&49``!W&0``?QD` M`( 9``"#&0``A!D``(@9``"?&0``L!D``! :```7&@``.QH``$4:``!B&@`` M:AH``&L:``!N&@``;QH``',:``"*&@``FQH``,\:``#9&@``WAH``.(:``#U M&@``^1H```H;```.&P``41L``%D;``!>&P`````@'@``4AX``%T>``!B'@````"D M'@``S!X``-,>``#6'@``X!X``.4>``#R'@``-Q\``#L?``"N'P``M1\``.X? M``#U'P``12 ``$T@``!H( ``=R ``-4@``#D( ``_B ```TA```C(0``,"$` M`)LA``"E(0``_R$```XB```](@``3"(``%$B``!9(@``6B(``%TB``!>(@`` M8B(``'DB``"&(@``XB(``.PB``!;(P``:B,``+XC``#,(P``\",``/XC```# M) ``#R0``$````'P```" ` M```A````(@```",````D````)0```"8````G````* ```"D````J````*P`` M`"P````M````+@```"\````P````,0```#(````S````- ```#4````V```` M-P```#@````Y````.@```#L````\````/0```#X````_````0 ```$$```!" M````0P```$0```!%````1@```/[____]____2P```/[___]3````_O______ M___________________________________^________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__________________________________]2`&\`;P!T`" `10!N`'0`<@!Y M``````````````````$````"````( ````(```````````````,`0 `8#$ ` M%@`%`?__________`0`````)`@``````P ```````$8`````H(R58!$$O '@ M3==C9@F\`4H```# `P``L1@``%<`;P!R`&0`1 !O`&,`=0!M`&4`;@!T```` M```'````_____P``````````>P(``````````````0````0````:``(!`@`` M``,```#_____`P! `/!#1P#8!0````````````#__P`````````````````` M`````.J,```!`````0!#`&\`;0!P`$\`8@!J``````"R& ``LQ@```@````` MH ```````-SO8@```````0````````#_____`````!(``@'_____________ M__\!`````@```" ````"````````````````````````````````````:@`` M`/__```%`%,`=0!M`&T`80!R`'D`20!N`&8`;P!R`&T`80!T`&D`;P!N```` MX, !`.+ `0``````````````````````* `"`?____\$````_____P`````` M`````````!8```!(``````````````````````````(```#\`0``+ ````$` M``#^____`P````0````%````!@````<````(````"0```/[___\+````# `` M``T````.````_O______________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________`0#^_P,*``#_____``D"``````# ````````1A@` M``!-:6-R;W-O9G0@5V]R9"!$;V-U;65N= `*````35-7;W)D1&]C`! ```!7 M;W)D+D1O8W5M96YT+C8`]#FR<0`````````````````````````````````` M``````````#^_P``! `"```````````````````````!````X(6?\OE/:!"K MD0@`*R>SV3 ```#,`0``$@````$```"8`````@```* ````#````X ````0` M``#L````!0````0!```&````$ $```<````<`0``" ```# !```)````2 $` M`!(```!4`0``"@```'P!```+````B $```P```"4`0``#0```* !```.```` MK $```\```"T`0``$ ```+P!```3````Q $```(```#D! ``'@```#<```!4 M96UP;&%T92!F;W(@;6%P(&9R;VT@;6]N:71O```` M36EC Can SENSE assist in the Trap problems of the Job Monitoring MIB? Message-ID: <199701242247.OAA18468@gate.dpc.com> The minutes of the JMP session in Albuquerque included the following (slightly edited for inclusion here): - Do we want to tackle Traps and/or notification? YES More clients - polling worsens as things get busy. Trap may never arrive. With traps, you would still poll at more relaxed rate in case traps get lost. Does SENSE solve the problem? Why hasn’t SENSE focused on Traps (apparently). Or has it? SENSE does not focus on Traps, but rather provides an interface to acquire the same information provided by a Trap (and more). I plan to describe this capability in detail at the upcoming PWG meeting in early February. For those of you attending the preceding interoperability testing, you'll be able to witness this capability via a live demo of Underscore's "PrintAlert" product that is based on the SENSE reference implementation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From rbergma at dpc.com Mon Jan 27 13:59:35 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Summary of Job MIB Mappings Message-ID: <199701271859.KAA25480@gate.dpc.com> I have placed a summary of the vendor Job MIB mappings on the PWG server. The file is located at: ftp://ftp.pwg.org/pwg/jmp/mono-map/mono-cmp.doc This document will be discussed in the conference call on Thursday. --------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From lpyoung at lexmark.com Mon Jan 27 15:12:25 1997 From: lpyoung at lexmark.com (Lloyd Young) Date: Wed May 6 14:00:01 2009 Subject: JMP> Implementation conference call Message-ID: <199701272122.AA13841@interlock.lexmark.com> The details for our next teleconference to discuss the various Job Monitoring implementations are as follows: Date: Thursday, January 30th Time: 4:00 pm EST (1:00 pm PST) Duration: 2 hours Phone number: 423-673-6717 Access code: 820010 # of lines reserved: 15 Lloyd Young Phone: (606) 232-5150 Lexmark International Inc. Fax: (606) 232-6740 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40511 From harryl at vnet.ibm.com Wed Jan 29 10:24:22 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> REQ, PRO, MOD - SNMP relation to IPP Message-ID: <199701291547.KAA21411@lists.underscore.com> Excerpt from Carl-Uno (discussing directory overload)... >If we want to get more detailed information about a printer's >capabilities, I would expect to go and ask for that Printer's >attribute list, using the IPP. Any variable information, such as >media loaded, or printer state has nothing to seek in the directory. Since IPP, PMP and JMP are all occurring under one PWG, I'd like to know if there is a consensus regarding role of the Printer and/or Job MIBs in relation to IPP. >I think that scenario 4.0 needs to get refined into more than >just Getting Status. In effect there are at least the following kind >of functions described under scenario 4. > >1) Getting detailed information about a printer's capabilities (static) > >2) Getting information about a printer's status (variable) > >3) Getting information about a job's status (variable) and fixed attributes. Is it generally held, by most participants, that IPP, given the above capabilities, *REPLACES* SNMP for obtaining this information? Harry Lewis - IBM Printing Systems From rbergma at dpc.com Wed Jan 29 12:55:31 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Agenda for Thursdays conference call Message-ID: <199701291755.JAA02531@gate.dpc.com> I would like to propose the following agenda for the JMP conference call on Thursday. 1. Objects not currently implemented by any vendors: - jmGeneralQueuingAlgorithm -- remove? - jmJobMessageToOperator -- propose this be removed - jmJobTypes -- should be retained 2. Resources not currently implemented by any vendors: - documentCopiesProduced -- remove? - faxPhoneNumber -- propose this be deferred -- to a fax MIB extension 3. Any other issues as a result of the MIB comparison? Should any of the vendor specific objects be included? 4. Discussion of the open issues in the latest specification from Tom Hastings. The details on the teleconference: Date: Thursday, January 30th Time: 4:00 pm EST (1:00 pm PST) Duration: 2 hours (maximum! We will stop at 6:00 pm EST!) Phone #: 423-673-6717 Access code: 820010 --------------------------------------------------------------------- Ron Bergman Dataproducts Crop rbergma@dpc.com (805)578-4421 From hastings at cp10.es.xerox.com Wed Jan 29 13:33:07 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> Agenda for Thursdays conference call [issue In-Reply-To: Agenda for Thursdays conference call [issue> Message-ID: <9701291834.AA03393@zazen.cp10.es.xerox.com> Looks like a good agenda. In order to best process the issues, I suggest that you all look at the TABLE OF ISSUES in the table of contents of the jmp-mib.pdf file, pages vii and viii. The table contains the page number where the issue affects the MIB and often has more text discussion the issue. Those issues that are going to take a lot of time, such as trapping, we should probably find out who is willing to work off-line on some proposed solutions. Hopefully, we can make a pass over all of the 34 issues, either deciding them or assigning them to one or more people to work on off-line. Thanks, Tom >Return-Path: >Date: Wed, 29 Jan 1997 09:55:31 PST >From: rbergma@dpc.com >Illegal-Object: Syntax error in To: address found on alpha.xerox.com: > To: GATE"jmp@pwg.org"@gate.dpc.com > ^ ^-missing end of address > \-extraneous tokens in address >To: >To: >To: >Subject: JMP> Agenda for Thursdays conference call >Sender: jmp-owner@pwg.org > >I would like to propose the following agenda for the JMP conference >call on Thursday. > > 1. Objects not currently implemented by any vendors: > > - jmGeneralQueuingAlgorithm -- remove? > - jmJobMessageToOperator -- propose this be removed > - jmJobTypes -- should be retained > > 2. Resources not currently implemented by any vendors: > > - documentCopiesProduced -- remove? > - faxPhoneNumber -- propose this be deferred > -- to a fax MIB extension > > 3. Any other issues as a result of the MIB comparison? Should any > of the vendor specific objects be included? > > 4. Discussion of the open issues in the latest specification from > Tom Hastings. > >The details on the teleconference: > > Date: Thursday, January 30th > Time: 4:00 pm EST (1:00 pm PST) > Duration: 2 hours (maximum! We will stop at 6:00 pm EST!) > Phone #: 423-673-6717 > Access code: 820010 > >--------------------------------------------------------------------- > Ron Bergman > Dataproducts Crop > rbergma@dpc.com > (805)578-4421 > > > From mccarter at mail.utexas.edu Thu Jan 30 17:31:43 1997 From: mccarter at mail.utexas.edu (Maureen Cockerill Carter) Date: Wed May 6 14:00:01 2009 Subject: JMP> Review of Job MIB Message-ID: <9701291834.AA03393@zazen.cp10.es.xerox.com> JMP Team, I hope everyone is doing well. I have been out of town all week on business and I am now sick at home. This means I can't participate in the telecon today (1/30) to review the job mib nor send my comments because my notes and writeup are at work. I will send my comments on Friday 1/31. I apologize for any inconvenience. Have a super day, Keith From hastings at cp10.es.xerox.com Thu Jan 30 20:19:27 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> Updated list of Issues for the Job Monitoring MIB Message-ID: <9701310121.AA03955@zazen.cp10.es.xerox.com> Five of us (Bob P, Lloyd Y, Ron B, Harry L, and Tom H) joined the JMP teleconference today and we are proposing resolution to a number of the 34 issues listed in the job-mib MIB. We also agreed on adding some enums and removing some objects (see Ron's telecon minutes), of course subject to review by the e-mail DL and the JMP meeting next week. We'd like to get feed back on the closure of these issues by e-mail and/or at the JMP meeting next week. We will also process the remaining issues at the meeting. I've put the files in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 23040 Jan 31 00:47 issues.doc -rw-r--r-- 1 pwg pwg 21935 Jan 31 00:47 issues.pdf -rw-r--r-- 1 pwg pwg 22388 Jan 31 00:48 issues.pdr The .pdf file is black revision marks and the .pdr is red revision marks. From rbergma at dpc.com Fri Jan 31 19:05:50 1997 From: rbergma at dpc.com (rbergma@dpc.com) Date: Wed May 6 14:00:01 2009 Subject: JMP> Conference Call Minutes for 1/30/97 Message-ID: <199702010005.QAA11474@gate.dpc.com> I have posted the minutes from yesterdays JMP conference call to the PWG FTP server. There is both a Word and a text file. The path is: ftp://ftp.pwg.org/pub/jmp/minutes/cc-300197 (.doc or .txt) The minutes are also included in this message. --------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com --------------------------------------------------------------------- JMP TELECONFERENCE MINUTES January 30, 1997 Participants: Ron Bergman - Dataproducts Tom Hastings - Xerox Harry Lewis - IBM Bob Pentecost - HP Lloyd Young - Lexmark It was agreed that any decisions made during the JMP Conference Calls would be present to the PWG at the next regularly scheduled meeting. The decisions would then become final if no objections were voiced at the PWG meeting. 1. Review of the Job Monitoring MIB objects not currently implemented by any vendors: jmGeneralQueuingAlgorithm Agreed to be deleted from the MIB. jmJobMessageToOperator Agreed to be deleted from the MIB. jmJobTypes Will be retained since this object allows extension of the MIB to support faxing and scanners. 2. Review of resource enums that are not currently supported by any vendors: DocumentCopiesProduced Will be retained. FaxPhoneNumber Remove, this enum belongs in a fax MIB. 3. Inclusion of vendor specific enums and objects: The following resource enums were agreed to be added: number of pages in original document output bins used colorants used media used The HP private objects in the Job Group were reviewed. It was decided that none of the objects would be added at this time. Bob Pentecost did accept the action item to review the objects srcIO, srcQ, and srcPort to determine if any of these should b Ron Bergman agreed to review the Dataproducts unique objects in the General Group and the Queue Group to determine if any of these should be included in the MIB. 4. Discussion of open issues (from Tom Hastings Job Monitoring MIB, January 23,1997) 1. Should we add a standard SNMP RowStatus object to the jmJobTable and jmResourceTable? It was agreed to postpone further discussion on this object until the PWG meeting next week. Rick Landau has previously commented on this proposal and we would like to review his reasons for objecting before preceding. 14. How do we add traps without adding too much network traffic? This issue will be discussed further at the PWG meeting. Recommend SENSE? 15. Should jmGeneralQueuingAlgorithm be writeable, so that the system administrator using an NMS can change the scheduling algorithm? 16. Add passThrough(6) to jmGeneralQueuingAlgorithm for servers that just pass jobs through without queuing? 28. Should jmGeneralQueuingAlgorithm be writeable so that the system administrator using an NMS can change the scheduling algorithm? The above issues were closed since it was agreed that jmGeneralQueuingAlgorithm is to be removed. 20. OK to have added fileName(3) to jmResourceType? Agreed. (Some implementations have both file names and document names.) 22. Why not require the agent to always return FAX numbers in ASCII, since it is easy to convert from Unicode to ASCII? Issue is closed, since the fax phone number enum has been removed. 23. Add resource item to indicate the out-bins that the job requests/uses? Agreed. Issue closed. 31. Should we re-introduce jmJobDeviceIndex to handle configuration 2b? No. A user or management application will never have to look at both the printer and the spooler, at the same time, for information regarding a specific job. 37. Change the jmJobSourceChannel from an index in the Printer MIB to the enum, since the server need not implement the Printer MIB? It was agreed that a change in this area will be required to support a spooler. 41. Is it worth rounding down jmJobOctetsCompleted until the job completes and then round up? No. It was agreed to keep it simple and always round up. The transfer time for a 1000 bytes is not significant enough to require the added complexity. 43. How can jmResourceName be a union of OCTET STRING, Integer32, and Counter32? Two separate objects will be required. The appropriate object will be used and the other will return a null object. From jkm at underscore.com Sat Feb 1 02:34:25 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:01 2009 Subject: JMP> Conference Call Minutes for 1/30/97 In-Reply-To: Conference Call Minutes for 1/30/97> Message-ID: <199702010005.QAA11474@gate.dpc.com> Ron, Thanks for posting the JMP telecon minutes to the list as well as on the server. Seems to make for more rapid digestion of this timely information. One portion of the minutes has me a bit worried: > 31. Should we re-introduce jmJobDeviceIndex to handle configuration > 2b? > > No. A user or management application will never have to look > at both the printer and the spooler, at the same time, for > information regarding a specific job. Sorry, but I don't have Tom's latest-greatest spec in front of me to recall what "configuration 2b" is exactly, but the response sends up a number of red flags for us at Underscore. The wide variety of grossly disparate spooling systems found in the average Enterprise today is not likely to change in the near future. While DPA-based technology may solve some critical problems, it is just that--yet another spooling system. In our humble opinion, the *only* way to present accurate job status information in a (typically) multi-platform environment is to tackle the highly formidable task of corroberating the job data of all these spooling systems, then presenting the results in some sort of "normalized" manner. So, in our view, a truly useful Job Monitoring application should be expected to simultaneously examine job data in both the spooler(s) and the printer to accurately depict the current state of a job. Hopefully this view doesn't rock to many peoples' boats. ;-) Opposing views are definitely welcome, too. All in all, the progress on the Job MIB is most promising. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From bpenteco at boi.hp.com Sat Feb 1 12:39:50 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:01 2009 Subject: JMP> Conference Call Minutes for 1/30/97 Message-ID: <01BC102C.410B5B40@hpb15767.boi.hp.com> I think the key wording from "A user or management application will never have to look at both the printer and the spooler, at the same time, for information regarding a specific job" is _for a specific job_. Our thinking is that once the job moves from the spooler to the printer, you can monitor the job in the printer. You don't have to be accumulating information from both the spooler and the printer about one job. Bob Pentecost HP ---------- From: JK Martin[SMTP:jkm@underscore.com] Sent: Saturday, February 01, 1997 12:34 AM To: rbergma@dpc.com Cc: PWG Job Monitoring MIB Project Subject: Re: JMP> Conference Call Minutes for 1/30/97 Ron, Thanks for posting the JMP telecon minutes to the list as well as on the server. Seems to make for more rapid digestion of this timely information. One portion of the minutes has me a bit worried: > 31. Should we re-introduce jmJobDeviceIndex to handle configuration > 2b? > > No. A user or management application will never have to look > at both the printer and the spooler, at the same time, for > information regarding a specific job. Sorry, but I don't have Tom's latest-greatest spec in front of me to recall what "configuration 2b" is exactly, but the response sends up a number of red flags for us at Underscore. The wide variety of grossly disparate spooling systems found in the average Enterprise today is not likely to change in the near future. While DPA-based technology may solve some critical problems, it is just that--yet another spooling system. In our humble opinion, the *only* way to present accurate job status information in a (typically) multi-platform environment is to tackle the highly formidable task of corroberating the job data of all these spooling systems, then presenting the results in some sort of "normalized" manner. So, in our view, a truly useful Job Monitoring application should be expected to simultaneously examine job data in both the spooler(s) and the printer to accurately depict the current state of a job. Hopefully this view doesn't rock to many peoples' boats. ;-) Opposing views are definitely welcome, too. All in all, the progress on the Job MIB is most promising. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jkm at underscore.com Sat Feb 1 14:47:12 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:01 2009 Subject: JMP> Conference Call Minutes for 1/30/97 In-Reply-To: Conference Call Minutes for 1/30/97> Message-ID: <01BC102C.410B5B40@hpb15767.boi.hp.com> Bob, > I think the key wording from "A user or management application will never > have to look at both the printer and the spooler, at the same time, for > information regarding a specific job" is _for a specific job_. Our thinking > is that once the job moves from the spooler to the printer, you can monitor > the job in the printer. You don't have to be accumulating information from > both the spooler and the printer about one job. You may be right. We'll have to see how this plays in the real world. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From hastings at cp10.es.xerox.com Sat Feb 1 19:24:19 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> Proposed Issue 43 resolution and other jmResourceTable problems Message-ID: <9702020026.AA04377@zazen.cp10.es.xerox.com> I've posted a paper on issue 43 and other clarifications needed for the jmResourceTable which I'd like to go over at the JMP meeting this Friday, 2/6. -rw-r--r-- 1 pwg pwg 57344 Feb 2 00:17 res-type.doc -rw-r--r-- 1 pwg pwg 55631 Feb 2 00:18 res-type.pdf -rw-r--r-- 1 pwg pwg 57108 Feb 2 00:19 res-type.pdr I'll bring copies of the res-type to the JMP meeting this Friday in San Jose. Here is the beginning of that paper: Subj: Problems and Solutions to the jmResourceTable - Issue 43 From: Tom Hastings Date: 2/1/97 File: res-type.doc There are several problems with jmResourceTable: 1. The jmResourceName object cannot be a union of a text string and an integer. Proposed solution to Issue 43: Have two objects: one for text and the other for an enum type for those resources that have identified enum types, such as interpreters. Call these objects: jmResourceNameAsText and jmResourceNameAsType. 2. It is not clear for objects that do not have a need for a text name or text type, whether the jmResourceNameAsText need be filled in at all. Proposed solution: Always fill in jmResourceNameAsText with some text string. For most resources jmResourceNameAsText shall be a fixed string specified by the MIB, such as 'pages completed' or 'sides'. For the remaining resources, the MIB would require filling a variable name, such as the actual file name, the actual document name, or the interpreter name. For those resources that have jmResourceNameAsType, such as channel or interpreter, both the jmResourceNameAsText and jmResourceNameAsType would be filled in. I would think that for internationalization/localization that it would help if all resources have a fixed text string, if the name isn't a variable text string. Then if a new enum is supported by an agent that the monitoring application didn't understand, at least the text string name could be displayed to the user. Of course, such a text string would be in the locale of the server or printer, which we expect to be the same as the monitoring application. New ISSUE 54: Do we need a way for the monitoring application to determine the locale of the server or printer? Then the monitoring application would know whether to use the jmResourceNameAsText directly or to use the jmResourceType enum that all resources have (not to be confused with the new jmResourceNameAsType object) and provide the localization for the user within the monitoring application. 3. It is not clear for those resources that are not counted, such as interpreters, what the value of the jmResourceAmount should be. I suggest that we specify that it shall be 1. 4. I've added mediumRequested and mediaConsumed. 5. I've added outputBin and colorantConsumed. From kccarter at VNET.IBM.COM Tue Feb 4 16:39:27 1997 From: kccarter at VNET.IBM.COM (kccarter@VNET.IBM.COM) Date: Wed May 6 14:00:01 2009 Subject: JMP> Job Mib Assessment Message-ID: <199702042141.QAA21309@lists.underscore.com> JMP Team, Here is my belated assessment of the Job Monitoring MIB document (version 0.6, dated 01/23/97) which we can discuss further at our JMP meeting in San Jose. Thanks to Tom Hastings for producing this document! * Page 7 - Job Object Lifecycle Summary: Please add a State for "Printing" to indicate that the job is currently printing on the printer. * Page 22 - MIB Datatype specifications: This is a nit, but it would be helpful to give an example of the format for DateAndTime. For example, how does one specify 12:01:00AM on Thursday, January 30, 1997? * Page 25 - jmQueueAlgorithmTC: I agree with the resolution of issue 15 and 16 which states that this object will be removed from the Job MIB. * Page 28 - jmJobStateTC: Please add a State for "printing" to indicate that the job is currently printing on the printer. * Page 31 - jmJobStateReasonsTC: Please confirm that state "completion" plus reason "successfulCompletion" means that all pages of the print job have been successfully printed and stacked in the output bin. If so, we're set. If not, then please add "jobStacked" to indicate the reason for the "completion" state is that all pages in the job have been stacked in the output bin of the printer. * Page 42 - jmResourceTypeTC: I agree with the resolution of issue 22 which states that "faxPhoneNumber" will be removed from the Job MIB. * Page 42/43 - impressionsCompleted and sheetsCompleted: How does number of copies affect these values? * Page 43 - jmResourceTypeTC: In OS/2 Warp, "pagesSpooled", "pagesSentToDevice" and "pagesCompleted" mean "impressions" - not "logical pages". Therefore, please change the name of these resources to "impressionsSpooled" and "impressionsSentToDevice". Please change the description from "logical pages" to "impressions". Please indicate that "impressionsSpooled" is for 1 copy of a job and "impressionsSentToDevice" is reset to 1 for each copy. "pagesCompleted" can be removed since it equals "impressionsCompleted". In OS/2 Warp, "impressionsCompleted" is reset to 1 for each copy of a job. * Page 43 - jmResourceTypeTC: Does "processingTime" count operator intervention time? (e.g. the time a job was held up due to a paper jam on the printer) * Page 49 - Should MIB provide jmGeneralNumberOfJobsQueued and jmGeneralNumberOfJobsComplete so a network management application can summarize the current status of the printer? * Page 49 - jmGeneralQueuingAlgorithm: I agree with the resolution of issue 28 which states that this object will be removed from the Job MIB. * Page 53 - jmJobMessageToOperator: It doesn't appear anyone supports this. Should this object be removed from the Job MIB? * Page 58 - jmJobName, jmJobIdName, jmJobIdNumber, jmJobComment: Clarify the use of these objects. Here is an example. A user submits a print job. The file name of the job is "C:\MYJOB.PS". The user specifies a comment of "Status Report 1/31/97". The print job is queued on server "SERVER1" in print queue "PSQUEUE". The numeric job id is 1234. What value is the value of each object? Do we need a specific object for source server and source queue to accommodate management applications such as the management application provided by HP that correlates jobs in a printer with jobs in a print queue on a print server? * Page 59 - jmJobIdNumber: OS/2 uses -1 to indicate there is not a job id. I recall seeing -2 in one of the Job MIB specs. Why not use -1 instead of -2? * Page 59 - jmJobTypes: It doesn't appear anyone supports this object. Is this object intended for a multi-function device (MFD) so the host can inform the MFD which of its devices to direct the job? * Page 60 - jmJobDeviceNameRequested: What is the purpose of this object? Is this the name of the printer (e.g. make and model)? * Page 60 - jmJobDeviceIndex: What value should a print server return if it doesn't support the printer mib? * Page 61 - jmJobSourceChannel: What are the enum values referred to in issue 37? Keith From hastings at cp10.es.xerox.com Wed Feb 5 01:20:11 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> I've posted some comments on the MIB from Ira McDonald and Message-ID: <9702050621.AA05234@zazen.cp10.es.xerox.com> In ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 16234 Feb 5 06:13 jmp-ira.txt I'd like to cover it at the meeting. Since it is plain text, I've also added it to this message: =========== Comments on IETF Job Monitoring MIB Draft =============== =========== Comments on 'jmp-mib.pdf', v0.6, 23 Jan 1997 =============== From: Ira McDonald and Tom Hastings Date: 2/4/97 * General - use of end papers with roman numeral page numbers makes reading the document confusing with Acrobat - the viewer numbers pages from decimal one in all search and goto functions (which makes the Table of Contents harder to use). * General - all of your INDEX objects suffer from a range of '(0..xxx)' - they should all have their range specified as '(1..xxx)' - an index of zero is NOT legal in SMIv1/SMIv2 tables - it indicates a simple object rather than a columnar one in the 'over-the-wire' protocol. A 'pointer' (copy of an index to some other table) that isn't specified in any 'INDEX' clause should usually be '(0..xxx)'. * iii/58 - change 'Interdet' to 'Internet'. * v/122 (and 75/1970) - change 'MIB Instance Group' to 'Job Set Group'. * 3/276 - Issue 1 - yes, add a RowStatus to 'jm[Job|Resource]Table'. * 3/283 - Issue 2 - yes, add 'jmGeneralTableOverflowPolicy'. * 4/331 - suggest italics for 'Server' * 4/342 - change 'to the network' to 'to a network' (systems may be simultaneously connected to several (PSTN/FAX and Ethernet/IP) * 5/355 - delete sentence 'In other words, queueing is a subset of spooling.' - that statement is incorrect - or 'A subset of spoolers also perform queueing.' * 5/382 (and 6/392) - change 'name, value-pair' to 'name/value pair' (the hyphen isn't needed here for clarity). * 6/412 - change 'sub-set' to 'subset' (a perfectly good word). * 6/424 - change 'are accessible via the ListJobAttributes operation' to 'are temporarily visible in this MIB's Job and Completed tables'. * 13/579 - Issue 5 - yes, restore NMS to both server and printer agents. * 14/585 - Issue 6 - no, the server deletes the job when submitting the job to the printer, if the server doesn't keep the job up to date. * 14/590 - Issue 7 - yes, add boolean about data 'freshness'. * 14/597 - Issue 8 - no, since the server deletes the job when submitting the job to the printer, if the server doesn't keep the job up to date. * 15/625 - change 'System Group...' to 'MIB-II System Group...'. * 15/628 - change 'Interface Group...' to 'MIB-II Interface Group...'. * 15/630 - change 'is implementer' to 'is implemented'. * 16/669 - delete ',i.e. , could be localized' (redundant). * 17/688 - change 'DateTime' to 'DateAndTime'. - add reference: '(see SNMPv2 Textual Conventions, RFC 1903)'. * 17/692 - change 'after the standard' to 'after this standard'. * 18/728 - Issue 9 - this MIB should leave ALL its objects 'read-only' Add a paragraph that indicates that implementors could allow monitoring applications to modify objects, by adding a private table that contains an encrypted password, with date and time mixed in and set in the clear. In addition, the OID of the object to be written and the new value is contained in the table. * 18/737 - Issue 10 - yes, add object for other jobs access policy. * 18/741 - Issue 11 - no, not writeable (see Issue 9 above). * 19/749-750 - soapbox - ALL uninstrumented objects in mandatory groups of any MIB should always correctly return 'read-only' static values specified in 'DEFVAL' clauses - 'DEFVAL' is a perfectly good SMIv2 feature intended to cover this situation - returning ANY SNMP error for ANY object in a mandatory group with a legal instance qualifier (ie, set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol spec (RFC 1905, page 10, in 'Get-Request PDU' handling). - that's what 'shall implement ALL the objects in this group' means! So add DEFVAL clauses to all objects. * 19/754 - Issue 12 - return 'noError' and 'DEFVAL' in variable binding. * 19/760 - Issue 13 - Printer MIB was RIGHT not to fake SNMP errors. * 19/776 - Issue 14 - you could add something like the old SNMPv2 Party table to the Job Mon MIB - the mechanism could be shared with the Printer MIB (ie, supports directed traps for Printer MIB and other device MIBs in future). - also, BOTH the NMS and Client systems will want to register for (potentially different) traps. * 20/789 - Object Groups and Tables - collapse leftmost two columns of table as '...[Group|Table]'. * 21/792+ - Datatypes used in the Job Monitoring MIB - OCTET STRING - add '(see OSI ASN.1, ITU X.208 | ISO 8824)'. - Integer32 - add '(see IETF SNMPv2-SMI, RFC 1902)'. * 22/792+ - Datatypes used in the Job Monitoring MIB - Counter32 - add '(see SNMPv2-SMI, RFC 1902)'. - DateAndTime - add '(SNMPv2 Textual Conventions, RFC 1903)'. * 25/840 - no, not writeable (see Issue 9 above). * 27/875 (and 59/1433) - JmJobTypesTC - 'print(0)' - change 'print(0)' to 'print(1)', because at 27/862 you say 'shall return a NON-ZERO value' and because SNMPv2-SMI (RFC 1902) says it recommends that enums run 'from 1 and continuously' - also, if 'print' turns no bit on, then it is impossible to tell if 'print' is one of the requested services. - 59/1433 - change 'SYNTAX' from 'JmJobTypesTC' to 'Integer32' - you intend to add multiple values from the 'TC' together in this value * 28/883 - change 'Management...' to 'Monitoring application...'. * 28/892+ - 'preprocessing(3)' - change 'The job maybe...' to 'The job may be...'. - next line, change 'of being...' to 'of: being' (ie, add colon). * 29/892+ - 'paused(13)' - change 'resumed at the point where the job was paused' to 'resumed at the point where the job was paused or at an earlier processing boundary, if necessary.' * 31/934+ (and 64/1647) - 'JmJobStateReasonsTC' - change the SYNTAX from 'OCTET STRING' to 'INTEGER' - because you are enumerating the bit-numbers to set in the target 'OCTET STRING' * 33/934+ - 'submissionInterrupted(17)' - change 'by issuing the ReleaseJob operation' to 'by using a job submission or job management protocol operation'. * 35/934+ - 'transferring(26)' - change to 'jobTransferring' for clarity (w/ log file). * 35/934+ - 'processingToStopPoint(29)' - mention auto-resume after interrupting job completes?? - couldn't 'PauseJob' also yield a 'processingToStopPoint' ?? * 35/934+ - 'validating(31)' - change 'after a CreateJob operation' to 'after the job was created with a job submission protocol'. * 36/934+ - 'exceededAccountLimit(38)' - change 'The account for which this job is drawn' to 'The account to which this job is assigned'. * 40/954+ - 'JmResourceTypeTC' - (NO unions are not legal - this whole list is confused - the type of 'jmResourceName' should NOT ever be 'Counter32' - the (coerced) type of 'jmResourceAmount' be 'Counter32', when appropriate - there are only two cases for 'jmResourceName' - 'jmResourceNameAsText' (OCTET STRING) and 'jmResourceNameAsIndex (Integer32). - also add 'other(1)' (for proprietary resource types) and 'unknown(2)' (needed for DEFVAL clause). * 40/954+ - Issue 20 - yes, add 'filename(3)' as resource type. * 41/954+ - 'interpreters(10)' and 'PrtInterpreterFamilyTC' - will publishing of IETF Job Mon as an I-D be held up until there is a new v2 Draft of IETF Printer MIB available for the TCs?? * 42/954+ - 'physicalDevice(11)' - Issue 21 - no, have BOTH 'physicalDeviceIndex' (using HR MIB) and 'physicalDeviceName' as separate possible resources (to make Job Mon independent of both Printer MIB and HR MIB) * 43/954+ - 'processingTime(20)' - is this 'CPU used time' or 'clock elapsed time' or what?? - change name to 'processingCPUTime(20)' * 43/954+ - Issue 23 - yes, add output bins resource type. * 43/954+ - Issue 24 - don't move any resource items to the 'jmJobGroup'. * 45/966 - 'JmResourceUnitsTC' - how many of these values are actually used? Need to specify which units go with which resources, else may affect interoperability. * 47/1001 - Issue 26 - 'jmJobSetIndex' must be persistent for this MIB and 'jmJobIndex' should be recommended to be persistent - about others, we should discuss this. * 48/1006 - The General Group - since this group is mandatory, why not delete Job Set Group and let the real 'jmGeneralJobSetIndex' be defined in General group?? * 49/1048 - 'jmGeneralJobCompletedPolicy' - Issue 27 - no, not writeable (see Issue 9 above). * 49/1048 - 'jmGeneralQueueingAlgorithm' - Issue 28 - no, not writeable (see Issue 9 above). * 52/1127 - 'jmQueueIndex' - why NOT monatonically increasing order, like 'jmCompletedIndex' ?? * 52/1133 - 'jmJobIndex' - change this tag to 'jmQueueJobIndex'. - change 'value 0 need not' to 'value 0 SHALL not' (because a zero instance identifier is reserved in SNMPv2 protocol for simple objects - columnar objects are NOT permitted an instance of zero). ISSUE - What about servers or printers that assign 0 as a valid job identifier? If the agent adds one, then an operator who uses both a monitoring application with this MIB and some other will be confused by the job-identifiers being different by 1. Altenatively, the agent could map a job-identifier value of 0 to the largest positive number. Then only the job-identifier value of 0 would be different between the SNMP and the job submission protocol. * 53/1175 - 'jmJobPriority' - delete 'The omission of this attribute...' - DPA lingo. * 55/1263 - 'jmCompletedIndex' - yes, monatonically increasing, but what about roll-over?? * 56/1284 - The Job Group - Issue 30 - yes, we should probably move some Job Group objects to the Resource Group to lighten up the implementation cost of this MIB - Move: jmJobSourceChannel, jmJobSubmissionTime, jmJobComment, jmJobTotalKOctets, jmJobKOctetsCompleted, jmJobStartedProcessingTime, jmJobCompletionTime, and jmJobAccountName to the Resource Group. * 57/1331 - 'jmJobIndex' - Issue 31 - no, do not re-introduce jmJobDeviceId since the server deletes the job while the copy of the job is in the printer in config 2b. * 59/1391 - Issue 32 - yes, if there is a separate numeric object then you need to require the uniform parsing of numeric elements from client-side identifiers. * 59/1398 - Issue 33 - Some systems need both, such as BSD.. * 59/1413 - Issue 34 - In either SNMPv1 or SNMPv2, the uninstrumented objects in mandatory groups should return their static DEFVALs. * 59/1433 - 'jmJobTypes' - change SYNTAX from 'JmJobTypesTC' (bits) to 'Integer32' (bitmap). * 61/1498 - 'jmDeviceIndex' - change '(hrDeviceIndex)' to '(to 'hrDeviceTable)'. * 61/1501 - 'jmDeviceIndex' - add reference: '(see Host Resources MIB, RFC 1514)'. * 61/1504-1505 - change 'shall return the SNMP ... rather than zero' to 'shall return zero, to indicate 'none''. * 61/1520 - Issue 37 - yes change 'jmJobSourceChannel' to use the enum, to avoid Printer MIB dependencies. * 62/1538 - Issue 38 - yes, add 'jmJobChannelInformation' to Server, to avoid Printer MIB dependencies. * 63/1624 - Issue 39 - no, return (-2) for unknown. * 65/1700 - Issue 41 - no, ALWAYS round up, so that the guage becomes non-zero as soon as any formatting activity commences and remains rounded up throughout - more user friendly. * 66/1757-1758 - 'jmJobAccountName' - change 'SNMP error ??? shall be returned' to 'the null string (zero length, see DEFVAL) shall be returned'. * 67/762+ - The Resource Group - change 'and/or used resources' to 'and/or consumed resources'. * 68/1782 - INDEX clause of 'jmResourceEntry' sequence - if you added 'jmResourceType' as the second to last (rightmost) index, then this table would be automatically sorted (and indexable) via resource type (by using a partial OID in the SNMP Get-Next PDU). * 68/1785+ - 'JmResourceEntry' and 'jmResourceName' - the postulated union is illegal in SMIv1 or SMIv2 - you can have 'jmResourceNameAsText' and 'jmResourceNameAsIndex' objects (see 40/954, 'JmResourceTypeTC' comments earlier in this note). * 69/1829 - Issue 43 - see above note and 40/954 comments. * 71/1885 - conformance for 'jmQueueGroup' - use a 'GROUP' subclause in your 'MODULE-COMPLIANCE' macro for all conditionally mandatory or option groups (SNMPv2-CONF, RFC 1904), NOT just a comment. * 72/1913 - 'jmQueueGroup' - The DESCRIPTION clauses of OBJECT-GROUP macros always reiterate the 'condition(s)' for 'conditionally mandatory' groups. * 98/1991+ - the header ending in '...Index' is wrong - and it remains wrong up through page 103/2035 (Change History) inclusive. From hastings at cp10.es.xerox.com Wed Feb 5 04:38:38 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:01 2009 Subject: JMP> JMP Suggestion to move 8 objects to the ResourcesTable Message-ID: <9702050940.AA05281@zazen.cp10.es.xerox.com> Subj: JMP Suggestion to move 8 objects to the ResourcesTable From: Tom Hastings and Ira McDonald File: move8obj.txt Date: 2/4/97 We have a suggestion to move 8 objects from the jmJobTable to become enums in the jmResourceTable. This would effectively remove 8 objects from the MIB, while still providing the capability to represent the same information. However, we have another suggestion that makes all of the objects in the jmResourceTable directly addressable. Then an application need not copy all of the resource items, in order to find a particular one. The idea is to insert a fourth index between the current second and third indexes. The value of the new thrid index will be the jmResourceType enum and the fourth index will be the instance within that type. For those resources that are per-document, such as fileName(3), documentName(4), and documentPages(new) the fourth index is the document number within the job. For the new resource, For those resources that can have multiple values per job, but are not per document, the fourth index is just an instance index. For example, interpreter(10), the fourth index is just an instance index. So the indexes for the jmResourceTable will be in order: 1. jmJobSetIndex 2. jmJobIndex 3. jmResourceType -- new 4. jmResourceIndex We propose that we move any object from the jmJobTable to the jmResourceTable that: 1. Is hard to implement, such as objects with syntax: DateAndTime 2. May not be implemented in some implementations, such as jmAccountName. 3. Take a lot of space and may not be implemented, such as jmJobComment. We propose to move the following objects from the jmJobTable to become enums in the jmResourceTable: -- Job Identification (I) objects: jmJobSourceChannel Integer32(1..2147483647), jmJobSubmissionTime DateAndTime, jmJobComment OCTET STRING(SIZE(0..63)), -- Job Parameters (P) objects: jmJobTotalKOctets Integer32(0..2147483647), -- Job Accounting (A) objects: jmJobKOctetsCompleted Counter32(0..2147483647), jmJobStartedProcessingTime DateAndTime, jmJobCompletionTime DateAndTime, jmJobAccountName OCTET STRING(SIZE(0..63)) The resulting enum names are (dropping the jm and lowercasing the first remaining letter: jobSourceChannel jobSubmissionTime jobComment -- Job Parameters (P) objects: jobTotalKOctets -- Job Accounting (A) objects: jobKOctetsCompleted jobStartedProcessingTime jobCompletionTime jobAccountName This leaves the following 10 objects in the jmJobTable: JmJobEntry ::= SEQUENCE { -- Job Identification (I) objects: jmJobIndex Integer32(0..2147483647), jmJobName OCTET STRING(SIZE(0..63)), jmJobIdName OCTET STRING(SIZE(0..63)), jmJobIdNumber Integer32(0..2147483647), jmJobTypes JmJobTypesTC, jmJobOwner OCTET STRING(SIZE(0..63)), jmJobDeviceNameRequested OCTET STRING(SIZE(0..63)), jmDeviceIndex Integer32(1..2147483647), -- Job Status (S) objects: jmJobCurrentState JmJobStateTC, jmJobStateReasons OCTET STRING(SIZE(0..63)), -- encoded as a bit string } 2. There is one object that we think should be added: jmJobSetName which is a text string that could be the name of the queue, server, or printer that the system administrator may assign to each job set. For a printer that has only one job set, the jmJobSetName would most likely be the printer name. For a server that has only job set, the jmJobSetName would most likely be the server name. For a server or printer that has multiple job sets, each job set would most likely be the name of the queue associated with each job set. jmJobSetName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the human readable string name of the job set as assigned by the system adminstrator to help distinguish between multiple job sets. This name does not need to be unique. If the agent is instrumting a printer and that printer has only one job set, this object could be the name of the printer. If the agent is instrumenting a server and that server has only one job set, this object could be the name of the server. If the printer or server has multiple job sets, this object could be the name of the queue associated with the job set." ::= { jmGeneralEntry 2 } From harryl at vnet.ibm.com Thu Feb 13 09:47:26 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <199702131457.JAA29765@lists.underscore.com> jmResourceTypeTC says (effectively) "The type (and amount) of resource... required to process the job...the amount is updated while the job processes... etc." I was starting to wonder if we were "affecting" the job, for example, number of copies. But I'm sure we've been very careful to avoid "missiles". Then, the purpose of an initial value is to establish a range for metering, like copy 1 of 3 has been printed - right? But, if the initial value is overwritten per "amount is updated while the job processes...", and the MIB basically acts as a data base to be polled, doesn't 1 of 3 fall apart, in which case what good would the initial value be? Sorry if I missed something here. Harry Lewis. From harryl at vnet.ibm.com Thu Feb 13 13:24:35 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Minutes delay Message-ID: <199702131829.NAA01093@lists.underscore.com> At the conf call, someone said they have a copy of the top 16 alerts list from Stardust. I think it was Stuart. I have the PMP minutes from last week about 70% complete but have hit a major snag at work that will require all my attention until at least Tuesday. Sorry... Since the top 16 list gates other work, it might be good if Stuart would post it. Harry Lewis. From bpenteco at boi.hp.com Thu Feb 13 11:28:41 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <01BC1990.4EB4FB80@hpb15767.boi.hp.com> Harry, jmResourceType is a read-only object, so how can the job be affected? Wouldn't the object change values only as resources are used? This brings up another question. jmResourceType says "The type of resource, e.g., medium, ink, staples, processing-time, color-impressions, etc. required to process the job before the job start processing. This value is updated while the job processes to indicate the amount of the resource that is being used while the job is processing. After the job completes processing, this value indicates the total usage of this resource made by the job." If a job hasn't started processing, a resource will indicate how many will be produced. Then, when the job starts processing, the value will go to zero and count up to three. Is the management application expected to query jmJobState to know how to interpret the value? If so, should we define which states cause the value of a resource to change from "required" to "used"? Bob Pentecost HP ---------- From: Harry Lewis [SMTP:harryl@VNET.IBM.COM] Sent: Thursday, February 13, 1997 7:47 AM To: jmp@pwg.org Subject: JMP> Resource table - Missile or Camera jmResourceTypeTC says (effectively) "The type (and amount) of resource... required to process the job...the amount is updated while the job processes... etc." I was starting to wonder if we were "affecting" the job, for example, number of copies. But I'm sure we've been very careful to avoid "missiles". Then, the purpose of an initial value is to establish a range for metering, like copy 1 of 3 has been printed - right? But, if the initial value is overwritten per "amount is updated while the job processes...", and the MIB basically acts as a data base to be polled, doesn't 1 of 3 fall apart, in which case what good would the initial value be? Sorry if I missed something here. Harry Lewis. From harryl at vnet.ibm.com Thu Feb 13 15:42:54 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <199702132045.PAA02008@lists.underscore.com> Bob, >jmResourceType is a read-only object, so how can the job be affected? Thanks for pointing that out. >This brings up another question. ................... ce, >......... If a job hasn't started processing, a resource will indicate how >many will be produced. Then, when the job starts processing, the value will >go to zero and count up to three. Is the management application expected to >query jmJobState to know how to interpret the value? If so, should we >define which states cause the value of a resource to change from "required" >to "used"? You've done a better job at stating my observation. My recommendation is to separate values which are passed in from values that will vary during the job. Harry Lewis From lpyoung at lexmark.com Thu Feb 13 17:14:26 1997 From: lpyoung at lexmark.com (Lloyd Young) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <199702132219.AA27740@interlock.lexmark.com> Bob Pentecost wrote >This brings up another question. jmResourceType says "The type of resource, >e.g., medium, ink, staples, processing-time, color-impressions, etc. >required to process the job before the job start processing. This value is >updated while the job processes to indicate the amount of the resource that >is being used while the job is processing. After the job completes >processing, this value indicates the total usage of this resource made by >the job." If a job hasn't started processing, a resource will indicate how >many will be produced. Then, when the job starts processing, the value will >go to zero and count up to three. Is the management application expected to >query jmJobState to know how to interpret the value? If so, should we >define which states cause the value of a resource to change from "required" >to "used"? I do not think it is likely that any system will ever fill in the values for a particular resource that are required to process the job before the job starts processing. It would make this whole thing simpler if we changed the first sentence and said "The type of resource, e.g. medium, ink, staples, processing-time, color-impressions, etc. that are consumed while processing the job. This value is updated while the job processes ....... ". With this wording change, the resources now are stricly what is consumed in processing the job. Lloyd Young Lexmark From harryl at vnet.ibm.com Thu Feb 13 21:11:37 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <199702140214.VAA02900@lists.underscore.com> Lloyd wrote: >I do not think it is likely that any system will ever fill in the values for a >particular resource that are required to process the job before the job starts >processing. It would make this whole thing simpler if we changed the first >sentence and said "The type of resource, e.g. medium, ink, staples, >processing-time, color-impressions, etc. that are consumed while >processing the job. This value is updated while the job processes. >With this wording change, the resources now are stricly what is >consumed in processing the job. Lloyd, I'd like to agree, but this gets to my original point... If you are using SNMP to poll the job table and want to display (based on your findings) "Page 1 of 3 is printing" then the number of pages requested (3) *has* to be filled out by the agent and *cannot* be overwritten as the pages begin to be consumed. Harry Lewis From rbergma at dpc.com Fri Feb 14 11:25:01 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource Table - Missile or Camera Message-ID: <199702140214.VAA02900@lists.underscore.com> One of my original concepts was to overload the resource objects and have the values represent the requested value prior to the printer processing the job and the actual value after. The primary reason was to minimize the number of objects. When these objects were deleted and replaced with the resource table, this idea had no advantages and was abandon. The Resource Enums were to be unique for "requested" and "actual" values. In reviewing the current specification I notice that in some cases this is not true. For example, sides(9) can be either requested or used. This should be changed to be consistent. I will review the current set of enums and correct where necessary. I agree that in most cases the only values presented will be the "actuals". (This is why I originally proposed overloading the objects.) However, with the Resource Table, the printer can present only those values desired and the number of objects will be a minimum. In the rare case of a DPA printer, the entire set of resource enums can be returned. The more I look at the resource table, the more I agree with Tom that it is a "win-win" situation. A DPA printer can present every possible parameter and a real-world printer can present only the useful values it can access. All of this without a large number of objects in the MIB. Ron Bergman Dataproducts Corp. rbergma@dpc.com (805) 578-4421 From harryl at vnet.ibm.com Fri Feb 14 12:42:29 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:01 2009 Subject: JMP> Resource Table - Missile or Camera Message-ID: <199702141745.MAA04994@lists.underscore.com> Ron wrote: >The more I look at the resource table, the more I agree with Tom >that it is a "win-win" situation. A DPA printer can present every >possible parameter and a real-world printer can present only the >useful values it can access. All of this without a large number >of objects in the MIB. I agree! The resource table, with resource type enums, is turning out to be a great idea. One thing I'm finding is that Resource Name seems to be redundant with information that should already be in the Printer MIB. I wonder how useful resource name is. If we're trying to name a resource like OutputBin (3) "Big Bin" - then the name is surely in the printer MIB and a server implementation would not be representing this resource. If we're trying to get fancy and say MediaType (Paper) "Hillary's Pink LetterHead", I really doubt any accounting application will be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.) for charging purposes is more practical. Anyone else vie for eliminating Resource Name? Again, otherwise, I really LIKE the resource table! Harry Lewis - IBM Printing Systems. From rbergma at dpc.com Fri Feb 14 20:31:16 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource Table - Missile or Camera (fwd) Message-ID: <199702141745.MAA04994@lists.underscore.com> Harry, It looks like the object jmResourceName is more confusing than descriptive. It is not intended to be the name of the resource but is to be used for resources that require a string to be returned. For example, fileName(3) and documentName(4) are resources that cannot be represented by a numeric value. In this case jmResourceAmount would be zero and the actual value of the resource is presented in jmResourceName. (I believe that this was discussed in last weeks meeting after you left for the airport.) In the case of a numeric value jmResourceName would be a string of zero length. Use of the object as a name of the resource in this case was agreed to be removed in the meeting last week. To eliminate some of this confusion the jmResourceName object name should be changed to something like jmResourceStringValue. Can anyone suggest a better name? Ron Bergman Dataproducts Corp. rbergma@dpc.com (805)578-4421 ---------- Forwarded message ---------- Harry wrote: One thing I'm finding is that Resource Name seems to be redundant with information that should already be in the Printer MIB. I wonder how useful resource name is. If we're trying to name a resource like OutputBin (3) "Big Bin" - then the name is surely in the printer MIB and a server implementation would not be representing this resource. If we're trying to get fancy and say MediaType (Paper) "Hillary's Pink LetterHead", I really doubt any accounting application will be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.) for charging purposes is more practical. Anyone else vie for eliminating Resource Name? Harry Lewis - IBM Printing Systems. From rbergma at dpc.com Sat Feb 15 13:39:52 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Proposed change to jmResourceName Message-ID: <199702141745.MAA04994@lists.underscore.com> The following change to jmResourceName is proposed as per the recent email on this subject: IS: ----------------------------------------------------------------------- jmResourceName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) or Integer32(0..2147483647) or Counter32(0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The coded character set name of the resource, e.g., iso-a4- white, red-ink, number 2 staples, or the string value, such as the document name, or device name, etc., or an index of a row in a table. The data type of jmResourceName is determined by the value of jmResourceType." ::= { jmResourceEntry 3 } ----------------------------------------------------------------------- CHANGE TO: ----------------------------------------------------------------------- jmResourceStringValue OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)), MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the value of a resource that must be represented as a string. If the resource is not represented as a string, this object must return a string of zero length. For numeric values, the object jmResourceUnits must be used." ::= { jmResourceEntry 3 } ----------------------------------------------------------------------- After a review of the related resource enums, I do not believe that any will require changes. The enums which have dual purpose (i.e. used for both requested and used states) are sides (simplex/duplex), interpters, and physical devices. I am not sure that these justify a split into a ...Requested and ...Used. However, I believe that we should add: impressionsRequested(?) pagesRequested(?) -- Total logical pages for all copies ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From rbergma at dpc.com Sat Feb 15 14:13:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> New text for MIB Abstract section Message-ID: <199702141745.MAA04994@lists.underscore.com> Proposed change to the "Abstact" text on the first page of the MIB document. This is simply a rewording and format change to the existing text. I have also added a sentence at the end regarding extensions of the MIB for fax and scanners. IS: ----------------------------------------------------------------------- Abstract This Internet-Draft specifies a job monitoring MIB that contains a set of objects for monitoring of the status and progress of print jobs and to obtain resource accounting data at the completion of a job using SNMP. This MIB is intended to be implemented in printers or the server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. ----------------------------------------------------------------------- CHANGE TO: ----------------------------------------------------------------------- Abstract This Internet-Draft specifies a set of MIB objects for monitoring the status and progress of print jobs and to obtain resource accounting data at the completion of a job using SNMP. This MIB is intended to be implemented in printers or the server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. ----------------------------------------------------------------------- ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp. rbergma@dpc.com (805)578-4421 From rbergma at dpc.com Sat Feb 15 16:13:58 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Major Revision to MIB Introduction Message-ID: <199702141745.MAA04994@lists.underscore.com> I have completed a major rewrite of the Introduction/Goals sections of the Job Monitoring MIB. Sorry for the uglyness of the IS: part. I will save of copy of this on the ftp server if anyone requests. IS: ----------------------------------------------------------------------- Introduction The Job Monitoring MIB contains a set of objects for monitoring of the status and progress of print jobs and to obtain resource accounting data at the completion of a job using SNMP. This MIB is intended to be implemented in printers or the server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Goals The following goals are copied from the charter: 1. The major goals of this MIB are to satisfy the needs of an agent in the printer and secondarily an agent in the server that submits jobs to printers and controls printers. Implementations should place the agent as close to the processing of the print job as possible. This MIB applies to printers that spool as well as those that don't. This MIB is also designed so that servers are able find out about jobs in a printer that may have been submitted by other servers using any job submission protocol. In most environments that support high function job submission/job control protocols, like ISO DPA, those protocols would be used to monitor and manage print jobs rather than using the Job Monitoring MIB. The following specific text was agreed to at the October 1996 JMP meeting: "The job monitoring MIB is for agents in the printer (spooling or non-spooling) or the first server closest to the printer where the printer is either: a. directly connected to the server only --or-- b. the printer does not contain the job monitoring MIB agent." 2. The job MIB is intended to provide the following information for the indicated Role Models (see Appendix D - Roles of Users in the Printer MIB draft update to RFC 1759). A limited set of mandatory job and document objects for a printer, plus a set of conditionally mandatory objects, will be developed to provide this information. User (U1) A timely notification that his job has completed and where. (U2) The current status of the user's job (user queries). (U3) Error and diagnostic information for jobs that did not successfully complete. (U4) Ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take. Operator (OP1) A presentation of the state of all the jobs in the print system. (OP2) Which users submitted each job. (OP3) What resources does each job need. (OP4) For which physical printers are the jobs candidates. (OP5) Some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates. Capacity Planner (C1) How busy are printers. (C2) What time of day are they used. (C3) How long do users' jobs wait before starting to print. Accountant (A1) A record of resources used and printer usage data for charging users or groups for resources used. The MIB will provide for printers that can contain more than one job at a time, but still be usable for low end printers that only contain a single job at a time. In particular, the MIB shall meet the needs of Windows and other PC environments for managing low-end networked devices without unnecessary overhead or complexity, while also providing for higher end systems and devices. 3. The MIB will provide job resource accounting information after the printer has finished printing the job. This resource accounting information is intended to be used by: A management station that is co-located with the printer to provide an enhanced console capability. End user job monitoring programs that provide status on progress and completion of jobs during the complete life cycle of the job, including a defined period after the job completes. System accounting programs that copy the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job- retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed). Issue 1 - Should we add a standard SNMP RowStatus object to the jmJobTable and jmResourceTable? Should we add a standard SNMP RowStatus object to the jmJobTable and jmResourceTable so that an accounting program can delete a row in the table after the job is completed and the accounting program has copied the accounting data to an accounting log? Then no accounting data would get lost. Issue 2 - If we add RowStatus to the jmJobTable, should we add a jmGeneralTableOverflowPolicy object to the jmGeneralGroup? If we add RowStatus to the jmJobTable, should we add a jmGeneralTableOverflowPolicy object to the jmGeneralGroup that specified whether the printer stops when the table fills up or continues? Then an administrator could decide whether it was more important to keep accurate accounting data or to keep the devices processing. Issue 3 - If we add jmGeneralTableOverflowPolicy object should it be read-write? If we add jmGeneralTableOverflowPolicy object should it be read-write, so that the policy can be set by an NMS? 4. System usage statistics gathering programs that copy the completed job statistics to system usage logs. 5. The MIB will provide objects that represent a compatible subset of job and document attributes of the ISO DPA standard, so that coherence is maintained between the two protocols and information presented to end users and system operators. However, the job monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI), as well as with ones that do implement ISO DPA. So nothing in the job monitoring MIB shall require implementation of the ISO DPA protocol. 6. The MIB will be designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs. The job MIB will be designed such that a future multi-function job monitoring MIB will be able to augment this MIB. 7. The MIB will not address any security issues. Security provisions will be limited only to those provided by SNMP, in current or future versions. 8. The MIB will provide for the monitoring of jobs that clients submit directly to devices, to supervisor control programs, or to spooling systems. 9. The MIB will provide SNMP MIB access to jobs submitted to the device by any protocol, including devices that accept jobs using multiple protocols. ----------------------------------------------------------------------- CHANGE TO: ----------------------------------------------------------------------- Introduction The Job Monitoring MIB is intended for use by an agent within a printer or the first server closest to the printer, where the printer is either directly connected to the server only or the printer does not contain the job monitoring MIB agent. It is recommended that implementations place the SNMP agent as close as possible to the processing of the print job. This MIB applies to printers with and withoutspooling capabilities. This MIB is designed to be compatible with most current comonly used job submission protocols. In most environments that support high function job submission/job control protocols, like ISO DPA, those protocols would be used to monitor and manage print jobs rather than using the Job Monitoring MIB. The job MIB is intended to provide the following information for the indicated Role Models (Refer to RFC 2XXX, Appendix D - Roles of Users). User: Provide the ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take. Provide the ability to identify the current status of the job (user queries). Provide a timely notification that the job has completed and where it can be found. Provide error and diagnostic information for jobs that did not successfully complete. Operator Provide a presentation of the state of all the jobs in the print system. Provide the ability to identify the user that submitted the print job. Provide the ability to identify the resources required by each job. Provide the ability to define which physical printers are candidates for the print job. Provide some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates. Capacity Planner: Provide the ability to determine printer utilization as a function of time. Provide the ability to determine how long jobs wait before starting to print. Accountant: Provide information to allow the creation of a record of resources used and printer usage data for charging users or groups for resources used. The MIB will support printers that can contain more than one job at a time, but still be usable for low end printers that only contain a single job at a time. In particular, the MIB shall support the needs of Windows and other PC environments for managing low-end networked devices without unnecessary overhead or complexity, while also providing for higher end systems and devices. The MIB will provide job resource accounting information after the printer has finished printing the job. This resource accounting information is intended to be used by: - A management station that is co-located with the printer to provide an enhanced console capability. - End user job monitoring programs that provide status on progress and completion of jobs during the complete life cycle of the job, ncluding a defined period after the job completes. - System accounting programs that copy the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job-retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed). The MIB provides a set of objects that represent a compatible subset of job and document attributes of the ISO DPA standard, so that coherence is maintained between the two protocols and information presented to end users and system operators. However, the job monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI), as well as with ones that do implement ISO DPA. So nothing in the job monitoring MIB shall require implementation of the ISO DPA protocol. The MIB is designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs as an augmentation to this MIB. ---------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From hastings at cp10.es.xerox.com Tue Feb 18 03:19:36 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Updated JMP issues list from Feb JMP meeting Message-ID: <9702180821.AA08145@zazen.cp10.es.xerox.com> We resolved all of the issues except the issues 5 and 26. Also we have added issues 44, 45, and 46. Finally, some good issues have been sent to the e-mail list by Keith, Bob P, and Harry which need addressing. Hopefully, we can address these issues on the next teleconference. I've posted the issues list resolutions as: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-rw-r-- 1 pwg pwg 33280 Feb 18 07:58 issues.doc -rw-rw-r-- 1 pwg pwg 29906 Feb 18 07:58 issues.pdf -rw-rw-r-- 1 pwg pwg 30203 Feb 18 07:59 issues.pdr The .pdf has revision marks in black and .pdr has them in red. The following issues remain with the indicated action items: Issue 5 - Restore NMS having to access both the server and printer agents (Configuration 2b)? 13 Yes, with the following understandings: Configuration 2b will show a monitoring application, a server, and a printer. The MIB will be only in the printer, but the monitoring application is also monitoring the server by some other means than the Job Monitoring MIB. The Job Monitoring MIB in the Printer shall have enough information in it for the monitoring application to find the job in the Printer's Job Monitoring MIB that it found in the server (by other means). In such cases, the server usually deletes its copy of the job, but need not. This configuration covers the configuration supported by the HP 5si Mopier private job monitoring MIB when driven from a Novell server. ACTION ITEM (Tom Hastings, Bob Pentacost): Tom draw up a new configuration 2b and show to Bob before distributing it to the group. Issue 26 - Which indexes shall be persistent across power off and which need not be? 47 No decision yet. ACTION ITEM (Tom Hastings): send this issue and the proposal for making the jmJobIndex and jmJobSetIndex persistent across power off. 1. New Issues Issue 44 - There was agreement that the Job Monitoring MIB needs a primary index that can separate jobs into disjoint sets for purposes of scheduling. This primary index serves the same purpose for the Job Monitoring MIB as the hrDeviceIndex does for the Printer MIB, except that the Job Monitoring MIB did not want to require the Host Resources MIB. What is the definition of Job Set? How do job sets relate to queues? Can a Printer have more than one job set without having queuing? For a printer that is fed from multiple external queues, are all the jobs from all those queues in a single job set in the Printer? Issue 45 - After fully agreeing on what a Job Set is, should the name remain Job Set, or be changes to queue, or job pool or job group? Issue 46 - Do we need to add a jmJobSetName object so that an operator can determine which job set he/she is looking at. The jmJobSetName is administratively assigned and could be the queue name, the server name if the server has only one job set or the printer name if the printer has only one job set. We definitely need jmQueueName (which I added to the jmQueueGroup). So is jmJobSetName a different object, at least in some configurations supported by the Job Monitoring MIB? From hastings at cp10.es.xerox.com Wed Feb 19 02:04:10 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Minutes of JMP meeting - thanks Harry Message-ID: <9702190706.AA08432@zazen.cp10.es.xerox.com> I've posted the minutes that Harry took in: ftp://ftp.pwg.org/pub/pwg/jmp/minutes/ -rw-r--r-- 1 pwg pwg 20480 Feb 12 21:24 970207-jmp-meeting-minutes.doc -rw-r--r-- 1 pwg pwg 10507 Feb 19 06:40 970207-jmp-meeting-minutes.pdf -rw-r--r-- 1 pwg pwg 3183 Feb 19 06:41 970207-jmp-meeting-minutes.txt The issues that I posted last week contain the additional agreements reached after Harry had to leave. There is one additional issues raised because Harry's notes start off with the agreement that we move jmJobSubmissionTime from the JobTable to the QueueTable. However, the later paper that we considered moved jmJobSubmissionTime to the ResourceTable. There are pros and cons with each: Moving jmJobSubmissionTime to the QueueTable means that an implementation that queues, shall implement the time, which is probably not a burden on something that queues and means that jobs will get a time stamp as they are entered into the MIB. On the other hand, a Printer that doesn't queue, cannot have a jmJobSubmissionTime at all. The advantage of putting it in the ResourceTable is for implementations that don't have concept of time. But our experience with alerts in the Printer MIB say it was a mistake not to require time stamps on alerts, so we changes prtAlertTime to become mandatory. Same should be true for JobSubmissionTime, shouldn't it? And shouldn't the job submission time be recorded whether the implementation queues or not? I've added this issue as issue 47 and updated issues.doc, issues.pdf and issues.pdr accordingly. See contributions sub-directory. Tom From jkm at underscore.com Wed Feb 19 09:18:00 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> We need to improve our publication announcements Message-ID: Sorry for the cross-posting here, but this message is long overdue. Folks, PLEASE take the 2.5 seconds to type in the complete URL to the documents you announce to the mailing lists. It only takes a very short time to be complete and accurate...and for those folks with decent mail agents, this makes it very, very easy for them to quickly reference your hard work. (After all, you DO want people to read your work, no? And the sooner the better, right?) This message was prompted by the attached message. Note that at this writing (just after the attached message was posted), the contents of the referenced server directory is: -rw-r--r-- 1 pwg pwg 7704 Feb 19 13:05 err1.PDF -rw-r--r-- 1 pwg pwg 29696 Feb 19 13:05 err1.doc -rw-r--r-- 1 pwg pwg 13824 Feb 13 00:29 inputsw.doc -rw-r--r-- 1 pwg pwg 15360 Feb 13 23:40 inputsw2.doc Let's not make undue work for each other, ok? Thanks for your cooperation. ...jay ----- Begin Included Message ----- To: "pmp%pwg.org" From: Lloyd Young Date: 19 Feb 97 8:09:55 EST Subject: PMP> A Top 20 Chart Mime-Version: 1.0 I have placed a copy of Chuck's file in Word and PDF formats in the /pub/pwg/contributions directory. Lloyd Young --------------------------- Original e-mail --------------------------- To: pmp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Lloyd Young) From: adamsc%pogo.WV.TEK.COM @ interlock.lexmark.com (Chuck Adams) @ SMTP Date: 02/18/97 07:50:58 AM Subject: PMP> A Top 20 Chart Folks, Attached is a first draft of a chart presenting my personal top 20 events list. I hope this will help us in our "attempt to standardize the alert table entries, sub-unit status, hrDeviceStatus, hrPrinterStatus and hrPrtDetectedErrorState for a subset of the most likely printer events." I'll get this out now without a couple of events since I believe they can be inferred from what is presented here. But if you want to add more events be my guest and have at it. Chuck Adams Tektronix, Inc. P.S. If someone would be so kind as to put this in the ftp://pwg.org/pub/pwg/pmp/contributions/ site I would appreciate it. ----- End Included Message ----- From harryl at vnet.ibm.com Thu Feb 20 00:39:31 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> jmJobSubmissionTime Message-ID: <199702200540.AAA24720@lists.underscore.com> Tom wrote (somewhat paraphrased - my response brackted by HRL -): >There is one additional issues raised ... (moving) >jmJobSubmissionTime from the JobTable to the QueueTable (or) >to the ResourceTable. > >There are pros and cons with each: > >Moving jmJobSubmissionTime to the QueueTable means that an implementation >that queues, shall implement the time, which is probably not a burden >on something that queues and means that jobs will get a time stamp >as they are entered into the MIB. On the other hand, a Printer >that doesn't queue, cannot have a jmJobSubmissionTime at all. HRL - I think the system that queues sets the submission DateTime HRL - as you say. For *printers* that don't queue, the DateTime must HRL - be passed in on submission from the server queue. >The advantage of putting it in the ResourceTable is for implementations >that don't have concept of time. But our experience with alerts in >the Printer MIB say it was a mistake not to require time stamps >on alerts, so we changes prtAlertTime to become mandatory. Same >should be true for JobSubmissionTime, shouldn't it? HRL - Another advantage of putting it in the ResourceTable is that HRL - not Time becomes an enumerated resource. The submission DateTime HRL - passed in from the server can be "stashed" as one TIME Resource HRL - and additional TIME Resources can be defined, as TimeTick that HRL - can be used to roughly correlate and track progress as follows HRL - in response to your final question. >And shouldn't the job submission time be recorded whether >the implementation queues or not? HRL - As I was saying. If submission DateTime is passed in with the HRL - submission protocol, the jmResourceType TIME could be defined HRL - as follows: (shorthand notation) HRL - HRL - jmResourceType - TIME HRL - HRL - 1 - Other HRL - 2 - Unknown HRL - 3 - jobSubmssionTime - DateTime HRL - 4 - jobSubmissionTick - TimeTicks HRL - 5 - jobStartTick - TimeTicks HRL - 6 - jobCompleteTicks - TimeTicks HRL - HRL - Using these TIME resources as entries in the Resource table, HRL - and assuming the agent closely correlates Time and Ticks on HRL - job submission (within a second or two?) then, using just HRL - Ticks (derived from sysUpTime) the Job Management App can HRL - determine how long the job waited on the printer and how long HRL - it took to print. HRL - HRL - One disadvantage I see is number of Resource table entries, but HRL - it seems we've created this table as a collector of sorts AND HRL - we've at least cleverly provided the jmResourceType providing HRL - coarser granularity for more efficient data gathering. Harry Lewis - IBM Printing Systems. From rbergma at dpc.com Fri Feb 21 16:34:47 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Conference Call on February 25 Message-ID: <199702200540.AAA24720@lists.underscore.com> The next JMP teleconference has been scheduled for Tuesday, February 25 at 4:00 PM EST, or 1:00 PM PST. Agenda: 1. Issues from Keith Carter's email dated 4-FEB-1997 2. Proposed changes to jmResourceName; email from Ron Bergman dated 15-FEB-1997 3. New text for "MIB Abstract" section; email from Ron Bergman dated 15-FEB-1997 4. Major Revision to "MIB Introduction"; email from Ron Bergman dated 15-FEB-1997 5. Review of "ftp://ftp.pwg.org/pub/pwg/jmp/contributions/issues.xxx" as posted by Tom Hastings on 18-FEB-1997 Thanks again to Lloyd Young for setting up the conference call, the details are: Date: Tuesday 2/25 Time: 4:00 - 6:00 pm EST (1:00 - 3:00 pm PST) Phone number: 423-673-6717 Access code: 820010 ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com From harryl at vnet.ibm.com Sat Feb 22 12:32:58 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> jmGeneral question Message-ID: <199702221747.MAA11255@lists.underscore.com> I'm wondering about MaxNumberofJobs and CurrentNumberofJobs. 3 basic questions: 1. If max number of jobs in the job table is important, then why isn't it also important to know th max number of entries in the resource table and the job completion table? 2. If we have JobCompletedPolicy (time in seconds that jobs are kept in table), then why do we have max entries as well? Memory allocation in the job monitor software? 3. How are max and current intended to be used in terms of differentiation? If there is a max, wouldn't the current basically start at 0, climb to max and stay there? Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue Feb 25 05:55:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Updated JmResourceTypeTC and jmResourceTable Message-ID: <9702251057.AA09901@zazen.cp10.es.xerox.com> I've made a stab at incorporating all the comments about the JmResourceTypeTC and the jmResourceTable that have been sent since the 2/7 JMP meeting, as well as incorporating the agreements reached at the JMP meeting. I hope we can cover it at the telecon today, 2/25 (1pm PST, 4pm EST). I've posted the files at: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 57344 Feb 25 10:53 res-type.doc -rw-r--r-- 1 pwg pwg 54671 Feb 25 10:54 res-type.pdf -rw-r--r-- 1 pwg pwg 56360 Feb 25 10:54 res-type.pdr From bpenteco at boi.hp.com Tue Feb 25 10:21:28 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:02 2009 Subject: JMP> 2/25 Phone conference comments Message-ID: <01BC22F4.E71C7DE0@hpb15767.boi.hp.com> Unfortunately, I may completely miss the JMP phone conference today. If I can free up some time, I'll join you. However, I do have a couple of comments. Re: Keith Carter's "Job MIB Assessment". * Page 58 - jmJobName, jmJobIdName, jmJobIdNumber, jmJobComment: Clarify the use of these objects. Here is an example. A user submits a print job. The file name of the job is "C:\MYJOB.PS". The user specifies a comment of "Status Report 1/31/97". The print job is queued on server "SERVER1" in print queue "PSQUEUE". The numeric job id is 1234. What value is the value of each object? Do we need a specific object for source server and source queue to accommodate management applications such as the management application provided by HP that correlates jobs in a printer with jobs in a print queue on a print server? It looks like the print queue name is covered by jmJobDeviceNameRequested. However, it looks like there's no place for the source server or client name. We should also try to provide the file name of the job and a source port object which tell which client port the job came from. We just held an internal review of the Job Monitoring MIB. I'll try to get the issues posted by the end of this week. Bob Pentecost HP From harryl at vnet.ibm.com Tue Feb 25 11:37:21 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> 2/25 Phone conference comments Message-ID: <199702251641.LAA21687@lists.underscore.com> Bob Pentecost wrote: > ............................................. Do we need a >specific object for source server and source queue to >accommodate management applications such as the management >application provided by HP that correlates jobs in a printer >with jobs in a print queue on a print server? I agree with Bob's recommendation. I think we need an object like jmJobServerName (or just jmJobServer) and jmJobQueueName. I think these should go in the job table. >It looks like the print queue name is covered by jmJobDeviceNameRequested. I guess so, but why not spell it out as above? >However, it looks like there's no place for the source server or client >name. We should also try to provide the file name of the job and a source >port object which tell which client port the job came from. Again, agreed. Harry Lewis From bpenteco at boi.hp.com Tue Feb 25 15:12:23 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:02 2009 Subject: JMP> Major Revision to MIB Introduction Message-ID: <01BC231D.8AA4A140@hpb15767.boi.hp.com> Again, because I can't make the phone conference, I'll put my comments here. There are references to DPA at the end of the first paragraph and again in the second to last paragraph. Are these really needed? Can't this document stand on its own without DPA? Under "User" it says "No attempt is made to actually predict the length of time that jobs will take." Then, under "Operator" it says "Provide some idea of how long each job will take." Aren't these contradictory? Bob Pentecost HP ---------- From: Ron Bergman[SMTP:rbergma@dpc.com] Sent: Saturday, February 15, 1997 6:14 AM To: jmp@pwg.org Subject: JMP> Major Revision to MIB Introduction I have completed a major rewrite of the Introduction/Goals sections of the Job Monitoring MIB. Sorry for the uglyness of the IS: part. I will save of copy of this on the ftp server if anyone requests. IS: ----------------------------------------------------------------------- ----------------------------------------------------------------------- CHANGE TO: ----------------------------------------------------------------------- Introduction The Job Monitoring MIB is intended for use by an agent within a printer or the first server closest to the printer, where the printer is either directly connected to the server only or the printer does not contain the job monitoring MIB agent. It is recommended that implementations place the SNMP agent as close as possible to the processing of the print job. This MIB applies to printers with and withoutspooling capabilities. This MIB is designed to be compatible with most current comonly used job submission protocols. In most environments that support high function job submission/job control protocols, like ISO DPA, those protocols would be used to monitor and manage print jobs rather than using the Job Monitoring MIB. The job MIB is intended to provide the following information for the indicated Role Models (Refer to RFC 2XXX, Appendix D - Roles of Users). User: Provide the ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take. Provide the ability to identify the current status of the job (user queries). Provide a timely notification that the job has completed and where it can be found. Provide error and diagnostic information for jobs that did not successfully complete. Operator Provide a presentation of the state of all the jobs in the print system. Provide the ability to identify the user that submitted the print job. Provide the ability to identify the resources required by each job. Provide the ability to define which physical printers are candidates for the print job. Provide some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates. Capacity Planner: Provide the ability to determine printer utilization as a function of time. Provide the ability to determine how long jobs wait before starting to print. Accountant: Provide information to allow the creation of a record of resources used and printer usage data for charging users or groups for resources used. The MIB will support printers that can contain more than one job at a time, but still be usable for low end printers that only contain a single job at a time. In particular, the MIB shall support the needs of Windows and other PC environments for managing low-end networked devices without unnecessary overhead or complexity, while also providing for higher end systems and devices. The MIB will provide job resource accounting information after the printer has finished printing the job. This resource accounting information is intended to be used by: - A management station that is co-located with the printer to provide an enhanced console capability. - End user job monitoring programs that provide status on progress and completion of jobs during the complete life cycle of the job, ncluding a defined period after the job completes. - System accounting programs that copy the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job-retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed). The MIB provides a set of objects that represent a compatible subset of job and document attributes of the ISO DPA standard, so that coherence is maintained between the two protocols and information presented to end users and system operators. However, the job monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI), as well as with ones that do implement ISO DPA. So nothing in the job monitoring MIB shall require implementation of the ISO DPA protocol. The MIB is designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs as an augmentation to this MIB. ---------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From rbergma at dpc.com Thu Feb 27 11:15:29 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Major Revision to MIB Introduction Message-ID: <01BC231D.8AA4A140@hpb15767.boi.hp.com> On 25-OCT-1997 Bob Pentecost wrote: There are references to DPA at the end of the first paragraph and again in the second to last paragraph. Are these really needed? Can't this document stand on its own without DPA? RB> In the re-write of the JMP MIB Introduction, I did not try to remove RB> any of the ideas that were present in the original goals and charter RB> for the project. I share your concerns of becoming tied into the RB> DPA philosophy of supporting everything possible and imaginable. RB> RB> I also recall a discussion in one of the PWG meetings of last year, RB> that referenced an even earlier meeting, whereby it was agreed that RB> all future PWG efforts would be based upon DPA. The first DPA RB> reference merely states that the Job Monitoring MIB is not intended RB> to be used in pure DPA environment. The second to last paragraph RB> states that the MIB objects "represent a compatible subset of job RB> and document attributes of the ISO DPA standard" but "nothing in the RB> job monitoring MIB shall require implementation of the ISO DPA RB> protocol". I justify the inclusion of the references as providing RB> a reason for not being 100% DPA compatible. RB> RB> You do raise a valid point, do we really need to reference DPA? RB> Are there any others that feel this should be removed? Under "User" it says "No attempt is made to actually predict the length of time that jobs will take." Then, under "Operator" it says "Provide some idea of how long each job will take." Aren't these contradictory? RB> Again, here is another area that we have discussed to death and I RB> let this by! I propose the paragraph under "Operator" be revised RB> or removed (removed is preferred). The paragraph presently reads: RB> RB> Provide some idea of how long each job will take. However, exact RB> estimates of time to process a job is not being attempted. Instead, RB> objects are included that allow the operator to be able to make RB> gross estimates. ---------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From rbergma at dpc.com Fri Feb 28 17:43:48 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Minutes from 2/25 Conference Call Message-ID: <01BC231D.8AA4A140@hpb15767.boi.hp.com> I have loaded the minutes on the PWG server at ftp://ftp.pwg.org/pub/pwg/jmp/minutes/cc-250297.doc (pdf) (txt) ------------------------------------------------------------------- Ron Bergman Dataproducts Corp From hastings at cp10.es.xerox.com Fri Feb 28 17:25:10 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> ACTION: fill out job submision protocols for job id attributes Message-ID: <9702282227.AA11233@zazen.cp10.es.xerox.com> I've created a new template with just the job id attributes and posted in: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 17920 Feb 28 21:39 jmtmplt1.doc I moved all of the stuff we did last June into the sub-directory historic/ At the Feb 19 meeting we agreed to the following action item: ACTION ITEM (responsible persons indicated below): Map the job identification objects of the current Job Monitoring MIB to their assigned job submission protocol, so that we can make sure that the specification of each object is clear. The resulting mapping will be incorporated into Appendix A of the Job Monitoring MIB. As a second step we will add all of the rest of the Job Monitoring MIB objects. Please fill out your templates by next Wednesday, March 5. Here are the steps: 1. Copy jmtmplt1.doc from ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmtmplt1.doc. 2. Fill in the first five lines of information about your job submission protocol immediately after the "cut here" line. 3. Delete the template before and including the "cut here". 4. Edit in the name of each of the job submission protocol attributes that corresponds to each of the object/attribute from the brainstorm list in the table below. 5. For objects/attributes that do not have a corresponding attribute in your job submission protocol, please enter just a - (hyphen). 6. If you aren't sure whether the job attribute you found is correct, put a question mark after the name of your job submission protocol attribute. 7. Add any notes to the last column labeled NOTES. 8. Rename your file to the xxx.doc file name indicated below for your job submission protocol. 9. Post your file in: ftp://ftp.external.hp.com/snmpmib/jobs-mib/protomap/xxx.doc 10. Send mail to the jmp list indicating that you have posted your mapping. I've already copied all of the original files into the historic sub-directory under protomap/, so you can use the same file name as before. Job Submission Protocol file name Responsible person ----------------------- --------- ------------------ . AppleTalk PAP applepap.doc Ron Bergman . IPDS ipds.doc Harry Lewis . ISO DPA iso-dpa.doc Tom Hastings . LPR/LPD - RFC 1179, PSIS extensions lpr-lpd.doc Ron Bergman . NDPS ndps.doc Craig Whittle . PJL pjl.doc Bob Pennacost . PostScript ps.doc Bob Setterbo . PSERVER pserver.doc Craig Whittle . RPRINTER rprinter.doc Craig Whittle . SMB smb.doc Bob Setterbo . TIPSI/NPAP tipsi.doc Don Wright For convenience, I have copied the full description of each of the objects that we are mapping to job submission protocols. In the table is a short description of each object, but the full text is what you should use to pick the curresponding attribute in your job submission protocol. From harryl at vnet.ibm.com Fri Feb 28 18:14:54 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource table entry Message-ID: <199702282320.SAA07957@lists.underscore.com> I'm a bit confused exactly what the resource table entry looks like now... I THINK it's jmResourceIndex jmResourceType jmResourceUnits jmValueasInteger jmValueasText Is this right. Somehow I wonder if we didn't have another index somewhere. Just trying to make sure this is the whole picture. Harry Lewis From hastings at cp10.es.xerox.com Fri Feb 28 19:40:27 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> I've posted updated Job Monitoring MIB issues list Message-ID: <9703010042.AA11343@zazen.cp10.es.xerox.com> We agreed to keep the issues list separate from the MIB spec itself. So here is the first publication. The open issues are in the first section and the closed issues are in the second section. I'll move closed issues to the second section with the agreements and reasoning for closing the issues. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-rw-r-- 1 pwg pwg 32768 Mar 1 00:39 issues.doc -rw-rw-r-- 1 pwg pwg 26639 Mar 1 00:39 issues.pdf Tom From imcdonal at eso.mc.xerox.com Sat Mar 1 15:59:06 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource table entry In-Reply-To: Resource table entry> Message-ID: <9703012059.AA00868@snorkel.eso.mc.xerox.com> Hi Harry, I would THINK that the order of the indices for the Resource Table should be INDEX { jmJobSetIndex, jmJobIdentifier, jmResourceType, jmResourceIndex } Therefore, yes the table contents should be jmResourceType -- first, because it's the leftmost self-index object jmResourceIndex jmResourceUnits jmResourceValueAsInteger jmResourceValueAsText Cheers, - Ira McDonald PS - The 4-deep Resource indices was originally my suggestion to Tom Hastings, here at Xerox. From harryl at vnet.ibm.com Mon Mar 3 17:42:41 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Total Octets vs Total Pages Message-ID: <199703032245.RAA18156@lists.underscore.com> We have a Resource Type jobTotakKOctets, but not jobTotalPages. I think we should either have both or neither. Can someone provide a scnerio where jobKOctetsCompleted and pagesCompletedCurrentCopy is not sufficient or one that shows why totalOctets makes sense but totalPages does not? Harry Lewis From harryl at vnet.ibm.com Mon Mar 3 18:38:46 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource Type enums Message-ID: <199703032339.SAA18418@lists.underscore.com> I can't find a full, contiguous list of Resource Type enumerations. I think we're still building this list, so that's ok. The list I did find has several enums with the same ID. Below, I've made a straight list of all the enums I've found documented so far. I don't mind if someone wants to renumber these. I have added suggestions for several more enums from 35-41. I also note that we do not distinguish between collated and uncollated copies. Should this be an issue? 1. Other 2. Unknown 3. fileName 4. documentName 5. jobCopiesRequested 6. jobCopiesCompleted 7. documentCopiesRequested 8. documentCopiesCompleted 9. sides 10. documentFormat 11. physicalDeviceIndex 12. physicalDeviceName 13. impressionsCompleted 14. sheetsCompleted 15. mediumRequested 16. mediaConsumed 17. impressionsSpooled 18. impressionsInterpreted 19. impressionsSentToDevice 20. impressionsCompletedCurrentCopy 21. pagesCompletedCurrentCopy 22. processingCPUTime 23. processingMessage 24. outputBin 25. colorantRequested 26. colorantConsumed 27. jobSourceChannelIndex 28. jobSubmissionTime 29. jobStartedPrintingTime 30. jobCompletedTime 31. jobComment 32. jobTotalKOctets 33. jobKOctetsCompleted 34. jobAccountName 35. finishingUsed 36. jobQualityRequested 37. jobQualityUsed 38. tonerEconomyRequested 39. tonerEconomyUsed 40. tonerDensityRequested 41. tonerDensityUsed From rbergma at dpc.com Tue Mar 4 11:10:33 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> RE: Total Octets vs Total Pages Message-ID: <199703032339.SAA18418@lists.underscore.com> Harry, I believe that the current set of Resources includes: TotalImpressionsCompleted TotalSheetsCompleted TotalPagesCompleted ImpressionsCompletedCurrentCopy SheetsCompletedCurrentCopy PagesCompletedCurrentCopy This should cover all possibilities. Also, thanks for putting together the list of Resource enums. We can compare this to the next MIB update to insure nothing has been missed. Ron Bergman ----------------------------------------------------------------------- On 03-MAR-1997 Harry Lewis wrote: --------------------------------- We have a Resource Type jobTotakKOctets, but not jobTotalPages. I think we should either have both or neither. Can someone provide a scnerio where jobKOctetsCompleted and pagesCompletedCurrentCopy is not sufficient or one that shows why totalOctets makes sense but totalPages does not? Harry Lewis From rbergma at dpc.com Tue Mar 4 11:21:13 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Template for Mapping Job Submission Protocols Message-ID: <199703032339.SAA18418@lists.underscore.com> The first object in the Template provided by Tom Hastings is jmJobIndex. Since this object is defined and used by the device that is providing the MIB it must always be present. IMHO, this object most likely will not map into an existing parameter defined by the Job Submission Protocol. I would recommend that this object be ignored by all who are completing this template. ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com (805)578-4421 From papowell at dickory.sdsu.edu Tue Mar 4 15:27:07 1997 From: papowell at dickory.sdsu.edu (Patrick Powell) Date: Wed May 6 14:00:02 2009 Subject: JMP> RE: Total Octets vs Total Pages In-Reply-To: RE: Total Octets vs Total Pages> Message-ID: <199703042027.MAA25688@dickory.sdsu.edu> # Harry, # I believe that the current set of Resources includes: # TotalImpressionsCompleted # TotalSheetsCompleted # TotalPagesCompleted # ImpressionsCompletedCurrentCopy # SheetsCompletedCurrentCopy # PagesCompletedCurrentCopy # This should cover all possibilities. Dear sirs: Ummm... what about inkjet plotters that charge by the linear inch and width? I have been reviewing the various items being discussed, and I think that there is a pervasive effort to provide detailed enumeration of all possible types of things, and then assign a quantity to them. For example, while the above list covers pages, etc., it does not discuss staples, cover sheets, envelopes, etc., which could also comprise a job;s usage. I would suggest that you might need modify this scheme to provide a list of resources used and the amount of each resource used. For example: ResourcesUsed Octets Pages Staples CoverSheet Edge Binding ResourceCount.Octets 1000 ResourceCount.Pages 300 ResourceCount.Staples 30 ResourceCount.CoverSheet 10 ResourceCount.Edge 10 ResourceCount.Binding 10 While this may not fit into the MIB model exactly, it makes better sense from an extensibility model. # Also, thanks for putting together the list of Resource enums. We can # compare this to the next MIB update to insure nothing has been missed. # Ron Bergman # ----------------------------------------------------------------------- # On 03-MAR-1997 Harry Lewis wrote: # --------------------------------- # We have a Resource Type jobTotakKOctets, but not jobTotalPages. I think we # should either have both or neither. Can someone provide a scnerio where # jobKOctetsCompleted and pagesCompletedCurrentCopy is not sufficient or one # that shows why totalOctets makes sense but totalPages does not? # Harry Lewis From harryl at vnet.ibm.com Tue Mar 4 18:31:24 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job Set vs. hrDeviceID Message-ID: <199703042336.SAA21419@lists.underscore.com> We have a jobSetIndex as well as a Resource Type of physicalDeviceIndex. I think physicalDeviceIndex is the same as hrDeviceID - right? Why do we need both jobSetIndex and hrDeviceID. Aren't they (practically) the same? Harry Lewis. From harryl at vnet.ibm.com Tue Mar 4 20:10:13 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> JobGroup Message-ID: <199703050110.UAA22807@lists.underscore.com> Can someone summarize what remains in the job table? I think it's jmJobSetIndex jmJobIndex jmJobName jmJobNameID jmJobNumberID jmJobOwner jmJobSourceChannel I think Bob Pentecost asked about the following (I'll make up the names) which I agree we should add but probably need to map to some submission protocol. jmJobServer jmJobQueue I think the following were moved from Job Group to Resource Group jmJobType jmJobDeviceNameRequested jmDeviceIndex jmJobSubmissionTime jmJobComment Can anyone confirm this? Harry Lewis From jkm at underscore.com Wed Mar 5 12:58:02 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job Set vs. hrDeviceID In-Reply-To: Job Set vs. hrDeviceID> Message-ID: <199703051758.MAA06088@uscore.underscore.com> Harry, > We have a jobSetIndex as well as a Resource Type of physicalDeviceIndex. > I think physicalDeviceIndex is the same as hrDeviceID - right? Why do we > need both jobSetIndex and hrDeviceID. Aren't they (practically) the same? I believe the ongoing philosophical position for the Job Monitoring MIB is that use of the MIB should NOT require the use (or implementation) of the Printer MIB. If this is still true, then even though the two values are essentially the same, they must both exist. ...jay From harryl at vnet.ibm.com Wed Mar 5 20:26:29 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job MIB recommendations Message-ID: <199703060126.UAA01089@lists.underscore.com> I have taken a very long and hard look at the Job MIB over the last couple weeks, including my design team in the process. We are fairly pleased with the current state of the job MIB but have some comments which suggest significant change in the structure of a couple tables. I don't think our recommendations are any more severe than what we've been doing recently with the Resource table and I hope you will perceive the added benefit. I think the recommended changes (or something similar) are needed to really make the job MIB USEFUL! I've posted a text version of my comments: ftp://ftp.pwg.org/pub/jmp/contributions/hrl_comments.txt For the convenience of anyone without ftp access, I will attach the same comments below: ============================================================ March 05 1997 Job MIB comments Letter to the PWG/JMP Harry Lewis - IBM Printing Systems I have the following observations and recommendations regarding use and structure of the Job MIB. 1. Job Table is not structured to allow a jobID (called jobIndex in the PWG Job MIB) to be obtained without "walking" the entire jmJobTable. The jmJobTable is indexed by jmJobSet and jmJobIndex (the "printer assigned job ID - if you will) and contains a lot more identification type objects like jmJobName (owner assigned), jmJobNameID (spooler assigned), jmJobNumberID (spooler assigned) etc. I think one use of the jmJobTable should be to DETERMINE your printer assigned jobID (jmJobIndex) which you can use, then, to index the Accounting and other tables. To facilitate this function, however, the jmJobTable would have to be indexed by jmJobName, jmJobNameID etc., *not* by jmJobIndex. This has already been demonstrated by HP's Netware Mopier solution and HP has also requested objects which I will arbitrarily name jmJobServerName and jmJobQueueName as indexes to the jmJob table. Objects like jmJobNameID, jmJobNumberID, jmJobServerName etc... should also be available in the Resource table for accounting applications who want to correlate this information with other resources for the job. 2. Restructuring the jmJob table, however, would make it difficult to obtain job State from the Job Group. We have been moving many objects away from the Job Group into the Resource Group. I recommend we investigate use of the Job Completed table as a Job State table. Completed is just one possible state. Why create the entry only when this particular state has been achieved? Why not create the entry at the same time the jmJobTable entry is created and track the state there. Since one key attribute of the Job Completed table is small size for greater persistence, I also recommend doing away with the cumbersome jmJobCurrentState / jmJobStateReasons pair and simply enumerating a list of possible job states. Today's jmJobCompleted table looks like this: jmJobSetIndex (4 bytes) jmCompletedIndex (4 bytes) jmJobIndex (4 bytes) My proposed jmJobState table would look like this: jmJobSetIndex (4 bytes) jmJobIndex (4 bytes) jmJobState (4 bytes) Note that the jmJobCompleted table is (again) navigated by a sequential index which means you have to go get the whole table to learn which jobs have completed. The jmJobState table is indexed by JobIndex so you can go right to the job you are interested in (you may have learned the id from the re-vamped jmJobTable!) and determine it's current state (which could very well be COMPLETED)! 3. Octets If we followed these two recommendations, I think we'd have a much more useful Job MIB. The jmJobTable could be renamed the jmJobIDTable, because it's sole purpose would be to locate your printer assigned job ID for use in other parts of the MIB. The Resource table is already indexed by jmJobIndex (the job ID) and so would be the new jmJobStateTable. We would have to make sure any other information that *was* in the jmJobTable has a home. We've moved most accounting and progress indications into the Resource table (I think). Octets is the only thing I'm not sure of. There is a tendency to want to put jmJobTotalKOctets and jmJobKOctetsCompleted in the jmJobState table. Then, this one table, indexed by job ID could be used to give the overall STATE and PROGRESS of the job. However, this would add 8 bytes to a 12 byte table, and should be considered carefully with regard to what type of persistence and storage overhead we intended for this table. The other place we could put octets is in the Resource table. I think it would work fine, just not as eloquently as having it in the jmJobState group. 4. jmGeneralJobCompletePolicy This object says how long entries will be kept in the jmJobTable and jmCompletedTable. Couple observations: - Why don't we care how long entries will be kept in the jmResourceTable? - Why makes us think the time will be the same for each table? I thought the jmJobCompleted table was intentionally short so it could be real deep (longer persistence). What is the intended use of jmGeneralMaxNumberofJobs and jmGeneralCurrentNumberofJobs? Is it storage allocation? If we have a time based object (above) then we don't need these "max's" to help figure out persistence. These may be great objects, I just need someone to help me with the scenario. And, I wonder why we don't want max size of other things like Resource table and/or jobCompleted (State?) tables. I think the job MIB is really converging. These comments are meant to encourage this, not to throw a wrench in the process. Please let me know if you agree that these changes would make the job MIB more realistic and more useful! Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed Mar 5 21:23:20 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Template for Mapping Job Submission Protocols In-Reply-To: Template for Mapping Job Submission Protocols> Message-ID: <9703060225.AA12734@zazen.cp10.es.xerox.com> Gee, I think just the opposite. Each job submission protocol has the recipient server or printer return an identifier to the submitter. So we need to know the *name* of the fundamental attribute in each job submission protocol that maps to the jmJobIndex object. So it is vital that we understand which attribute (that is returned by the recipient) maps to the jmJobIndex. By the way, we have the serious issue of what happens for a job submission protocol in which the job identifier generated by the server or printer is 0 (say for the first job after the system is booted). SNMP won't allow us to have a 0 value as an index. SO we need to know how many job submission protocols return 0 for a valid job identifier. If there are some, we need to figure out what to do. See the issues list. Map 0 to the highest index? Tom At 08:21 03/04/97 PST, you wrote: >The first object in the Template provided by Tom Hastings is jmJobIndex. > >Since this object is defined and used by the device that is providing >the MIB it must always be present. IMHO, this object most likely will >not map into an existing parameter defined by the Job Submission >Protocol. I would recommend that this object be ignored by all who >are completing this template. > >----------------------------------------------------------------------- > Ron Bergman > Dataproducts Corp > rbergma@dpc.com > (805)578-4421 > > > > From hastings at cp10.es.xerox.com Wed Mar 5 21:29:57 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource table entry In-Reply-To: Resource table entry> Message-ID: <9703060231.AA12743@zazen.cp10.es.xerox.com> Some minor tweaks on what Ira said. Tom At 12:59 03/01/97 PST, Ira Mcdonald x10962 wrote: >Hi Harry, > >I would THINK that the order of the indices for the Resource Table >should be >INDEX { jmJobSetIndex, > jmJobIdentifier, which we are calling jmJobIndex > jmResourceType, > jmResourceIndex } > >Therefore, yes the table contents should be > >jmResourceType -- first, because it's the leftmost self-index object >jmResourceIndex >jmResourceUnits We agreed to get rid of the units object as well and make the units be specified by the jmResourceType. This may increase the number of enums slightly, for when we want to have more than one kind of units for some information, such as time (ticks and DateAndTime). But its clearer and simpler. >jmResourceValueAsInteger >jmResourceValueAsText > >Cheers, >- Ira McDonald > >PS - The 4-deep Resource indices was originally my suggestion to >Tom Hastings, here at Xerox. > > > From rbergma at dpc.com Thu Mar 6 11:55:21 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job Submission Mappings for LPD and AppleTalk Message-ID: <9703060231.AA12743@zazen.cp10.es.xerox.com> I have loaded to the FTP server Job Identification Mappings for LPD and AppleTalk. These files can be found at: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmt1-atk.pdf ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmt1-lpd.pdf Ron Bergman Dataproducts Corp rbergma@dpc.com From rbergma at dpc.com Thu Mar 6 12:20:02 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Template for Mapping Job Submission Protocols Message-ID: <9703060231.AA12743@zazen.cp10.es.xerox.com> Tom, On Thu Mar 06, 1997 you wrote: Gee, I think just the opposite. Each job submission protocol has the recipient server or printer return an identifier to the submitter. So we need to know the *name* of the fundamental attribute in each job submission protocol that maps to the jmJobIndex object. So it is vital that we understand which attribute (that is returned by the recipient) maps to the jmJobIndex. By the way, we have the serious issue of what happens for a job submission protocol in which the job identifier generated by the server or printer is 0 (say for the first job after the system is booted). SNMP won't allow us to have a 0 value as an index. SO we need to know how many job submission protocols return 0 for a valid job identifier. If there are some, we need to figure out what to do. See the issues list. Map 0 to the highest index? Tom RB> None of the Job Submission protocols supported by a Dataproducts RB> NIC requres an identifier to be returned. I do believe that OS/2 RB> does have this requirement from the server to the client. Could RB> you let me know what protocols you are aware of with this requirement? RB> RB> Also, a more fundamental issue is what Protocols that currently RB> have an index in the server and/or printer cannot conform to the RB> restrictions of jmJobIndex. RB> RB> As for the index of zero, is this a real problem and in what RB> protocols? At 08:21 03/04/97 PST, you wrote: >The first object in the Template provided by Tom Hastings is jmJobIndex. > >Since this object is defined and used by the device that is providing >the MIB it must always be present. IMHO, this object most likely will >not map into an existing parameter defined by the Job Submission >Protocol. I would recommend that this object be ignored by all who >are completing this template. > >----------------------------------------------------------------------- > Ron Bergman > Dataproducts Corp > rbergma@dpc.com > (805)578-4421 > From hastings at cp10.es.xerox.com Thu Mar 6 14:05:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Re: What job submission protocols does the recipient In-Reply-To: Message-ID: <9703061908.AA12904@zazen.cp10.es.xerox.com> So here is a start of the job submission protocols for which unique job identifiers are generated for each job: 1. Jobs in BSD LPR/LPD have a unique job identifier. Here is the text from RFC 1179: Model of Printing Environment A group of hosts request services from a line printer daemon process running on a host. The services provided by the process are related to printing jobs. A printing job produces output from one file. Each job will have a unique job number which is between 0 and 999, inclusive. The jobs are requested by users which have names. These user names may not start with a digit. 2. ISO DPA, the server generates a unique job identifer (as a text string, so it could have non-numeric characters in it, but the DPA implementations that I'm aware of use stricgly ASCII digits for the identifer). Here is the (wide) list from the old mapping we did last Spring: Job Identification (I) ISO DPA Apple IPDS LPRLPD NDPS PJL PSERVER SMB TIPSI PAP 1. Job id on original client x x x x x x x 2. Job id on device (printer) x x x x x x Perhaps we are getting tangled up in semantics here, because I see that you labeled LPR/LPD as an id coming from the original client. But the LPD client is NOT free to make up just any old job id; the BSD LPD client has to use the next available job id on the server or at least not use a job id already in use, correct? Doesn't the client have to determine the next job id by looking at the file names in the server's directory? RFC 1179 is a little sketchy here. However, the real issue here is how does a user find a job in the Job Monitoring MIB, if that user know the unique identifier for the job for that system (whether generated by the client as part of the submission proces or returned by the server as a result of the submission request. In BSD, I claim that the jmJobIndex that the MIB agent uses to index jobs would be the handiest way for a Job Monitoring MIB client to access a job. Then the client only has to make one Get request to get a jobs data. The client doesn't have to get jobs one at a time and look at a particular column to find a match for the job that the client is looking for. However, in BSD, a job can have "000" as its id, so that the jmJobIndex for such a job, would have to have a different value, say, the largest positive integer. Discussion (and its going to need a lot to understand one another)? Thanks, Tom At 09:20 03/06/97 PST, Ron Bergman wrote: >Tom, > >On Thu Mar 06, 1997 you wrote: > >Gee, I think just the opposite. Each job submission protocol has the >recipient server or printer return an identifier to the submitter. >So we need to know the *name* of the fundamental attribute in each >job submission protocol that maps to the jmJobIndex object. > >So it is vital that we understand which attribute (that is returned >by the recipient) maps to the jmJobIndex. > >By the way, we have the serious issue of what happens for a job submission >protocol in which the job identifier generated by the server or printer >is 0 (say for the first job after the system is booted). SNMP won't allow >us to have a 0 value as an index. SO we need to know how many job >submission protocols return 0 for a valid job identifier. If there are some, >we need to figure out what to do. See the issues list. Map 0 to the highest >index? > >Tom > >RB> None of the Job Submission protocols supported by a Dataproducts >RB> NIC requres an identifier to be returned. I do believe that OS/2 >RB> does have this requirement from the server to the client. Could >RB> you let me know what protocols you are aware of with this requirement? >RB> >RB> Also, a more fundamental issue is what Protocols that currently >RB> have an index in the server and/or printer cannot conform to the >RB> restrictions of jmJobIndex. >RB> >RB> As for the index of zero, is this a real problem and in what >RB> protocols? > > > >At 08:21 03/04/97 PST, you wrote: >>The first object in the Template provided by Tom Hastings is jmJobIndex. >> >>Since this object is defined and used by the device that is providing >>the MIB it must always be present. IMHO, this object most likely will >>not map into an existing parameter defined by the Job Submission >>Protocol. I would recommend that this object be ignored by all who >>are completing this template. >> >>----------------------------------------------------------------------- >> Ron Bergman >> Dataproducts Corp >> rbergma@dpc.com >> (805)578-4421 >> > > > > > From harryl at vnet.ibm.com Thu Mar 6 16:41:43 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Re: MOD - Comments from Patrick Powell In-Reply-To: Message-ID: <199703062146.QAA06933@lists.underscore.com> >Tom or somebody else from the MIB project, >could you answer some of these questions? Pat, given some other starting point, you are probably right, SNMP is not the ideal approach... >I have looked at some of the stuff, and have a sinking feeling that >the folks who are doing the MIB stuff have never tried to build/monitor >a printing system with jobs flowing through/around it, make it portable, >small, and able to be implemented by the lowest bidder :-) As an aside, it appears HP has done this... >I always try to do the simplest thing, on the grounds that the more >complex you make it the more things you forget. But, we're not starting at the beginning. It has taken several years for printer vendors to respond to market demand for SNMP in their network products - in a standard way. The complex SNMP overhead you refer to is already there in many cases as a result. Given *this* starting point... what seems undesirable is the need to invent and accommodate *yet* another protocol, perhaps unless it is one that looms so large that it can't be ignored - such as HTTP. >Why not just define some simple MIB objects that haul text strings >over and parse the text strings? The overhead of implementing a >SNMP MIB with all of the complexity that they are putting in will be >a horrific nightmare. The management of the system will be hideous, >the database alone will be nasty to design and build, and most of the >information will be of little use. If we're designing a MIB that contains mostly useless information... that's a *separate* problem! >I also note that many of the folks on the MIB team seem to feel an >need to have enumerated status types/messages. I keep wondering why - >most of the time the detailed information about a state is being >supplied in an additional message. Why not just send a text string >with the state as the first token? It is trivial to parse this. >And besides, for display purposes you will need to translate/index >into a table of strings. I agree with Don's assessment, here. You could parse fixed string definitions and land on your feet at the same time for one of 49 languages. Where's the benefit? If you're going to parse the string then it must be specifically listed somewhere otherwise you are wide open to interpretation (ex. PCL5, PCL-5, PCL5e, PCL FIVE...). A list implies a number. A number is shorter than most strings. Why not use it? Harry Lewis - IBM Printing Systems. From papowell at dickory.sdsu.edu Fri Mar 7 20:18:40 1997 From: papowell at dickory.sdsu.edu (Patrick Powell) Date: Wed May 6 14:00:02 2009 Subject: JMP> Re: MOD - Comments from Patrick Powell In-Reply-To: Re: MOD - Comments from Patrick Powell> Message-ID: <199703080118.RAA01139@dickory.sdsu.edu> # >Tom or somebody else from the MIB project, # >could you answer some of these questions? # Pat, given some other starting point, you are probably right, SNMP # is not the ideal approach... # >I have looked at some of the stuff, and have a sinking feeling that # >the folks who are doing the MIB stuff have never tried to build/monitor # >a printing system with jobs flowing through/around it, make it portable, # >small, and able to be implemented by the lowest bidder :-) # As an aside, it appears HP has done this... Ummm... yes, but did they do it RIGHT? * *Sorry HP folks, couldn't resist that one... # >I always try to do the simplest thing, on the grounds that the more # >complex you make it the more things you forget. # But, we're not starting at the beginning. It has taken several years # for printer vendors to respond to market demand for SNMP in their # network products - in a standard way. The complex SNMP overhead you # refer to is already there in many cases as a result. Given *this* # starting point... what seems undesirable is the need to invent and # accommodate *yet* another protocol, perhaps unless it is one that # looms so large that it can't be ignored - such as HTTP. OK, this makes sense. Horrible, ugly, nasty sense, but sense... Sigh... # >Why not just define some simple MIB objects that haul text strings # >over and parse the text strings? The overhead of implementing a # >SNMP MIB with all of the complexity that they are putting in will be # >a horrific nightmare. The management of the system will be hideous, # >the database alone will be nasty to design and build, and most of the # >information will be of little use. # If we're designing a MIB that contains mostly useless information... # that's a *separate* problem! Ummm... perhaps that is the problem I am trying to express. # >I also note that many of the folks on the MIB team seem to feel an # >need to have enumerated status types/messages. I keep wondering why - # >most of the time the detailed information about a state is being # >supplied in an additional message. Why not just send a text string # >with the state as the first token? It is trivial to parse this. # >And besides, for display purposes you will need to translate/index # >into a table of strings. # I agree with Don's assessment, here. You could parse fixed string definitions # and land on your feet at the same time for one of 49 languages. Where's # the benefit? If you're going to parse the string then it must be # specifically listed somewhere otherwise you are wide open to interpretation # (ex. PCL5, PCL-5, PCL5e, PCL FIVE...). A list implies a number. A # number is shorter than most strings. Why not use it? Because there are alternatives to this that have worked in other places. The FTP/SMTP (Simple Mail Transfer Protcol) come to mind. In this protocol, we send a command, and get a response: 220 sdsu.edu ESMTP Sendmail SDSU ready for action at Fri, 7 Mar 1997 17:16:11 -0800 (PST) >>> EHLO dickory.sdsu.edu 250-sdsu.edu Hello dickory.sdsu.edu [130.191.163.56], pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP >>> MAIL From: SIZE=37 250 ... Sender ok >>> RCPT To: 250 ... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . When you have multiple status lines you can use the continuation facility - 220-this line 220-that line 220 last line See 250 stuff above. Note: I once thought about using SMTP/MIME as a print protocol. I think I have a working document around somewhere... # Harry Lewis - IBM Printing Systems. From hastings at cp10.es.xerox.com Fri Mar 7 21:39:33 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> I've uploaded iso-dpa.doc job submission mapping Message-ID: <9703080241.AA13491@zazen.cp10.es.xerox.com> ftp://ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 5632 Mar 8 02:39 iso-dpa.doc Tom P.S. I only saw two other files there! Please do your respective action items. It will only take a few minutes, since we are only talking about 7 attribute/objects. From rbergma at dpc.com Mon Mar 10 11:03:14 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> RE[2]: What Job submission protocols does the recipient... Message-ID: <9703080241.AA13491@zazen.cp10.es.xerox.com> Tom, First, since I always view the world as 'printer centric', I will provide my LPD scenario and an explanation of why I listed the LPD Ids as Client Ids. The client submits his job to an LPD server which spools the job and submits it to the printer. The printer contains an SNMP agent. The client identifiers for the job are assigned by the LPD server. The client obtains the server assigned identifiers from the server and uses these to find his job on the printer. The printer is not aware that the identifiers were assigned by the server and not the client. If the Job Monitoring MIB was implemented on an LPD server it would be conceivable to use the LPD Server Job Id Number as jmJobIndex. This would, as you stated, "be the handiest way for a Job Monitoring MIB client to access a job" from the server. This may be a better approach than my proposal to implement an independent jmJobIndex. In this case, the solution to the zero index problem would be to use 1000 as the equivalent of a Job Id Number of zero. The value 1000 is well within the acceptable range for a table index and would be an easy conversion within an SNMP manager. However, a printer must be capable of receiving jobs from multiple LPD servers and multiple protocols. So within a printer SNMP agent jmJobIndex must be independent of the LPD Server Job Id Number. Now what problem are we trying to solve? Implementation of the Job Monitoring MIB in the printer should be our prime goal. This is where the necessary job information must be obtained. What benefit is obtained by implementing the MIB on an LPD Server? The LPD protocol provides all the information needed while the print job is queued on the server. We have already eliminated the scenario of an intermediate server collecting Job information. So why would anyone implement the Job Monitoring MIB on an LPD server? I am not as familiar with DPA implementations, but I believe that they also include a method to return job status to the client. The real problem then is how to get the information from the printer. I hope this sheds some light on my position. ...Ron At 07:38:47 Thu Mar 06 1997, Tom Hastings wrote: Gee, I think just the opposite. Each job submission protocol has the recipient server or printer return an identifier to the submitter. So we need to know the *name* of the fundamental attribute in each job submission protocol that maps to the jmJobIndex object. So it is vital that we understand which attribute (that is returned by the recipient) maps to the jmJobIndex. By the way, we have the serious issue of what happens for a job submission protocol in which the job identifier generated by the server or printer is 0 (say for the first job after the system is booted). SNMP won't allow us to have a 0 value as an index. SO we need to know how many job submission protocols return 0 for a valid job identifier. If there are some, we need to figure out what to do. See the issues list. Map 0 to the highest index? Tom At 08:21 03/04/97 PST, you wrote: >The first object in the Template provided by Tom Hastings is jmJobIndex. > >Since this object is defined and used by the device that is providing >the MIB it must always be present. IMHO, this object most likely will >not map into an existing parameter defined by the Job Submission >Protocol. I would recommend that this object be ignored by all who >are completing this template. > >----------------------------------------------------------------------- > Ron Bergman > Dataproducts Corp > rbergma@dpc.com > (805)578-4421 From bpenteco at boi.hp.com Mon Mar 10 19:24:46 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:02 2009 Subject: JMP> HP Review of Job Monitoring MIB Message-ID: <01BC2D77.F4FFE360@hpb15767.boi.hp.com> The following is from an HP review of the Job Monitoring MIB. References are to page and line numbers (which are pushed off the left side of the page, unfortunately) in the Revision 0.6 document job-mib.pdf (no revision marks). This review was done a few weeks ago so I apologize if changes have been made since then that fix some of the issues. 1. Page 1; Line 258. The table should include (A2?) The ability to predict consumables usage and stocking needs. 2. Page 32; discardTimeArrived(15). Refers to "job-retention-period" which is not defined in the MIB. 3. Page 40; Line ...43. "medium, ink, staples, processing-time, color-impressions" are referred to but not defined. 4. Page 52; Line 46. What is the value of jmQueueNumberOfInterveningJobs if jmJobProcessAfterTime is set to sometime in the future? 5. Page 52; Line 46. jmQueueNumberOfInterveningJobs specifies "The server or device shall set the value of this object to 0 when the job starts processing." Does a spooler set this to 0 when the job is submitted to the printer? What if the printer hasn't started processing the job? 6. Page 54; Line ...54. "...completed processing,..." is confusing in this sentence. Suggest "The 32-bit index of the jobs that are in the terminating, retained, or completed states." 7. Page 61; Line ...93. jmDeviceIndex does not provide sufficient information to identify the printer that received the job. Is it making the assumption that the printer is part of the server? 8. There is a general concern about how some objects will behave in Configuration 2 (page 13; line 547). 8a. What value is returned by jmQueueNumberOfInterveningJobs when the job has moved to a spooler in the printer (there are no intervening jobs on the server, but there may be some on the printer; would the value go to zero and then back up to some value)? 8b. Same question for jmJobPriority. 8c. Are jmJobCurrentStatus and jmJobStateReasons relative to the server or would they be passed back from the printer? 8d. Perhaps all objects should be reviewed with respect to each Configuration. From harryl at vnet.ibm.com Tue Mar 11 13:12:40 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> LPD Job submission mapping Message-ID: <199703111831.NAA11875@lists.underscore.com> Thanks, Ron, for the LPD mapping. One question, however. Doesn't the job information ususally FOLLOW the print data? I think there's a way to specify for it to proceed, but I don't know if it's typical or available on all platforms. Harry Lewis. From rbergma at dpc.com Tue Mar 11 21:21:02 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> LPD Job submission mapping In-Reply-To: <199703111831.NAA11875@lists.underscore.com> Message-ID: <199703111831.NAA11875@lists.underscore.com> On Tue, 11 Mar 1997, Harry Lewis wrote: > Thanks, Ron, for the LPD mapping. One question, however. Doesn't the > job information ususally FOLLOW the print data? I think there's a way > to specify for it to proceed, but I don't know if it's typical or > available on all platforms. > > Harry Lewis. > > Harry, My understanding is RFC 1179 specifies that the Data File and Control File may be sent in any order but most implementations send the Data File first. I do not know of a method to reverse the order. Maybe a Unix expert can help. This is one of the major problems in using LPD with a printer that cannot spool the job. By the time the Control File is received, the Data File is almost finished printing. I should have added a note to this effect. Ron Bergman Dataproducts Corp From jkm at underscore.com Tue Mar 11 21:34:38 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> LPD Job submission mapping In-Reply-To: LPD Job submission mapping> Message-ID: <199703120234.VAA07063@uscore.underscore.com> Ron, Since we live and breath (and die?) in the Unix environment every day, perhaps we should respond to your question: > My understanding is RFC 1179 specifies that the Data File and Control > File may be sent in any order but most implementations send the Data > File first. I do not know of a method to reverse the order. Maybe > a Unix expert can help. Put simply, there is no real way to "reverse the order"...at least with respect to the protocol. The LPD protocol (aka RFC 1179) was NOT designed in a vacuum. It was designed as part and parcel of the LPD daemon environment; that environment expected to FIRST spool all components of the submitted job (one or more data files, followed by one control file). So, if you have the luxury of spooling all these components, then of course you can "reverse the order". Of course, given the typical printer implementation (ie, no disk, etc), this is not possible. LPD would work SO WELL if only the control file were always transmitted first. If this were true, then the notion of extending LPD to improve network printing would be a real possibility. In the category of "Fun Things to Know and Forget": in our travels, only OS/2 2.1 sends the control file before the data file(s). I wonder how many LPD daemon systems mess up as a result of this... ...jay From papowell at dickory.sdsu.edu Wed Mar 12 10:24:10 1997 From: papowell at dickory.sdsu.edu (Patrick Powell) Date: Wed May 6 14:00:02 2009 Subject: JMP> LPD Job submission mapping In-Reply-To: LPD Job submission mapping> Message-ID: <199703121524.HAA07139@dickory.sdsu.edu> # The LPD protocol (aka RFC 1179) was NOT designed in a vacuum. It was # designed as part and parcel of the LPD daemon environment; that environment # expected to FIRST spool all components of the submitted job (one or more # data files, followed by one control file). So, if you have the luxury # of spooling all these components, then of course you can "reverse the order". Umm... you are going to hate this, but actually LPR came first, RFC1179 was simply documenting LPR. This is the same thing as RIP - RIP was first, then the RIP RFC came much later; note that the RFC had some 'do this as I say, not as I do' type things in it. # In the category of "Fun Things to Know and Forget": in our travels, # only OS/2 2.1 sends the control file before the data file(s). I wonder # how many LPD daemon systems mess up as a result of this... Ummm... I think you mean 'the broken vendor implementation of OS/2's print spooler'... There are 2nd party spoolers that do it in EITHER order, selectable by a run time switch. Note that the BSD based LPR implementations usually send control files first, the ones supplied with SYS III, send data files first, and the SYS VR4 seem to do what they damn well please from release to release. In the PC world, I have seen both - there is a drop in LPR client for most Windows 3.1 WINSOCK support packages, and I have seen both data first or job first from different packages. I have also noted that some printer manufacturers, when the implement LPD servers in their systems, IGNORE the control file and use 'autosense' methods to determine what the file contents are. I remember fighting with a XXX (censored) printer, and trying to print a students 'malformed postscript' file so I could take it away and look at it and the printer kept locking up with 'postscript stack... ' messages printed on it. Hey! Why should we be surprised? Given so much broken software out there, most people try to be as accomodating as possible in what they accept, and as restricted as possible in what they send. Patrick Powell # ...jay From hastings at cp10.es.xerox.com Thu Mar 13 12:30:10 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Resource Type enums In-Reply-To: Resource Type enums> Message-ID: <9703131732.AA01564@zazen.cp10.es.xerox.com> Harry, I'm editing the job-mib with all of the comments so far. Could you write up some proposed text to go with your proposed additional enums? We discovered in the Printer MIB that "names do not a spec make". So could you propose some text for each of: 35. finishingUsed 36. jobQualityRequested 37. jobQualityUsed 38. tonerEconomyRequested 39. tonerEconomyUsed 40. tonerDensityRequested 41. tonerDensityUsed Make sure to include the units in the description, since we are now doing that for all of the resource enums. Thanks, Tom At 15:38 03/03/97 PST, Harry Lewis wrote: >I can't find a full, contiguous list of Resource Type enumerations. I think >we're still building this list, so that's ok. The list I did find has several >enums with the same ID. Below, I've made a straight list of all the enums >I've found documented so far. I don't mind if someone wants to renumber these. > >I have added suggestions for several more enums from 35-41. > >I also note that we do not distinguish between collated and uncollated copies. >Should this be an issue? > > >1. Other >2. Unknown >3. fileName >4. documentName >5. jobCopiesRequested >6. jobCopiesCompleted >7. documentCopiesRequested >8. documentCopiesCompleted >9. sides >10. documentFormat >11. physicalDeviceIndex >12. physicalDeviceName >13. impressionsCompleted >14. sheetsCompleted >15. mediumRequested >16. mediaConsumed >17. impressionsSpooled >18. impressionsInterpreted >19. impressionsSentToDevice >20. impressionsCompletedCurrentCopy >21. pagesCompletedCurrentCopy >22. processingCPUTime >23. processingMessage >24. outputBin >25. colorantRequested >26. colorantConsumed >27. jobSourceChannelIndex >28. jobSubmissionTime >29. jobStartedPrintingTime >30. jobCompletedTime >31. jobComment >32. jobTotalKOctets >33. jobKOctetsCompleted >34. jobAccountName >35. finishingUsed >36. jobQualityRequested >37. jobQualityUsed >38. tonerEconomyRequested >39. tonerEconomyUsed >40. tonerDensityRequested >41. tonerDensityUsed > > > > From hastings at cp10.es.xerox.com Thu Mar 13 15:31:03 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> How should a PDF document be indicated in the Printer MIB, Job Message-ID: <9703132033.AA01609@zazen.cp10.es.xerox.com> Currently there is no enum registered for a PDF document-format for use in the Printer MIB, the Job Monitoring MIB, and IPP. How should a PDF document be indicated in the Printer MIB, Job Monitoring MIB and IPP? IPP is part of PostScript level 3, I understand, so that the PostScript enum langPD(6) with a level of "3" in prtInterpreterLangLevel in the Printer MIB could indicate a Printer that is capabile of consuming a PDF file. But what about the Job Monitoring MIB where we don't have level and IPP where we don't have level? Also it seems that a Printer might be able to consume PDF, but not any PostScript level 3. Finally, in a document repository, it would be useful to know that a document is a PDF file, so that a PDF reader can be used to image it. We've discussed at several Printer Working Group meetings the idea of registering combinations of language family and level in order to give them distinct enums. So we could register PS1, PS2, PS3, and PDF. Also PCL5e, PCL5, and PCL4 as separate enums for use when a particular level is important. And we could keep the current langPCL(3) and langPS(6) for use when level is not important, or when the level is specified by other attributes, such as in the Printer MIB. The advantage of keeping the family separate from the level, is that an old application would still have a clue that a new level of document is really an upwards compatible level with the enum that it understands, where as if we register a new enum for each level, the old application will have no clue that the document is PostScript. For IPP, we might have a string, in which the family and level are syntactially distinguished, so that an old application could separate the family from the level. In the Job Monitoring MIB we have the Printer MIB enum. But we might change to the text string that has both family and level, if that is the way that IPP goes. Then we wouldn't need to register the different levels of PostScript and PCL. However, we may still want to register a PDF enum, since it is such a common document format these days. We need some help here from Adobe and HP on what is the best course to follow for the Printer MIB, Job Monitoring MIB, and IPP. I'd like to see this issue come up in the PWG agenda, since it affect all three PWG progjects, if we can't resolve this via e-mail. Thanks, Tom See the current 1.5 or 1.6 IPP Model and Semantics. Here is the extracted text from that: 5.2.7.1 document-format (type2Enumformat) This job attribute identifies the document format of this document, and may be a per-document attribute. This printer attribute indicates default value. It also indicates the values of the attribute supported by this printer and the states of readiness for each value. One possible supported and default value is "auto-sense". The following standard values have been reviewed with the Printer Working Group and are registered with IANA as part of the IETF Printer MIB project. The token value assigned by the PWG starts with the four letters: "lang", in order to follow SNMP ASN.1 rules that all enum symbols shall start with a lower case letter. The token values in IPP shall be the same as the IANA token values, with the "lang" removed. The MIB (integer) value is included here for reference only, the MIB value shall not be used in IPP; the token value shall be used instead: Token Value MIB value Description other 1 PCL 3 PCL. Starting with PCL version 5, HP-GL/2 is included as part of the PCL language. PCL and HP-GL/2 are registered trademarks of Hewlett-Packard Company. HPGL 4 Hewlett-Packard Graphics Language. HP-GL is a registered trademark of Hewlett-Packard Company. PJL 5 Peripheral Job Language. Appears in the data stream between data intended for a page description language. Hewlett-Packard Co. PS 6 PostScript Language (tm) Postscript - a trademark of Adobe Systems Incorporated which may be registered in certain jurisdictions IPDS 7 Intelligent Printer Data Stream Bi-directional print data stream for documents consisting of data objects (text, image, graphics, bar codes), resources (fonts, overlays) and page, form and finishing instructions. Facilitates system level device control, document tracking and error recovery throughout the print process. Pennant Systems, IBM PPDS 8 IBM Personal Printer Data Stream. Originally called IBM ASCII, the name was changed to PPDS when the Laser Printer was introduced in 1989. Lexmark International, Inc. EscapeP 9 Epson Corp. Epson 10 DDIF 11 Digital Document Interchange Format Digital Equipment Corp., Maynard MA Interpress 12 Xerox Corp. ISO6429 13 ISO 6429. Control functions for Coded Character Sets (has ASCII control characters, plus additional controls for character imaging devices.) ISO Standard, Geneva, Switzerland LineData 14 line-data: Lines of data as separate ASCII or EBCDIC records and containing no control functions (no CR, LF, HT, FF, etc.). For use with traditional line printers. May use CR and/or LF to delimit lines, instead of records. See ISO 10175 Document Printing Application (DPA) ISO standard, Geneva, Switzerland MODCA 15 Mixed Object Document Content Architecture Definitions that allow the composition, interchange, and presentation of final form documents as a collection of data objects (text, image, graphics, bar codes), resources (fonts, overlays) and page, form and finishing instructions. Pennant Systems, IBM REGIS 16 Remote Graphics Instruction Set, Digital Equipment Corp., Maynard MA SCS 17 SNA Character String Bi-directional print data stream for SNA LU-1 mode of communications IBM SPDL 18 ISO 10180 Standard Page Description Language ISO Standard TEK4014 19 Tektronix Corp. PDS 20 IGP 21 Printronix Corp. CodeV 22 Magnum Code-V, Image and printer control language used to control impact/dot- matrix printers. QMS, Inc., Mobile AL DSCDSE 23 DSC-DSE: Data Stream Compatible and Emulation Bi-directional print data stream for non-SNA (DSC) and SNA LU-3 3270 controller (DSE) communications IBM WPS 24 Windows Printing System, Resource based command/data stream used by Microsoft At Work Peripherals. Developed by the Microsoft Corporation. LN03 25 Early DEC-PPL3, Digital Equipment Corp. CCITT 26 QUIC 27 QUIC (Quality Information Code), Page Description Language for laser printers. Included graphics, printer control capability and emulation of other well- known printer . QMS, Inc. CPAP 28 Common Printer Access Protocol Digital Equipment Corp DecPPL 29 Digital ANSI-Compliant Printing Protocol (DEC-PPL) Digital Equipment Corp SimpleText 30 simple-text: character coded data, including NUL, CR , LF, HT, and FF control characters. See ISO 10175 Document Printing Application (DPA) ISO standard, Geneva, Switzerlan NPAP 31 Network Printer Alliance Protocol (NPAP). This protocol has been superseded by the IEEE 1284.1 TIPSI standard. (ref. LangTIPSI(49)). DOC 32 Document Option Commands, Appears in the data stream between data intended for a page description . QMS, Inc imPress 33 imPRESS, Page description language originally developed for the ImageServer line of systems. A binary language providing representations for text, simple graphics (rules, lines, conic sections), and some large forms (simple bit-map and CCITT group 3/4 encoded).The language was intended to be sent over an 8-bit channel and supported early document preparation languages (e.g. TeX and TROFF). QMS, Inc. Pinwriter 34 24 wire dot matrix printer for USA, Europe, and Asia except Japan. More widely used in Germany, and some Asian countries than in US. NEC NPDL 35 Page printer for Japanese market. NEC NEC201PL 36 Serial printer language used in the Japanese market. NEC Automatic 37 Automatic PDL sensing. Automatic sensing of the interpreter language family by the printer examining the document content. Which actual interpreter language families are sensed depends on the printer implementation. Pages 38 Page printer Advanced Graphic Escape Set IBM Japan LIPS 39 LBP Image Processing System TIFF 40 Tagged Image File Format (Aldus) Diagnostic 41 A hex dump of the input to the interprete PSPrinter 42 The PostScript Language used for control (with any PDLs) Adobe Systems Incorporated CaPSL 43 Canon Print Systems Language EXCL 44 Extended Command Language Talaris Systems Inc LCDS 45 Line Conditioned Data Stream Xerox Corporatio XES 46 Xerox Escape Sequences Xerox Corporation PCLXL 47 Printer Control Language. Extended language features for printing, and printer control. Technical reference manual # TBD. Hewlett-Packard Co. ART 48 Advanced Rendering Tools (ART). Page Description language originally developed for the Laser Press printers. Tehnical reference manual: "ART IV Reference Manual", No F33M. Fuji Xerox Co., Ltd. TIPSI 49 Transport Independent Printer System Interface (ref. IEEE Std. 1284.1) Prescribe 50 Page description and printer control language. It can be described with ordinary ASCII characters. Technical reference manual: "PRESCRIBE II Programming Manual" LinePrinter 51 A simple-text character stream which supports the control codes LF, VT, FF and CR plus Centronics or Dataproducts Vertical Format Unit (VFU). language is commonly used on many older model line and matrix printers. IDP 52 Imaging Device Protocol Apple Computer. XJCL 53 Xerox Corp. From hastings at cp10.es.xerox.com Thu Mar 13 19:10:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> RESEND: How should a PDF document be indicated in the Printer Message-ID: <9703140012.AA01683@zazen.cp10.es.xerox.com> I meant to say that "PDF" is part of PostScript level 3, not IPP a part of PostScript level 3. Also langPS(6), not langPD(6). Sorry, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Thu, 13 Mar 1997 12:31:03 PST >To: pmp@pwg.org, ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: PMP> How should a PDF document be indicated in the Printer MIB, Job > Monitoring MIB and IPP? >Sender: pmp-owner@pwg.org > >Currently there is no enum registered for a PDF document-format for use >in the Printer MIB, the Job Monitoring MIB, and IPP. > >How should a PDF document be indicated in the Printer MIB, Job Monitoring >MIB and IPP? > >IPP is part of PostScript level 3, I understand, so that the PostScript PDF [I meant to say - TNH] >enum langPD(6) with a level of "3" in prtInterpreterLangLevel in the langPS(6) [I meant to say - TNH] >Printer MIB could indicate a Printer that is capabile of consuming a PDF >file. But what about the Job Monitoring MIB where we don't have level >and IPP where we don't have level? > >Also it seems that a Printer might be able to consume PDF, but not any >PostScript level 3. Finally, in a document repository, it would be useful >to know that a document is a PDF file, so that a PDF reader can be used >to image it. > >We've discussed at several Printer Working Group meetings the idea of >registering combinations of language family and level in order to give them >distinct enums. So we could register PS1, PS2, PS3, and PDF. Also PCL5e, >PCL5, and PCL4 as separate enums for use when a particular level is important. >And we could keep the current langPCL(3) and langPS(6) for use when level >is not important, or when the level is specified by other attributes, >such as in the Printer MIB. > >The advantage of keeping the family separate from the level, is that an old >application would still have a clue that a new level of document is really >an upwards compatible level with the enum that it understands, where as if >we register a new enum for each level, the old application will have no clue >that the document is PostScript. > >For IPP, we might have a string, in which the family and level are syntactially >distinguished, so that an old application could separate the family from >the level. > >In the Job Monitoring MIB we have the Printer MIB enum. But we might >change to the text string that has both family and level, if that is the >way that IPP goes. Then we wouldn't need to register the different levels >of PostScript and PCL. > >However, we may still want to register a PDF enum, since it is such a >common document format these days. > >We need some help here from Adobe and HP on what is the best course to >follow for the Printer MIB, Job Monitoring MIB, and IPP. > >I'd like to see this issue come up in the PWG agenda, since it affect >all three PWG progjects, if we can't resolve this via e-mail. > >Thanks, >Tom > > >See the current 1.5 or 1.6 IPP Model and Semantics. > >Here is the extracted text from that: > >5.2.7.1 document-format (type2Enumformat) >This job attribute identifies the document format of this document, and may >be a per-document attribute. > >This printer attribute indicates default value. It also indicates the values >of the attribute supported by this printer and the states of readiness for >each value. One possible supported and default value is "auto-sense". > >The following standard values have been reviewed with the Printer Working >Group and are registered with IANA as part of the IETF Printer MIB project. >The token value assigned by the PWG starts with the four letters: "lang", in >order to follow SNMP ASN.1 rules that all enum symbols shall start with a >lower case letter. The token values in IPP shall be the same as the IANA >token values, with the "lang" removed. The MIB (integer) value is included >here for reference only, the MIB value shall not be used in IPP; the token >value shall be used instead: > >Token Value MIB value Description > >other 1 > >PCL 3 PCL. Starting with PCL version 5, HP-GL/2 is included as part of the >PCL language. PCL and HP-GL/2 are registered trademarks of Hewlett-Packard >Company. > >HPGL 4 Hewlett-Packard Graphics Language. HP-GL is a registered trademark >of Hewlett-Packard Company. > >PJL 5 Peripheral Job Language. Appears in the data stream between data >intended for a page description language. Hewlett-Packard Co. > >PS 6 PostScript Language (tm) Postscript - a trademark of Adobe Systems >Incorporated which may be registered in certain jurisdictions > >IPDS 7 Intelligent Printer Data Stream Bi-directional print data stream for >documents consisting of data objects (text, image, graphics, bar codes), >resources (fonts, overlays) and page, form and finishing instructions. >Facilitates system level device control, document tracking and error >recovery throughout the print process. Pennant Systems, IBM > >PPDS 8 IBM Personal Printer Data Stream. Originally called IBM ASCII, the >name was changed to PPDS when the Laser Printer was introduced in 1989. >Lexmark International, Inc. > >EscapeP 9 Epson Corp. > >Epson 10 > >DDIF 11 Digital Document Interchange Format Digital Equipment Corp., Maynard MA > >Interpress 12 Xerox Corp. > >ISO6429 13 ISO 6429. Control functions for Coded Character Sets (has ASCII >control characters, plus additional controls for character imaging devices.) >ISO Standard, Geneva, Switzerland > >LineData 14 line-data: Lines of data as separate ASCII or EBCDIC records and >containing no control functions (no CR, LF, HT, FF, etc.). For use with >traditional line printers. May use CR and/or LF to delimit lines, instead >of records. See ISO 10175 Document Printing Application (DPA) ISO standard, >Geneva, Switzerland > >MODCA 15 Mixed Object Document Content Architecture Definitions that allow >the composition, interchange, and presentation of final form documents as a >collection of data objects (text, image, graphics, bar codes), resources >(fonts, overlays) and page, form and finishing instructions. Pennant >Systems, IBM > >REGIS 16 Remote Graphics Instruction Set, Digital Equipment Corp., Maynard MA > >SCS 17 SNA Character String Bi-directional print data stream for SNA LU-1 >mode of communications IBM > >SPDL 18 ISO 10180 Standard Page Description Language ISO Standard > >TEK4014 19 Tektronix Corp. > >PDS 20 > >IGP 21 Printronix Corp. > >CodeV 22 Magnum Code-V, Image and printer control language used to control >impact/dot- matrix printers. QMS, Inc., Mobile AL > >DSCDSE 23 DSC-DSE: Data Stream Compatible and Emulation Bi-directional print >data stream for non-SNA (DSC) and SNA LU-3 3270 controller (DSE) >communications IBM > >WPS 24 Windows Printing System, Resource based command/data stream used by >Microsoft At Work Peripherals. Developed by the Microsoft Corporation. >LN03 25 Early DEC-PPL3, Digital Equipment Corp. > >CCITT 26 > >QUIC 27 QUIC (Quality Information Code), Page Description Language for laser >printers. Included graphics, printer control capability and emulation of >other well- known printer . QMS, Inc. > >CPAP 28 Common Printer Access Protocol Digital Equipment Corp > >DecPPL 29 Digital ANSI-Compliant Printing Protocol (DEC-PPL) Digital >Equipment Corp > >SimpleText 30 simple-text: character coded data, including NUL, CR , LF, HT, >and FF control characters. See ISO 10175 Document Printing Application >(DPA) ISO standard, Geneva, Switzerlan > >NPAP 31 Network Printer Alliance Protocol (NPAP). This protocol has been >superseded by the IEEE 1284.1 TIPSI standard. (ref. LangTIPSI(49)). > >DOC 32 Document Option Commands, Appears in the data stream between data >intended for a page description . QMS, Inc > >imPress 33 imPRESS, Page description language originally developed for the >ImageServer line of systems. A binary language providing representations >for text, simple graphics (rules, lines, conic sections), and some large >forms (simple bit-map and CCITT group 3/4 encoded).The language was intended >to be sent over an 8-bit channel and supported early document preparation >languages (e.g. TeX and TROFF). QMS, Inc. > >Pinwriter 34 24 wire dot matrix printer for USA, Europe, and Asia except >Japan. More widely used in Germany, and some Asian countries than in US. NEC > >NPDL 35 Page printer for Japanese market. NEC > >NEC201PL 36 Serial printer language used in the Japanese market. NEC > >Automatic 37 Automatic PDL sensing. Automatic sensing of the interpreter >language family by the printer examining the document content. Which actual >interpreter language families are sensed depends on the printer implementation. > >Pages 38 Page printer Advanced Graphic Escape Set IBM Japan > >LIPS 39 LBP Image Processing System > >TIFF 40 Tagged Image File Format (Aldus) > >Diagnostic 41 A hex dump of the input to the interprete > >PSPrinter 42 The PostScript Language used for control (with any PDLs) Adobe >Systems Incorporated > >CaPSL 43 Canon Print Systems Language > >EXCL 44 Extended Command Language Talaris Systems Inc > >LCDS 45 Line Conditioned Data Stream Xerox Corporatio > >XES 46 Xerox Escape Sequences Xerox Corporation > >PCLXL 47 Printer Control Language. Extended language features for printing, >and printer control. Technical reference manual # TBD. Hewlett-Packard Co. > >ART 48 Advanced Rendering Tools (ART). Page Description language originally >developed for the Laser Press printers. Tehnical reference manual: "ART IV >Reference Manual", No F33M. Fuji Xerox Co., Ltd. > >TIPSI 49 Transport Independent Printer System Interface (ref. IEEE Std. >1284.1) > >Prescribe 50 Page description and printer control language. It can be >described with ordinary ASCII characters. Technical reference manual: >"PRESCRIBE II Programming Manual" > >LinePrinter 51 A simple-text character stream which supports the control >codes LF, VT, FF and CR plus Centronics or Dataproducts Vertical Format Unit >(VFU). language is commonly used on many older model line and matrix printers. > >IDP 52 Imaging Device Protocol Apple Computer. > >XJCL 53 Xerox Corp. > > > From hastings at cp10.es.xerox.com Thu Mar 13 20:07:59 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> DateAndTime is a binary string of octets! Message-ID: <9703140110.AA01724@zazen.cp10.es.xerox.com> DateAndTime which we are using for date and time in our Job Monitoring MIB is not printable characters; its binary (don't be fooled by the display hint, which is just how to convert the binary to text). We decided to have two values in our Resource Table (which I'm renaming to Attribute Table due to some confusion about resources in the e-mail and since we have agreed to put more than just resources into it): jmAttributeValueAsInteger jmAttributeValueAsText Since Text is represented as OCTET STRING in SNMP, there is no problem with sending the binary using the same object. However, we might want to rename the second object to jmAttributeValueAsOctets, so that it covers the DateAndTime. Comments? Tom WARNING: By the way, SNMPV2-TC isn't very clear whether the two octet year is Big Endian or Little Endian, but I suspect that it must be Big Endian, since SNMP uses ASN.1 which is Big Endian (most significant octet first). So the year 256 would be represented as 1 in the first octet and 0 in the second octet, not the other way around. Be careful, since PCs are Little Endian, so they have to swap the octets. RFC 1903 SNMPv2-TC is copied as follows: DateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC 0..11 10 11 minutes from UTC 0..59 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present." SYNTAX OCTET STRING (SIZE (8 | 11)) From papowell at dickory.sdsu.edu Fri Mar 14 10:21:58 1997 From: papowell at dickory.sdsu.edu (Patrick Powell) Date: Wed May 6 14:00:02 2009 Subject: JMP> DateAndTime is a binary string of octets! In-Reply-To: DateAndTime is a binary string of octets!> Message-ID: <199703141521.HAA13566@dickory.sdsu.edu> DateAndTime which we are using for date and time in our Job Monitoring MIB is not printable characters; its binary (don't be fooled by the display hint, which is just how to convert the binary to text). We decided to have two values in our Resource Table (which I'm renaming to Attribute Table due to some confusion about resources in the e-mail and since we have agreed to put more than just resources into it): jmAttributeValueAsInteger jmAttributeValueAsText I would suggest that you might also want to add 'textencoding' as well. For example, you might have UNICODE text or simple ASCII text. Since Text is represented as OCTET STRING in SNMP, there is no problem with sending the binary using the same object. However, we might want to rename the second object to jmAttributeValueAsOctets, so that it covers the DateAndTime. Comments? Tom WARNING: By the way, SNMPV2-TC isn't very clear whether the two octet year is Big Endian or Little Endian, but I suspect that it must be Big Endian, since SNMP uses ASN.1 which is Big Endian (most significant octet first). So the year 256 would be represented as 1 in the first octet and 0 in the second octet, not the other way around. Be careful, since PCs are Little Endian, so they have to swap the octets. I believe that there is a general fiat that the Network Standard Order for multiple octect values is Big Endian. RFC 1903 SNMPv2-TC is copied as follows: DateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC 0..11 10 11 minutes from UTC 0..59 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present." SYNTAX OCTET STRING (SIZE (8 | 11)) This is also the standard for representing time in some other ISO standards. Why not make this the cannonical way to represent time/date values? Patrick From harryl at us.ibm.com Fri Mar 14 14:45:56 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Renaming the Resource Group Message-ID: <5030100000736494000002L042*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, may I suggest we rename the Resource group to the Accounting group rather than Attribute? Isn't the primary purpose of this table for accounting? Just a suggestion. I agree we had stretched the notion of a job Resource in this table. ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 03/14/97 12:37 PM --------------------------- IINUS1.RSCS0864@D03AU018 03/14/97 08:32 AM Please respond to IINUS1.RSCS0864 @ VM To: Harry Lewis/Boulder/IBM@IBMUS cc: Subject: Re: JMP> DateAndTime is a binary string of octets! *We decided to have two values in our Resource Table (which I'm renaming *to Attribute Table due to some confusion about resources in the e-mail and *since we have agreed to put more than just resources into it): From hastings at cp10.es.xerox.com Fri Mar 14 18:05:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> I've posted Job Monitoring MIB V0.7 Message-ID: <9703142307.AA01951@zazen.cp10.es.xerox.com> I've posted V0.7 of the Job Monitoring MIB: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 446976 Mar 14 22:54 jmp-mib.doc -rw-r--r-- 1 pwg pwg 389447 Mar 14 23:00 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 488375 Mar 14 23:04 jmp-mib.pdr The .pdr is with red revision marks. I didn't have time to produce black revision marks. I'll do that Monday. I didn't get a chance to spell check it, nor even see a printed copy before posting it, but some people want it for the weekend. I also didn't get to update the clarifications about job states and job-state-reasons, though I added job-printing as a reason as agreed with Keith. I've not tried to compile this either. I changed the name of the Resources table to the Attributes table, since we now have more than just resources in it. Also I didn't get to finish putting all of the attributes into the index. Only objects. I also want to get each object and attribute into the table of contents. But I'll do that later. I'll update the issues list next week and e-mail responses to the comments. I also didn't get a chance to update the Change History in the back. Tom From hastings at cp10.es.xerox.com Mon Mar 17 17:40:19 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> RE: PMP> How should a PDF document be indicated in Message-ID: <9703172242.AA02360@zazen.cp10.es.xerox.com> >Return-Path: >From: Bob Pentecost >To: "'Tom Hastings'" >Cc: "'PWG-pmp'" >Subject: RE: PMP> How should a PDF document be indicated in thePrinterMIB, JobMonitoring MIB and IPP? >Date: Mon, 17 Mar 1997 14:11:29 PST >Encoding: 243 TEXT >Sender: pmp-owner@pwg.org > >Tom, > >Here are some answers to your questions... > >> ---------- >From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] >> Sent: Monday, March 17, 1997 10:39 AM >> To: Bob Pentecost >> Subject: RE: PMP> How should a PDF document be indicated in >thePrinterMIB, JobMonitoring MIB and IPP? >> >> Bob, >> >> I'm not familiar with MIME types that have been registered. >> 1. Is PCL a registered type? > >Yes. HP recently registered PCL, PCLXL and HP-GL. > >> 2. Or do you have some printer-independent form of PCL registered? > >We chose to register PCL as a single type. A viewer that recognizes the PCL >MIME type must be able to understand all PCL commands if it is going to be >able to display PCL files created for all printers. > >> 3. Where is the MIME registry? > >See http://www.isi.edu/in-notes/iana/assignments/media-types/application/ >where you can find vnd.hp-HPGL, vnd.hp-PCL and vnd.hp-PCLXL. > >> 4. When you use such a MIME type, are the document contents no longer >> printer-specific? I.e., such a PCL MIME type would >> be printable on both the LaserJet 5 and 5Si? > >A file with MIME type PCL could be any level of PCL and could be intended >for any printer from DeskJet to LaserJet to Color LaserJet. > >Would it be printable on any printer? I think that depends on the software >being used. If the software just dumps the file to a printer, it may not >work. However, if the software converts the file to some intermediate >format and then prints through a printer driver, it could be printed on any >printer (the same as the way I can print a .pdf file by using my browser to >view it and print it, even though my printer doesn't understand .pdf >format). > >> >> This is the kind of *significant* discussion I'd like to have in the PWG >> with regard to PostScript and PCL. Can I make our mail discussion >> public to the PWG, PMP, and JMP DLs? It looks like a great start to the >> discussion. > >Go ahead and make it public. In fact, I'll just cc PMP on this message. > >> >> We need to understand the difference between a document format and >> an interpreter (which is what I think is the distinction you are >raising). >> We need to understand which we are specifying in a job submision protocol >> and so are reporting in the Job Monitoring MIB. >> >> Thanks, >> Tom > >Bob Pentecost >HP > > >> >> At 15:03 03/14/97 PST, you wrote: >> >Tom, >> > >> >For a document repository, wouldn't it make sense to use MIME types to >know >> >the document format? >> > >> >For PCL, we tend to make slight changes from printer to printer even >though >> >they are all considered to be PCL5e. There's no guarantee that a file >> >generated for a LaserJet 5 will print correctly on a 5Si. Therefore, I >> >would be hesitant to tie a language pairing to a document. >> > >> >Bob >> > >> > >> >---------- >> >From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] >> >Sent: Thursday, March 13, 1997 5:06 PM >> >To: Bob Pentecost >> >Subject: RE: PMP> How should a PDF document be indicated in the >> >PrinterMIB, JobMonitoring MIB and IPP? >> > >> >I think the PWG is aware of the appropriate language pairings for >> >current levels, e.g., PCL4, PCL5, PCL5e, PS1, PS2, PS3. >> > >> >But is PDF part of PS3 or a separate document format or both? >> > >> >We really need help in deciding how to represent PCL and PS in these >> >three standards: Printer MIB, Job Monitoring MIB, and IPP. >> >Also these registrations will be used in other places, such as document >> >repositories where a user wants to know the document-format, so he can >> >decide which piece of software to use to acces it and to which printers >> >he/she can send the document, but maybe such use of enums in document >> >repositories is clouding the issue with the use of these enums in these >> >three >> >standards. >> > >> >PCL and PostScript "belong" to HP and Adobe, though the rest of us are >> >affected too. >> > >> >Tom >> > >> >At 13:48 03/13/97 PST, you wrote: >> >>Tom, >> > >> >I'm not sure what you're asking for. You say "We need some help here >from >> >>Adobe and HP on what is the best course to follow for the Printer MIB, >Job >> >>Monitoring MIB, and IPP." Is help needed to know which are the >appropriate >> >>language-version pairings? Or is help needed to understand whether or >not >> >>this feature is needed at all? >> >> >> >>Bob >> >> >> >> >> >> >> >>---------- >> >>From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] >> >>Sent: Thursday, March 13, 1997 1:31 PM >> >>To: pmp@pwg.org; ipp@pwg.org; jmp@pwg.org >> >>Subject: PMP> How should a PDF document be indicated in the Printer >MIB, >> >>JobMonitoring MIB and IPP? >> >> >> >>Currently there is no enum registered for a PDF document-format for use >> >>in the Printer MIB, the Job Monitoring MIB, and IPP. >> >> >> >>How should a PDF document be indicated in the Printer MIB, Job >Monitoring >> >>MIB and IPP? >> >> >> >>IPP is part of PostScript level 3, I understand, so that the PostScript >> >>enum langPD(6) with a level of "3" in prtInterpreterLangLevel in the >> >>Printer MIB could indicate a Printer that is capabile of consuming a >PDF >> >>file. But what about the Job Monitoring MIB where we don't have level >> >>and IPP where we don't have level? >> >> >> >>Also it seems that a Printer might be able to consume PDF, but not any >> >>PostScript level 3. Finally, in a document repository, it would be >useful >> >>to know that a document is a PDF file, so that a PDF reader can be used >> >>to image it. >> >> >> >>We've discussed at several Printer Working Group meetings the idea of >> >>registering combinations of language family and level in order to give >> >them >> >>distinct enums. So we could register PS1, PS2, PS3, and PDF. Also >PCL5e, >> >>PCL5, and PCL4 as separate enums for use when a particular level is >> >>important. >> >>And we could keep the current langPCL(3) and langPS(6) for use when >level >> >>is not important, or when the level is specified by other attributes, >> >>such as in the Printer MIB. >> >> >> >>The advantage of keeping the family separate from the level, is that an >> >old >> >>application would still have a clue that a new level of document is >really >> >>an upwards compatible level with the enum that it understands, where as >if >> >>we register a new enum for each level, the old application will have no >> >>clue >> >>that the document is PostScript. >> >> >> >>For IPP, we might have a string, in which the family and level are >> >>syntactially >> >>distinguished, so that an old application could separate the family >from >> >>the level. >> >> >> >>In the Job Monitoring MIB we have the Printer MIB enum. But we might >> >>change to the text string that has both family and level, if that is >the >> >>way that IPP goes. Then we wouldn't need to register the different >levels >> >>of PostScript and PCL. >> >> >> >>However, we may still want to register a PDF enum, since it is such a >> >>common document format these days. >> >> >> >>We need some help here from Adobe and HP on what is the best course to >> >>follow for the Printer MIB, Job Monitoring MIB, and IPP. >> >> >> >>I'd like to see this issue come up in the PWG agenda, since it affect >> >>all three PWG progjects, if we can't resolve this via e-mail. >> >> >> >>Thanks, >> >>Tom >> >> >> >> >> >>See the current 1.5 or 1.6 IPP Model and Semantics. >> >> >> >>Here is the extracted text from that: >> >> >> >>5.2.7.1 document-format (type2Enumformat) >> >>This job attribute identifies the document format of this document, and >> >may >> >>be a per-document attribute. >> >> >> >>This printer attribute indicates default value. It also indicates the >> >>values >> >>of the attribute supported by this printer and the states of readiness >for >> >>each value. One possible supported and default value is "auto-sense". >> >> >> >>The following standard values have been reviewed with the Printer >Working >> >>Group and are registered with IANA as part of the IETF Printer MIB >> >project. >> >>The token value assigned by the PWG starts with the four letters: >"lang", >> >>in >> >>order to follow SNMP ASN.1 rules that all enum symbols shall start with >a >> >>lower case letter. The token values in IPP shall be the same as the >IANA >> >>token values, with the "lang" removed. The MIB (integer) value is >> >included >> >>here for reference only, the MIB value shall not be used in IPP; the >> >token >> >>value shall be used instead: >> >> >> >>Token Value MIB value Description >> >> < >> > >> > >> > > > > > > > From hastings at cp10.es.xerox.com Mon Mar 17 18:06:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> DateAndTime is a binary string of octets! In-Reply-To: DateAndTime is a binary string of octets!> Message-ID: <9703172308.AA02385@zazen.cp10.es.xerox.com> Patrick, What did the "This" refer to at the end? Thanks, Tom At 07:21 03/14/97 PST, you wrote: > DateAndTime which we are using for date and time in our Job Monitoring MIB > is not printable characters; its binary (don't be fooled by the display > hint, which is just how to convert the binary to text). > > We decided to have two values in our Resource Table (which I'm renaming > to Attribute Table due to some confusion about resources in the e-mail and > since we have agreed to put more than just resources into it): > > jmAttributeValueAsInteger > jmAttributeValueAsText > >I would suggest that you might also want to add 'textencoding' as well. >For example, you might have UNICODE text or simple ASCII text. I'm not sure what you are suggesting here? I was suggesting that we change the name to jmAtributeValueAsOctets so that the object contains whatever the enum says it contains. If the enum says it contains coded characters, then the object contains coded characters which may be ASCII or UNICODE or whatever. The monitoring application is assumed to know what coded character submitter use. See page 30, under OCTET STRING. It the object contains binary octets, such as DateAndTime, then that is what it contains. Ok? > > Since Text is represented as OCTET STRING in SNMP, there is no problem > with sending the binary using the same object. However, we might want > to rename the second object to jmAttributeValueAsOctets, so that it > covers the DateAndTime. > > Comments? > > Tom > > WARNING: > > By the way, SNMPV2-TC isn't very clear whether the two octet year is > Big Endian or Little Endian, but I suspect that it must be Big Endian, > since SNMP uses ASN.1 which is Big Endian (most significant octet first). > > So the year 256 would be represented as 1 in the first octet and 0 in the > second octet, not the other way around. > > Be careful, since PCs are Little Endian, so they have to swap the octets. > >I believe that there is a general fiat that the Network Standard Order >for multiple octect values is Big Endian. > > RFC 1903 SNMPv2-TC is copied as follows: > > DateAndTime ::= TEXTUAL-CONVENTION > DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" > > STATUS current > DESCRIPTION > "A date-time specification. > > field octets contents range > ----- ------ -------- ----- > 1 1-2 year 0..65536 > 2 3 month 1..12 > 3 4 day 1..31 > 4 5 hour 0..23 > 5 6 minutes 0..59 > 6 7 seconds 0..60 > (use 60 for leap-second) > 7 8 deci-seconds 0..9 > 8 9 direction from UTC '+' / '-' > 9 10 hours from UTC 0..11 > 10 11 minutes from UTC 0..59 > > For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be > displayed as: > > 1992-5-26,13:30:15.0,-4:0 > > Note that if only local time is known, then timezone > information (fields 8-10) is not present." > SYNTAX OCTET STRING (SIZE (8 | 11)) > > >This is also the standard for representing time in some other ISO standards. >Why not make this the cannonical way to represent time/date values? What does "This" refer to? The ASCII display: 1992-5-26,13:30:15.0,-4:0 or the binary format? We have agreed that including a date is not possible for some implementations, so we are also providing the TimeStamp textual convention from SNMPv2-TC which is 100ths of a second offset from the time the system was started. We've doubled the number of time enums to provide both formats. Tom > >Patrick > > From hastings at cp10.es.xerox.com Mon Mar 17 18:35:13 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> I've posted a black and white JMP with revision marks. Message-ID: <9703172337.AA02401@zazen.cp10.es.xerox.com> For those needing black and white revision marks for version 0.7 of the Job Monitoring MIB, I've added the .pdb (black) PDF file: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 446976 Mar 14 22:54 jmp-mib.doc -rw-r--r-- 1 pwg pwg 480229 Mar 17 23:34 jmp-mib.pdb -rw-r--r-- 1 pwg pwg 389447 Mar 14 23:00 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 488375 Mar 14 23:04 jmp-mib.pdr -rw-rw-r-- 1 pwg pwg 12800 Mar 11 21:35 mib.dot Tom From harryl at us.ibm.com Mon Mar 17 19:03:32 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job Type enumerations Message-ID: <5030100000787583000002L032*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, thanks for all the great work on updating the Job MIB. Quick question. Either there's been a change, or I'm noticing for the first time... but why are there "holes" in the jmJobTypesTC list of type-2 enums? We've got 1 - Other 2 - Unknown 4 - Print 8 - Scan 16 - faxIn 328 - faxOut 64 - getFile 128 - putFile 256 - mailList. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon Mar 17 19:18:07 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job States and State Reasons Message-ID: <5030100000787915000002L052*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I've stated before, but perhaps not strongly enough, that I think job state and job state reasons should be combined into one OID in the job MIB. It must be that DPA defined it as two, I guess that's what is driving the spec today. But, try and implement this in an embedded controller. There you are wasting 4 bytes times every entry in your State table. If you are designing for persistent data (across polling cycles, not with NVRAM) in the printer, you want as many entries as possible in the table. Is anyone else designing for embedded controller who shares my opinion strongly enough to make a comment? Anyone who feels the job MIB, in general, is too cumbersome for embedded controllers? Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon Mar 17 19:28:15 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Output Bin Attribute Message-ID: <5030100000788149000002L092*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Why is outputBin (the jmAttributeTC) defined as TEXT rather than an index into the associated Printer MIB (like jobSourceChannelIndex)? Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Mon Mar 17 21:03:14 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job Type enumerations In-Reply-To: Job Type enumerations> Message-ID: <9703180205.AA02480@zazen.cp10.es.xerox.com> Each bit is a power of 2 (except for my typo). Thus a job can be more than one. A compound job (in the future) could be scanning and faxing, for example. I'll add more explantion. Tom At 16:03 03/17/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >Tom, thanks for all the great work on updating the Job MIB. Quick question. >Either there's been a change, or I'm noticing for the first time... but why are >there "holes" in the jmJobTypesTC list of type-2 enums? We've got > > 1 - Other > 2 - Unknown > 4 - Print > 8 - Scan > 16 - faxIn >328 - faxOut Should have been 32, not 328. > 64 - getFile >128 - putFile >256 - mailList. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon Mar 17 21:14:05 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job States and State Reasons In-Reply-To: Job States and State Reasons> Message-ID: <9703180216.AA02492@zazen.cp10.es.xerox.com> The reason for two separate objects, is that the job states can't be added to without breaking application software. If PWG registers more states, such software will get some new state that it doesn't understand. The idea is that the application software is likely to do something based on a state, but is NOT likely to do anything based on a job-state-reason. Only the human is interested in the job-state-reasons. The job-state-reasons are extensible, since they aren't really new states, but are additional information or sub-states. If an application gets a job-state-reason that it doesn't understand, it not a big problem. For an embedded controller without much memory, why not leave out most of the job-state-reasons? Perhaps only the completion with errors or success? WE could make jmJobState a type 1 enum, instead of a type 2 enum, to reflect this strategy? This is the same strategy that we are taking in IPP as well where the job and printer states are type 1 enums. Tom At 16:18 03/17/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >I've stated before, but perhaps not strongly enough, that I think job state and >job state reasons should be combined into one OID in the job MIB. It must be >that DPA defined it as two, I guess that's what is driving the spec today. But, >try and implement this in an embedded controller. There you are wasting 4 bytes >times every entry in your State table. If you are designing for persistent data >(across polling cycles, not with NVRAM) in the printer, you want as many >entries as possible in the table. > >Is anyone else designing for embedded controller who shares my opinion strongly >enough to make a comment? Anyone who feels the job MIB, in general, is too >cumbersome for embedded controllers? > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon Mar 17 21:19:07 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Output Bin Attribute In-Reply-To: Output Bin Attribute> Message-ID: <9703180221.AA02500@zazen.cp10.es.xerox.com> So that the Job Monitoring MIB can be used with a server that hasn't implemented the Printer MIB. We could add a second enum that has a value that is the output bin index for those implementations that have a Printer MIB, should we? (I think its better to add a second enum, instead of saying that this outputBin enum could have either a text value or an integer (index) value or both, correct?) Tom At 16:28 03/17/97 PST, Harry wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >Why is outputBin (the jmAttributeTC) defined as TEXT rather than an index into >the associated Printer MIB (like jobSourceChannelIndex)? > >Harry Lewis - IBM Printing Systems > > From rbergma at dpc.com Mon Mar 17 22:14:54 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> First Comment Set on version 0.7 MIB Message-ID: <9703180221.AA02500@zazen.cp10.es.xerox.com> Note: Line numbers are from the .pdf version. line 31: should be Dataproducts Corp. line 36: Harry Lewis should be added to the list of authors. lines 155-159: This is a repeat of the abstract and should be removed. line 164: "withoutspooling" S/B "without spooling" line 165: "comonly" S/B "commonly" line 197: "will support" S/B "supports" line 199: "shall support" S/B "supports" line 202: "will provide" S/B "provides" line 222: The table grid remains with no text. S/B removed. line 223: S/B "2. Terminology and Job Model" lines 234-242: This paragraph is very confusing. I propose- "A JOB SET is a set of jobs that are queued and scheduled together according to a specified scheduling algorithm for a specified device or set of devices. For implementations that embed the SNMP agent in the device, the MIB JOB SET normally defines all the jobs known to the device. If implemented in a server for multiple devices, each JOB SET would define a job queue for a specific device." lines 251-252: Delete- "The client may or may not also use SNMP and the Job Monitoring MIB to monitor jobs, depending upon implementation." lines 266-268: Change to- "SPOOLING is the act of a DEVICE or SERVER of accepting jobs and writing the jobs attributes and document data on to a secondary storage." lines 269-272: Change to- "Queuing is the act of a DEVICE or SERVER of ordering (queuing) jobs for the purpose of scheduling the jobs to be processed." line 277: "monitorand" S/B "monitor and" line 348: How will this table convert to text? General comment: I am not positive, but I believed that a draft document had to be in text format to be posted. If this is true, it looks like there is a significant amount of work remaining before this document can be submitted. Figure 1 especially! Comments? line 556: There is currently a discussion with respect to the Printer MIB regarding Conformance statements. This section should "conform" (no pun intended) to the final outcome in PMP. line 712: Since we are not adding any new data types, is this section necessary? I propose section 12 be removed. line 1632: Appendices A, B, and C should eventually become a separate RFC document. Should a note be added? line 1679: This is good information, but should be pulled from the document and included as a separate file on the ftp server. More to come.... ...Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Mon Mar 17 23:22:36 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Output Bin Attribute In-Reply-To: Output Bin Attribute> Message-ID: <5030100000791231000002L012*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, thanks for reminding me. If this is the case, then I think we should add the extra enum for treating outputbin as an index into the printer MIB for printer implementation. --- Forwarded by Harry Lewis/Boulder/IBM on 03/17/97 09:14 PM --- jmp-owner@pwg.org 03/17/97 07:31 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org@internet Subject: Re: JMP> Output Bin Attribute So that the Job Monitoring MIB can be used with a server that hasn't implemented the Printer MIB. We could add a second enum that has a value that is the output bin index for those implementations that have a Printer MIB, should we? (I think its better to add a second enum, instead of saying that this outputBin enum could have either a text value or an integer (index) value or both, correct?) Tom Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon Mar 17 23:43:39 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Job States and State Reasons In-Reply-To: Job States and State Reasons> Message-ID: <5030100000791394000002L042*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Doesn't seem like it would take too much of a filter to the existing application to convert the enum values back into pairs, if that's what's needed at that end. Reducing the number of job states called out or changing them to type-2 enums is not the issue. My concern is number of OIDs. --- Forwarded by Harry Lewis/Boulder/IBM on 03/17/97 09:33 PM -- jmp-owner@pwg.org 03/17/97 07:17 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org@internet Subject: Re: JMP> Job States and State Reasons The reason for two separate objects, is that the job states can't be added to without breaking application software. If PWG registers more states, such software will get some new state that it doesn't understand. The idea is that the application software is likely to do something based on a state, but is NOT likely to do anything based on a job-state-reason. Only the human is interested in the job-state-reasons. The job-state-reasons are extensible, since they aren't really new states, but are additional information or sub-states. If an application gets a job-state-reason that it doesn't understand, it not a big problem. For an embedded controller without much memory, why not leave out most of the job-state-reasons? Perhaps only the completion with errors or success? WE could make jmJobState a type 1 enum, instead of a type 2 enum, to reflect this strategy? This is the same strategy that we are taking in IPP as well where the job and printer states are type 1 enums. Tom Harry Lewis - IBM Printing Systems From bpenteco at boi.hp.com Tue Mar 18 13:02:21 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:02 2009 Subject: JMP> Output Bin Attribute Message-ID: <01BC338B.DBC7B3E0@hpb15767.boi.hp.com> This looks good to me. The printer can have a simple enum index pointing into the Printer MIB. If a server is working with a printer that has implemented the Job Monitoring MIB and the Printer MIB, then the server can go to the printer's Printer MIB and find an appropriate string to put in its own Job Monitoring MIB. If the server is returning text, what about localization? The Printer MIB localizes prtOutputDescription, will the server just return that string, however it is localized? Bob Pentecost HP ---------- From: Harry Lewis[SMTP:harryl@us.ibm.com] Sent: Monday, March 17, 1997 9:23 PM To: jmp@pwg.org Subject: Re: JMP> Output Bin Attribute Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, thanks for reminding me. If this is the case, then I think we should add the extra enum for treating outputbin as an index into the printer MIB for printer implementation. --- Forwarded by Harry Lewis/Boulder/IBM on 03/17/97 09:14 PM --- jmp-owner@pwg.org 03/17/97 07:31 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org@internet Subject: Re: JMP> Output Bin Attribute So that the Job Monitoring MIB can be used with a server that hasn't implemented the Printer MIB. We could add a second enum that has a value that is the output bin index for those implementations that have a Printer MIB, should we? (I think its better to add a second enum, instead of saying that this outputBin enum could have either a text value or an integer (index) value or both, correct?) Tom Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue Mar 18 17:24:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Plans for Job Monitoring MIB Internet Draft Message-ID: <9703182226.AA02705@zazen.cp10.es.xerox.com> Ron and I just discussed how to prepare an Internet Draft of the Job Monitoring MIB. We all see to be real busy with telecons on IPP and the Printer MIB this week to hold a JMP telecon too. But we want an Internet Draft for the IETF to see and comment on at the April 8 meeting in Memphis. Ron thinks we will have a full day in Austin at the PWG JMP meeting, on Friday, April 4, to resolve the few, but significant, remaining issues. So please send any comments on version 0.7 by this Thursday, 3/20, and I'll either incorporate them into the draft or add them to the issues list, depending on the nature of the comment. I'll produce another version, 0.71, and produce the plain text form (as well as .ps and .pdf) that the IETF needs for an Internet Draft, so that we can submit it by the deadline, Wednesday, 3/26. Someone needs to tell me how to submit an Internet Draft and get the file name to be put into the document. Thanks, Tom From imcdonal at eso.mc.xerox.com Tue Mar 18 19:03:19 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:02 2009 Subject: JMP> Plans for Job Monitoring MIB Internet Draft In-Reply-To: Plans for Job Monitoring MIB Internet Draft> Message-ID: <9703190003.AA01620@snorkel.eso.mc.xerox.com> Hi Tom, Your 'JmJobStateReasonsTC' is INCORRECTLY typed 'OCTET STRING'. Use the new 'BITS' (named bits) type from RFC 1902 (SMIv2) instead and it will work (remember to number from ZERO, not ONE - just name bit 0 'reserved' to save hassle). I'm buried this week and gone Friday, so I'm not going to get to looking at your draft this week. Also, Joe Filion and I tried to follow the procedure in your Appendix on how to get a 'flat text' I-D this morning (so we could try to check for compiler errors), but all attempts failed - we could not keep MS-Word from murdering a lot of the MIB text. Tom, could you sync up with Joe and let him help you with the compile stuff, sometime soon? The IETF won't like an I-D that doesn't compile... By the way, 'BITS' is the gratuitous corruption of the perfectly good true ASN.1 base type 'BIT STRING', added to SMIv2 in RFC 1902 (NOT present in RFC 1442, old SMIv2). Cheers, - Ira McDonald (High North Inc) From don at lexmark.com Wed Mar 19 07:45:30 1997 From: don at lexmark.com (Don Wright) Date: Wed May 6 14:00:02 2009 Subject: JMP> Plans for Job Monitoring MIB Internet Draft In-Reply-To: Plans for Job Monitoring MIB Internet Draft> Message-ID: <199703191238.AA19376@interlock.lexmark.com> Please be aware that JMP shares Friday with SENSE. Don To: jmp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP Date: 03/18/97 02:24:39 PM Subject: JMP> Plans for Job Monitoring MIB Internet Draft Ron and I just discussed how to prepare an Internet Draft of the Job Monitoring MIB. We all see to be real busy with telecons on IPP and the Printer MIB this week to hold a JMP telecon too. But we want an Internet Draft for the IETF to see and comment on at the April 8 meeting in Memphis. Ron thinks we will have a full day in Austin at the PWG JMP meeting, on Friday, April 4, to resolve the few, but significant, remaining issues. So please send any comments on version 0.7 by this Thursday, 3/20, and I'll either incorporate them into the draft or add them to the issues list, depending on the nature of the comment. I'll produce another version, 0.71, and produce the plain text form (as well as .ps and .pdf) that the IETF needs for an Internet Draft, so that we can submit it by the deadline, Wednesday, 3/26. Someone needs to tell me how to submit an Internet Draft and get the file name to be put into the document. Thanks, Tom From jkm at underscore.com Wed Mar 19 13:10:43 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> Plans for Job Monitoring MIB Internet Draft In-Reply-To: Plans for Job Monitoring MIB Internet Draft> Message-ID: <199703191810.NAA07092@uscore.underscore.com> Don et al, I will not be able to attend the upcoming PWG meetings in Austin, Texas, next month. (Harry Lewis has been kind enough to fill in for me as PWG Secretary for these meetings.) Therefore, if the JMP group needs an entire day, it should at least be able to take over the "SENSE slot". ...jay ----- Begin Included Message ----- To: Tom Hastings Cc: "jmp%pwg.org" From: Don Wright Date: 19 Mar 97 7:45:30 EST Subject: Re: JMP> Plans for Job Monitoring MIB Internet Draft Mime-Version: 1.0 Please be aware that JMP shares Friday with SENSE. Don To: jmp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP Date: 03/18/97 02:24:39 PM Subject: JMP> Plans for Job Monitoring MIB Internet Draft Ron and I just discussed how to prepare an Internet Draft of the Job Monitoring MIB. We all see to be real busy with telecons on IPP and the Printer MIB this week to hold a JMP telecon too. But we want an Internet Draft for the IETF to see and comment on at the April 8 meeting in Memphis. Ron thinks we will have a full day in Austin at the PWG JMP meeting, on Friday, April 4, to resolve the few, but significant, remaining issues. So please send any comments on version 0.7 by this Thursday, 3/20, and I'll either incorporate them into the draft or add them to the issues list, depending on the nature of the comment. I'll produce another version, 0.71, and produce the plain text form (as well as .ps and .pdf) that the IETF needs for an Internet Draft, so that we can submit it by the deadline, Wednesday, 3/26. Someone needs to tell me how to submit an Internet Draft and get the file name to be put into the document. Thanks, Tom ----- End Included Message ----- From harryl at us.ibm.com Wed Mar 19 16:22:03 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Plans for Job Monitoring MIB Internet Draft In-Reply-To: Plans for Job Monitoring MIB Internet Draft> Message-ID: <5030100000832534000002L042*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Will there be a SENSE this month? ---- Forwarded by Harry Lewis/Boulder/IBM on 03/19/97 02:17 PM -- jmp-owner@pwg.org 03/19/97 05:38 AM Please be aware that JMP shares Friday with SENSE. Don Harry Lewis. From hastings at cp10.es.xerox.com Mon Mar 24 11:24:06 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> I need your .doc files for the mapping, not just .pdf Message-ID: <9703241626.AA01794@zazen.cp10.es.xerox.com> I wanted to include some mapping at least for the interesting objects in Appendix A for the Internet-draft for LPD and DPA and any others I can get. If anyone else has their contribution, please do it Monday. Also please use the file names that I suggest in the template, so that it is easy to relate the protocol to the file. And please post both .pdf and .doc. Thanks, Tom From harryl at us.ibm.com Tue Mar 25 17:40:19 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Additions to Job MIB Message-ID: <5030100000954980000002L002*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I'm looking at the 3/14 version of the job MIB and some things look rather new to me. For example, in the jmGeneral group, we now have a jobSetName, NumberofJobstoComplete, and NumberofJobsCompleted. I don't recall discussing these changes, I'm wondering about the rational for including them. Did I miss some meetings? Is this an attempt to harmonize with IPP? Maybe these things were always there and I've just overlooked them. Harry Lewis - IBM Printing Systems From imcdonal at eso.mc.xerox.com Tue Mar 25 23:04:44 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:02 2009 Subject: JMP> Compile Errors in IETF Job Mon MIB draft Message-ID: <9703260404.AA03940@snorkel.eso.mc.xerox.com> Hi Tom Hastings, Tuesday (25 March 1997) Joe Filion got me the 'raw text' of your latest IETF Job Monitoring MIB draft, to check for compiler errors, this afternoon. With the following fixes, your latest IETF Job Monitoring MIB draft compiles cleanly under Epilogue v7.0 (ie, Emissary v6.0), using RFC 190x series (SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF). Note_1: For your 'JmJobServiceTypesTC' and 'JmJobStateReasonsTC' to compile, you need the new built-in type 'BITS' (a silly rename of the true ASN.1 type 'BIT STRING'), which is defined in new SMIv2 (RFC 1902). Note_2: You CANNOT use the older (1994) version of SMICng - it doesn't understand the RFC 190x series - you will need the new SMICng Pro (under license) or SMICng Book (free to owners of Perkins' book 'Understanding SNMP MIBs') - they are available from 'http://www.snmpinfo.com'. Note_3: You CANNOT use the older Epilogue v6.0 (Emissary v5.0) - it doesn't understand the RFC 190x series - you will need the newer version named above - we (Xerox) do have a license - Joe Filion can send you a pointer to the executable - I used it to do this cleanup work today - Epilogue is NOT as rigorous as SMICng about the compliance macros, so you MAY still have some cleanup to do there. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 ************ Bugs in latest IETF Job Monitoring MIB draft ************** 1) At beginning, invalid presence of 'temp OBJECT IDENTIFER...' - modules MUST begin with a MODULE-IDENTITY (immediately following any IMPORTS clause) 2) In tag on MODULE-IDENTITY macro, non-standard use of 'jobmonmib' - should be changed to 'jobMonMIB' (eg, see Mobile IP MIB, RFC 2006) 3) In SYNTAX clause of 'JmJobStateReasonsTC', invalid use of INTEGER (or OCTET STRING) - should be BITS (per SMIv2, RFC 1902) - REMEMBER to define bit zero (eg, 'reserved(0)') - REMEMBER defined bits MUST be contiguous (ie, 0,1,2,...) 4) In DESCRIPTION clause of 'JmAttributeTypeTC', invalid use of double quotes in '...used (no "Octets:" tag), the Agent...' - should be single quotes 5) In SYNTAX clause of 'JmAttributeTypeTC', invalid ASN.1 comment on line beginning '-- jmAttributeTypeIndex -- Description...' - should move ALL of this text up into DESCRIPTION clause - per OSI ASN.1 (ISO 8824), comments end at a SECOND '--' token OR end-of-line 6) In SYNTAX clause of 'JmAttributeTypeTC', need a '--' comment token in 'other(1)' before the text 'with IANA.' 7) In SYNTAX clause of 'JmAttributeTypeTC', need to DELETE comma after 'processingCPUTime(46)' - which is LAST enumeration 8) In 'JmGeneralEntry' SEQUENCE, need to ADD comma after 'jmGeneralJobSetName OCTET STRING(SIZE(0..63))' 9) In DESCRIPTION clause of 'jmJobIdName', invalid use of double quotes in '...on the "client-side"...' and in '...referred to as the "client-side"...' and in '...jobs currently "known"...' - should be single quotes 10) In DESCRIPTION clause of 'jmJobIdNumber', invalid use of double quotes in '...job on the "client-side"...' - should be single quotes 11) In DESCRIPTION clause of 'jmAttributeTypeIndex', invalid use of double quotes in '..."Integer:"...' (twice) and '..."Octets"...' (twice) - should be single quotes 12) In OBJECTS clause of 'jmGeneralGroup' OBJECT-GROUP macro, invalid comma after 'jmGeneralNumberOfJobsCompleted' 13) In SYNTAX clause of 'jmQueueIndex', invalid range - should be 'Integer32(1..2147483647)', NOT '(0..' 14) In OBJECTS clause of 'jmQueueGroup' OBJECT-GROUP, invalid inclusion of 'jmQueueIndex' (which is 'not-accessible') 15) In MAX-ACCESS clause of 'jmCompletedJobIndex', should change 'not-accessible' to 'read-only' - at LEAST one object in each SEQUENCE must be 'read-only' or better (see RFC 1902) 16) In SYNTAX clause of 'jmJobStateReasons' and in SEQUENCE 'JmJobEntry' - change to 'JmJobStateReasonsTC' (see item 3 above) 17) In SYNTAX clause of 'JmJobServiceTypesTC', invalid use of INTEGER (or OCTET STRING) - should be BITS (per SMIv2, RFC 1902) - REMEMBER to define bit zero (eg, 'reserved(0)') - REMEMBER defined bits MUST be contiguous (ie, 0,1,2,...) 18) In SYNTAX clause of 'jmJobServiceTypes' and in SEQUENCE 'JmJobEntry' - change to 'JmJobServiceTypesTC' (see item 17 above) From hastings at cp10.es.xerox.com Wed Mar 26 12:08:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Additions to Job MIB In-Reply-To: Additions to Job MIB> Message-ID: <9703261711.AA02503@zazen.cp10.es.xerox.com> Harry, These were things discussed on some telecon and in the issues list. I put then in, since they seemed like non-controversial things. We can discuss them further at the upcoming JMP meeting. The jmJobSetName will be the queue name, the printer name or the server name, depending on how job sets are realized. I've added a bunch of text to explain things that people are having trouble understanding in the Internet Draft which I am still trying to convert to plain text. Tom At 14:40 03/25/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >I'm looking at the 3/14 version of the job MIB and some things look rather new >to me. For example, >in the jmGeneral group, we now have a jobSetName, NumberofJobstoComplete, >and NumberofJobsCompleted. I don't recall discussing these changes, I'm >wondering about >the rational for including them. Did I miss some meetings? Is this an attempt >to harmonize with >IPP? Maybe these things were always there and I've just overlooked them. > >Harry Lewis - IBM Printing Systems > > From rbergma at dpc.com Wed Mar 26 11:18:29 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Additions to Job MIB Message-ID: <9703261711.AA02503@zazen.cp10.es.xerox.com> Harry, ------------------------------------------------------------------------ II. Review of Keith Carters (OS/2) comments on the job MIB from Feb 4). >>> snip ... snip >>> * Page 49 - Should MIB provide jmGeneralNumberOfJobsQueued and jmGeneralNumberOfJobsComplete so a network management application can summarize the current status of the printer? Tom will add an object that indicates the number of jobs to complete which includes both jobs queued and jobs currently being processed. ------------------------------------------------------------------------ Of course this decision is still open to review. We can discuss further in Austin. Ron Bergman On Tue, 25 Mar 1997 17:40:19 Harry Lewis wrote: > > I'm looking at the 3/14 version of the job MIB and some things look rather new > to me. For example, > in the jmGeneral group, we now have a jobSetName, NumberofJobstoComplete, > and NumberofJobsCompleted. I don't recall discussing these changes, I'm > wondering about > the rational for including them. Did I miss some meetings? Is this an attempt > to harmonize with > IPP? Maybe these things were always there and I've just overlooked them. > > Harry Lewis - IBM Printing Systems > From jkm at underscore.com Wed Mar 26 12:17:36 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... Message-ID: <199703261717.MAA10506@uscore.underscore.com> Can we have a public "show of hands" of those persons/companies actively engaged in developing one or more prototypes of the Job MIB? I know there are at least a few companies that have been involved in developing their own, proprietary Job-like MIBs, but how many folks out there are actually working on developing an implementation of the Job MIB as it is currently defined? Given that sooo much time has been spent on this effort, it would be nice to know that we are not merely working on a "paper" design after all these years. Thanks in advance. ...jay From rbergma at dpc.com Wed Mar 26 15:58:05 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: <199703261717.MAA10506@uscore.underscore.com> Message-ID: <199703261717.MAA10506@uscore.underscore.com> Jay, Dataproducts has a private Job Monitoring MIB which will be converted to the JMP MIB when it has reached a point of stability. (Hence my interest in this project.) Ron Bergman On Wed, 26 Mar 1997, JK Martin wrote: > Can we have a public "show of hands" of those persons/companies actively > engaged in developing one or more prototypes of the Job MIB? > > I know there are at least a few companies that have been involved in > developing their own, proprietary Job-like MIBs, but how many folks > out there are actually working on developing an implementation of > the Job MIB as it is currently defined? > > Given that sooo much time has been spent on this effort, it would be > nice to know that we are not merely working on a "paper" design after > all these years. > > Thanks in advance. > > ...jay > From michael at rd.qms.com Wed Mar 26 16:07:11 1997 From: michael at rd.qms.com (Michael Bringmann) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9703262107.AA22672@doc.rd.qms.com> > Jay, > > Dataproducts has a private Job Monitoring MIB which will be converted > to the JMP MIB when it has reached a point of stability. (Hence my > interest in this project.) > > Ron Bergman QMS also has a private Job Monitoring MIB. We are also waiting for more stability in the various MIB projects for printers. Michael W. Bringmann > > > On Wed, 26 Mar 1997, JK Martin wrote: > > > Can we have a public "show of hands" of those persons/companies actively > > engaged in developing one or more prototypes of the Job MIB? > > > > I know there are at least a few companies that have been involved in > > developing their own, proprietary Job-like MIBs, but how many folks > > out there are actually working on developing an implementation of > > the Job MIB as it is currently defined? > > > > Given that sooo much time has been spent on this effort, it would be > > nice to know that we are not merely working on a "paper" design after > > all these years. > > > > Thanks in advance. > > > > ...jay > > > > From harryl at us.ibm.com Wed Mar 26 16:07:41 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... Message-ID: <5030100000977272000002L022*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Jay, you asked... >Can we have a public "show of hands" of those persons/companies actively >engaged in developing one or more prototypes of the Job MIB? >I know there are at least a few companies that have been involved in >developing their own, proprietary Job-like MIBs, but how many folks >out there are actually working on developing an implementation of >the Job MIB as it is currently defined? >Given that sooo much time has been spent on this effort, it would be >nice to know that we are not merely working on a "paper" design after >all these years. IBM started prototyping the PWG Job MIB and is now working on what I would call a "hybrid" of that MIB. If I can get my act together soon enough, I hope to have some time on the JMP agenda next week to present our findings as a result of this prototype, the alternate paths we've taken and why. Not only have we found it necessary to simplify our design (which, admittedly is specific to printers, not servers) but, in thinking hard about who will use each object and what for, we've made some changes that we feel enhance the operation of the MIB. I sent e-mail outlining some of our findings a few weeks back but received very little response. I've taken that as a sign that, perhaps, everyone is focused on IPP and loosing interest in the Job MIB. Therefore, I appreciate your query. If there are only a small set of companies interested in the Job MIB, now, perhaps we can reach consensus about the scope and complexity. I am willing (and hope to be ready) to share our prototype experience and knowledge. I hope others will do so as well. Harry Lewis - IBM Printing Systems From STUART at KEI-CA.CCMAIL.CompuServe.COM Wed Mar 26 19:48:13 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <5030100000977272000002L022*@MHS> Jay, Kyocera is in the process of developing a Job Monitoring MIB which will be heavily influenced by the JMP effort. Stuart Rowley ______________________________ Reply Separator _________________________________ Subject: JMP> Calling all Job Monitoring MIB prototypers... Author: INTERNET:jkm@underscore.com at CSERVE Date: 3/26/97 2:03 PM Can we have a public "show of hands" of those persons/companies actively engaged in developing one or more prototypes of the Job MIB? I know there are at least a few companies that have been involved in developing their own, proprietary Job-like MIBs, but how many folks out there are actually working on developing an implementation of the Job MIB as it is currently defined? Given that sooo much time has been spent on this effort, it would be nice to know that we are not merely working on a "paper" design after all these years. Thanks in advance. ...jay From walker at dazel.com Thu Mar 27 10:19:11 1997 From: walker at dazel.com (Jim Walker) Date: Wed May 6 14:00:02 2009 Subject: JMP> Directions to DAZEL for Upcoming Meetings Message-ID: <333A8FEF.3CBC@dazel.com> Per request, I have just posted directions to DAZEL's offices on the PWG site, ftp://ftp.pwg.org/pub/pwg/general/misc/DazelMap.doc ftp://ftp.pwg.org/pub/pwg/general/misc/DazelMap.ps If anyone could load a PDF, I am sure that the community at large would appreciate it. Just a note... our reception area is on the 11th floor, and the room that we will be meeting in is on the 10th floor. If you manage to find your way to either floor, someone will get you to the right place. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From bpenteco at boi.hp.com Thu Mar 27 14:15:07 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... Message-ID: <01BC3AA8.8468AAE0@hpb15767.boi.hp.com> HP is very interested in how the Job Monitoring MIB works with our proprietary MIB solution. We have been putting in time and effort to make sure we would not loose functionality if we convert from our proprietary solution to the standard solution. However, it is HP's policy to not discuss projects that may or may not be under development. Bob Pentecost HP ---------- From: JK Martin[SMTP:jkm@underscore.com] Sent: Wednesday, March 26, 1997 5:18 AM To: jmp@pwg.org Subject: JMP> Calling all Job Monitoring MIB prototypers... Can we have a public "show of hands" of those persons/companies actively engaged in developing one or more prototypes of the Job MIB? I know there are at least a few companies that have been involved in developing their own, proprietary Job-like MIBs, but how many folks out there are actually working on developing an implementation of the Job MIB as it is currently defined? Given that sooo much time has been spent on this effort, it would be nice to know that we are not merely working on a "paper" design after all these years. Thanks in advance. ...jay From lpyoung at lexmark.com Thu Mar 27 16:53:51 1997 From: lpyoung at lexmark.com (Lloyd Young) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <199703272155.AA06117@interlock.lexmark.com> Lexmark is not actively engaged in developing a prototype of the Job MIB because we currently monitor jobs utilizing IEEE 1284.1. We are spending time reviewing the Job MIB to ensure that it contains the objects that we monitor today. While I can not directly comment on future product plans, we are potentially interested in the Job MIB for a future implementation. Lloyd Young Lexmark ----------------- Original message ------------------- To: jmp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Lloyd Young) From: jkm @ underscore.com (JK Martin) @ interlock.lexmark.com @ SMTP Date: 03/26/97 12:17:36 PM Subject: JMP> Calling all Job Monitoring MIB prototypers... Can we have a public "show of hands" of those persons/companies actively engaged in developing one or more prototypes of the Job MIB? I know there are at least a few companies that have been involved in developing their own, proprietary Job-like MIBs, but how many folks out there are actually working on developing an implementation of the Job MIB as it is currently defined? Given that sooo much time has been spent on this effort, it would be nice to know that we are not merely working on a "paper" design after all these years. Thanks in advance. ...jay From hastings at cp10.es.xerox.com Fri Mar 28 13:12:45 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9703281815.AA03115@zazen.cp10.es.xerox.com> At 13:07 03/26/97 PST, Harry Lewis wrote: >IBM started prototyping the PWG Job MIB and is now working on what I would call >a "hybrid" of that MIB. If I can get my act together soon enough, I hope to >have some time on the JMP agenda next week to present our findings as a result >of this prototype, the alternate paths we've taken and why. > >Not only have we found it necessary to simplify our design (which, admittedly >is specific to printers, not servers) but, in thinking hard about who will use >each object and what for, we've made some changes that we feel enhance the >operation of the MIB. > >I sent e-mail outlining some of our findings a few weeks back but received very >little response. I've taken that as a sign that, perhaps, everyone is focused >on IPP and loosing interest in the Job MIB. Therefore, I appreciate your query. >If there are only a small set of companies interested in the Job MIB, now, >perhaps we can reach consensus about the scope and complexity. I am willing >(and hope to be ready) to share our prototype experience and knowledge. I hope >others will do so as well. > >Harry Lewis - IBM Printing Systems > Harry, Sorry not to respond a few weeks ago to your mail, but IPP, and geting the Job Monitoring MIB ready for the Internet-Draft has taken all my time. Its clear from the responses to Jay's query, that there is real interest in the Job Monitoring MIB. I think your ideas on adding a mapping table that an application can use to find a specified job without having to copy the entire job table is the biggest issue left. I encourage you to come to the meeting with your ideas and make a presentation. Something like adding a table that has an index that is the identifier that the client knows about. The hard part is getting such an identifier from the client through the server into the printer where the printer agent could put it into a table with an index that the monitoring application can use in a single get. Perhaps the monitoring application only gets back the jmJobIndex and has to do one more get to get all the data. So its an additional mapping table. Thanks, Tom From harryl at us.ibm.com Fri Mar 28 13:55:06 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:02 2009 Subject: JMP> IBM "hybrid" Job MIB proposal Message-ID: <5030100001024550000002L002*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems To provide as much preview as possible, I have uploaded a copy of my presentation to ftp://ftp.pwg.org/pub/jmp/contributions/pwgjm.pdf This is meant to be a simple, high-level view of the job MIB changes we are recommending as a result of our prototyping of the PWG Job MIB. It's not a "spec", but I hope it provides enough information so you don't feel I'm coming into the JMP meeting with totally foreign material. I intend to have a MIB that compiles available prior to the meeting on Friday. The 2 main areas we have changed are the JobID and JobState tables. The General and Accounting tables are intended to be identical to the PWG although I may not have tracked every recent change. I welcome comment and discussion although I will be away from the office now until Monday. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Fri Mar 28 16:59:21 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Internet Draft for Job Monitoring MIB posted Message-ID: <9703282201.AA03311@zazen.cp10.es.xerox.com> I've posted the Internet Draft that I sent to the IETF on our server: ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 314206 Mar 28 21:26 draft-ietf-printmib-job-monitor-00.pdf -rw-r--r-- 1 pwg pwg 288707 Mar 28 21:19 draft-ietf-printmib-job-monitor-00.txt The .pdf is identical to the .txt file, except the .pdf file has line numbers that start over on each page. Both are in fixed pitch font as required by the IETF. (I did not send the .pdf to the IETF, since I was told they don't accept PDF). I submitted a garbled version in time for the deadline last Wednesday, with a request to replace it with the cleaned-up versions that I just posted. We will have to wait to see whether the IETF will allow that substitution. I will post later today, the pretty versions with and without change bars and a revision history. Also I'll post the issues list, which should be what we focus on in our upcoming JMP meeting. I'll try to include the issues from the mailing list, especially, Harry's idea about making it easy for a monitoring application to find a particular job and HP's issue about how each of the objects is used in the three configurations we are trying to support. The .txt file compiles with one error: the jmAttributeTypeIndex is not-accessible, but the Conformance section has the sheetsCompleted attribute listed as mandatory in the conformance. But not-accessible objects aren't in a group, and so cannot be referenced in a conformance clause. So we need to change the MAX-ACCESS from not-accessible to read-only, in spite of SMIv2 strongly recommending that indexes be not-accessible. I compiled with SMICng compiler against the 14xx series SMI, not the 19xx. It caught the above error. I also compiled with the Epilogue and MOSY compilers and they found no errors. They all warned about the definition of the temp object to get the experimental OID, but I guess we have to live with that until we are assigned a real OID for the Job Monitoring MIB, went it becomes an RFC. Another enhancement is to use the BITS data type available in the 19xx series SMI for our bit string that defines jmJobStateReasons. I had a huge amount of trouble producing the plain text from the MS-WORD file. It took 17 hours of hand re-formatting to straighten out the garbage that the generic text printer driver produces for tables and page numbers (in footers, and cross-references). The generic text printer driver, 3.10, from FRALC, uses overprinting to get tables and page numbers. So it outputs a CR to reposition the cursor at the beginning of the line and then produces another text string that "overlays" the first. For some table rows, it can do this overlay 3-4 times. Perhaps, just a post processor that merges overlays would be all that is needed. Alternatively, use SAVE AS text with formatting and use a tool to add headers and footers (but not usually in the most pleasing places). Tom From don at lexmark.com Fri Mar 28 17:15:21 1997 From: don at lexmark.com (Don Wright) Date: Wed May 6 14:00:02 2009 Subject: JMP> Internet Draft for Job Monitoring MIB posted In-Reply-To: Internet Draft for Job Monitoring MIB posted> Message-ID: <199703282215.AA19615@interlock.lexmark.com> Exchange 3.0 complains that this PDF is damaged. Don To: jmp%pwg.org @ interlock.lexmark.com @ SMTP cc: chrisw%iwl.com @ interlock.lexmark.com @ SMTP (bcc: Don Wright) From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP Date: 03/28/97 01:59:21 PM Subject: JMP> Internet Draft for Job Monitoring MIB posted I've posted the Internet Draft that I sent to the IETF on our server: ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 314206 Mar 28 21:26 draft-ietf-printmib-job-monitor-00.pdf -rw-r--r-- 1 pwg pwg 288707 Mar 28 21:19 draft-ietf-printmib-job-monitor-00.txt The .pdf is identical to the .txt file, except the .pdf file has line numbers that start over on each page. Both are in fixed pitch font as required by the IETF. (I did not send the .pdf to the IETF, since I was told they don't accept PDF). I submitted a garbled version in time for the deadline last Wednesday, with a request to replace it with the cleaned-up versions that I just posted. We will have to wait to see whether the IETF will allow that substitution. I will post later today, the pretty versions with and without change bars and a revision history. Also I'll post the issues list, which should be what we focus on in our upcoming JMP meeting. I'll try to include the issues from the mailing list, especially, Harry's idea about making it easy for a monitoring application to find a particular job and HP's issue about how each of the objects is used in the three configurations we are trying to support. The .txt file compiles with one error: the jmAttributeTypeIndex is not-accessible, but the Conformance section has the sheetsCompleted attribute listed as mandatory in the conformance. But not-accessible objects aren't in a group, and so cannot be referenced in a conformance clause. So we need to change the MAX-ACCESS from not-accessible to read-only, in spite of SMIv2 strongly recommending that indexes be not-accessible. I compiled with SMICng compiler against the 14xx series SMI, not the 19xx. It caught the above error. I also compiled with the Epilogue and MOSY compilers and they found no errors. They all warned about the definition of the temp object to get the experimental OID, but I guess we have to live with that until we are assigned a real OID for the Job Monitoring MIB, went it becomes an RFC. Another enhancement is to use the BITS data type available in the 19xx series SMI for our bit string that defines jmJobStateReasons. I had a huge amount of trouble producing the plain text from the MS-WORD file. It took 17 hours of hand re-formatting to straighten out the garbage that the generic text printer driver produces for tables and page numbers (in footers, and cross-references). The generic text printer driver, 3.10, from FRALC, uses overprinting to get tables and page numbers. So it outputs a CR to reposition the cursor at the beginning of the line and then produces another text string that "overlays" the first. For some table rows, it can do this overlay 3-4 times. Perhaps, just a post processor that merges overlays would be all that is needed. Alternatively, use SAVE AS text with formatting and use a tool to add headers and footers (but not usually in the most pleasing places). Tom From jkm at underscore.com Fri Mar 28 19:44:31 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <199703290044.TAA06009@uscore.underscore.com> Tom, You wrote: > Its clear from the responses to Jay's query, that there is > real interest in the Job Monitoring MIB. Interest, yes. Work on a real prototype, NO. Note that everyone made comments to the effect of either: "We're working on a job MIB, and watching what's happening." or perhaps: "The job MIB we're developing is ``heavily influenced'' by the Job MIB" No one actually said they were prototyping an implementation that actually follows the specification as it stands now. Note that I *explicitly* asked this question in my message: "I know there are at least a few companies that have been involved in developing their own, proprietary Job-like MIBs, but how many folks out there are actually working on developing an implementation of the Job MIB as it is currently defined?" If there is so much effort being expended on job MIB-related work, why is no one actually trying to prototype the proposed spec? Does anyone have an answer to that question? Oh, and Tom, by the way. How is Xerox's Job MIB prototyping effort going? I didn't see a "show of hands" from the Xerox camp. Can you tell us how you're doing on your prototype? ...jay From hastings at cp10.es.xerox.com Fri Mar 28 20:34:56 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> More readable Job Monitoring MIB and other info posted Message-ID: <9703290137.AA03428@zazen.cp10.es.xerox.com> I've posted the other forms of the Job Monitoring MIB in: ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 120628 Mar 29 01:29 jmp-mib.mib -rw-r--r-- 1 pwg pwg 414326 Mar 29 01:26 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 458240 Mar 29 01:09 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 458389 Mar 29 01:16 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 466991 Mar 29 01:22 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 5955 Mar 29 01:27 jmp.dic -rw-r--r-- 1 pwg pwg 13312 Mar 29 01:26 mibvaria.dot These forms use the more readable Times Roman outside the BEGIN/END. The jmp-mibr.doc is the MS-WORD file with revision marks since V0.7, dated 3/14/97 that went into making the Internet Draft (V0.71), dated 3/26/97. I also added the change history for V6 to V7 and V7 to V7.1 (included in this mail message as well). The jmp-mibr.* stands for with Revision marks. jmp-mib.pdf is without revision marks and corresponds to the Internet Draft. jmp-mib.mib is the compilable BEGIN/END block of the MIB stripped of headers and footers. jmp-mibr.doc is the MS-WORD 6.0 source for V0.71 with revision marks. jmp-mibr.pdf is the PDF form with (BLACK) revision marks. jmp-mibr.pdr is the PDF form with RED revisin marks. jmp.dic is the spelling dictionary mibvaria.dot is the job template with TimesRoman fonts for the styles that are used outside the BEGIN/END block. The line numbers run continuously throughout the document, while in the Internet Draft, they start over at each page in order to make them fit and to make them distinguishable from this file, since now we have two versions of the clean MIB, with line numbers: the Internet Draft and the jmp-mib file. The Internet Draft does not have the change history and does not have the cover page. In theory, the Internet Draft is produced by deleting some sections from jmp-mibr.doc and attaching mibfixed.dot, instead of mibvaria.dot. Unfortunately, MS-WORD and the generic text printer driver conspire to make it much more difficult. The generic text printer driver uses overstriking to generate page numbers, cross references and table entries. A simple post processor that merges overstrikes (lines separate by CR, instead of LF or CRLF), would make it easy to use MS-WORD to generate and maintain MIBs. I'll publish the list of remaining issues shortly for our upcoming JMP meeting next week in Austin, Friday April 4. I'll also try to respond to the mail messages to indicate whether I put something into the document or added it to the issues list. Send any comments to the jmp@pwg.org DL. Thanks, Tom 18. Change History (not to be included in the Internet Draft) All future changes will be recorded here in reverse chronological order by version. 18.1 Changes to version 0.7, dated 3/13/97 to make version 0.71, dated 3/26/97 1. Made the formatting changes necessary to make an Internet Draft. 2. Replaced Figure 1 with a Job State Transition table. 3. Clarified that an agent shall not return an SNMP error for an instrumented object, but shall return the identifies distinguished value. 4. Removed the IMPORT for PrtInterpreterLangFamilyTC, since the MIB doesn't acutally use this enum. In fact no enums used in the Attributes table actually need their enum TC imported into the Job Monitoring MIB, making the Job Monitoring MIB more extensible for adding new attributes that have textual conventions. The MIB now imports very little. Only DateAndTime, because it is used in the Queue table. Even the TimeStamp TC which is used in the attribute table, need not be imported into the Job Monitoring MIB. 5. Explained why there is both a jmJobState and a jmJobStateReasons object: so that the reasons can be extended without the monitoring application becoming confused as to what is happening, since the states won't be extended. 6. Clarified that retained is an optional state and its relationship to the completed state. Added conformance that only the processing, needsAttention, and completed states are required for conformance. 7. Changed the name of the jmAttributeValueAsText object to jmAttributeValueAsOctets, since the DateAndTime type is binary, not text. Changed the tag in the TC from "Text:" to "Octets". 8. Changed the name of the mediaConsumed(33) to mediumConsumed(33), since each entry is singular. 18.2 Changes to version 0.6, dated 1/23/97 to make version 0.7, dated 3/13/97 Changes to version 0.6, dated 1/23/97 to make version 0.7, dated 1/29/97: 1. Added PWG agreed boiler plate Status of this Memo. 2. Updated the Abstract from Ron's comments. 3. Incorporated Ron's re-written Introduction. 4. Explained the job set concept as representing a queue within a printer or a server, if the printer or server has several or the entire set of jobs, if the printer or server has only one queue. 5. Introduced the terminology of "attribute" instead of resource, since our table represents more than just resources now, as we agreed to move many non-resource objects into it. Changed the name of the group and table from jmResource to jmAttribute. 6. Clarified that the JmAttributesTypeTC and jmAttributesTable contains information about the job, such as file name, document name, , as well as resources requested and/or consumed. Re-organized the attributes into groups of similar attributes. 7. Added more explanation about configuration 1 and 2 and added Configuration 3 as agreed to cover the case of a monitoring application that monitors a server not using SNMP while also monitoring using our MIB the printer(s) that the server controls. 8. Added more explanation of the security, internationalization, and IANA considerations. 9. Deleted the Job Set Group, since the monitoring application can find all the job sets via a Get. 10. Removed the jmResourceUnits object and specified the units in each jmAttributeTypeIndex enum. This makes it clearer what the units are and reduces the variability between agent implementations, thus making monitoring applications easier. Also cleanup the attribute names by adding the data type to the attribute name for those attributes that have more than one type that differs in the units (Index vs Name, Name vs. Enum, DateAndTime vs TimeStamp). 11. Added the TimeStamp data type as an alternative to DateAndTime and doubled the number of attributes that have to do with time. 12. Deleted the JmQueuingAlgorithmTC and RmResourceUnitsTC textual-conventions. 13. Added other(1) and unknown(2) to the JmJobTypesTC and moved the rest of the bits over. 14. Added other(1) to the JmJobStatesTC. 15. Added jobPrinting(45) to the JmJobStateReasonsTC to align with IPP. 16. Move 9 objects from the jmJobTable to the JmAttributeTypeTC and jmAttributeTable, making them attributes: jobAccountName, jobComment, jobSourceChannelIndex, physicalDeviceName, jobTotalKOctets, jobKOctetsCompleted, jobSubmissionDateAndTime, jobSubmissionTimeStamp, jobStartedProcessingDateAndTime, jobStartedProcessingTimeStamp, jobCompletionDateAndTime, jobCompletionTimeStamp. NOTE that some objects became two attributes as we have two forms of time. Also made the end of each name indicate the data type. 17. Added Requested, Completed, and CompletedCurrentCopy forms for impressions, sheets, and pages attributes. 18. Added: other(1), outputBin(9) attributes. 19. Added "CPU" to processingCPUTime attribute. 20. Added jmGeneralJobSetName so that the user could associate a name with a job set when the implementation had more than one job set. The name would typically be the queue name in such a case. 21. Added jmGeneralNumberOfJobsCompleted and renamed jmGeneralCurrentNumberOfJobs to jmGeneralNumberOfJobsToComplete, so that a monitoring application can find out how many jobs have completed for the jmCompletedTable and how many are still to be comppleted. Their sum in the total number of jobs in the jmJobTable. 22. Clarified that jmQueueIndex shall be monitonically increasing which can change as new job arrive or the configuration changes. 23. Added the word Queue to make jmQueueJobIndex in the Queue table. 24. Clarifed that the jmQueueJobIndex and jmJobIndex shall not be 0 as required by SNMP for indexes. This gives agents that want to use the job-identifier that is generated by the system as the value for the jmJobIndex and jmQueueJobIndex a problem, if 0 is a legal value, such as in LPD. 25. Clarified the distinction betwen jmJobName and jmJobComment (now jobComment attribute): jmJobName is more of a name for identificaion purposes while jobComment is free form text that often isn't present and is intended to convey anything the submitting user wanted to convey usually to him/herself. 26. Clarified that -2 (unknown) shall be returned if the value of jmJobIndexNumber is unknown as in the Printer MIB convention. 27. Added "OrQueue" to make jmJobDeviceNameOrQueueRequested, since some didn't know which object to use for a system in which the user specifies a queue. 28. Added upper bound in jmJobIndex so that the MIB would compile. 29. Added "Index" to make jmAttributeTypeIndex object, since this object is both a type and an index. 30. Changed the name of the jmResourceIndex to jmAttributeInstanceIndex, since this index can be used for attributes that can have more than one instance per job, such as fileName, documentFormat, outputBin, etc. 31. Clarified that the jmAttributeInstanceIndex shall be the document number for those attributes that are one to one with a document, such as fileName(3) and documentName(4). 32. Replaced the jmResourceAmount with jmAttributeValueAsInteger and jmAttributeValueAsText From hastings at cp10.es.xerox.com Fri Mar 28 20:51:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9703290153.AA03443@zazen.cp10.es.xerox.com> Jay, You ask some good questions here. We need to discuss what is needed to make the Job Monitoring spec be the thing that is being prototyped. Lets put this discussion on the JMP agenda for next week? 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? Another reason is that, as HP points out, we need to better understand how each object is used with each job submission protocol and in each of the configurations that we are trying to support. How can we make better progress on this part? I'll be glad to document the understandings in the spec, so that they can be tested during interoperability testing. Of course, another reason may be that the committee keeps evolving the spec with each meeting, so that it is a moving target. Is this a problem? Except for the remaining issues, I think we are reaching more stability. We keep removing objects, so that now we are down to only 21 mandatory objects (but we have 45 attributes, that are conditionally manatory: you implement them if you got them). Xerox has its own job monitoring MIB as well with its own solutions to the above. Xerox would like to implement the IETF spec when it is stablized. Tom At 16:44 03/28/97 PST, JK Martin wrote: >Tom, > >You wrote: > >> Its clear from the responses to Jay's query, that there is >> real interest in the Job Monitoring MIB. > >Interest, yes. Work on a real prototype, NO. > >Note that everyone made comments to the effect of either: > > "We're working on a job MIB, and watching what's happening." > >or perhaps: > > "The job MIB we're developing is ``heavily influenced'' by the Job MIB" > >No one actually said they were prototyping an implementation that actually >follows the specification as it stands now. Note that I *explicitly* >asked this question in my message: > > "I know there are at least a few companies that have been involved in > developing their own, proprietary Job-like MIBs, but how many folks > out there are actually working on developing an implementation of > the Job MIB as it is currently defined?" > >If there is so much effort being expended on job MIB-related work, >why is no one actually trying to prototype the proposed spec? > >Does anyone have an answer to that question? > >Oh, and Tom, by the way. How is Xerox's Job MIB prototyping effort >going? I didn't see a "show of hands" from the Xerox camp. Can you >tell us how you're doing on your prototype? > > ...jay > > From hastings at cp10.es.xerox.com Fri Mar 28 20:58:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:02 2009 Subject: JMP> Internet Draft for Job Monitoring MIB posted In-Reply-To: Internet Draft for Job Monitoring MIB posted> Message-ID: <9703290200.AA03451@zazen.cp10.es.xerox.com> Thanks Don, I transmitted it in ASCII, instead of BINARY Mode with FTP. I've reposted it about 3:30 pm PST. So if people copied it after that, it should be ok. BTW, when I noticed what I had done, I retrieved it and it seemed to work ok though. Sorry, Tom At 14:15 03/28/97 PST, Don Wright wrote: >Exchange 3.0 complains that this PDF is damaged. > >Don > > >To: jmp%pwg.org @ interlock.lexmark.com @ SMTP >cc: chrisw%iwl.com @ interlock.lexmark.com @ SMTP (bcc: Don Wright) >From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP >Date: 03/28/97 01:59:21 PM >Subject: JMP> Internet Draft for Job Monitoring MIB posted > >I've posted the Internet Draft that I sent to the IETF on our server: > >ftp.pwg.org/pub/pwg/jmp/internet-drafts/ > >-rw-r--r-- 1 pwg pwg 314206 Mar 28 21:26 draft-ietf-printmib-job-monitor-00.pdf >-rw-r--r-- 1 pwg pwg 288707 Mar 28 21:19 draft-ietf-printmib-job-monitor-00.txt > >The .pdf is identical to the .txt file, except the .pdf file has line numbers >that start over on each page. Both are in fixed pitch font as required >by the IETF. (I did not send the .pdf to the IETF, since I was told they >don't accept PDF). > >I submitted a garbled version in time for the deadline last Wednesday, >with a request to replace it with the cleaned-up versions that I just >posted. We will have to wait to see whether the IETF will allow that >substitution. > >I will post later today, the pretty versions with and without change bars >and a revision history. Also I'll post the issues list, which should >be what we focus on in our upcoming JMP meeting. I'll try to include the >issues from the mailing list, especially, Harry's idea about making it >easy for a monitoring application to find a particular job and HP's >issue about how each of the objects is used in the three configurations >we are trying to support. > >The .txt file compiles with one error: the jmAttributeTypeIndex is >not-accessible, but the Conformance section has the sheetsCompleted attribute >listed as mandatory in the conformance. But not-accessible objects aren't in >a group, and so cannot be referenced in a conformance clause. So we >need to change the MAX-ACCESS from not-accessible to read-only, in spite >of SMIv2 strongly recommending that indexes be not-accessible. > >I compiled with SMICng compiler against the 14xx series SMI, not the 19xx. >It caught the above error. I also compiled with the Epilogue and MOSY >compilers and they found no errors. > >They all warned about the definition of the temp object to get the >experimental OID, but I guess we have to live with that until we are assigned >a real OID for the Job Monitoring MIB, went it becomes an RFC. > >Another enhancement is to use the BITS data type available in the 19xx series >SMI for our bit string that defines jmJobStateReasons. > >I had a huge amount of trouble producing the plain text from the MS-WORD >file. It took 17 hours of hand re-formatting to straighten out the garbage >that the generic text printer driver produces for tables and page numbers >(in footers, and cross-references). >The generic text printer driver, 3.10, from FRALC, uses overprinting to get >tables and page numbers. So it outputs a CR to reposition the cursor at the >beginning of the line and then produces another text string that "overlays" >the first. For some table rows, it can do this overlay 3-4 times. > >Perhaps, just a post processor that merges overlays would be all that is >needed. Alternatively, use SAVE AS text with formatting and use a tool >to add headers and footers (but not usually in the most pleasing places). > >Tom > > > > > From hastings at cp10.es.xerox.com Fri Mar 28 21:27:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Here is the TOC and INDEX from the Internet Draft Message-ID: <9703290229.AA03459@zazen.cp10.es.xerox.com> The Table of Contents will help us get a summary view of the MIB objects and attributes. The INDEX helps look up objects and attributes given the name. 13. MIB specification 39 Textual conventions for this MIB module 41 JmJobServiceTypesTC - bit encoded job service type definitions 41 JmJobStateTC - job state definitions 43 JmJobStateReasonsTC - additional information about job states 47 JmAttributeTypeTC - attribute type definitions 60 other 60 fileName 60 documentName 61 jobAccountName 61 jobComment 61 processingMessage 61 jobSourceChannelIndex 61 outputBinIndex 62 outputBinName 62 sides 62 documentFormatIndex 62 documentFormatEnum 63 physicalDeviceIndex 63 physicalDeviceName 64 jobCopiesRequested 64 jobCopiesCompleted 64 documentCopiesRequested 64 jobKOctetsTotal 64 jobKOctetsCompleted 66 impressionsSpooled 67 impressionsSentToDevice 67 impressionsInterpreted 67 impressionsRequested 67 impressionsCompleted 67 impressionsCompletedCurrentCopy 67 pagesRequested 67 pagesCompleted 67 pagesCompletedCurrentCopy 67 sheetsRequested 68 sheetsCompleted 68 sheetsCompletedCurrentCopy 68 mediumRequested 68 mediumConsumed 68 colorantRequestedIndex 69 colorantRequestedName 69 colorantConsumedIndex 69 colorantConsumedName 69 jobSubmissionDateAndTime 70 jobSubmissionTimeStamp 70 jobStartedProcessingDateAndTime 70 jobStartedProcessingTimeStamp 70 jobCompletedDateAndTime 70 jobCompletedTimeStamp 70 processingCPUTime 70 The General Group (Mandatory) 72 jmJobSetIndex 73 jmGeneralJobSetName 73 jmGeneralJobCompletedPolicy 73 jmGeneralMaxNumberOfJobs 73 jmGeneralNumberOfJobsToComplete 74 jmGeneralNumberOfJobsCompleted 74 The Queue Group (Conditionally Mandatory) 75 jmQueueIndex 76 jmQueueJobIndex 76 jmQueueNumberOfInterveningJobs 77 jmJobPriority 77 jmJobProcessAfterDateAndTime 77 The Completed Group (Mandatory) 79 jmCompletedIndex 80 jmCompletedJobIndex 80 The Job Group (Mandatory) 81 jmJobIndex 82 jmJobName 82 jmJobIdName 83 jmJobIdNumber 84 jmJobServiceTypes 84 jmJobOwner 85 jmJobDeviceNameOrQueueRequested 85 jmJobCurrentState 85 jmJobStateReasons 86 The Attribute Group (Mandatory) 88 jmAttributeTypeIndex 90 jmAttributeInstanceIndex 91 jmAttributeValueAsInteger 91 jmAttributeValueAsOctets 92 Here is the INDEX: 19. INDEX This index includes the textual conventions, the objects, and the attributes. Textual conventions all start with the prefix: "JM" and end with the suffix: "TC". Objects all starts with the prefix: "jm" followed by the group name. Attributes are identified with enums, and so start with any lower case letter and have not special prefix. --- jmGeneralJobSetName, 73, 97 C jmGeneralMaxNumberOfJobs, 73, 98 --- jmGeneralNumberOfJobsCompleted, colorantConsumedIndex, 69 74, 98 colorantConsumedName, 69 jmGeneralNumberOfJobsToComplete, colorantRequestedIndex, 69 74, 98 colorantRequestedName, 69 jmJobCurrentState, 85, 109 --- jmJobDeviceNameOrQueueRequested, D 85, 108 --- jmJobIdName, 83, 105 documentCopiesRequested, 64 jmJobIdNumber, 84, 106 documentFormatEnum, 63 jmJobIndex, 82, 103 documentFormatIndex, 62 jmJobName, 82, 104 documentName, 61 jmJobOwner, 85, 107 --- jmJobPriority, 77, 100 F --- jmJobProcessAfterDateAndTime, 77, fileName, 60 jmJobServiceTypes, 84, 106 JmJobServiceTypesTC, 41 --- I jmJobSetIndex, 73, 97 --- jmJobStateReasons, 86, 114 impressionsCompleted, 67 JmJobStateReasonsTC, 47 impressionsCompletedCurrentCopy, JmJobStateTC, 43 67 jmQueueIndex, 76, 99 impressionsInterpreted, 67 jmQueueJobIndex, 76, 99 impressionsRequested, 67 jmQueueNumberOfInterveningJobs, impressionsSentToDevice, 67 77, 99 impressionsSpooled, 67 jobAccountName, 61 --- jobComment, 61 J jobCompletedDateAndTime, 70 --- jobCompletedTimeStamp, 70 jmAttributeInstanceIndex, 91, 139 jobCopiesCompleted, 64 jmAttributeTypeIndex, 90, 115 jobCopiesRequested, 64 JmAttributeTypeTC, 60 jobKOctetsCompleted, 66, 127 jmAttributeValueAsInteger, 91, jobKOctetsTotal, 64, 126 139 jobSourceChannelIndex, 61 jmAttributeValueAsOctets, 92, 139 jobStartedProcessingDateAndTime, jmCompletedIndex, 80, 102 70 jmCompletedJobIndex, 80, 102 jobStartedProcessingTimeStamp, 70 jmGeneralJobCompletedPolicy, 73, jobSubmissionDateAndTime, 70 98 jobSubmissionTimeStamp, 70 --- pagesCompleted, 67 M pagesCompletedCurrentCopy, 67 --- pagesRequested, 67 mediumConsumed, 68 physicalDeviceIndex, 63 mediumRequested, 68 physicalDeviceName, 64 --- processingCPUTime, 70 O processingMessage, 61 --- --- other, 60 S outputBinIndex, 62 --- outputBinName, 62 sheetsCompleted, 68 --- sheetsCompletedCurrentCopy, 68 P sheetsRequested, 68 --- sides, 62 From jkm at underscore.com Sat Mar 29 12:35:03 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <199703291735.MAA06953@uscore.underscore.com> Tom, > You ask some good questions here. We need to discuss what is needed to > make the Job Monitoring spec be the thing that is being prototyped. > Lets put this discussion on the JMP agenda for next week? Regretably, I will not be able to make the Austin meetings. However, I have been in pretty close contact with Harry Lewis about most of these issues, and I believe Harry can accurately state my views in my absense. --- NOTE TO AUSTIN-BOUND JOB MIB MEETING ATTENDEES --- Please take a few moments before the Job MIB meeting to read this message, then form your own opinions and (please!) publicly state your opinions at the meeting. The day of reckoning draws near... > 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? It could very well be. Underscore has studied this problem over the last year or so, and it appears to be a very difficult nut to crack. So much so, that we now agree with Harry (and some others) in stating that the Job MIB should be constrained to a simple client-server model...with no intervening print server concept. Just a "client" (server, mgmt app) talking to a "server" (printer, print server). > 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? You can do anything with proprietary MIBs. But that is not the point. We need to create standard MIBs here. A long time ago I passionately argued for a modular approach, whereby the initial Job MIB would be VERY VERY SIMPLE, and that we would then augment that simple MIB to support such things as accounting, etc. That way we could get the SIMPLE MIB out in the marketplace as quickly as possible so as to gain some real operational experience, particularly in order to know exactly what kinds of extensions are truly necessary (ie, "necessary" == "demanded by paying customers"). > Another reason is that, as HP points out, we need to better understand > how each object is used with each job submission protocol and in each > of the configurations that we are trying to support. How can we make > better progress on this part? I'll be glad to document the understandings > in the spec, so that they can be tested during interoperability testing. This paragraph really scares me, Tom. I thought the whole purpose of developing the table of "Existing Protocols Mapped to Job MIB Attributes" was supposed to address this topic. And, please recall (PLEASE), that last November in New Orleans, I pointed out that the Job MIB actually contained attributes for which NO EXISTING PRINT SUBMISSION PROTOCOL SUPPORTS. That is, you had added attributes that do not map to any existing print submission protocol. During that meeting I suggested that we IMMEDIATELY remove those attributes. You did not agree, stating (as usual) that "someone in the future might find a need for those attributes" (or something to that effect). This is sheer lunacy. And the paying marketplace suffers as a result, not to mention the vendors who wish to develop and deliver useful solutions to that marketplace. > Of course, another reason may be that the committee keeps evolving > the spec with each meeting, so that it is a moving target. Is this > a problem? If this weren't so sad, I'd really have to laugh. Tom, YOU are the one who keeps changing the spec! Yes, the group then ends up making more changes...but almost always because your new changes don't map to any known reality in the market-driven world. > Except for the remaining issues, I think we are reaching > more stability. We keep removing objects, so that now we are down to > only 21 mandatory objects (but we have 45 attributes, that are conditionally > manatory: you implement them if you got them). I think everyone should listen to what Harry Lewis is going to present. If the group doesn't buy Harry's approach, then I'd like to propose that Hewlett-Packard submit their Job MIB to the PWG as a new candidate for the official Job MIB (with all HP-proprietary stuff removed, of course). Similarly, any other vendor with a known working solution should be invited to propose their model. > Xerox has its own job monitoring MIB as well with its own solutions to > the above. Xerox would like to implement the IETF spec when it is > stablized. Then why on earth didn't you just propose the solution as developed by Xerox, for heaven's sake?? Why did you constantly view the Job MIB effort as a "fundamental research activity", apparently ignoring any and all existing practice? Tom, you really have quite the ability to generate massive amounts of spec-oriented material. You do that very well, and much of the content is quite interesting. However, it is also clear that, unlike almost all other Job MIB participants, you do not actually develop product. More importantly, since you don't develop product, you have very little sensitivity to the concepts of "time to market" and plain, old fashioned bottom-line responsibility. The Job MIB effort has been going on for close to TWO YEARS now, and it's time to come to closure. IMMEDIATELY. I apologize for the particularly intense flame-o-gram here, but enough is enough. Standards developed by the PWG are intended as a vehicle to promote free enterprise within a level-playing-field environment. The PWG is NOT an altruistic body of interested people, but rather a group of cooperating competitors trying to raise the reference bar for new technologies in an evolutionary manner. Let's close this effort and get to the task of developing products for our customers. ...jay From imcdonal at eso.mc.xerox.com Sun Mar 30 12:19:55 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9703301719.AA04811@snorkel.eso.mc.xerox.com> Hi Jay, I think you have overstepped the mark here. You say that it is clear that Tom Hastings doesn't develop product. That is at best, a half truth. Tom's closest co-workers in the Xerox open system management community include the common client group that I act as system architect for. Within weeks of the first version of the Xerox Job Monitoring MIB (two years ago), our common client team built a live prototype. Joe Filion, who offerred excellent comments on the Printer MIB V2.0 draft recently, is a technical team leader in our common client group. Joe, Tom, and I are in communication every single week. I am puzzled by your objections to the IDEA of the IETF Job Mon MIB. After converging on how to manage a printer DEVICE (which will only happen when the various vendors upgrade to the Printer MIB V2.0 and fix conformance problems found in the recent interop testing), isn't the next natural thing to standardize the management of printer JOBs? Certainly robust job management is the single highest priority that we hear from Xerox marketing and product planning folks, and they're all DELIGHTED that the IETF Job Mon MIB project is in progress and (in the view of many participants) making good headway. The original Printer MIB took several years to complete and advance into the IETF standards process. And experience has taught us all that it clearly needs refinement and clarification. Why not ease up on Tom and the other members of the JMP? Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 From jkm at underscore.com Sun Mar 30 15:24:31 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <199703302024.PAA08877@uscore.underscore.com> Ira, It is unfortunate that you somehow misunderstand some of the major objections I have with the way the Job Monitoring MIB has been progressing. Hopefully this message will serve to improve that understanding. First, it is important for you to recall that you have never been present at any of the JMP meetings. (And believe me, I wish you had been there, at least for some of them.) If you had been to at least *one* of the meetings, I'm confident you would have interpreted my last mail message in a very different way. One sentence you wrote is a bit disturbing: > Why not ease up on Tom and the other members of the JMP? I don't recall making any kind of statements about any of the JMP members other than Tom. In fact, I think the other members are doing an excellent job of persevering through the extraordinarily lengthy process of getting the Job MIB to closure. Another disturbing comment, for which I have no idea how you've reached this opinion: > I am puzzled by your objections to the IDEA of the IETF Job Mon MIB. How did you ever reach this conclusion? Those JMP members who've been attending the JMP meetings all along know very well that your statement does not reflect my opinion about the Job MIB in any way. I am very much in favor of a Job MIB...however, a SIMPLE Job MIB, and not a complex one that attempts to solve all the world's problems in one fell swoop. What *many* of us in the JMP group believe is that the approach taken by Tom has resulted in an overly complicated approach to providing print job-related info via a job MIB. Harry Lewis (IBM) has echoed this position *countless* times over the last several months...yet Tom always seems to totally ignore this serious concern, and continues to propose an object model that does not map very well to existing printing systems. (True, bits and pieces of the Job MIB map to most printing system, but only in a "sparse" sense.) > Within weeks of the first version of > the Xerox Job Monitoring MIB (two years ago), our common client team > built a live prototype. Why didn't Xerox (via Tom or some other Xerox representative) simply propose this Xerox-developed model as a starting point? If you review the history of the JMP Job MIB, you can't help but believe that its development was *not* spawned from real practice, but rather some sort of "fundamental research" approach. Please note that during a break at the JMP meeting in San Jose last December, I specifically asked Tom about how Xerox's efforts were going with prototyping the model he has been championing. His response was that Xerox was not currently attempting to prototype the Job MIB. Perhaps you can now understand my concern about this. > After converging on how to manage a printer DEVICE (which will only > happen when the various vendors upgrade to the Printer MIB V2.0 > and fix conformance problems found in the recent interop testing), > isn't the next natural thing to standardize the management of > printer JOBs? It's interesting you've chosen to draw this sequence of events here, namely "first the Printer MIB, then the Job MIB". Yes, I agree with you, but only in basic premise. You see, after years of developing the Printer MIB, there is a significant number of PMP participants who now believe the Printer MIB itself is too complicated. (Steve Waldbusser, our original IETF advisor and "mentor") repeatedly warned us about going too far in the specification, both in terms of scope and depth. We appeared to have ignored his warnings, and now we're paying the price. Several of us in the JMP group believe the Job MIB has already crossed the line of excessive complexity (quite some time ago), and we're now trying to reign in some of that complexity, using this basic approach: "Start off with a SIMPLE spec to get product in the market and gain experience, then augment that work in the future." However, whenever the group tries to seriously pare down the scope and model of the Job MIB, Tom always seems to ignore these concerns and continues to push on with a "let's get it all in on the first draft" approach. (How many times have we heard Tom say in a JMP meeting "I'd like to revisit XXX..."?) I'm hoping other JMP participants state their views on this topics. This is not meant to be a "bash Xerox" or "bash Tom" effort, but rather a serious plea to SIMPLIFY the spec and come to CLOSURE. The true success of a standards effort is the IMPLEMENTATION of that standard within products available in the marketplace. Many of us in the JMP believe the current model is too complex, and will result in a "sparse" implementation for the average product. Interoperability is key, which usually translates to lots of products offering the same capabilities. As it stands now, the current Job MIB design does not promote this. ...jay From hastings at cp10.es.xerox.com Mon Mar 31 04:29:12 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Issues List posted for I-D (and .71) version Message-ID: <9703310931.AA03630@zazen.cp10.es.xerox.com> I've posted the issues that need to be resolved in our Internet Draft 00 (revision 0.71). The file contains the closed issues as well. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-rw-r-- 1 pwg pwg 29184 Mar 31 09:19 issues.doc -rw-rw-r-- 1 pwg pwg 34494 Mar 31 09:07 issues.pdf -rw-r--r-- 1 pwg pwg 35417 Mar 31 09:08 issues.pdr The .pdr is with red revision marks, and the .pdf is with black revision marks. The agenda for the upcoming meeting in Austin, 4/4, should be dealing with these issues. I see issues 61, 62, and 64 as being the most significant. What we will do with the resolutions to these issues for the meeting the following week at the IETF in Memphis, 4/8, we need to discuss. I've moved contributions that have been covered to the historical sub-directory (but with current dates, unfortunately). Here is a copy of the open issues. See the complete file for the open and close issues with revision marks. Subj: Issues from Job Monitoring MIB, version 0.71, dated 3/26/97 From: Tom Hastings Date: 3/28/97 File: issues.doc This file will be our standing list of open and closed issues for the Job Monitoring MIB. The open issues are in the first section, the closed issues that have not been reflected in the current draft are in the second section and the closed issues are in the third section (third section not attached). When an issue is closed, I indicate the resolution and why and move the issue to the closed section. Revision marks show changes from the 2/28/97 version of the issues list. When I move an issue from Open to Closed, I only show the revision marks of what changed, not the movement itself. This version of the issues list includes issues that are in the Internet Draft 00 (same as revision 0.71) that need to be resolved. I've updated the issues with the agreements reached at the JMP meeting, 2/7/97 and the reasons behind the resolutions. If you object to any of the proposed resolutions to the issues, please send e-mail. 1. Open Issues Issue 32 - Shouldn't we require any numeric portion of the client-side identifiers to always be in the jmJobIdNumber object? ACTION ITEM (Tom Hastings): Send e-mail on this proposal. Issue 45 - After fully agreeing on what a Job Set is, should the name remain Job Set, or be changed to Queue, or Job Pool or Job Group to improve understandability? The new jmGeneralJobSetName would also be changed to jmGeneralQueueName, or jmGeneralJobPoolName, or jmGeneralJobGroupName. See the Internet Draft 00 and version 0.71. Issue 48 - Since jmJobIndex cannot be 0 according to SNMP rules for indexes, what shall an agent do that is instrumenting a printer or server that uses 0 as a valid job-identifier? Use largest positive integer for job 0? Or the agent map the 0 value to the value that is one higher than the maximum that the server or printer uses? Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object can have and the roll over to 1 happens for the next job received? Or add jmGeneralMaxJobIndex as another object in the General table? Then the monitoring application would know what the roll over limit would be. For agents that instrument servers or printers that use a job identifier of 0, the actual maximum number would be one more than the actual job identifier that the server or printer generates. So for LPD, the value of jmGeneralMaxJobIndex would by 1000, not 999. The current definition of jmGeneralMaxNumberOfJobs is: jmGeneralMaxNumberOfJobs OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of queued and completed jobs that this server or print can support at the same time. The value (-1) indicating other shall indicate that there is no fixed limit." ::= { jmGeneralEntry 4 } What is the purpose of jmGeneralMaxNumberOfJobs as currently defined? ISSUE 51 - Should the jmJobCurrentState (and JmJobStateTC) be changed from a type 2 enum to a type 1 enum, since adding states would have serious impact on released clients? Currently the IPP draft has the job-state and printer-state attributes defined as type 1 enums (actually they've changed the terminology, but not the concept, to keyword). ISSUE 52- Should JmJobStateReasonsTC and JmJobServiceTypesTC be defined using the RFC 1902 BITS built-in? JmJobStateReasonsTC is 540 bits, while JmJobServiceTypesTC is only 31 bits. ISSUE 53 - Should there be an object that specifies the current default coded character set of the Job Monitoring MIB, so that the client can figure out how to interpret objects of type OCTET STRING that are coded characters, in case the client might not be configured the same as the server or printer? See Section 6 in the Internet Draft 00 and revision 0.71 for the discussion of coded character sets, including the use of Unicode/ISO 10646. ISSUE 54 - Should we move all of the objects in the jmJobTable (9 objects) into the jmAttributeTable as enums and then specify some of them to be required for implementation? What about the jmQueueTable (6 objects)? What about the jmCompletedTable (3 objects)? This would reduce the number of required objects from 21 mandatory objects and 6 conditionally mandatory objects to just 9 mandatory objects and no conditionally mandatory objects. ISSUE 55 - Should we remove the needsAttention state to align with IPP (and DPA)? The printer-stopped job-state-reasons value from IPP has already been added to the JmJobStateReasonsTC, so that the user will be able to find out that the job that is processing has a printer stopped. ISSUE 56 - Which of the jmJobTable entries that were moved to the jmAttributeTable should be mandatory enums, if any? They were all mandatory when they were in the jmJobTable. 1. physicalDeviceName (or physicalDeviceIndex) 2. jobSourceChannelIndex 3. jobSubmissionDateAndTime or jobSubmissionTimeStamp 4. jobComment 5. jobKOctetsTotal 6. jobKOctetsCompleted 7. jobStartedProcessingDateAndTime or jobStartedProcessingTimeStamp 8. jobCompletedDateAndTime or jobCompletedTimeStamp 9. jobAccountName Or should we move any mandatory attributes, such as sheetsCompleted back to the jmJobTable, so that the attributes table contains no mandatory attributes, only conditionally mandatory attributes and the jmJobTable is the place that we put the mandatory information? ISSUE 57 - OK to change jmAttributeTypeIndex from not-accessible to read-only, so that it can be mentioned in the conformance clause where we specify that sheetsCompleted is the only attribute that is mandatory (so far). Currently the Internet Draft and version 0.71 get a compile error when attempting to mention an enum that is mandatory for an object that is not listed in the conformance clause. Objects that are not-accessible cannot be mentioned in the conformance clauses, but read-only can, since they (jmAttributeTypeIndex) would also get added to the list of objects in the group. Issue 58 - OK that sides, documentFormat, and physicalDeviceIndex/Name, remain as the only attributes that are both requested and used at the same time (with the same instance in the jmAttributeTable) as suggested in Ron's EMail of 2/15, or should we make four new attributes that are used/consumed and change the current ones to be requested? Issue 59 - Add the name of the source server or client? As an object or an attribute? See Bob Pentecost EMail of 2/25. Need more specific text for such proposals. Issue 60 - Add the "file name of the job" and a "source port object to tell which client port the job came from"? As objects or attributes? See Bob Pentecost EMail of 2/25. Need more specific text for such proposals. Issue 61 - Need to clarify the semantics of each object and attribute with respect to Configuration 1, 2, and 3. See Bob Pentecost EMail of 3/10 (HP internal review). Most objects refer to the jobs as they exist in the server or printer that the agent embedded in, i.e., is instrumenting. A few objects, represent information that comes from upstream places in the case of configuration 1 from the client, in the case of configuration 2, the client as well, and in the case of configuration 3, the server and maybe even the client as well. Issue 62 - Harry Lewis has a proposal for a mapping table that allows a monitoring application that knows a client identifier to directly address the mapping table with a single get in order to find the jmJobIndex that the printer is using. See 3/5/97 and 3/28/97 EMail and ftp.pwg.org/pub/pwg/jmp/contributions/pwgjm.pdf. Harry will make a presentation at the JMP meeting. Issue 63 - Should we add attributes for inkjet plotters? See EMail from Patrick Powell, of 3/4/97 Issue 64 - Need to fill out Appendix A on mapping from the job submission protocols to the Job Monitoring MIB for each of the three configurations. Issue 65 - What Appendices should remain, which should be separate Internet Drafts and/or informational RFCs and which should disappear? 2. Closed Issues - not yet reflected in the current draft The following issues have been closed and have been incorporated into the Internet Draft 00 and version 0.71 or earlier: Issue 12 - What is the SNMPv1 and SNMPv2 error that an agent shall return if there is no instrumentation for an object? Closed: There is no such SNMP error. ALL uninstrumented objects in mandatory groups of any MIB should always correctly return 'read-only' static values specified in 'DEFVAL' clauses. 'DEFVAL' is a perfectly good SMIv2 feature intended to cover this situation. Returning ANY SNMP error for ANY object in a mandatory group with a legal instance qualifier (i.e., set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol spec (RFC 1905, page 10, in 'Get-Request PDU' handling). That's what 'shall implement ALL the objects in this group' means! So add DEFVAL clauses to all objects. Issue 26 - Which indexes shall be persistent across power off and which need not be? Closed: The persistent indexes shall be: jmJobIndex and jmJobSetIndex From harryl at us.ibm.com Mon Mar 31 10:42:11 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <5030100001059019000002L092*@MHS> 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 From Angelo_Caruso at wb.xerox.com Mon Mar 31 13:05:13 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <" Jay, >> 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? > >It could very well be. Underscore has studied this problem over the >last year or so, and it appears to be a very difficult nut to crack. >So much so, that we now agree with Harry (and some others) in stating >that the Job MIB should be constrained to a simple client-server >model...with no intervening print server concept. Just a "client" >(server, mgmt app) talking to a "server" (printer, print server). I agree that this problem is a tough one to solve. But, I think that constraining the MIB to a simple client to one-server model will result in a MIB that is useless to a huge portion of the existing market. How will the simple model allow Netware-based customers to monitor their jobs as they progress from client to netware print queue to one of perhaps several printers that may service the queue? What good is this MIB if it does not provide a solution for the majority of the non-unix customer base? >> Xerox has its own job monitoring MIB as well with its own solutions to >> the above. Xerox would like to implement the IETF spec when it is >> stablized. > >Then why on earth didn't you just propose the solution as developed by >Xerox, for heaven's sake?? Why did you constantly view the Job MIB >effort as a "fundamental research activity", apparently ignoring any >and all existing practice? In Tom's defense, the original proposal to the PWG by Tom was in fact the Xerox proprietary solution with a very few proprietary objects removed. Thanks, Angelo From hastings at cp10.es.xerox.com Mon Mar 31 16:45:14 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9703312147.AA03801@zazen.cp10.es.xerox.com> Jay, I have some replies to your comments and some diagreements and some differences of opinion on the facts. I'm sorry that you won't be in Austin. Please read my responses carefully. Tom At 09:35 03/29/97 PST, JK Martin wrote: >Tom, > >> You ask some good questions here. We need to discuss what is needed to >> make the Job Monitoring spec be the thing that is being prototyped. >> Lets put this discussion on the JMP agenda for next week? > >Regretably, I will not be able to make the Austin meetings. However, >I have been in pretty close contact with Harry Lewis about most of >these issues, and I believe Harry can accurately state my views in >my absense. > > --- NOTE TO AUSTIN-BOUND JOB MIB MEETING ATTENDEES --- > > Please take a few moments before the Job MIB meeting to read this > message, then form your own opinions and (please!) publicly state > your opinions at the meeting. The day of reckoning draws near... > > >> 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? > >It could very well be. Underscore has studied this problem over the >last year or so, and it appears to be a very difficult nut to crack. >So much so, that we now agree with Harry (and some others) in stating >that the Job MIB should be constrained to a simple client-server >model...with no intervening print server concept. Just a "client" >(server, mgmt app) talking to a "server" (printer, print server). But HP has desmonstrated with their 5si Mopier that there is a solution at least with a Novell server sitting between the client and the printer, correct? That is configuration 3 which I added to the draft, after the JMP agreed to add it. > > >> 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? > >You can do anything with proprietary MIBs. But that is not the point. >We need to create standard MIBs here. I agree we need to come up with standard MIBs and that is what I have been trying to foster. > >A long time ago I passionately argued for a modular approach, whereby >the initial Job MIB would be VERY VERY SIMPLE, and that we would then >augment that simple MIB to support such things as accounting, etc. >That way we could get the SIMPLE MIB out in the marketplace as quickly >as possible so as to gain some real operational experience, particularly >in order to know exactly what kinds of extensions are truly necessary >(ie, "necessary" == "demanded by paying customers"). > > >> Another reason is that, as HP points out, we need to better understand >> how each object is used with each job submission protocol and in each >> of the configurations that we are trying to support. How can we make >> better progress on this part? I'll be glad to document the understandings >> in the spec, so that they can be tested during interoperability testing. > >This paragraph really scares me, Tom. I thought the whole purpose of >developing the table of "Existing Protocols Mapped to Job MIB Attributes" >was supposed to address this topic. Yes, the mapping will help a lot. On the other hand, if each protocol maps to the standard in different ways, a monitoring application will have to know which job submission protocol was used, in order to know how to display the results to its user. I would hope you would agree that such a burden on monitoring applications would be unacceptable, especially since Underscore would be writing monitoring applications that monitor jobs that are submitted with a variety of job submission protocols. For example, if LPd uses the jmJobIdNumber for the job number 0 to 999 and PJL uses jmJobIndex for its job number, your monitoring application will have to know whether the job was submitted by PJL or LPD in order to know what to display to the user as the job identifier. > >And, please recall (PLEASE), that last November in New Orleans, I pointed >out that the Job MIB actually contained attributes for which NO EXISTING >PRINT SUBMISSION PROTOCOL SUPPORTS. That is, you had added attributes >that do not map to any existing print submission protocol. > >During that meeting I suggested that we IMMEDIATELY remove those attributes. >You did not agree, stating (as usual) that "someone in the future might >find a need for those attributes" (or something to that effect). > >This is sheer lunacy. And the paying marketplace suffers as a result, >not to mention the vendors who wish to develop and deliver useful solutions >to that marketplace. Jay, Which objects were you referring to? We have pruned out objects at successive meetings. We have also agreed to keep jmJobServiceType, even though no job submission protocol currently has it, except IDPS. We are down to 21 mandatory objects. Which of those do you want to remove? Please make specific proposals to prune out objects to the DL, rather than complain about the objects that we have not being simple enough. We'll listen. I don't make the decisions either. The JMP team attempts to reach consensus. Ron is the chairman. I'm the editor. > > >> Of course, another reason may be that the committee keeps evolving >> the spec with each meeting, so that it is a moving target. Is this >> a problem? > >If this weren't so sad, I'd really have to laugh. Tom, YOU are the one >who keeps changing the spec! Yes, the group then ends up making more >changes...but almost always because your new changes don't map to any >known reality in the market-driven world. I change the spec as a result of the discussion, not because I feel like changing the spec. > > >> Except for the remaining issues, I think we are reaching >> more stability. We keep removing objects, so that now we are down to >> only 21 mandatory objects (but we have 45 attributes, that are conditionally >> manatory: you implement them if you got them). > >I think everyone should listen to what Harry Lewis is going to present. >If the group doesn't buy Harry's approach, then I'd like to propose that >Hewlett-Packard submit their Job MIB to the PWG as a new candidate for >the official Job MIB (with all HP-proprietary stuff removed, of course). >Similarly, any other vendor with a known working solution should be >invited to propose their model. > > >> Xerox has its own job monitoring MIB as well with its own solutions to >> the above. Xerox would like to implement the IETF spec when it is >> stablized. > >Then why on earth didn't you just propose the solution as developed by >Xerox, for heaven's sake?? Why did you constantly view the Job MIB >effort as a "fundamental research activity", apparently ignoring any >and all existing practice? > Where did you get the idea that it was a "fundamental research activity"? I did submit the Xerox proprietary Job Monitoring MIB a year and a half ago, and its still on your server under jmp/mibs/historical/. See all the files with Oct 26 1995. It even compiles. But the JMP group didn't accept it. The JMP team wanted to develop its own. > >Tom, you really have quite the ability to generate massive amounts of >spec-oriented material. You do that very well, and much of the content >is quite interesting. However, it is also clear that, unlike almost >all other Job MIB participants, you do not actually develop product. >More importantly, since you don't develop product, you have very little >sensitivity to the concepts of "time to market" and plain, old fashioned >bottom-line responsibility. I have written code in the past: TOPS10, VMS Common Run-time Library. I tried to jump start the JMP by contributing the Xerox MIB, but you guys didn't seem to see any urgency in getting the project done. We could have had a MIB a year ago, if you had considered my contribution seriously. > >The Job MIB effort has been going on for close to TWO YEARS now, and >it's time to come to closure. IMMEDIATELY. I couldn't agree more and I'm working very hard to get such closure. > >I apologize for the particularly intense flame-o-gram here, but enough >is enough. Standards developed by the PWG are intended as a vehicle >to promote free enterprise within a level-playing-field environment. >The PWG is NOT an altruistic body of interested people, but rather a >group of cooperating competitors trying to raise the reference bar for >new technologies in an evolutionary manner. > >Let's close this effort and get to the task of developing products for >our customers. > > ...jay > > From hastings at cp10.es.xerox.com Mon Mar 31 17:25:33 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Job Mib Assessment In-Reply-To: Job Mib Assessment> Message-ID: <9703312228.AA03818@zazen.cp10.es.xerox.com> Keith, I've either incorporated your comments into the Internet Draft 00 (rev 0.71) or added them to the issues list as indicated. Tom At 13:39 02/04/97 PST, kccarter@vnet.ibm.com wrote: >JMP Team, > >Here is my belated assessment of the Job Monitoring MIB >document (version 0.6, dated 01/23/97) which we can discuss >further at our JMP meeting in San Jose. Thanks to Tom >Hastings for producing this document! > >* Page 7 - Job Object Lifecycle Summary: Please add a >State for "Printing" to indicate that the job is currently >printing on the printer. I added job-printing as a JmJobStateReasons enum to align with IPP and to keep the job states aligned between IPP and the JMP. Ok? An additional advantage is that implementations that don't want to distinguish between processing and printing, don't need to. > >* Page 22 - MIB Datatype specifications: This is a nit, >but it would be helpful to give an example of the format for >DateAndTime. For example, how does one specify 12:01:00AM on >Thursday, January 30, 1997? Done. DateAndTime is a binary 8 or 11 octet format. > >* Page 25 - jmQueueAlgorithmTC: I agree with the >resolution of issue 15 and 16 which states that this object >will be removed from the Job MIB. Done. > >* Page 28 - jmJobStateTC: Please add a State for >"printing" to indicate that the job is currently printing on >the printer. > I added job-printing as a JmJobStateReasons enum to align with IPP. and to keep the job states aligned between IPP and the JMP. Ok? An additional advantage is that implementations that don't want to distinguish between processing and printing, don't need to. >* Page 31 - jmJobStateReasonsTC: Please confirm that state >"completion" plus reason "successfulCompletion" means that >all pages of the print job have been successfully printed >and stacked in the output bin. If so, we're set. If not, >then please add "jobStacked" to indicate the reason for the >"completion" state is that all pages in the job have been >stacked in the output bin of the printer. Good clarification. I agree that complete and retained states both mean that all media has been sucessfully stacked. See Internet Draft 00 to see if the clarification is understandable. > >* Page 42 - jmResourceTypeTC: I agree with the resolution >of issue 22 which states that "faxPhoneNumber" will be >removed from the Job MIB. Done. > >* Page 42/43 - impressionsCompleted and sheetsCompleted: >How does number of copies affect these values? Number up divides these numbers by n. > >* Page 43 - jmResourceTypeTC: In OS/2 Warp, >"pagesSpooled", "pagesSentToDevice" and "pagesCompleted" >mean "impressions" - not "logical pages". Therefore, please >change the name of these resources to "impressionsSpooled" >and "impressionsSentToDevice". Please change the >description from "logical pages" to "impressions". Please >indicate that "impressionsSpooled" is for 1 copy of a job >and "impressionsSentToDevice" is reset to 1 for each copy. >"pagesCompleted" can be removed since it equals >"impressionsCompleted". In OS/2 Warp, >"impressionsCompleted" is reset to 1 for each copy of a job. Done. There is now the following impression (more), pages, and sheet attributes (from the TOC): impressionsSpooled 60 impressionsSentToDevice 60 impressionsInterpreted 60 impressionsRequested 60 impressionsCompleted 60 impressionsCompletedCurrentCopy 60 pagesRequested 60 pagesCompleted 60 pagesCompletedCurrentCopy 60 sheetsRequested 61 sheetsRequested 61 sheetsCompleted 61 sheetsCompletedCurrentCopy 61 > >* Page 43 - jmResourceTypeTC: Does "processingTime" count >operator intervention time? (e.g. the time a job was held >up due to a paper jam on the printer) No it should not, so that the time is reproducible and fair. I changed the name to processingCPUTime to clarify and added why. > >* Page 49 - Should MIB provide jmGeneralNumberOfJobsQueued >and jmGeneralNumberOfJobsComplete so a network management >application can summarize the current status of the printer? Yes. I added: jmGeneralNumberOfJobsToComplete 65 jmGeneralNumberOfJobsCompleted 66 > >* Page 49 - jmGeneralQueuingAlgorithm: I agree with the >resolution of issue 28 which states that this object will be >removed from the Job MIB. Done. > >* Page 53 - jmJobMessageToOperator: It doesn't appear >anyone supports this. Should this object be removed from >the Job MIB? Gone as agreed. > >* Page 58 - jmJobName, jmJobIdName, jmJobIdNumber, >jmJobComment: Clarify the use of these objects. Here is an >example. A user submits a print job. The file name of the >job is "C:\MYJOB.PS". The user specifies a comment of >"Status Report 1/31/97". The print job is queued on server >"SERVER1" in print queue "PSQUEUE". The numeric job id is >1234. What value is the value of each object? Do we need a >specific object for source server and source queue to >accommodate management applications such as the management >application provided by HP that correlates jobs in a printer >with jobs in a print queue on a print server? I think that jmJobComment is intended for more free form "on the spot" text, such as the user reminding him/herself what to do with the output or indicating differences between several submissions, if trying different features of the system, while jmJobName is more of a name and defaults from the document name or file name. In IPP jmJobName cannot be set by the client, only defaulted by the Printer from the document name or file name. See if my clarifications of jobComment attribute and the jmJobName object help. For the other objects, I agree we need to continue the discussion as HP points out for each of our configurations. The other questions and issues are issues 59-61. > >* Page 59 - jmJobIdNumber: OS/2 uses -1 to indicate there >is not a job id. I recall seeing -2 in one of the Job MIB >specs. Why not use -1 instead of -2? -2 is a convention from the Printer MIB for unknown. -1 is for other. They correspond to enums other(1) and unknown(2). A WARP agent will have an easy time mapping the WARP -1 to the JMP -2 on a Get operation. > >* Page 59 - jmJobTypes: It doesn't appear anyone supports >this object. Is this object intended for a multi-function >device (MFD) so the host can inform the MFD which of its >devices to direct the job? As JMP agreed, it is there for the future when this MIB is augmented or extended for non-printing services. For a printer, the object can be implemented as a hard-coded print(4). We could move it to the attributes table. Should we? > >* Page 60 - jmJobDeviceNameRequested: What is the purpose >of this object? Is this the name of the printer (e.g. >make and model)? No. Its purpose is the fundamental input parameter that the end-user supplies to indicate on which printer the job is to be printed. For systems where the user specifies a queue, then this object is the queue name that the user supplied. To further clarify this, I've changed the name to: jmJobDeviceNameOrQueueRequested > >* Page 60 - jmJobDeviceIndex: What value should a print >server return if it doesn't support the printer mib? Since we moved this object to the attributes table, a server wouldn't return this attribute. Had it remained as an object in the Job Table, the server agent would have returned a 0, which is an illegal index value in SNMP. > >* Page 61 - jmJobSourceChannel: What are the enum values >referred to in issue 37? These are enums in the Printer MIB indicating the type of job submission channel. > >Keith > > From hastings at cp10.es.xerox.com Mon Mar 31 17:41:51 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <9703312244.AA03834@zazen.cp10.es.xerox.com> At 08:28 02/13/97 PST, Bob Pentecost wrote: >Harry, > >jmResourceType is a read-only object, so how can the job be affected? >Wouldn't the object change values only as resources are used? > >This brings up another question. jmResourceType says "The type of resource, >e.g., medium, ink, staples, processing-time, color-impressions, etc. >required to process the job before the job start processing. This value is >updated while the job processes to indicate the amount of the resource that >is being used while the job is processing. After the job completes >processing, this value indicates the total usage of this resource made by >the job." If a job hasn't started processing, a resource will indicate how >many will be produced. Then, when the job starts processing, the value will >go to zero and count up to three. Is the management application expected to >query jmJobState to know how to interpret the value? If so, should we >define which states cause the value of a resource to change from "required" >to "used"? Except for the following, each attribute is either xxxRequested or xxxConsumed, but not both. outputBinIndex 56 outputBinIndex 56 outputBinName 56 sides 56 documentFormatIndex 56 documentFormatEnum 56 physicalDeviceIndex 57 physicalDeviceName 57 In no case is a requested value reset to 0, except for the xxxCurrentCopy attributes. jobCopiesRequested 57 jobCopiesCompleted 57 documentCopiesRequested 57 documentCopiesCompleted 57 [glitch in TOC doesn't show this - oops] jobKOctetsTotal 58 jobKOctetsCompleted 59 impressionsSpooled 60 impressionsSentToDevice 60 impressionsInterpreted 60 impressionsRequested 60 impressionsCompleted 60 impressionsCompletedCurrentCopy 60 pagesRequested 60 pagesCompleted 60 pagesCompletedCurrentCopy 60 sheetsRequested 61 sheetsRequested 61 sheetsCompleted 61 sheetsCompletedCurrentCopy 61 mediumRequested 61 mediumConsumed 61 colorantRequestedIndex 61 colorantRequestedName 61 colorantConsumedIndex 62 colorantConsumedName 62 > >Bob Pentecost >HP > > > >---------- >From: Harry Lewis [SMTP:harryl@VNET.IBM.COM] >Sent: Thursday, February 13, 1997 7:47 AM >To: jmp@pwg.org >Subject: JMP> Resource table - Missile or Camera > >jmResourceTypeTC says (effectively) > > "The type (and amount) of resource... required to process the job...the > amount is updated while the job processes... etc." > >I was starting to wonder if we were "affecting" the job, for example, >number >of copies. But I'm sure we've been very careful to avoid "missiles". Then, >the purpose of an initial value is to establish a range for metering, like >copy 1 of 3 has been printed - right? But, if the initial value is >overwritten >per "amount is updated while the job processes...", and the MIB basically >acts as a data base to be polled, doesn't 1 of 3 fall apart, in which case >what good would the initial value be? > >Sorry if I missed something here. > >Harry Lewis. > > > > > From hastings at cp10.es.xerox.com Mon Mar 31 17:46:51 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <9703312249.AA03846@zazen.cp10.es.xerox.com> At 14:14 02/13/97 PST, Lloyd Young wrote: >Bob Pentecost wrote >>This brings up another question. jmResourceType says "The type of resource, >>e.g., medium, ink, staples, processing-time, color-impressions, etc. >>required to process the job before the job start processing. This value is >>updated while the job processes to indicate the amount of the resource that >>is being used while the job is processing. After the job completes >>processing, this value indicates the total usage of this resource made by >>the job." If a job hasn't started processing, a resource will indicate how >>many will be produced. Then, when the job starts processing, the value will >>go to zero and count up to three. Is the management application expected to >>query jmJobState to know how to interpret the value? If so, should we >>define which states cause the value of a resource to change from "required" >>to "used"? > >I do not think it is likely that any system will ever fill in the values for a >particular resource that are required to process the job before the job starts >processing. It would make this whole thing simpler if we changed the first >sentence and said "The type of resource, e.g. medium, ink, staples, >processing-time, >color-impressions, etc. that are consumed while processing the job. This value >is >updated while the job processes ....... ". With this wording change, the >resources >now are stricly what is consumed in processing the job. I agree. Here is what I've clarified the beginning of the jmAttributeGroup in the Internet Draft 00: The jmAttributeGroup consists attributes of the job and document(s). Attribute may represent information about the job and document(s), such as file-names, document-names, submission-time, completion-time, size. Attributes may also represent requested and/or consumed resources for each job. Instead of allocating distinct objects for each attribute, each attribute item is represented as a separate row in the jmAttributeTable. Each column in the row describes the attribute, such as its type represented as an enum, and the value represented as (1) an integer or (2) an octet string (character coded text and binary octet strings, such as DateAndTime) or (3) both. Ok? > >Lloyd Young >Lexmark > > From hastings at cp10.es.xerox.com Mon Mar 31 17:55:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <9703312257.AA03855@zazen.cp10.es.xerox.com> At 18:11 02/13/97 PST, Harry Lewis wrote: >Lloyd wrote: > >>I do not think it is likely that any system will ever fill in the values for a >>particular resource that are required to process the job before the job starts >>processing. It would make this whole thing simpler if we changed the first >>sentence and said "The type of resource, e.g. medium, ink, staples, >>processing-time, color-impressions, etc. that are consumed while >>processing the job. This value is updated while the job processes. >>With this wording change, the resources now are stricly what is >>consumed in processing the job. > >Lloyd, I'd like to agree, but this gets to my original point... >If you are using SNMP to poll the job table and want to display >(based on your findings) "Page 1 of 3 is printing" then the >number of pages requested (3) *has* to be filled out by the agent >and *cannot* be overwritten as the pages begin to be consumed. I've tried to clarify the current Internet draft 00. The description of the JmAttributeTypeTC start off with: Attributes may represent information about a job, such as a file-name, or a document-name, or submission-time or completion time. Attributes may also represent resources required, e.g., a medium or a colorant , etc. to process the job before the job start processing OR to indicate the amount of the resource that is being consumed while the job is processing, e.g., pages completed or impressions completed. If both a required and a consumed value of a resource is needed, two separate attribute enums are assigned in the textual convention. Is that clear enough? >Harry Lewis > > > From hastings at cp10.es.xerox.com Mon Mar 31 17:57:38 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource Table - Missile or Camera Message-ID: <9703312300.AA03858@zazen.cp10.es.xerox.com> At 09:42 02/14/97 PST, Harry Lewis wrote: >Ron wrote: > >>The more I look at the resource table, the more I agree with Tom >>that it is a "win-win" situation. A DPA printer can present every >>possible parameter and a real-world printer can present only the >>useful values it can access. All of this without a large number >>of objects in the MIB. > >I agree! The resource table, with resource type enums, is turning >out to be a great idea. > >One thing I'm finding is that Resource Name seems to be redundant >with information that should already be in the Printer MIB. I wonder >how useful resource name is. If we're trying to name a resource like >OutputBin (3) "Big Bin" - then the name is surely in the printer MIB >and a server implementation would not be representing this resource. >If we're trying to get fancy and say MediaType (Paper) "Hillary's >Pink LetterHead", I really doubt any accounting application will >be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.) >for charging purposes is more practical. > >Anyone else vie for eliminating Resource Name? > >Again, otherwise, I really LIKE the resource table! So now we have just the following objects in the Attribute table: The Attribute Group (Mandatory) 78 jmAttributeTypeIndex 80 jmAttributeInstanceIndex 81 jmAttributeValueAsInteger 81 jmAttributeValueAsOctets 82 Ok? > >Harry Lewis - IBM Printing Systems. > > > > From hastings at cp10.es.xerox.com Mon Mar 31 17:58:31 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource Table - Missile or Camera (fwd) Message-ID: <9703312300.AA03861@zazen.cp10.es.xerox.com> At 17:31 02/14/97 PST, Ron Bergman wrote: >Harry, > >It looks like the object jmResourceName is more confusing than >descriptive. It is not intended to be the name of the resource >but is to be used for resources that require a string to be >returned. For example, fileName(3) and documentName(4) are >resources that cannot be represented by a numeric value. In >this case jmResourceAmount would be zero and the actual value >of the resource is presented in jmResourceName. (I believe >that this was discussed in last weeks meeting after you left >for the airport.) > >In the case of a numeric value jmResourceName would be a >string of zero length. Use of the object as a name of the >resource in this case was agreed to be removed in the meeting >last week. > >To eliminate some of this confusion the jmResourceName object >name should be changed to something like jmResourceStringValue. > >Can anyone suggest a better name? So now we have: The Attribute Group (Mandatory) 78 jmAttributeTypeIndex 80 jmAttributeInstanceIndex 81 jmAttributeValueAsInteger 81 jmAttributeValueAsOctets 82 Ok? > > > Ron Bergman > Dataproducts Corp. > rbergma@dpc.com > (805)578-4421 > > >---------- Forwarded message ---------- > > >Harry wrote: > >One thing I'm finding is that Resource Name seems to be redundant >with information that should already be in the Printer MIB. I wonder >how useful resource name is. If we're trying to name a resource like >OutputBin (3) "Big Bin" - then the name is surely in the printer MIB >and a server implementation would not be representing this resource. >If we're trying to get fancy and say MediaType (Paper) "Hillary's >Pink LetterHead", I really doubt any accounting application will >be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.) >for charging purposes is more practical. > >Anyone else vie for eliminating Resource Name? > > >Harry Lewis - IBM Printing Systems. > > > > > From hastings at cp10.es.xerox.com Mon Mar 31 18:03:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> New text for MIB Abstract section In-Reply-To: New text for MIB Abstract section> Message-ID: <9703312306.AA03881@zazen.cp10.es.xerox.com> Ron, I took another look at the Abstract and took the liberty of adding points (2) and (3) for the Internet draft 00, since our MIB is also providing such capability" Abstract This Internet-Draft specifies a set of SNMP MIB objects for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented in printers or a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Ok? Tom At 11:13 02/15/97 PST, Ron Bergman wrote: >Proposed change to the "Abstact" text on the first page of the MIB >document. This is simply a rewording and format change to the >existing text. I have also added a sentence at the end regarding >extensions of the MIB for fax and scanners. > >IS: >----------------------------------------------------------------------- >Abstract > >This Internet-Draft specifies a job monitoring MIB that contains a >set of objects for monitoring of the status and progress of print >jobs and to obtain resource accounting data at the completion of a >job using SNMP. >This MIB is intended to be implemented in printers or the server >that supports one or more printers. >Use of the object set is not limited to printing. However, support >for services other than printing is outside the scope of this Job >Monitoring MIB. >----------------------------------------------------------------------- > >CHANGE TO: >----------------------------------------------------------------------- >Abstract > >This Internet-Draft specifies a set of MIB objects for monitoring >the status and progress of print jobs and to obtain resource >accounting data at the completion of a job using SNMP. This MIB is >intended to be implemented in printers or the server that supports >one or more printers. Use of the object set is not limited to >printing. However, support for services other than printing is >outside the scope of this Job Monitoring MIB. Future extensions to >this MIB may include, but are not limited to, fax machines and >scanners. >----------------------------------------------------------------------- >----------------------------------------------------------------------- > Ron Bergman > Dataproducts Corp. > rbergma@dpc.com > (805)578-4421 > > > From hastings at cp10.es.xerox.com Mon Mar 31 18:26:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> jmJobSubmissionTime In-Reply-To: jmJobSubmissionTime> Message-ID: <9703312328.AA03903@zazen.cp10.es.xerox.com> At 21:39 02/19/97 PST, Harry Lewis wrote: >Tom wrote (somewhat paraphrased - my response brackted by HRL -): > >>There is one additional issues raised ... (moving) >>jmJobSubmissionTime from the JobTable to the QueueTable (or) >>to the ResourceTable. >> >>There are pros and cons with each: >> >>Moving jmJobSubmissionTime to the QueueTable means that an implementation >>that queues, shall implement the time, which is probably not a burden >>on something that queues and means that jobs will get a time stamp >>as they are entered into the MIB. On the other hand, a Printer >>that doesn't queue, cannot have a jmJobSubmissionTime at all. > >HRL - I think the system that queues sets the submission DateTime >HRL - as you say. For *printers* that don't queue, the DateTime must >HRL - be passed in on submission from the server queue. > >>The advantage of putting it in the ResourceTable is for implementations >>that don't have concept of time. But our experience with alerts in >>the Printer MIB say it was a mistake not to require time stamps >>on alerts, so we changes prtAlertTime to become mandatory. Same >>should be true for JobSubmissionTime, shouldn't it? > >HRL - Another advantage of putting it in the ResourceTable is that >HRL - not Time becomes an enumerated resource. The submission DateTime >HRL - passed in from the server can be "stashed" as one TIME Resource >HRL - and additional TIME Resources can be defined, as TimeTick that >HRL - can be used to roughly correlate and track progress as follows >HRL - in response to your final question. > >>And shouldn't the job submission time be recorded whether >>the implementation queues or not? > >HRL - As I was saying. If submission DateTime is passed in with the >HRL - submission protocol, the jmResourceType TIME could be defined >HRL - as follows: (shorthand notation) >HRL - >HRL - jmResourceType - TIME >HRL - >HRL - 1 - Other >HRL - 2 - Unknown >HRL - 3 - jobSubmssionTime - DateTime >HRL - 4 - jobSubmissionTick - TimeTicks >HRL - 5 - jobStartTick - TimeTicks >HRL - 6 - jobCompleteTicks - TimeTicks >HRL - >HRL - Using these TIME resources as entries in the Resource table, >HRL - and assuming the agent closely correlates Time and Ticks on >HRL - job submission (within a second or two?) then, using just >HRL - Ticks (derived from sysUpTime) the Job Management App can >HRL - determine how long the job waited on the printer and how long >HRL - it took to print. >HRL - >HRL - One disadvantage I see is number of Resource table entries, but >HRL - it seems we've created this table as a collector of sorts AND >HRL - we've at least cleverly provided the jmResourceType providing >HRL - coarser granularity for more efficient data gathering. In re-reading you e-mail, I missed the point that you wanted the jobSubmissionDateAndTime to be the submission time to the server and the jobSubmissionTimeStamp to be the submission time to the printer. It would seem to me that we would need to specify in the semantics of the attribute whether the time was when the job was submitted to the server vs. the printer. So I would think that we would need another attribute. Presumably a server would always have access to a date and time clock, so would not need the TimeStamp form for the server. So we should replace: jobSubmissionDateAndTime JobSubmissionTimeStamp with: jobSubmissionToServerDateAndTime jobSubmissionToPrinterDateAndTime JobSubmissionToPrinterTimeStamp If you are implementing just a printer and don't know when the job was submitted to the server, you would not implement the jobSubmissionToServerDateAndTime attribute, correct? What other attributes do we need separate instances for the server vs. the printer in order to handle configuration 2 and 3? I've added this issue as issue 66 to the issues list (but I just sent the issues list, so this is a new one). Tom > >Harry Lewis - IBM Printing Systems. > > > From hastings at cp10.es.xerox.com Mon Mar 31 18:32:55 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> 2/25 Phone conference comments In-Reply-To: 2/25 Phone conference comments> Message-ID: <9703312335.AA03919@zazen.cp10.es.xerox.com> At 07:21 02/25/97 PST, Bob Pentecost wrote: >Unfortunately, I may completely miss the JMP phone conference today. If I >can free up some time, I'll join you. However, I do have a couple of >comments. > >Re: Keith Carter's "Job MIB Assessment". >* Page 58 - jmJobName, jmJobIdName, jmJobIdNumber, >jmJobComment: Clarify the use of these objects. Here is an >example. A user submits a print job. The file name of the >job is "C:\MYJOB.PS". The user specifies a comment of >"Status Report 1/31/97". The print job is queued on server >"SERVER1" in print queue "PSQUEUE". The numeric job id is >1234. What value is the value of each object? Do we need a >specific object for source server and source queue to >accommodate management applications such as the management >application provided by HP that correlates jobs in a printer >with jobs in a print queue on a print server? > >It looks like the print queue name is covered by jmJobDeviceNameRequested. Agreed. To clarify, I changed the name to: jmJobDeviceNameOrQueueRequested and the description. >However, it looks like there's no place for the source server or client >name. We should also try to provide the file name of the job and a source >port object which tell which client port the job came from. I added these as Issues 59 and 60. We need specific proposals for these objects or attributes. > >We just held an internal review of the Job Monitoring MIB. I'll try to get >the issues posted by the end of this week. > >Bob Pentecost >HP > > > > > From imcdonal at eso.mc.xerox.com Mon Mar 31 19:38:05 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9704010038.AA05356@snorkel.eso.mc.xerox.com> 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: 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@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA17024 for ; 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@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 To: 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@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 From harryl at us.ibm.com Tue Apr 1 12:05:39 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Max number of jobs Message-ID: <5030100001086282000003L023*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems In my view, max number of jobs *cannot* be defined as the wrap point for jmJobIndex! >Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs >to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object >can have and the roll over to 1 happens for the next job received? Or add >jmGeneralMaxJobIndex as another object in the General table? Then the >monitoring application would know what the roll over limit would be. For >agents that instrument servers or printers that use a job identifier of 0, >the actual maximum number would be one more than the actual job identifier >that the server or printer generates. So for LPD, the value of >jmGeneralMaxJobIndex would by 1000, not 999. The jmJobIndex is a large integer specifically to prevent identical ID's from existing within any reasonable time window. If a printer can only hold information about (say) 20 jobs and it wraps at 21, then there is a chance that two different jobs may appear to have the same ID (1). A wrap at the max value of a vary large integer will prevent this from occurring. My opinion. From harryl at us.ibm.com Tue Apr 1 12:27:34 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource Table - Missile or Camera Message-ID: <5030100001086727000002L072*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, >So now we have just the following objects in the Attribute table: >The Attribute Group (Mandatory)*78 >jmAttributeTypeIndex*80 >jmAttributeInstanceIndex*81 >jmAttributeValueAsInteger*81 >jmAttributeValueAsOctets*82 >Ok? I think so although where is the jmJobIndex? I expected this to be the first index (other than, perhaps jobSet). From harryl at us.ibm.com Tue Apr 1 19:00:25 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <5030100001097502000002L022*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Ira, I welcome your response. >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! I respect Xerox's (and all PWG members) privacy and want to take this opportunity to clarify that IBM has similar policies regarding un-announced products. I think there's been a bit of a misunderstanding regarding Jay's "call for a show of hands". My interpretation of this query related strictly to PROTOTYPING THE JMP JOB MIB. If I'm not mistaken, the IETF process recommends prototyping prior to and in parallel with draft submission. So the design I'm sharing with the PWG is the result of this prototype activity and should not be misconstrued as a product announcement. I think this (lengthy) clarification probably goes equally for all respondents... at least that's how I've perceived it. Of course, none of us would be in this game if it weren't for products so I understand how the treading can become very light in this area.;-) Then... I have to admit I have lost track of the ClientIDMapTable that you refer to. I plan to share the clientJobID formats that we consider useful and I think it would be helpful if Xerox chose to share your formats also. Of course, this is strictly up to Xerox. I think the notion of registered formats for clientJobIDs could go a long way to facilitating standard print job monitoring. Again, thanks for your review and I welcome any further comments. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue Apr 1 16:24:23 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Max number of jobs [Second part of Issue 49] In-Reply-To: Max number of jobs [Second part of Issue 49]> Message-ID: <9704012126.AA04229@zazen.cp10.es.xerox.com> Harry, Convincing that we need to keep jmGeneralMaxNumberOfJobs as it is independent of the wrap point. So do we also need to add an object, say, jmGeneralMaxJobIndex, for the wrap point as my second question in the issue asks? For example, BSD LPR/LPD wraps at 999 back to 0. That question will be the only part of Issue 49 unresolved. Thanks, Tom At 09:05 04/01/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >In my view, max number of jobs *cannot* be defined as the wrap point for >jmJobIndex! > >>Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs >>to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object >>can have and the roll over to 1 happens for the next job received? Or add >>jmGeneralMaxJobIndex as another object in the General table? Then the >>monitoring application would know what the roll over limit would be. For >>agents that instrument servers or printers that use a job identifier of 0, >>the actual maximum number would be one more than the actual job identifier >>that the server or printer generates. So for LPD, the value of >>jmGeneralMaxJobIndex would by 1000, not 999. > >The jmJobIndex is a large integer specifically to prevent identical ID's from >existing within any reasonable time window. If a printer can only hold >information about (say) 20 jobs and it wraps at 21, then there is a chance that >two different jobs may appear to have the same ID (1). A wrap at the max value >of a vary large integer will prevent this from occurring. > >My opinion. > > From harryl at us.ibm.com Tue Apr 1 19:38:06 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera Message-ID: <5030100001098247000002L072*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I think this clarification helps. We may also need specific guidelines per object but these should just be a formalization of what is obvious by the name of the attribute.. ------ Forwarded by Harry Lewis/Boulder/IBM on 04/01/97 05:31 PM ---- jmp-owner@pwg.org 04/01/97 10:04 AM To: harryl@vnet.ibm.com@internet cc: jmp@pwg.org@internet Subject: RE: JMP> Resource table - Missile or Camera At 18:11 02/13/97 PST, Harry Lewis wrote: >Lloyd wrote: > >>I do not think it is likely that any system will ever fill in the values for a >>particular resource that are required to process the job before the job starts >>processing. It would make this whole thing simpler if we changed the first >>sentence and said "The type of resource, e.g. medium, ink, staples, >>processing-time, color-impressions, etc. that are consumed while >>processing the job. This value is updated while the job processes. >>With this wording change, the resources now are stricly what is >>consumed in processing the job. > >Lloyd, I'd like to agree, but this gets to my original point... >If you are using SNMP to poll the job table and want to display >(based on your findings) "Page 1 of 3 is printing" then the >number of pages requested (3) *has* to be filled out by the agent >and *cannot* be overwritten as the pages begin to be consumed. I've tried to clarify the current Internet draft 00. The description of the JmAttributeTypeTC start off with: Attributes may represent information about a job, such as a file-name, or a document-name, or submission-time or completion time. Attributes may also represent resources required, e.g., a medium or a colorant , etc. to process the job before the job start processing OR to indicate the amount of the resource that is being consumed while the job is processing, e.g., pages completed or impressions completed. If both a required and a consumed value of a resource is needed, two separate attribute enums are assigned in the textual convention. Is that clear enough? >Harry Lewis > > > From hastings at cp10.es.xerox.com Tue Apr 1 16:36:27 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource Table - Missile or Camera Message-ID: <9704012138.AA04232@zazen.cp10.es.xerox.com> Yes, the Attribute Table has four indexes (all currently listed as not-accessible): jmJobSetIndex jmJobIndex jmAttributeTypeIndex jmAttributeInstanceIndex Only jmAttributeTypeIndex and jmAttributeInstanceIndex are in the jmAttributeEntry SEQUENCE though, because jmJobSetIndex (in the General table SEQUENCE) and jmJobIndex (in the Job table SEQUENCE) appear elsewhere in the MIB. Isn't that correct SNMP? Issue 57 deals with making jmAttributeTypeIndex read-only so that we can mention the sheetsCompleted as a mandatory enum. Tom At 09:27 04/01/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >Tom, > >>So now we have just the following objects in the Attribute table: > >>The Attribute Group (Mandatory)*78 >>jmAttributeTypeIndex*80 >>jmAttributeInstanceIndex*81 >>jmAttributeValueAsInteger*81 >>jmAttributeValueAsOctets*82 > >>Ok? > >I think so although where is the jmJobIndex? I expected this to be the first >index (other than, perhaps jobSet). Correct, but because they are not-accessible, none of the indexes can be listed in the conformance group section. > > > > > > From harryl at us.ibm.com Wed Apr 2 00:40:17 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera In-Reply-To: Resource table - Missile or Camera> Message-ID: <5030100001101432000002L022*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I do not understand the need for requested values for any of the following "attributes" within the context of a resource accounting table such as we have defined. >Most attributes are either the requested value or the consumed (updated >as the job progresses), but not both. The only attributes that are both >requested/used are: >outputBinIndex*56 >outputBinIndex*56 >outputBinName*56 >sides*56 >documentFormatIndex*56 >documentFormatEnum*56 >physicalDeviceIndex*57 >physicalDeviceName*57 Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed Apr 2 01:05:10 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Max number of jobs [Second part of Issue 49] In-Reply-To: Max number of jobs [Second part of Issue 49]> Message-ID: <5030100001101551000003L013*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, I'm confused a bit by your question: >Convincing that we need to keep jmGeneralMaxNumberOfJobs as it is >independent of the wrap point. >So do we also need to add an object, say, jmGeneralMaxJobIndex, >for the wrap point as my second question in the issue asks? >For example, BSD LPR/LPD wraps at 999 back to 0. What does the fact that BSD LPR/LPD wraps at 999 have to do with the wrap point of jmJobIndex (that *is* what we're talking about, isn't it?). I'm missing your point. little value, especially if we also have another object representing how long a job entry will remain in the table (in seconds). I assume some applications will use jmGeneralMaxNumberOfJobs for storage allocation, but this assumes a rather static approach by this application. Can someone shed more light on who will use this object, how and why? Tom, maybe you can help me out with the BSD slant. Harry Lewis From jkm at underscore.com Wed Apr 2 08:57:59 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:03 2009 Subject: JMP> Max number of jobs In-Reply-To: Max number of jobs> Message-ID: <199704021357.IAA14148@uscore.underscore.com> Harry, You are absolutely correct. As a matter of fact, we had one customer who actually had Sun "enhance" LPD so that the 1000 job limit could be overcome, as many of their Unix-based print queues were receiving jobs faster than they could process them...and hence, rolled past the limit of 1000 simultaneous jobs (ie, job IDs between 0 and 999). Why exactly would a mgmt app need to know the roll-over point for the job index, anyway? Can someone explain why this is necessary and/or desirable? ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: JMP> Max number of jobs Date: Tue, 1 Apr 1997 12:05:39 -0500 Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems In my view, max number of jobs *cannot* be defined as the wrap point for jmJobIndex! >Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs >to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object >can have and the roll over to 1 happens for the next job received? Or add >jmGeneralMaxJobIndex as another object in the General table? Then the >monitoring application would know what the roll over limit would be. For >agents that instrument servers or printers that use a job identifier of 0, >the actual maximum number would be one more than the actual job identifier >that the server or printer generates. So for LPD, the value of >jmGeneralMaxJobIndex would by 1000, not 999. The jmJobIndex is a large integer specifically to prevent identical ID's from existing within any reasonable time window. If a printer can only hold information about (say) 20 jobs and it wraps at 21, then there is a chance that two different jobs may appear to have the same ID (1). A wrap at the max value of a vary large integer will prevent this from occurring. My opinion. ----- End Included Message ----- From jds at underscore.com Wed Apr 2 12:11:54 1997 From: jds at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:00:03 2009 Subject: JMP> Majordomo Filtering of PWG Mailing lists Message-ID: <199704021357.IAA14148@uscore.underscore.com> Several individuals have recently had mail rejected by the Majordomo mailing list software we are using on the PWG server. I thought I'd take this opportunity to explain what is happenning. In order to eliminate mail storms (like those we experienced when Underscore first set up the PWG server), the Majordomo software looks for suspicious phrases in both the subject line and a more extended list in the first five lines of the message body. I'll detail the forbidden text below. In addition, Majordomo imposes certain other limits to avoid problems with various older mail agents: - Header lines must not exceed 192 bytes. - Header fields must not exceed 1024 bytes. - Message size in excess of 120,000 bytes. The filtered subjects are those that start with: - subscribe - unsubscribe - help - RCPT: - Delivery Confirmation - NON-DELIVERY of - Undeliverable Message - Receipt Confirmation - Failed mail - change <*> address - request <*> addition The phrase are filtered against appearing anywhere in the first five lines of the message body: - delete me - remove me - add me - change <*> address - request <*> addition - subscribe - sub - unsubscribe - unsub - mail11 - undeliverable - transcript of session - original message was received - message could not be delivered - block not createable after - bounce - bounced - not deliver after - returned mail Finally, Majordomo may reject messages if any of the first five lines of the message body begin with: - help - info - lists - which - index - who - get - approve - passwd - newinfo - config - newconfig - writeconfig - mkdigest I hope this helps explain things. If you can't find a way to rephrase a forbidden phrase, you might try "pig-latin"... /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From hastings at cp10.es.xerox.com Wed Apr 2 13:54:41 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera In-Reply-To: Resource table - Missile or Camera> Message-ID: <9704021857.AB04525@zazen.cp10.es.xerox.com> Harry, I agree with you that none of the attributes you listed are needed by an accounting program. However, I think that they are useful for end users and operators that are monitoring jobs. That is why I have resisted your suggestion to change the name of the Resource Table to the Accounting Table, since the contents of the table are for more purposes than just accounting. I think that the name Attributes is more appropriate, since the contents of the table include information that is not of interest to accounting programs. I would think that accounting programs would not be interested in any requested attributes, not just the ones you listed. Furthermore, the consumed attributes in the table are of interest to non-accounting programs before the job is finished. The consumed attributes are dynamic, in that they start at 0 and count up, so even the consumed attributes are not used only by accounting programs, but by monitoring programs that want to display the progress of the job before the job completes. Ok? By the way all of the attributes that you listed are the ones for which we don't have separate attributes (or multiple entries) for requested vs. consumed. In otherwords, the same entry is used for both (and the requested and consumed value should be the same, so it wasn't worth having two enums for each. See Ron Berman mail on this subject. Ok? Tom At 21:40 04/01/97 PST, Harry Lewis wrote: >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >I do not understand the need for requested values for any of the >following "attributes" within the context of a resource accounting >table such as we have defined. > >>Most attributes are either the requested value or the consumed (updated >>as the job progresses), but not both. The only attributes that are both >>requested/used are: > >>outputBinIndex*56 >>outputBinIndex*56 >>outputBinName*56 >>sides*56 >>documentFormatIndex*56 >>documentFormatEnum*56 >>physicalDeviceIndex*57 >>physicalDeviceName*57 > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed Apr 2 13:54:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> JMP Internet Draft didn't make the cutoff Message-ID: <9704021857.AB04525@zazen.cp10.es.xerox.com> I'm terribly embarrassed, but I didn't make the IETF cutoff time for the Job Monitoring MIB. I just talked to Steve Coya of the IETF staff. He said that there is no problem with discussing what was supposed to be the I-D, at the IETF meeting next week, as long as the printmib chair (Chris Wellens and Don) agree. Most chairs don't have a problem with discussing papers that aren't I-Ds. The unfortunate thing is that we don't get feed back from non-PWG members. Ok Chris to discuss the Job Monitoring MIB draft at the printmib meeting next week, even though it wasn't posted as an Internet Draft? I don't know how we can advertize the location of the document on the pwg server to others who might attend. Also we have to resubmit the draft after the meeting. The IETF doesn't keep a queue. I suggest that we submit it as soon as we can, in order to get more IETF feed back, rather than waiting for the next IETF meeting where all the I-Ds get bunched up. What happened: Steve said that my Email didn't make the 5:00 pm EST (2:00 pm PST) cutoff time by 4 minutes on March 26. The IETF looks at the posting time, not the arrival time, so mail delays don't enter in. Unfortuantely, when I went to send the I-D at 1:50 pm PST, my mail server was down, even though everything else on my Sun workstation was working fine. So I had to copy the file to a diskette and send it from Stan's PC. By that time, I had run past 5:00 pm by 4 minutes. I've never seen this problem before. Sorry. Even if I had gotten it posted, it still had the overstrike formatting problem. While I think it could have been printed ok, it isn't readable on a screen. The lines that are overstruck with CR and a bunch of spaces appear on the next line on the screen. I'm in the process of getting a program to undo overstrikes that the Generic text print driver uses to output page number, cross reference page numbers, and tables. I will make this program available for all to use along with the cscan and maxln tools I have already contributed (courtesy of Ira McDonald). I had removed all bolding, since I knew that the generic print driver sends three lines with the bold material present on the second and third pass. BTW we should add these tools for creating I-Ds and RFCs to the PWG web page for use by all our projects. So the document for the IETF printmib meeting next week (and this week JMP meeting) should be the one that is formatted with TimesRoman font: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf (and has the cover page that is not part of the I-D and has the change history that is not part of the I-D.) NOT the one formatted with the fixed pitch Courier throughout: ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito ring-00.pdf Steve said to resubmit as 00.txt after April 14 including any changes we want to make (which may be considerable after Harry's presentation). Tom From hastings at cp10.es.xerox.com Wed Apr 2 13:55:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <9704021857.AB04525@zazen.cp10.es.xerox.com> Jay, I'm not sure why we are having this Email exchange. My entire purpose of working on any standards is for their implementation in products and as fast as possible. TTM is a real concern of mine, as well as yours. I've been working as fast and as hard as I can to get closure on the Job Monitoring MIB, starting a year and a half ago when I submitten a complete, compilable MIB and continuing. I agree that one of the best ways to get closure and short TTM is to go for simplicity and add after the first ship. Furthermore, I am most interested in writing a standard that monitoring applications from one implementor or vendor can interwork with multiple agents from other vendors. I'm not very interested in just writing a MIB that works only for a vendor that writes both the client and agent. In other words, I'm not interested in writing a standard that just becomes a checkoff item for procurement specifications. I would think that my objective would align with Underscore's as well here. So we need to make sure that all implementors have the same understanding about the specification. Sorry you won't be in Austin to discuss this face to face. We will definitely discuss Harry's good specific proposal for simplification. It looks real good. Making specific proposals for simplification, such as Harry's, is the best way to make progress towards simplification. It doesn't help to say we need to simplify without making a specific proposal for simplification. So please make some specific simplification proposals yourself. Its easier to engineer complication. The hardest and best engineering is making things simple (and still useful). Thanks, Tom At 09:35 03/29/97 PST, JK Martin wrote: >Tom, > >> You ask some good questions here. We need to discuss what is needed to >> make the Job Monitoring spec be the thing that is being prototyped. >> Lets put this discussion on the JMP agenda for next week? > >Regretably, I will not be able to make the Austin meetings. However, >I have been in pretty close contact with Harry Lewis about most of >these issues, and I believe Harry can accurately state my views in >my absense. > > --- NOTE TO AUSTIN-BOUND JOB MIB MEETING ATTENDEES --- > > Please take a few moments before the Job MIB meeting to read this > message, then form your own opinions and (please!) publicly state > your opinions at the meeting. The day of reckoning draws near... > > >> 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? > >It could very well be. Underscore has studied this problem over the >last year or so, and it appears to be a very difficult nut to crack. >So much so, that we now agree with Harry (and some others) in stating >that the Job MIB should be constrained to a simple client-server >model...with no intervening print server concept. Just a "client" >(server, mgmt app) talking to a "server" (printer, print server). > > >> 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? > >You can do anything with proprietary MIBs. But that is not the point. >We need to create standard MIBs here. > >A long time ago I passionately argued for a modular approach, whereby >the initial Job MIB would be VERY VERY SIMPLE, and that we would then >augment that simple MIB to support such things as accounting, etc. >That way we could get the SIMPLE MIB out in the marketplace as quickly >as possible so as to gain some real operational experience, particularly >in order to know exactly what kinds of extensions are truly necessary >(ie, "necessary" == "demanded by paying customers"). > > >> Another reason is that, as HP points out, we need to better understand >> how each object is used with each job submission protocol and in each >> of the configurations that we are trying to support. How can we make >> better progress on this part? I'll be glad to document the understandings >> in the spec, so that they can be tested during interoperability testing. > >This paragraph really scares me, Tom. I thought the whole purpose of >developing the table of "Existing Protocols Mapped to Job MIB Attributes" >was supposed to address this topic. > >And, please recall (PLEASE), that last November in New Orleans, I pointed >out that the Job MIB actually contained attributes for which NO EXISTING >PRINT SUBMISSION PROTOCOL SUPPORTS. That is, you had added attributes >that do not map to any existing print submission protocol. > >During that meeting I suggested that we IMMEDIATELY remove those attributes. >You did not agree, stating (as usual) that "someone in the future might >find a need for those attributes" (or something to that effect). > >This is sheer lunacy. And the paying marketplace suffers as a result, >not to mention the vendors who wish to develop and deliver useful solutions >to that marketplace. > > >> Of course, another reason may be that the committee keeps evolving >> the spec with each meeting, so that it is a moving target. Is this >> a problem? > >If this weren't so sad, I'd really have to laugh. Tom, YOU are the one >who keeps changing the spec! Yes, the group then ends up making more >changes...but almost always because your new changes don't map to any >known reality in the market-driven world. > > >> Except for the remaining issues, I think we are reaching >> more stability. We keep removing objects, so that now we are down to >> only 21 mandatory objects (but we have 45 attributes, that are conditionally >> manatory: you implement them if you got them). > >I think everyone should listen to what Harry Lewis is going to present. >If the group doesn't buy Harry's approach, then I'd like to propose that >Hewlett-Packard submit their Job MIB to the PWG as a new candidate for >the official Job MIB (with all HP-proprietary stuff removed, of course). >Similarly, any other vendor with a known working solution should be >invited to propose their model. > > >> Xerox has its own job monitoring MIB as well with its own solutions to >> the above. Xerox would like to implement the IETF spec when it is >> stablized. > >Then why on earth didn't you just propose the solution as developed by >Xerox, for heaven's sake?? Why did you constantly view the Job MIB >effort as a "fundamental research activity", apparently ignoring any >and all existing practice? > > >Tom, you really have quite the ability to generate massive amounts of >spec-oriented material. You do that very well, and much of the content >is quite interesting. However, it is also clear that, unlike almost >all other Job MIB participants, you do not actually develop product. >More importantly, since you don't develop product, you have very little >sensitivity to the concepts of "time to market" and plain, old fashioned >bottom-line responsibility. > >The Job MIB effort has been going on for close to TWO YEARS now, and >it's time to come to closure. IMMEDIATELY. > >I apologize for the particularly intense flame-o-gram here, but enough >is enough. Standards developed by the PWG are intended as a vehicle >to promote free enterprise within a level-playing-field environment. >The PWG is NOT an altruistic body of interested people, but rather a >group of cooperating competitors trying to raise the reference bar for >new technologies in an evolutionary manner. > >Let's close this effort and get to the task of developing products for >our customers. > > ...jay > > From jkm at underscore.com Wed Apr 2 15:10:07 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:03 2009 Subject: JMP> Calling all Job Monitoring MIB prototypers... In-Reply-To: Calling all Job Monitoring MIB prototypers...> Message-ID: <199704022010.PAA15432@uscore.underscore.com> Tom, With all due respect, this will be my last mail message on this topic. Hopefully by now you have also received the comments from Ron Bergman (JMP Chairman) on this thread; I've attached it here in case you have yet to read it. You say: > Its easier to engineer complication. The hardest and best engineering > is making things simple (and still useful). You should know by now that I couldn't agree more with this statement. The fact that you are stating it, though, is a bit of a surprise. Over the course of the last year, the JMP group has repeatedly asked you to consider a more simplified model for the Job MIB. And, regrettably, you repeatedly appeared to have ignored every request of that type. (Note that simply removing objects out of the proposed MIB is *not* necessarily simplifying the model.) You also say: > [Time to market] is a real concern of mine, as well as yours. > I've been working as fast and as hard as I can to get closure on the > Job Monitoring MIB, starting a year and a half ago when I submitten > a complete, compilable MIB and continuing. IMHO, it should not have taken us this long to get to where we are now. If the JMP group had gone the normal IETF working group route when the Job MIB effort first started, we would either have a working Job MIB by now...or the entire effort would have been shutdown by the IETF, due to the IETF's strong rules on length-of-effort and maintaining the associated schedule. You and I are fundamentally different with regard to standards development, that's for sure. (And that's good, I believe.) I prefer small, simple efforts that can be quickly developed, while you prefer large, all- encompassing efforts that attempt to solve all known problems in all known environments (and even a few that don't fit this description! ;-). Given that difference of position, it's likely that we'll have a disagreement now and then. That's ok, as long as it can be worked out in an open forum. (And it is, I believe.) ...jay ----- Begin Included Message ----- Date: Tue, 1 Apr 1997 08:28:54 -0800 (PST) From: Ron Bergman To: JK Martin Subject: Re: JMP> Calling all Job Monitoring MIB prototypers... X-X-Sender: rbergma@it.dpc.com Jay, Your message to Tom was very appropriate and expresses much of what I have been thinking over the past months. It seems like the more we cut from the MIB, the larger the document becomes and the more issues that are closed, the more new issues are added. I have reviewed Harry Lewis' proposed changes and, except for some points I don't fully understand, agree they are welcome improvements. I am sure that the remaining members will also agree. Keeping this project moving has been a difficult task due to many of the reasons so well expressed in your message. It is always nice to see that someone else shares this view. Ron Bergman ----- End Included Message ----- From hastings at cp10.es.xerox.com Thu Apr 3 01:05:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> Recalling PWG removal of job client id map from Job Monitoring Message-ID: <9704030608.AA04666@zazen.cp10.es.xerox.com> Here is the change history from the 1.5 year old Job Monitoring MIB that is posted on the PWG server. Point number 7 shows that we considered the client id to server id map at the 11-Sept-1995 PWG meeting and decided to remove it from the MIB proposal. I'm glad that Harry's team has discovered its value through prototyping and that he will be proposing the idea to the JMP this Friday (from the slides he posted last Friday). Tom The following changes were made from version 0.5, dated 11-Sep-1995 to make version 0.6, dated 20-Sep-1995 (the first 9 changes are as a result of the review at the 18-Sept IETF/DMTF PWG meeting: 1. Clarified that the mandatory objects are for a printer and the optional attributes are for print spooling systems. 2. Indicated that the job information retained by the agent after a job completes is intended for use by: management stations used by system operators, a remote console capability, end-user monitoring, system accounting, and system usage programs. 3. Clarified the requirement that the job monitoring MIB is intended to be used with print systems that do not implement ISO DPA, as well as with ones that do. 4. Added the goal that the current proposal is for print jobs, but that the MIB should be designed so that a future MIB could augment this job monitoring MIB for monitoring scan and FAX jobs. 5. Indicated that this job monitoring MIB must be designed to be used with SNMPv1 and SNMPv2, including the different security mechanisms provided. 6. Clarified that if job control functions (cancel job, etc.) are to be provided, they should be provided by a separate job control MIB, that would be a companion MIB to this job monitoring MIB. 7. Removed the idea that the agent keeps a client job id to server job id map, since such complication in an agent is against SNMP philosophy of keeping agents simple (and putting the smarts into management stations). 8. Clarified the goal about legacy protocols. 9. Added goal of supplying only objects that are of interest to the system operator and system administrator, as opposed to the end user, since that is the focus of job managment MIBs. From chrisw at iwl.com Thu Apr 3 11:09:38 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:03 2009 Subject: JMP> Re: JMP Internet Draft didn't make the cutoff In-Reply-To: <9704021857.AB04525@zazen.cp10.es.xerox.com> Message-ID: Tom, Everyone should have your work ethic. (1) The Job Monitoring MIB is still on the schedule for the Tuesday, April 8, 2-3 p.m. (2) Bring extra copies of the draft to the meeting. (3) Send a concise announcement of the date, time, and URL for the document to ietf@ietf.org. That will be the best way to advertise it to other attendees. By the way, I will not be there, because of a meeting I must attend on Monday that is all day, and causes me to miss the last flight. On Wed, 2 Apr 1997, Tom Hastings wrote: > I'm terribly embarrassed, but I didn't make the IETF cutoff time > for the Job Monitoring MIB. > > I just talked to Steve Coya of the IETF staff. > He said that there is no problem with discussing what was supposed to > be the I-D, at the IETF meeting next week, as long as the printmib > chair (Chris Wellens and Don) agree. Most chairs don't have a problem > with discussing papers that aren't I-Ds. The unfortunate thing is that > we don't get feed back from non-PWG members. Ok Chris to discuss the > Job Monitoring MIB draft at the printmib meeting next week, even though > it wasn't posted as an Internet Draft? I don't know how we can advertize > the location of the document on the pwg server to others who might attend. > > Also we have to resubmit the draft after the meeting. The IETF doesn't > keep a queue. I suggest that we submit it as soon as we can, in order > to get more IETF feed back, rather than waiting for the next IETF meeting > where all the I-Ds get bunched up. > > What happened: > > Steve said that my Email didn't > make the 5:00 pm EST (2:00 pm PST) cutoff time by 4 minutes on > March 26. The IETF looks at the posting time, not the arrival time, > so mail delays don't enter in. > > Unfortuantely, when I went to send the I-D at 1:50 pm PST, my mail > server was down, even though everything else on my Sun workstation was > working fine. So I had to copy the file to a diskette and send it from > Stan's PC. By that time, I had run past 5:00 pm by 4 minutes. I've never > seen this problem before. Sorry. > > Even if I had gotten it posted, it still had the overstrike formatting > problem. While I think it could have been printed ok, it isn't readable > on a screen. The lines that are overstruck with CR and a bunch of spaces > appear on the next line on the screen. I'm in the process of getting a > program to undo overstrikes that the Generic text print driver uses > to output page number, cross reference page numbers, and tables. I will > make this program available for all to use along with the cscan and maxln > tools I have already contributed (courtesy of Ira McDonald). > I had removed all bolding, since I knew that the generic print driver > sends three lines with the bold material present on the second and third > pass. > > BTW we should add these tools for creating I-Ds and RFCs to the PWG > web page for use by all our projects. > > So the document for the IETF printmib meeting next week (and this > week JMP meeting) should be the one that is formatted with TimesRoman > font: > > ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf > > (and has the cover page that is not part of the I-D and has the change > history that is not part of the I-D.) > > NOT the one formatted with the fixed pitch Courier throughout: > > ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito > ring-00.pdf > > Steve said to resubmit as 00.txt after April 14 including any changes > we want to make (which may be considerable after Harry's presentation). > > Tom > > From harryl at us.ibm.com Thu Apr 3 15:19:27 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Resource table - Missile or Camera In-Reply-To: Resource table - Missile or Camera> Message-ID: <5030100001147543000002L032*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Tom, I think you missed my point here, TOM SAID >By the way all of the attributes that you listed are the ones for >which we don't have separate attributes (or multiple entries) for >requested vs. consumed. In otherwords, the same entry is used for >both (and the requested and consumed value should be the same, so it >wasn't worth having two enums for each. See Ron Berman mail on this >subject. HARRY HAD SAID >>I do not understand the need for requested values for any of the >>following "attributes" within the context of a resource accounting >>table such as we have defined. >> >>>Most attributes are either the requested value or the consumed (updated >>>as the job progresses), but not both. The only attributes that are both >>>requested/used are: >> >>>outputBinIndex*56 >>>outputBinIndex*56 >>>outputBinName*56 >>>sides*56 >>>documentFormatIndex*56 >>>documentFormatEnum*56 >>>physicalDeviceIndex*57 >>>physicalDeviceName*57 Key word in my statements is REQUESTED. I was trying to make the point, regarding requested/consumed, that requested is unnessary for these attributes. Can you give me an example of why they would be needed? Harry Lewis - IBM Printing Systems From rturner at sharplabs.com Fri Apr 4 17:29:52 1997 From: rturner at sharplabs.com (Randy Turner) Date: Wed May 6 14:00:03 2009 Subject: JMP> [Fwd: Expression MIB] Message-ID: <5030100001147543000002L032*@MHS> This is a multi-part message in MIME format. --------------5FD172769 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------5FD172769 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from slafw.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by sla5c.enet.sharplabs.com (8.8.4/8.8.4) with ESMTP id FAA00847 for ; Wed, 2 Apr 1997 05:28:32 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by slafw.sharplabs.com (8.8.4/8.7.3) with ESMTP id FAA05806 for ; Wed, 2 Apr 1997 05:34:48 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA16087; Wed, 2 Apr 1997 08:18:15 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id IAA08886 for disman-out; Wed, 2 Apr 1997 08:17:25 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA08875 for ; Wed, 2 Apr 1997 08:17:18 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id IAA01699 for ; Wed, 2 Apr 1997 08:17:51 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA20285 for ; Wed, 2 Apr 1997 05:17:46 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 1997 08:16:42 -0500 To: Distributed Management WG From: Bob Stewart Subject: Expression MIB Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Internet Draft Expression MIB 26 March 1997 Expression MIB 26 March 1997 draft-ietf-disman-express-mib-00.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires 26 March 1997+6 months [Page 1] Internet Draft Expression MIB 26 March 1997 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. Expires 26 March 1997+6 months [Page 2] Internet Draft Expression MIB 26 March 1997 2. The SNMP Network Management Framework They are: The SNMP Network Management Framework presently consists of three major components. They are: the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 26 March 1997+6 months [Page 3] Internet Draft Expression MIB 26 March 1997 3. Overview The MIB was designed around the basic premise that an evaluated expression should result in a MIB object that appears no different from any other and is thus usable anywhere any other MIB object can be used, whether by a management application directly or via another MIB. Note that the operation of this MIB depends on the ability to use OID fragments, that is, a part of an OID that may be missing the usual prefix starting with iso. It is the opinion of the author that such a use is legitimate even if it violates some pure definition of ASN.1, since SNMP's use of ASN.1 is colloquial, not standard. The more important test is whether implementations can readily handle such OID fragments, and I believe they should be able to. Expires 26 March 1997+6 months [Page 4] Internet Draft Expression MIB 26 March 1997 4. Definitions EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, AutonomousType, DisplayString, FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF expressionMIB MODULE-IDENTITY LAST-UPDATED "9703141700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for defining expressions of MIB objects for network management purposes." ::= { experimental xx } ExpressionName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identification for an expression. An ExpressionName corresponds one-to-one to an ExpressionIndex. This is the reliable identification of an expression, subject to change only by administrative request." SYNTAX DisplayString (SIZE (1..64)) ExpressionIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer shorthand identification for an expression. An ExpressionIndex corresponds one-to-one to an ExpressionName. A system may change the value of an ExpressionIndex when it is reinitialized but must correct all references to that ExpressionIndex." Expires 26 March 1997+6 months [Page 5] Internet Draft Expression MIB 26 March 1997 SYNTAX Unsigned32 (1..4294967295) ExpressionIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Either an ExpressionIndex or zero. The meaning of zero depends on the DESCRIPTION of the object." SYNTAX Unsigned32 (0..4294967295) expressionMIBObjects OBJECT IDENTIFIER ::= { expressionMIB 1 } expCreate OBJECT IDENTIFIER ::= { expressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { expressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { expressionMIBObjects 3 } -- -- Creation Table -- expCreateLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an expression was created or deleted or had its name changed using expExpressionName." ::= { expCreate 1 } expCreateTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpCreateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression names, for creating and deleting expressions." ::= { expCreate 2 } expCreateEntry OBJECT-TYPE SYNTAX ExpCreateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. New expressions Expires 26 March 1997+6 months [Page 6] Internet Draft Expression MIB 26 March 1997 can be created using expCreateStatus. To create an expression create the named entry in this table and activate it with RowStatus. Then use expExpressionIndex to populate expExpressionTable expObjectTable. Deleting an entry deletes all related entries in expExpressionTable and expObjectTable." INDEX { IMPLIED expExpressionName } ::= { expCreateTable 1 } ExpCreateEntry ::= SEQUENCE { expCreateName ExpressionName, expExpressionIndex ExpressionIndex, expCreateStatus RowStatus } expCreateName OBJECT-TYPE SYNTAX ExpressionName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. Choosing names with useful lexical ordering supports using GetNext or GetBulk to retrieve a useful subset of the table." ::= { expCreateEntry 1 } expExpressionIndex OBJECT-TYPE SYNTAX ExpressionIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The numeric identification of the expression." ::= { expCreateEntry 2 } expCreateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Activate the entry then use expExpressionIndex to define the expression in expExpressionTable." Expires 26 March 1997+6 months [Page 7] Internet Draft Expression MIB 26 March 1997 ::= { expCreateEntry 3 } -- -- Expression Definition Table -- expExpressionTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression definitions." ::= { expDefine 1 } expExpressionEntry OBJECT-TYPE SYNTAX ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. An entry appears in this table when an expCreateEntry is activated. Deleting the matching expCreateEntry deletes this entry and its associated expObjectTable entries." INDEX { expExpressionIndex } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionName ExpressionName, expExpression DisplayString, expExpressionComment DisplayString, expExpressionPrefix OBJECT IDENIFIER } expExpressionName OBJECT-TYPE SYNTAX ExpressionName MAX-ACCESS read-write STATUS current DESCRIPTION "The unique name of the expression, the same as expCreateName. Use this object to change the expression's name without changing its expExpressionIndex." ::= { expExpressionEntry 1 } Expires 26 March 1997+6 months [Page 8] Internet Draft Expression MIB 26 March 1997 expExpression OBJECT-TYPE SYNTAX DisplayString (SIZE (1..1024)) MAX-ACCESS read-write STATUS current DESCRIPTION "The expression to be evaluated. Except for the variable names the expression is in ANSI C syntax. ANSI C operators and functions are allowed only if explicitly listed here. Variables are expressed as a dollar sign ('$') and an integer that corresponds to an expObjectIndex. An example of a valid expression is: ($1-$5)*100 The only operators and functions allowed are: ( ) + - * / & | ^ << >> ~ ! && || == != > >= < <= Integer-typed object are treated as 32- or 64-bit, signed or unsigned integers, as appropriate. The results of mixing them are as for ANSI C. OCTET STRINGS and OBJECT IDENTIFIERs are treated as arrays of unsigned 8-bit integers and unsigned 32-bit integers, respectively. A short list of array handling functions for comparing and masking are to be defined. Conditional expressions result in a 32-bit, unsigned integer of value 0 for false or 1 for true. When an arbitrary value is used in a boolean expression 0 is false and non-zero is true." DEFVAL { ''H } ::= { expExpressionEntry 2 } expExpressionComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 9] Internet Draft Expression MIB 26 March 1997 "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 3 } expExpressionPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object prefix to assist an application in determining the instance indexing to use in expValueTable, relieving the application of the need to scan the expObjectTable to determine such a prefix. See expObjectTable for information on wildcarded objects. If the expValueInstance portion of the value OID may be treated as a scalar (that is, normally, 0) the value of expExpressionPrefix is 0.0. Otherwise expExpressionPrefix is the value of any wildcarded instance of expObjectID for the expression. This is sufficient as the remainder, that is, the instance fragment relevant to instancing the values must be the same for all wildcarded objects in the expression." ::= { expExpressionEntry 4 } -- -- Object Table -- expObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of object definitions for each expExpression. Wildcarding instance IDs: It is legal to omit all or part of the instance portion for some or all of the objects in an expression. (See the DESCRIPTION of expObjectID for details. However, note that if more than one object in the same expression is wildcarded Expires 26 March 1997+6 months [Page 10] Internet Draft Expression MIB 26 March 1997 in this way, they all must be objects where that portion of the instance is the same. In other words, all objects may be in the same SEQUENCE or in different SEQUENCEs but with the same semantic index value (e.g., the value of ifIndex) for the wildcarded portion." ::= { expDefine 2 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a object. An application creates entries in this table while creating an expression." -- SPARSE-AUGMENTS { expExpressionEntry } INDEX { expExpressionIndex, expObjectIndex } ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectSampleType INTEGER, expObjectDeltaInterval Integer32, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectConditional OBJECT IDENTIFIER, expObjectStatus RowStatus } expObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique, numeric identification for an object. Prefixed with a dollar sign ('$') this is used to reference the object in the corresponding expExpression." ::= { expObjectEntry 1 } expObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of this object. Note that this can be the OID of a leaf object in a MIB (e.g., ifInOctets.1 Expires 26 March 1997+6 months [Page 11] Internet Draft Expression MIB 26 March 1997 or sysUpTime.0). The OID may be fully qualified, meaning it includes an instance identifier part, or it may not be fully qualified, meaning it may lack all or part of the instance identifier. If the expObjectID is not fully qualified, then the value of the expression will be multiple values, as if done for a GetNext sweep of the object." ::= { expObjectEntry 2 } expObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable." DEFVAL { absoluteValue } ::= { expObjectEntry 3 } expObjectDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Sampling interval for objects with expObjectSampleType 'deltaValue'. This object is not instantiated if not applicable. A value of 0 indicates no automated sampling. In this case the delta is the difference from the last time the expression was evaluated. Note that this is subject to unpredictable delta times in the face of retries or multiple managers. A value greater than zero is the number of seconds between automated samples. Until the delta interval has expired once the delta for the object is effectively not instantiated and evaluating the expression has results as if the object itself were not instantiated. Note that delta values potentially consume large amounts of Expires 26 March 1997+6 months [Page 12] Internet Draft Expression MIB 26 March 1997 system CPU and memory. Delta state and processing must continue constantly even if the expression is not being used. For wildcarded objects this can be substantial overhead." DEFVAL { 0 } ::= { expObjectEntry 4 } expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks object that indicates a discontinuity in the value at expObjectID. This object is not instantiated if not applicable. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. DEFVAL { 0 0 } ::= { expObjectEntry 5 } expObjectConditional OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of an object that overrides whether the instance of expObjectID is to be considered usable. If the value of the object at expObjectConditional is 0, the object at expObjectID is treated as if it is not instantiated, otherwise it is treated as usual. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. DEFVAL { 0 0 } ::= { expObjectEntry 5 } expObjectStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { expObjectEntry 7 } Expires 26 March 1997+6 months [Page 13] Internet Draft Expression MIB 26 March 1997 -- -- Expression Value Table -- expValueTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of values from evaluated expressions." ::= { expValue 1 } expValueEntry OBJECT-TYPE SYNTAX ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single value from an evaluated expression. For a given instance, only one "Val" object in the conceptual row will be instantiated, that is, the one with the appropriate type for the value. Reading a value from the table causes the evaluation of the expression for that value. If in the attempt to evaluate the expression one or more of the necessary objects is not available, the corresponding entry in this table is effectively not instantiated." INDEX { expExpressionIndex, expValueInstance } ::= { expValueTable 1 } ExpValueEntry ::= SEQUENCE { expValueInstance OBJECT IDENTIFIER, expValueType INTEGER, expValueUnsigned32Val Unsigned32, expValueInteger32Val Integer32, expValueOctetStringVal OCTET STRING, expValueOidVal OBJECT IDENTIFIER, expValueCounter64Val Counter64 } expValueInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER, MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 14] Internet Draft Expression MIB 26 March 1997 "The final instance portion of a value's OID according to the wildcarding in instances of expObjectID for the expression. If there is no wildcarding, the value is 0.0. If there is wildcarding, the value is 0.0 followed by a value that the wildcard can take, thus defining one value instance for each real, possible value of the wildcard. So, for example, if the wildcard worked out to be an ifIndex, there is an expValueInstance for each applicable ifIndex." ::= { expValueEntry 1 } expValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsignedOrGauge32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow will be valid based on this type." ::= { expValueEntry 2 } expValueUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 -- (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expValueType is one of 'counter32', 'unsignedOrGauge32', or 'timeTicks'." ::= { expValueEntry 3 } expValueInteger32Val OBJECT-TYPE SYNTAX Integer32 -- (-2147483648..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expValueType is 'integer32'." ::= { expValueEntry 4 } expValueOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65536)) MAX-ACCESS read-only STATUS current Expires 26 March 1997+6 months [Page 15] Internet Draft Expression MIB 26 March 1997 DESCRIPTION "The value when expValueType is 'ipAddress' or 'octetString'." ::= { expValueEntry 5 } expValueOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expValueType is 'objectId'." ::= { expValueEntry 6 } expValueCounter64Val OBJECT-TYPE SYNTAX Counter64 -- (0..18446744073709551615) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expValueType is 'counter64'." ::= { expValueEntry 7 } -- The compliance statements have yet to be written. The intent is -- that all objects are required. A proper subset -- of the MIB may disallow instance wildcards, deltaValues, or -- expObjectConditionals. END Expires 26 March 1997+6 months [Page 16] Internet Draft Expression MIB 26 March 1997 5. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 26 March 1997+6 months [Page 17] Internet Draft Expression MIB 26 March 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Expires 26 March 1997+6 months [Page 18] Internet Draft Expression MIB 26 March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 26 March 1997+6 months [Page 19] Internet Draft Expression MIB 26 March 1997 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Network Management Framework ........................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 4 Definitions ..................................................... 5 5 Acknowledgements ................................................ 17 6 References ...................................................... 18 7 Security Considerations ......................................... 19 8 Author's Address ................................................ 19 Expires 26 March 1997+6 months [Page 20] --------------5FD172769-- From rturner at sharplabs.com Fri Apr 4 17:30:06 1997 From: rturner at sharplabs.com (Randy Turner) Date: Wed May 6 14:00:03 2009 Subject: JMP> [Fwd: Event MIB] Message-ID: <5030100001147543000002L032*@MHS> This is a multi-part message in MIME format. --------------774370004D06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------774370004D06 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from slafw.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by sla5c.enet.sharplabs.com (8.8.4/8.8.4) with ESMTP id FAA00852 for ; Wed, 2 Apr 1997 05:28:35 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by slafw.sharplabs.com (8.8.4/8.7.3) with ESMTP id FAA05805 for ; Wed, 2 Apr 1997 05:34:37 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA16074; Wed, 2 Apr 1997 08:18:12 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id IAA08885 for disman-out; Wed, 2 Apr 1997 08:17:21 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA08856 for ; Wed, 2 Apr 1997 08:17:14 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id IAA01695 for ; Wed, 2 Apr 1997 08:17:47 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA20280 for ; Wed, 2 Apr 1997 05:17:39 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 1997 08:15:52 -0500 To: Distributed Management WG From: Bob Stewart Subject: Event MIB Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Internet Draft Event MIB 26 March 1997 Event MIB 26 March 1997 draft-ietf-disman-event-mib-00.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires 26 March 1997+6 months [Page 1] Internet Draft Event MIB 26 March 1997 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing monitoring of MIB objects and taking action through events. Expires 26 March 1997+6 months [Page 2] Internet Draft Event MIB 26 March 1997 2. The SNMP Network Management Framework They are: The SNMP Network Management Framework presently consists of three major components. They are: the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 26 March 1997+6 months [Page 3] Internet Draft Event MIB 26 March 1997 3. Overview This MIB is based heavily on the RMON and Manager-to-Manager MIBs. It depends on the services of the Target, Notification, and Expression MIBs. All of this must suit either a relatively powerful manager or mid-level manager, as well as a somewhat more limited self-managing system. Expires 26 March 1997+6 months [Page 4] Internet Draft Event MIB 26 March 1997 4. Definitions EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32 NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, DisplayString, AutonomousType, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF EntryIndex, EntryName, EntryIndexOrZero FROM MANAGEMENT-TARGET-MIB FailureReason FROM NOTIFICATION-MIB eventMIB MODULE-IDENTITY LAST-UPDATED "9703241700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes." ::= { experimental xx } eventMIBObjects OBJECT IDENTIFIER ::= { eventMIB 1 } mteTrigger OBJECT IDENTIFIER ::= { eventMIBObjects 1 } mteEvent OBJECT IDENTIFIER ::= { eventMIBObjects 2 } -- -- Trigger Section -- mteTriggerLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent addition or Expires 26 March 1997+6 months [Page 5] Internet Draft Event MIB 26 March 1997 deletion of a trigger or a trigger name change. A management application can monitor this object to know that the trigger list has changed in a way requiring reloading of the trigger names." ::= { mteTrigger 1 } mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to check for a trigger condition has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded object." ::= { mteTrigger 2 } mteTriggerLastFailedTrigger OBJECT-TYPE SYNTAX triggerIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The trigger that last failed an attempt to check for a trigger condition." ::= { mteTrigger 3 } mteTriggerLastFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS read-only STATUS current DESCRIPTION "The reason for the last failure of an attempt to check for a trigger condition." ::= { mteTrigger 4 } mteTriggerLastFailedTargetGroup OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The target group of the last failed attempt to check a trigger condition. The value 0 means this does not apply." ::= { mteTrigger 5 } Expires 26 March 1997+6 months [Page 6] Internet Draft Event MIB 26 March 1997 mteTriggerLastFailedTargetScope OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The target scope of the last failed attempt to check a trigger condition. The value 0 means this does not apply" ::= { mteTrigger 6 } mteTriggerLastValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifier from mteTriggerValueID from the last attempt to check a trigger condition. This must be as full-qualified as possible, including filling in wild-card information determined in processing." ::= { mteTrigger 7 } mteTriggerLastValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS notification-only STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fires." ::= { mteTrigger 8 } mteTriggerTargetScope OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS notification-only STATUS current DESCRIPTION "The targetIndex of the scope for which the trigger fires or for which a check was attempted." ::= { mteTrigger 9 } -- -- Trigger Creation Table -- mteTriggerCreationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerCreationEntry Expires 26 March 1997+6 months [Page 7] Internet Draft Event MIB 26 March 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of triggers for network management events." ::= { mteTrigger 10 } mteTriggerCreationEntry OBJECT-TYPE SYNTAX MteTriggerCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger. To create an entry create the named entry in this table and activate it with mteTriggerCreationStatus. Then use mteTriggerIndex to populate mteTriggerTable. Deleting an entry deletes the related entry in mteTriggerTable." INDEX { IMPLIED mteTriggerCreationName } ::= { mteTriggerCreationTable 1 } MteTriggerCreationEntry ::= SEQUENCE { mteTriggerCreationName EntryName, mteTriggerIndex EntryIndex, mteTriggerCreationStatus RowStatus } mteTriggerCreationName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the trigger." ::= { mteTriggerCreationEntry 1 } mteTriggerIndex OBJECT-TYPE SYNTAX EntryIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The numeric identification of the trigger." ::= { mteTriggerCreationEntry 2 } mteTriggerCreationStatus OBJECT-TYPE Expires 26 March 1997+6 months [Page 8] Internet Draft Event MIB 26 March 1997 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Once made active an entry may not be modified except to delete it or change its name via mteTriggerName." ::= { mteTriggerCreationEntry 3 } -- -- Trigger Table -- mteTriggerTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information." ::= { mteTrigger 11 } mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management event trigger. An entry appears in this table when an mteTriggerCreationEntry is activated. Deleting the matching mteTriggerCreationEntry deletes this entry." INDEX { mteTriggerIndex } ::= { mteTriggerteble 1 } MteTriggerEntry ::= SEQUENCE { mteTriggerName EntryName, mteTriggerComment DisplayString, mteTriggerTest INTEGER, mteTriggerValueID Integer32, mteTriggerFrequency Integer32, mteTriggerTarget EntryIndexOrZero, mteTriggerRisingThreshold Integer32, mteTriggerFallingThreshold Integer32, mteTriggerEvent EntryIndexOrZero, mteTriggerRisingEvent EntryIndexOrZero, Expires 26 March 1997+6 months [Page 9] Internet Draft Event MIB 26 March 1997 mteTriggerFallingEvent EntryIndexOrZero } mteTriggerName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS read-write STATUS current DESCRIPTION "The unique name of the target trigger, identical to mteTriggerCreationName. Use this object to change the trigger's mteTriggerCreationName without changing its mteTriggerIndex." ::= { mteTriggerEntry 1 } mteTriggerComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 2 } mteTriggerTest OBJECT-TYPE SYNTAX INTEGER { boolean(1), threshold(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of trigger test to perform. For all tests, mteTriggerValue must evaluate to an integer. For 'boolean', a value of 0 is false. A non-zero value is true and fires the trigger. For 'threshold' it works like RMON and the text needs to be copied into this MIB." DEFVAL { boolean } ::= { mteTriggerEntry 3 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 10] Internet Draft Event MIB 26 March 1997 "The object identifier of the MIB object to check to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the condition is obtained as if with a GetNext function, checking multiple values if they exist." DEFVAL { 0 0 } ::= { mteTriggerEntry 4 } mteTriggerFrequency OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of seconds to wait between trigger condition checks. To encourage consistency in sampling, the interval is measured from the beginning of one check to the beginning of the next." DEFVAL { 600 } ::= { mteTriggerEntry 5 } mteTriggerTarget OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The targetIndex of the scope or group of scopes from which to obtain the condition for a trigger check. A value of 0 indicates the local system." DEFVAL { 0 } ::= { mteTriggerEntry 6 } mteTriggerRisingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. In this case if the value of the object at mteTriggerValueID is greater than or equal to this threshold and the value at the last sampling interval was less than this threshold, one mteTriggerRisingEvent is triggered. Expires 26 March 1997+6 months [Page 11] Internet Draft Event MIB 26 March 1997 If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 7 } mteTriggerFallingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. In this case if the value of the object at mteTriggerValueID is less than or equal to this threshold and the value at the last sampling interval was greater than this threshold, one mteTriggerFallingEvent is triggered. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 8 } mteTriggerEvent OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'boolean' and this trigger fires. A value of 0 indicates no event. If mteTriggerType is not 'boolean', this object is not instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 9 } mteTriggerRisingEvent OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerRisingThreshold. A value of 0 indicates no event. If mteTriggerType is not 'threshold', this object is not instantiated." Expires 26 March 1997+6 months [Page 12] Internet Draft Event MIB 26 March 1997 DEFVAL { 0 } ::= { mteTriggerEntry 10 } mteTriggerFallingEvent OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerFallingThreshold. A value of 0 indicates no event. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 11 } -- -- Event Section -- mteEventLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent addition or deletion of an event or an event name change. A management application can monitor this object to know that the event list has changed in a way requiring reloading of the event names." ::= { mteEvent 1 } mteEventFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to invoke an event has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded trigger object." ::= { mteEvent 2 } Expires 26 March 1997+6 months [Page 13] Internet Draft Event MIB 26 March 1997 mteEventLastFailedEvent OBJECT-TYPE SYNTAX eventIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The event that last failed an attempted invocation." ::= { mteEvent 3 } mteEventLastFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS read-only STATUS current DESCRIPTION "The reason for the last failure of an attempted event invocation." ::= { mteEvent 4 } mteEventLastFailedTargetGroup OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The target group of the last failed attempt to invoke an event. The value 0 means this does not apply." ::= { mteEvent 5 } mteEventLastFailedTargetScope OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The target scope of the last failed attempt to invoke an event. The value 0 means this does not apply" ::= { mteEvent 6 } -- -- Event Creation Table -- mteEventCreationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of events for network management action." Expires 26 March 1997+6 months [Page 14] Internet Draft Event MIB 26 March 1997 ::= { mteEvent 7 } mteEventCreationEntry OBJECT-TYPE SYNTAX MteEventCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event. To create an entry create the named entry in this table and activate it with mteEventCreationStatus. Then use mteEventIndex to populate mteEventTable. Deleting an entry deletes the related entry in mteEventTable." INDEX { IMPLIED mteEventCreationName } ::= { mteEventCreationTable 1 } MteEventCreationEntry ::= SEQUENCE { mteEventCreationName EntryName, mteEventIndex EntryIndex, mteEventCreationStatus RowStatus } mteEventCreationName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventCreationEntry 1 } mteEventIndex OBJECT-TYPE SYNTAX EntryIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The numeric identification of the event." ::= { mteEventCreationEntry 2 } mteEventCreationStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 15] Internet Draft Event MIB 26 March 1997 "The control that allows creation/deletion of entries. Once made active an entry may not be modified except to delete it or change its name via mteEventName." ::= { mteEventCreationEntry 3 } -- -- Event Table -- mteEventTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 3 } mteEventEntry OBJECT-TYPE SYNTAX MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management event's actions. An entry appears in this table when an mteEventCreationEntry is activated. Deleting the matching mteEventCreationEntry deletes this entry." INDEX { mteEventIndex } ::= { mteEventTable 1 } MteEventEntry ::= SEQUENCE { mteEventName EntryName, mteEventComment DisplayString, mteEventActions BITS, mteEventNotification OBJECT IDENTIFIER, mteEventSetObject OBJECT IDENTIFIER, mteEventSetValue Integer32, mteEventTarget EntryIndexOrZero } mteEventName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS read-write STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 16] Internet Draft Event MIB 26 March 1997 "The unique name of the event, identical to mteEventCreationName. Use this object to change the event's mteEventCreationName without changing its mteEventIndex." ::= { mteEventEntry 1 } mteEventComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the event's function and use." DEFVAL { ''H } ::= { mteEventEntry 2 } mteEventActions OBJECT-TYPE SYNTAX BITS { notification, trap, inform, set } MAX-ACCESS read-write STATUS current DESCRIPTION "The actions to peform when this event occurs. For 'notification', Traps and/or Informs are sent according to the configuration in the Notification MIB.. For 'trap', Traps are sent unless the Notification MIB has the Trap 'hardDisabled' or there are no targets for it. For 'inform', Informs are sent unless the Notification MIB has the Inform 'hardDisabled' or there are no targets for it. For 'set', an SNMP Set operation is performed according to control values in this entry." DEFVAL { 0 } ::= { mteEventEntry 3 } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if metEventActions has 'notification', 'trap', or 'inform' set. Expires 26 March 1997+6 months [Page 17] Internet Draft Event MIB 26 March 1997 If none of the above bits are set, this object is not instantiated." DEFVAL { 0 0 } ::= { mteEventEntry 4 } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the MIB object to set if metEventActions has 'set' set. If 'set' is not set, this object is not instantiated." DEFVAL { 0 0 } ::= { mteEventEntry 5 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObect." DEFVAL { 0 } ::= { mteEventEntry 6 } mteEventSetTarget OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "A scope or group of scopes in which to the object at mteEventSetObject to mteEventSetValue. A value of 0 indicates the local system." DEFVAL { 0 } ::= { mteEventEntry 7 } -- -- Notifications -- eventMIBNotificationPrefix OBJECT IDENTIFIER ::= { eventMIB 2 } eventMIBNotifications OBJECT IDENTIFIER ::= { eventMIBNotificationPrefix 0 } Expires 26 March 1997+6 months [Page 18] Internet Draft Event MIB 26 March 1997 mteTriggerSenseAlarm NOTIFICATION-TYPE OBJECTS { mteTriggerName, mteTriggerTargetScope, mteTriggerLastValueID, mteTriggerLastValue } STATUS current DESCRIPTION "Notification that the trigger indicated by the object instances has fired, for triggers with mteTriggerType 'boolean'." ::= { eventMIBNotifications 1 } mteTriggerRisingAlarm NOTIFICATION-TYPE OBJECTS { mteTriggerName, mteTriggerTargetScope, mteTriggerLastValueID, mteTriggerLastValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { eventMIBNotifications 2 } mteTriggerFallingAlarm NOTIFICATION-TYPE OBJECTS { mteTriggerName, mteTriggerTargetScope, mteTriggerLastValueID, mteTriggerLastValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { eventMIBNotifications 3 } mteTriggerFailureAlarm NOTIFICATION-TYPE OBJECTS { mteTriggerName, mteTriggerLastFailedReason, mteTriggerLastFailedTargetGroup, mteTriggerLastFailedTargetScope, mteTriggerLastFailedValueID } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with Expires 26 March 1997+6 months [Page 19] Internet Draft Event MIB 26 March 1997 a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { eventMIBNotifications 4 } mteEventFailureAlarm NOTIFICATION-TYPE OBJECTS { mteTriggerName, mteTriggerTargetScope, mteTriggerLastValueID, mteTriggerLastValue, mteEventLastFailedReason, mteEventLastFailedTargetGroup, mteEventLastFailedTargetScope } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { eventMIBNotifications 5 } -- The compliance statements have yet to be written. The intent is -- that all objects are required except where otherwise mentioned above -- and that a self-managing system need not support groups, remote checking, -- or wildcarding. END Expires 26 March 1997+6 months [Page 20] Internet Draft Event MIB 26 March 1997 5. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 26 March 1997+6 months [Page 21] Internet Draft Event MIB 26 March 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Expires 26 March 1997+6 months [Page 22] Internet Draft Event MIB 26 March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 26 March 1997+6 months [Page 23] Internet Draft Event MIB 26 March 1997 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Network Management Framework ........................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 4 Definitions ..................................................... 5 5 Acknowledgements ................................................ 21 6 References ...................................................... 22 7 Security Considerations ......................................... 23 8 Author's Address ................................................ 23 Expires 26 March 1997+6 months [Page 24] --------------774370004D06-- From rturner at sharplabs.com Fri Apr 4 17:30:22 1997 From: rturner at sharplabs.com (Randy Turner) Date: Wed May 6 14:00:03 2009 Subject: JMP> [Fwd: Management Target MIB] Message-ID: <5030100001147543000002L032*@MHS> This is a multi-part message in MIME format. --------------1BD11DE0524B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------1BD11DE0524B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from slafw.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by sla5c.enet.sharplabs.com (8.8.4/8.8.4) with ESMTP id FAA00856 for ; Wed, 2 Apr 1997 05:29:59 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by slafw.sharplabs.com (8.8.4/8.7.3) with ESMTP id FAA05810 for ; Wed, 2 Apr 1997 05:36:09 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA16004; Wed, 2 Apr 1997 08:17:50 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id IAA08833 for disman-out; Wed, 2 Apr 1997 08:17:00 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA08824 for ; Wed, 2 Apr 1997 08:16:57 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id IAA01687 for ; Wed, 2 Apr 1997 08:17:29 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA20274 for ; Wed, 2 Apr 1997 05:17:21 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 1997 08:13:54 -0500 To: Distributed Management WG From: Bob Stewart Subject: Management Target MIB Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Internet Draft Management Target MIB 26 March 1997 Management Target MIB 26 March 1997 draft-ietf-disman-mgt-target-mib-00.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires 26 March 1997+6 months [Page 1] Internet Draft Management Target MIB 26 March 1997 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing a list of network management destinations (targets) and the information needed to get to them and to group them. Expires 26 March 1997+6 months [Page 2] Internet Draft Management Target MIB 26 March 1997 2. The SNMP Network Management Framework They are: The SNMP Network Management Framework presently consists of three major components. They are: the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 26 March 1997+6 months [Page 3] Internet Draft Management Target MIB 26 March 1997 3. Overview Systems that support SNMP commonly need a list of target systems to which they can send SNMP messages. On system that performs only agent functions this need is for Traps, which requires a subset of the information appropriate to a system that sends manager messages. A system that sends only Inform of the manager messages needs less than a more general-purpose manager. This MIB is designed with explicit subsets for those situations. This MIB provides infrastructure for other MIBs in the form of target systems or groups of target systems that can be destinations for SNMP requests and notifications. It was designed with the following requirements and goals in mind. To address an SNMP message you need: transport type, address, and port access control (e.g. community) All of those should be embodied in the selector. Selection needs to be by some scoping related to a logical entity, but with finer granularity based on level of access (e.g. read-only or read-write). Selection should work the same for an individual scope or a group of scopes. Defining a group must work by manual assignment or automation. All of this must suit either a relatively powerful manager or mid-level manager, as well as a somewhat more limited self-managing system. Expires 26 March 1997+6 months [Page 4] Internet Draft Management Target MIB 26 March 1997 4. Definitions MANAGEMENT-TARGET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, DisplayString, AutonomousType, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF managementTargetMIB MODULE-IDENTITY LAST-UPDATED "9703211700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for defining destination systems for network management purposes." ::= { experimental xx } EntryName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identification for an entry. An EntryName corresponds one-to-one to an EntryIndex. Names are intended for display for humans and should have meaninful content accordingly. If by policy names are selected with a useful sorting order applications can easily retreive only the currently interesting subset of the list. This is the reliable identification of an entry, subject to change only by administrative request." SYNTAX DisplayString (SIZE (1..64)) EntryIndex ::= TEXTUAL-CONVENTION STATUS current Expires 26 March 1997+6 months [Page 5] Internet Draft Management Target MIB 26 March 1997 DESCRIPTION "An integer shorthand identification for an entry. An EntryIndex corresponds one-to-one to an EntryName. Indexes are intended for use by computers as a short, convenient handle. They are of no interest to humans. An index may be assigned convenient values by the agent. A system may change the value of an EntryIndex when it is reinitialized but must correct all references to that EntryIndex." SYNTAX Unsigned32 (1..4294967295) EntryIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Either an EntryIndex or zero. The meaning of zero depends on the DESCRIPTION of the object." SYNTAX Unsigned32 (0..4294967295) IANAAddrFamily ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An address family. Values are defined in Assigned Numbers, RFC1700. Note that not all these values make sense in all contexts where this type is used in this MIB, but they are included for completeness." REFERENCE "Assigned Numbers, RFC1700, ADDRESS FAMILY NUMBERS" SYNTAX INTEGER { other(0), ipV4(1), ipV6(2), nsap(3), hdlc(4), bbn1822(5), ieee802(6), e163(7), e164(8), f69(9), x121(10), ipx(11), Expires 26 March 1997+6 months [Page 6] Internet Draft Management Target MIB 26 March 1997 appleTalk(12), decnetIV(13), banyanVines(14), e164WithNsap(15) } GenAddr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of an address." SYNTAX OCTET STRING (SIZE (0..60)) managementTargetMIBObjects OBJECT IDENTIFIER ::= { managementTargetMIB 1 } mtaSystem OBJECT IDENTIFIER ::= { targetMIBObjects 1 } mtaTarget OBJECT IDENTIFIER ::= { targetMIBObjects 2 } -- -- System Section -- mtaSystemLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent addition or deletion of a system or a system name change. A management application can monitor this object to know that the system list has changed in a way requiring reloading of the system names." ::= { mtaSystem 1 } -- -- System Creation Table -- mtaSystemCreationTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaSystemCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of systems of interest to the local system as destinations for management operations." Expires 26 March 1997+6 months [Page 7] Internet Draft Management Target MIB 26 March 1997 ::= { mtaSystemCreationCreation 2 } mtaSystemCreationEntry OBJECT-TYPE SYNTAX MtaSystemCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management target. Entries in this table may be created manually or by network management applications such as discovery. New targets can be created using mtaSystemCreationStatus. To create an entry create the named entry in this table and activate it with mtaSystemCreationStatus. Then use mtaSystemIndex to populate mtaSystemTable and mtaSystemAddressTable. Deleting an entry deletes all related entries in mtaSystemTable and mtaSystemAddressTable." INDEX { IMPLIED mtaSystemCreationName } ::= { mtaSystemCreationTable 1 } MtaSystemCreationEntry ::= SEQUENCE { mtaSystemCreationName EntryName, mtaSystemIndex EntryIndex, mtaSystemCreationStatus RowStatus } mtaSystemCreation OBJECT-TYPE SYNTAX EntryName MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the system." ::= { mtaSystemCreationEntry 1 } mtaSystemIndex OBJECT-TYPE SYNTAX EntryIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The numeric identification of the system." ::= { mtaSystemCreationEntry 2 } Expires 26 March 1997+6 months [Page 8] Internet Draft Management Target MIB 26 March 1997 mtaSystemCreationStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Once made active an entry may not be modified except to delete it or change its name via mtaSystemName." ::= { mtaSystemCreationEntry 3 } -- -- System Table -- mtaSystemTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaSystemEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target system information." ::= { mtaSystem 3 } mtaSystemEntry OBJECT-TYPE SYNTAX MtaSystemEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management target system. An entry appears in this table when an mtaSystemCreationEntry is activated. Deleting the matching expCreateEntry deletes this entry." INDEX { mtaSystemIndex } ::= { mtaSystemTable 1 } MtaSystemEntry ::= SEQUENCE { mtaSystemName EntryName, mtaSystemAlgorithm AutonomousType, mtaSystemCreateTime DateAndTime, mtaSystemLastContact DateAndTime, mtaSystemSysContact DisplayString, mtaSystemSysLocation DisplayString, mtaSystemSysObjectID OBJECT IDENTIFIER, mtaSystemDomainName DisplayString } Expires 26 March 1997+6 months [Page 9] Internet Draft Management Target MIB 26 March 1997 mtaSystemName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS read-write STATUS current DESCRIPTION "The unique name of the target system, identical to mtaSystemCreationName. Use this object to change the system's mtaSystemCreationName without changing its mtaSystemIndex." ::= { mtaSystemEntry 1 } -- Note: The remaining objects in this table are required only on -- systems that manage other systems and have extensive needs -- for automated group definitions. mtaSystemAlgorithm OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS current DESCRIPTION "The algorithm by which this entry was created. The value 0.0 indicates a manual entry." DEFVAL { 0 0 } ::= { mtaSystemEntry 2 } mtaSystemCreationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this entry was created. This is a date and time so it has long term significance and on the assumption that a manager will have that information." DEFVAL { ''H } ::= { mtaSystemEntry 3 } mtaSystemLastContact OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the last successful management contact with the system. This is a date and time so it has long term significance and on the assumption that a manager will have Expires 26 March 1997+6 months [Page 10] Internet Draft Management Target MIB 26 March 1997 that information." DEFVAL { ''H } ::= { mtaSystemEntry 4 } mtaSystemSysContact OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The system's sysContact value." ::= { mtaSystemEntry 5 } mtaSystemSysLocation OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The system's sysLocation value." ::= { mtaSystemEntry 6 } mtaSystemSysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The system's sysObjectID value." ::= { mtaSystemEntry 7 } mtaSystemDomainName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The system's fully-qualified domain name." ::= { mtaSystemEntry 8 } -- -- Addressing Table -- mtaAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 11] Internet Draft Management Target MIB 26 March 1997 "A table of address information for either SNMP managers or SNMP agents on individual target systems. Entries may be created manually or by an application using mtaAddressRowStatus." ::= { mtaSystem 3 } mtaAddressEntry OBJECT-TYPE SYNTAX MtaAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management target system. An entry appears in this table when an mtaSystemCreationEntry is activated. Deleting the matching expCreateEntry deletes this entry." INDEX { mtaSystemIndex, mtaAddressIndex } ::= { mtaAddressTable 1 } MtaAddressEntry ::= SEQUENCE { mtaIndex Unsigned32, mtaAddressType IANAAddrFamily, mtaAddressAddr GenAddress, mtaAddressPort Unsigned32, mtaAddressRetransAlgorithm INTEGER, mtaAddressRetransTimer Integer32, mtaAddressRetransMaxRetries Integer32, mtaAddressStatus RowStatus } mtaAddressIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer index to distinguish multiple address entries for the same system." ::= { mtaAddressEntry 1 } mtaAddressType OBJECT-TYPE SYNTAX IANAAddrFamily MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the address contained in mtaAddressAddr." Expires 26 March 1997+6 months [Page 12] Internet Draft Management Target MIB 26 March 1997 DEFVAL { snmpUDPDomain } ::= { mtaAddressEntry 2 } mtaAddressAddr OBJECT-TYPE SYNTAX GenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "A management address for the manager or agent. A zero-length string indicates an unknown address." DEFVAL { ''H } ::= { mtaAddressEntry 3 } mtaAddressPort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A port number to use with the transport address. If not explicitly set this object is not instantiated." ::= { mtaAddressEntry 4 } mtaAddressRetransAlgorithm OBJECT-TYPE SYNTAX INTEGER { constant(1), expBackOff(2), randomBackOff(3), other(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The algorithm to use for retransmission to this system." DEFVAL { constant } ::= { mtaAddressEntry 5 } mtaAddressRetransTimer OBJECT-TYPE SYNTAX Integer32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum number of seconds to wait between retransmit attempts." DEFVAL { 2 } Expires 26 March 1997+6 months [Page 13] Internet Draft Management Target MIB 26 March 1997 ::= { mtaAddressEntry 6 } mtaAddressRetransMaxRetries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) UNITS "retries" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times to resend a message to this manager or agent before deciding it is undeliverable. A value of -1 indicates retrying forever." DEFVAL { 2 } ::= { mtaAddressEntry 7 } mtaAddressStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { mtaAddressEntry 8 } -- -- Target Section -- mtaTargetLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent addition or deletion of a target or a target name change. A management application can monitor this object to know that the target list has changed in a way requiring reloading of the target names." ::= { mtaTarget 1 } -- -- Target Creation Table -- mtaTargetCreationTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaTargetCreationEntry Expires 26 March 1997+6 months [Page 14] Internet Draft Management Target MIB 26 March 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of targets of interest to the local system as destinations for management operations." ::= { mtaTarget 2 } mtaTargetCreationEntry OBJECT-TYPE SYNTAX MtaTargetCreationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management target. Entries in this table may be created manually or by network management applications such as discovery. New targets can be created using mtaTargetCreationStatus. To create an entry create the named entry in this table and activate it with mtaTargetCreationStatus. Then use mtaTargetIndex to populate mtaTargetTable and mtaTargetAddressTable. Deleting an entry deletes all related entries in mtaTargetTable, mtaScopeTable, mtaScopeCommunityTable, mtaGroupRuleTable, and mtaGroupMemberTable." INDEX { IMPLIED mtaTargetCreationName } ::= { mtaTargetCreationTable 1 } MtaTargetCreationEntry ::= SEQUENCE { mtaTargetCreationName EntryName, mtaTargetIndex EntryIndex, mtaTargetCreationStatus RowStatus } mtaTargetCreationName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the target." ::= { mtaTargetCreationEntry 1 } mtaTargetIndex OBJECT-TYPE SYNTAX EntryIndex Expires 26 March 1997+6 months [Page 15] Internet Draft Management Target MIB 26 March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The numeric identification of the target." ::= { mtaTargetCreationEntry 2 } mtaTargetCreationStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Once made active an entry may not be modified except to delete it or change its name via mtaTargetName." ::= { mtaTargetCreationEntry 3 } -- -- Target Table -- mtaTargetTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaTargetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target information." ::= { mtaTarget 3 } mtaTargetEntry OBJECT-TYPE SYNTAX MtaTargetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management target. An entry appears in this table when an mtaTargetCreationEntry is activated. Deleting the matching mtaTargetCreationEntry deletes this entry." INDEX { mtaTargetIndex } ::= { mtaTargetTable 1 } MtaTargetEntry ::= SEQUENCE { mtaTargetName EntryName, mtaTargetType INTEGER, mtaTargetAccess BITS, Expires 26 March 1997+6 months [Page 16] Internet Draft Management Target MIB 26 March 1997 mtaTargetVersion INTEGER } mtaTargetName OBJECT-TYPE SYNTAX EntryName MAX-ACCESS read-write STATUS current DESCRIPTION "The unique name of the target, identical to mtaTargetCreationName. Use this object to change the target's mtaTargetCreationName without changing its mtaTargetIndex." ::= { mtaTargetEntry 1 } mtaTargetType OBJECT-TYPE SYNTAX INTEGER { scope(1), group(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The target type, either an individual scope or a group of scopes and groups." DEFVAL { scope } ::= { mtaTargetEntry 2 } mtaTargetAccess OBJECT-TYPE SYNTAX BITS { readOnly, readWrite, notification } MAX-ACCESS read-write STATUS current DESCRIPTION "The access allowed to the target. All scopes in a group must have the same mtaTargetAccess." DEFVAL { 0 } ::= { mtaTargetEntry 3 } mtaTargetVersion OBJECT-TYPE SYNTAX INTEGER { community(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "The access control version applicable to the target. The value 'community' indicates SNMPv1 or SNMPv2c. The necessary information is in mtaScopeCommunityTable. Expires 26 March 1997+6 months [Page 17] Internet Draft Management Target MIB 26 March 1997 All scopes in a group must have the same mtaTargetVersion." DEFVAL { community } ::= { mtaTargetEntry 4 } -- -- Scope Table -- mtaScopeTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target scope information." ::= { mtaTarget 4 } mtaScopeEntry OBJECT-TYPE SYNTAX MtaScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management scope. An entry appears in this table when an mtaTargetEntry's mtaTargetType is set to 'scope'. Setting that object to a different value deletes this entry." INDEX { mtaTargetIndex } ::= { mtaScopeTable 1 } MtaScopeEntry ::= SEQUENCE { mtaScopeSystemIndex EntryIndex } mtaScopeSystemIndex OBJECT-TYPE SYNTAX EntryIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The system that supports this scope." ::= { mtaScopeEntry 1 } -- -- Scope Community Table -- mtaScopeCommunityTable OBJECT-TYPE Expires 26 March 1997+6 months [Page 18] Internet Draft Management Target MIB 26 March 1997 SYNTAX SEQUENCE OF MtaScopeCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target scope community information." ::= { mtaTarget 4 } mtaScopeCommunityEntry OBJECT-TYPE SYNTAX MtaScopeCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Community information about a single management scope. An entry appears in this table when an mtaTargetEntry's mtaTargetVersion is set to 'community'. Setting that object to any other value deletes this entry." INDEX { mtaTargetIndex } ::= { mtaScopeCommunityTable 1 } MtaScopeCommunityEntry ::= SEQUENCE { mtaScopeCommunity OCTET STRING } mtaScopeCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "The community string necessary to access this scope." ::= { mtaScopeCommunityEntry 1 } -- -- Group Rule Table -- mtaGroupRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaGroupRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target group membership rules." ::= { mtaTarget 5 } mtaGroupRuleEntry OBJECT-TYPE Expires 26 March 1997+6 months [Page 19] Internet Draft Management Target MIB 26 March 1997 SYNTAX MtaGroupRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management group rule. Entries are created in this table using mtaGroupRuleStatus. Entries are deleted with mtaGroupRuleStatus, when the group is deleted using mtaTargetStatus, or if mtaTargetType is changed to 'scope'." INDEX { mtaTargetIndex } ::= { mtaGroupRuleTable 1 } MtaGroupRuleEntry ::= SEQUENCE { mtaGroupRuleCondition OBJECT IDENTIFIER, mtaGroupRuleStatus RowStatus } mtaGroupRuleCondition OBJECT-TYPE SYNTAX OBJECT IDENTIFER MAX-ACCESS read-write STATUS current DESCRIPTION "An integer-valued object that defines membership in the for all values of mtaSystemIndex. The object identifier's instance must end in mtaSystemIndex or its semantic equivalent. That portion of the object identifier is not included in the value of this object. If the value of the condition object for a given mtaSystemIndex is 0, the corresponding system is not a member of this group, otherwise it is a member." ::= { mtaGroupRuleEntry 1 } mtaGroupRuleStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { mtaGroupRuleEntry 2 } -- -- Group Member Table Expires 26 March 1997+6 months [Page 20] Internet Draft Management Target MIB 26 March 1997 -- mtaGroupMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaGroupMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management target group membership information." ::= { mtaTarget 6 } mtaGroupMemberEntry OBJECT-TYPE SYNTAX MtaGroupMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single management group member. Entries exist in this table either by manual operation using mtaGroupMemberStatus or by operation of mtaGroupRuleConditional. The first value of mtaTargetIndex in the instance must be of mtaTargetType 'group'. The second may be of mtaTargetType 'group' or 'scope'." INDEX { mtaTargetIndex, mtaTargetIndex } ::= { mtaGroupMemberTable 1 } MtaGroupMemberEntry ::= SEQUENCE { mtaGroupMemberManual TruthValue, mtaGroupMemberStatus RowStatus } mtaGroupMemberManual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether this group was was created manually (true) or by the operation of mtaGroupRuleCondition (false). Entries created by rule may not be deleted." ::= { mtaGroupMemberEntry 1 } mtaGroupMemberStatus OBJECT-TYPE SYNTAX RowStatus Expires 26 March 1997+6 months [Page 21] Internet Draft Management Target MIB 26 March 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { mtaGroupRuleEntry 2 } -- The compliance statements have yet to be written. The intent is -- that all objects are required except where otherwise mentioned above -- and that a self-managing system need not support groups by rule or -- groups at all. END Expires 26 March 1997+6 months [Page 22] Internet Draft Management Target MIB 26 March 1997 5. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 26 March 1997+6 months [Page 23] Internet Draft Management Target MIB 26 March 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Expires 26 March 1997+6 months [Page 24] Internet Draft Management Target MIB 26 March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 26 March 1997+6 months [Page 25] Internet Draft Management Target MIB 26 March 1997 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Network Management Framework ........................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 4 Definitions ..................................................... 5 5 Acknowledgements ................................................ 23 6 References ...................................................... 24 7 Security Considerations ......................................... 25 8 Author's Address ................................................ 25 Expires 26 March 1997+6 months [Page 26] --------------1BD11DE0524B-- From rturner at sharplabs.com Fri Apr 4 17:30:47 1997 From: rturner at sharplabs.com (Randy Turner) Date: Wed May 6 14:00:03 2009 Subject: JMP> [Fwd: Notification MIB] Message-ID: <5030100001147543000002L032*@MHS> This is a multi-part message in MIME format. --------------4EB8500C3E38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------4EB8500C3E38 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from slafw.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by sla5c.enet.sharplabs.com (8.8.4/8.8.4) with ESMTP id FAA00860 for ; Wed, 2 Apr 1997 05:32:18 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by slafw.sharplabs.com (8.8.4/8.7.3) with ESMTP id FAA05813 for ; Wed, 2 Apr 1997 05:38:20 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA16024; Wed, 2 Apr 1997 08:17:58 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id IAA08844 for disman-out; Wed, 2 Apr 1997 08:17:08 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA08835 for ; Wed, 2 Apr 1997 08:17:04 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id IAA01691 for ; Wed, 2 Apr 1997 08:17:37 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA20277 for ; Wed, 2 Apr 1997 05:17:30 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 1997 08:14:56 -0500 To: Distributed Management WG From: Bob Stewart Subject: Notification MIB Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Internet Draft Notification MIB 26 March 1997 Notification MIB 26 March 1997 draft-ietf-disman-notify-mib-00.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires 26 March 1997+6 months [Page 1] Internet Draft Notification MIB 26 March 1997 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing SNMP notifications. Expires 26 March 1997+6 months [Page 2] Internet Draft Notification MIB 26 March 1997 2. The SNMP Network Management Framework They are: The SNMP Network Management Framework presently consists of three major components. They are: the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 26 March 1997+6 months [Page 3] Internet Draft Notification MIB 26 March 1997 3. Overview Systems that support SNMP need a means of controlling and directing notifications, that is, Traps and Informs. Furthermore it would be useful to have a common mechanism for recording notification information as a hedge against lost Traps. This MIB provides infrastructure for other MIBs in the form of control over the generation of notifications and specification of where to send them, as well as counters and a local logging function. It is intended strictly for senders of notifications. Expires 26 March 1997+6 months [Page 4] Internet Draft Notification MIB 26 March 1997 4. Definitions NOTIFICATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Integer32, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, DisplayString, AutonomousType, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF EntryType, targetIndex FROM MANAGEMENT-TARGET-MIB notificationMIB MODULE-IDENTITY LAST-UPDATED "9703231700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for controlling, directing, and logging SNMP notifications, that is, Traps and Informs." ::= { experimental xx } -- -- Textual Conventions -- SendControl ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The choice of control values for whether a notification is sent, representing a range of insistence within an overall hierarchy. When choices are in conflict, target-level controls take precedence over notification-level controls, which take precedence over system-level control. hardEnable enable except for a level override softEnable enable unless a hardDisable overrides Expires 26 March 1997+6 months [Page 5] Internet Draft Notification MIB 26 March 1997 defer defer to next level softDisable disable unless a hardEnable overrides hardDisable disable except for a level override If all levels defer, the notification is disabled. " SYNTAX INTEGER { hardEnable(1), softEnable(2), defer(3), softDisable(4), hardDisable(5) } BlockTime ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The minimum number of seconds that must expire between occurances of the same type. A value of 0 indicates no limit. A value of -1 indicates the global default limit." SYNTAX Integer32 (-1..65535) FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to send a notification." SYNTAX INTEGER { localResourceLack(1), badDestination(2), tooBig(3), badAccessControl(4), noAck(5) } notificationMIBObjects OBJECT IDENTIFIER ::= { notificationMIB 1 } ntiSystemConfig OBJECT IDENTIFIER ::= { notificationMIBObjects 1 } ntiSystemStats OBJECT IDENTIFIER ::= { notificationMIBObjects 2 } ntiNotifConfig OBJECT IDENTIFIER ::= { notificationMIBObjects 3 } ntiNotifStats OBJECT IDENTIFIER ::= { notificationMIBObjects 4 } ntiTargetConfig OBJECT IDENTIFIER ::= { notificationMIBObjects 5 } ntiTargetStats OBJECT IDENTIFIER ::= { notificationMIBObjects 6 } ntiLog OBJECT IDENTIFIER ::= { notificationMIBObjects 7 } -- -- System-level Configuration Section -- -- -- System Configuration Table -- Expires 26 March 1997+6 months [Page 6] Internet Draft Notification MIB 26 March 1997 ntiSysConTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiSysConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of notification configuration for the overall managed system." ::= { ntiSystemConfig 1 } ntiSysConEntry OBJECT-TYPE SYNTAX NtiSysConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration for one notification form. Entries in this table may not be created or deleted. Their existence depends on what the system supports." INDEX { ntiNotificationForm } ::= { ntiSysConTable 1 } NtiSysConEntry ::= SEQUENCE { ntiNotificationForm INTEGER, ntiSysConControl SendControl, ntiSysConRateBlock BlockTime } ntiNotificationForm OBJECT-TYPE SYNTAX INTEGER { log(1), trap(2), inform(3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The form of notification this entry configures." ::= { ntiSysConEntry 1 } ntiSysConControl OBJECT-TYPE SYNTAX SendControl MAX-ACCESS read-write STATUS current DESCRIPTION "The system-level control option for this form of notification. For equal controls, system level defers to both notification level and target level." Expires 26 March 1997+6 months [Page 7] Internet Draft Notification MIB 26 March 1997 DEFVAL { softDisabled } ::= { ntiSysConEntry 2 } ntiSysConTrapRateBlock OBJECT-TYPE SYNTAX BlockTime UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The system-level value for limiting the transmission rate of this form of notifications from this managed system. A notification of this form may not be sent more often than this number of seconds apart unless overridden by a notification- or target-level rate block." DEFVAL { 60 } ::= { ntiSysConEntry 3 } -- -- System-level Statistics Section -- -- -- System-level Statistics Table -- ntiSysStatTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiSysStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of notification statistics for the overall managed system." ::= { ntiSystemStats 1 } ntiSysStatEntry OBJECT-TYPE SYNTAX NtiSysStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for one notification form. Entries in this table may not be created or deleted. Their existence depends on what the system supports." AUGMENTS { ntiSysConTable } ::= { ntiSysStatTable 1 } Expires 26 March 1997+6 months [Page 8] Internet Draft Notification MIB 26 March 1997 NtiSysStatEntry ::= SEQUENCE { ntiSysStatNotificationsSent Counter32, ntiSysStatLastSentTime TimeStamp, ntiSysStatLastSentOID OCTET STRING, ntiSysStatsFailed Counter32, ntiSysStatLastFailedTime TimeStamp, ntiSysStatLastFailedOID OCTET STRING } ntiSysStatNotificationsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form sent successfully from this managed system." ::= { ntiSysStatEntry 1 } ntiSysStatLastSentTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time a notification of this form was successfully sent." ::= { ntiSysStatEntry 2 } ntiSysStatLastSentOID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the last notification of this form successfully sent from this managed system." ::= { ntiSysStatEntry 3 } ntiSysStatNotificationsFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form that completely failed an attempt to send. This means, for example, that allowed retries were exhausted." Expires 26 March 1997+6 months [Page 9] Internet Draft Notification MIB 26 March 1997 ::= { ntiSysStatEntry 4 } ntiSysStatLastFailedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value os sysUpTime the last time an attempt to send failed for a notification of this form." ::= { ntiSysStatEntry 5 } ntiSysStatLastFailedOID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the last notification of this form for which an attempt to send failed." ::= { ntiSysStatEntry 6 } -- -- Notification-level Configuration Section -- -- -- Notification Configuration Table -- ntiNotConTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiNotConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of configuration for individual notifications from this managed system." ::= { ntiNotificationConfig 1 } ntiNotConEntry OBJECT-TYPE SYNTAX NtiNotConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration for one notification form.. Expires 26 March 1997+6 months [Page 10] Internet Draft Notification MIB 26 March 1997 A system may choose to populate this table for all notifications that it supports or may support addition and deletion of individual entries using ntiNotConStatus." INDEX { ntiNotificationForm, IMPLIED ntiNotificationID } ::= { ntiNotConTable 1 } NtiNotConEntry ::= SEQUENCE { ntiNotificationID OCTET STRING, ntiNotificationIndex Unsigned32, ntiNotConControl SendControl, ntiNotConRateBlock BlockTime, ntiNotConStatus RowStatus } ntiNotificationID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of a notification supported by this managed system." ::= { ntiNotConEntry 1 } ntiNotificationIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "An arbitrary integer identification for the notification, in one-to-one correspondence with ntiNotificationID. The purpose of this object is to provide a short, convenient identification for use by computers and as a value for other MIB objects. The agent may change this value when it is reinitialized but must correct all places where the value is used." ::= { ntiNotConEntry 2 } ntiNotConControl OBJECT-TYPE SYNTAX SendControl MAX-ACCESS read-write STATUS current DESCRIPTION "The notification-level control option for this form of notification. Expires 26 March 1997+6 months [Page 11] Internet Draft Notification MIB 26 March 1997 For equal controls, notification level defers to target level." DEFVAL { softDisabled } ::= { ntiNotConEntry 3 } ntiNotConTrapRateBlock OBJECT-TYPE SYNTAX BlockTime UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The notification-level value for limiting the transmission rate of this form of notifications from this managed system. A notification of this form may not be sent more often than this number of seconds apart unless overridden by a target-level rate block." DEFVAL { 60 } ::= { ntiNotConEntry 4 } ntiNotConStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { ntiNotConEntry 5 } -- -- Notification-level Statistics Section -- -- -- Notification-level Statistics Table -- ntiNotStatTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiNotStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of notification statistics for the managed system." ::= { ntiNotificationStats 1 } ntiNotStatEntry OBJECT-TYPE Expires 26 March 1997+6 months [Page 12] Internet Draft Notification MIB 26 March 1997 SYNTAX NtiNotStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for one notification form. Entries in this table may not be created or deleted. Their existence depends on what the system supports." AUGMENTS { ntiNotConTable } ::= { ntiNotStatTable 1 } NtiNotStatEntry ::= SEQUENCE { ntiNotStatNotificationsSent Counter32, ntiNotStatLastSentTime TimeStamp, ntiNotStatsFailed Counter32, ntiNotStatLastFailedTime TimeStamp, ntiNotStatLastFailedTargetGroup EntryIndexOrZero, ntiNotStatLastFailedTargetScope EntryIndexOrZero, ntiNotStatLastFailedReason FailureReason } ntiNotStatNotificationsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form and ID sent successfully from this managed system." ::= { ntiNotStatEntry 1 } ntiNotStatLastSentTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time a notification of this form and ID was successfully sent." ::= { ntiNotStatEntry 2 } ntiNotStatNotificationsFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form and ID that Expires 26 March 1997+6 months [Page 13] Internet Draft Notification MIB 26 March 1997 completely failed an attempt to send. This means, for example, that allowed retries were exhausted." ::= { ntiNotStatEntry 3 } ntiNotStatLastFailedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an attempt to send failed for a notification of this form and ID." ::= { ntiNotStatEntry 4 } ntiNotStatLastFailedTargetGroup OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The targetIndex of the group target for which the last attempt to send a notification of this form and ID failed. A value of 0 indicates this object does not apply." ::= { ntiNotStatEntry 5 } ntiNotStatLastFailedTargetScope OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The targetIndex of the target scope for which the last attempt to send a notification of this form and ID failed. A value of 0 indicates that this object does not apply." ::= { ntiNotStatEntry 6 } ntiNotStatLastFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS read-only STATUS current DESCRIPTION "The reason the last attempt to send a notification of this form and ID failed." ::= { ntiNotStatEntry 7 } -- -- Target-level Configuration Section -- Expires 26 March 1997+6 months [Page 14] Internet Draft Notification MIB 26 March 1997 -- -- Target Configuration Table -- ntiTarConTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiTarConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of configuration for notification targets from this managed system." ::= { ntiTargetConfig 1 } ntiTarConEntry OBJECT-TYPE SYNTAX NtiTarConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration for one notification form for a particular notification and target. Create and delete entries using ntiTarConStatus. The ntiNotificationForm value 'log' is not valid for this table." INDEX { targetIndex, ntiNotificationForm, ntiNotificationIndex } ::= { ntiTarConTable 1 } NtiTarConEntry ::= SEQUENCE { ntiTarConControl SendControl, ntiTarConRateBlock BlockTime, ntiTarConStatus RowStatus } ntiTarConControl OBJECT-TYPE SYNTAX SendControl MAX-ACCESS read-write STATUS current DESCRIPTION "The target-level control option for this form of notification." DEFVAL { softDisabled } ::= { ntiTarConEntry 1 } Expires 26 March 1997+6 months [Page 15] Internet Draft Notification MIB 26 March 1997 ntiTarConTrapRateBlock OBJECT-TYPE SYNTAX BlockTime UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The target-level value for limiting the transmission rate of this form of notifications from this managed system. A notification of this form may not be sent more often than this number of seconds apart." DEFVAL { 60 } ::= { ntiTarConEntry 2 } ntiTarConStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries." ::= { ntiTarConEntry 3 } -- -- Target-level Statistics Section -- -- -- Target-level Statistics Table -- ntiTarStatTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiTarStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of target statistics for the managed system." ::= { ntiTargetStats 1 } ntiTarStatEntry OBJECT-TYPE SYNTAX NtiTarStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for one notification form and ID for one target." AUGMENTS { ntiTarConTable } Expires 26 March 1997+6 months [Page 16] Internet Draft Notification MIB 26 March 1997 ::= { ntiTarStatTable 1 } NtiTarStatEntry ::= SEQUENCE { ntiTarStatNotificationsSent Counter32, ntiTarStatLastSentTime TimeStamp, ntiTarStatsFailed Counter32, ntiTarStatLastFailedTime TimeStamp, ntiTarStatLastFailedTargetGroup EntryIndexOrZero, ntiTarStatLastFailedTargetScope EntryIndexOrZero, ntiTarStatLastFailedReason FailureReason } ntiTarStatNotificationsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form and ID sent successfully to this target. If the target is a group, this counts one for each scope in that group." ::= { ntiTarStatEntry 1 } ntiTarStatLastSentTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time a notification of this form and ID was successfully sent to this target." ::= { ntiTarStatEntry 2 } ntiTarStatNotificationsFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of notifications of this form and ID that completely failed an attempt to send. This means, for example, that allowed retries were exhausted. If this target is a group, this counts one for each scope in that group." ::= { ntiTarStatEntry 3 } ntiTarStatLastFailedTime OBJECT-TYPE SYNTAX TimeStamp Expires 26 March 1997+6 months [Page 17] Internet Draft Notification MIB 26 March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an attempt to send failed for a notification of this form and ID to this target." ::= { ntiTarStatEntry 4 } ntiTarStatLastFailedTargetScope OBJECT-TYPE SYNTAX EntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The targetIndex of the target scope for which the last attempt to send a notification of this form and ID failed. A value of 0 indicates that this object does not apply." ::= { ntiTarStatEntry 5 } ntiTarStatLastFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS read-only STATUS current DESCRIPTION "The reason the last attempt to send a notification of this form and ID failed to this group." ::= { ntiTarStatEntry 6 } -- -- Log Section -- ntiLogEntryLimit OBJECT-TYPE SYNTAX Integer32 {-1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries that can be held in ntiLogTable. A value of -1 indicates no limit." ::= { ntiLog 1 } ntiLogEntriesDiscarded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 18] Internet Draft Notification MIB 26 March 1997 "The number of times the oldest log entry was discarded to make room for a new entry." ::= { ntiLog 2 } -- -- Log Table -- ntiLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of notification log entries." ::= { ntiTargetConfig 1 } ntiLogEntry OBJECT-TYPE SYNTAX NtiLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A notification log entry. Entries appear in this table when notifications occur, according to the notification controls." INDEX { ntiLogIndex } ::= { ntiLogTable 1 } NtiLogEntry ::= SEQUENCE { ntiLogIndex Integer32, ntiLogTime TimeStamp, ntiLogNotificationIndex Unsigned32 } ntiLogIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1 and may flush existing entries." ::= { ntiLogEntry 1 } Expires 26 March 1997+6 months [Page 19] Internet Draft Notification MIB 26 March 1997 ntiLogTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry occurred." ::= { ntiLogEntry 2 } ntiLogNotificationIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The notification that occurred." ::= { ntiLogEntry 3 } -- -- Log Table -- ntiLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NtiLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with notification log entries." ::= { ntiTargetConfig 1 } ntiLogVariableEntry OBJECT-TYPE SYNTAX NtiLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A notification log entry variable. Entries appear in this table when there are variables in the varbind list of a notification in ntiLogTable." INDEX { ntiLogIndex, ntiLogVariableIndex } ::= { ntiLogVariableTable 1 } NtiLogVariableEntry ::= SEQUENCE { ntiLogVariableIndex Integer32, ntiLogVariableID OBJECT IDENTIFIER, ntiLogVariableType INTEGER, ntiLogVariableUnsigned32Val Unsigned32, Expires 26 March 1997+6 months [Page 20] Internet Draft Notification MIB 26 March 1997 ntiLogVariableInteger32Val Integer32, ntiLogVariableOctetStringVal OCTET STRING, ntiLogVariableOidVal OBJECT IDENTIFIER, ntiLogVariableCounter64Val Counter64 } ntiLogVariableIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries." ::= { ntiLogVariableEntry 1 } ntiLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { ntiLogVariableEntry 2 } ntiLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsignedOrGauge32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow will be valid based on this type." ::= { ntiLogVariableEntry 3 } ntiLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 -- (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when ntiLogVariableType is one of 'counter32', 'unsignedOrGauge32', or 'timeTicks'." ::= { ntiLogVariableEntry 4 } ntiLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 -- (-2147483648..2147483647) Expires 26 March 1997+6 months [Page 21] Internet Draft Notification MIB 26 March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when ntiLogVariableType is 'integer32'." ::= { ntiLogVariableEntry 5 } ntiLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65536)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when ntiLogVariableType is 'ipAddress' or 'octetString'." ::= { ntiLogVariableEntry 6 } ntiLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when ntiLogVariableType is 'objectId'." ::= { ntiLogVariableEntry 7 } ntiLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 -- (0..18446744073709551615) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when ntiLogVariableType is 'counter64'." ::= { ntiLogVariableEntry 8 } -- -- Notifications -- notificationMIBNotificationPrefix OBJECT IDENTIFIER ::= { notificationMIB 2 } notificationMIBNotifications OBJECT IDENTIFIER ::= { notificationMIBNotificationPrefix 0 } notificationFailure NOTIFICATION-TYPE OBJECTS { ntiNotStatLastFailedTargetGroup, ntiNotStatLastFailedTargetScope, ntiNotStatLastFailedReason } STATUS current DESCRIPTION Expires 26 March 1997+6 months [Page 22] Internet Draft Notification MIB 26 March 1997 "Notification of a failure to send an event. The form and ID of the notification are imbedded in the OIDs for the included objects. The managed system must not attempt to send this notification for a failure to send this notification. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { notificationMIBNotifications 1 } -- The compliance statements have yet to be written. The intent is -- that all objects are required except where otherwise mentioned above -- and that a system that does not support management applications need -- not support entries of the notifification form 'inform'. END Expires 26 March 1997+6 months [Page 23] Internet Draft Notification MIB 26 March 1997 5. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 26 March 1997+6 months [Page 24] Internet Draft Notification MIB 26 March 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Expires 26 March 1997+6 months [Page 25] Internet Draft Notification MIB 26 March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 26 March 1997+6 months [Page 26] Internet Draft Notification MIB 26 March 1997 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Network Management Framework ........................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 4 Definitions ..................................................... 5 5 Acknowledgements ................................................ 24 6 References ...................................................... 25 7 Security Considerations ......................................... 26 8 Author's Address ................................................ 26 Expires 26 March 1997+6 months [Page 27] --------------4EB8500C3E38-- From rturner at sharplabs.com Fri Apr 4 17:32:13 1997 From: rturner at sharplabs.com (Randy Turner) Date: Wed May 6 14:00:03 2009 Subject: JMP> [Fwd: Re: My Internet Drafts] In-Reply-To: Message-ID: <5030100001147543000002L032*@MHS> This is a multi-part message in MIME format. --------------2D4D586D4199 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com --------------2D4D586D4199 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from slafw.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by sla5c.enet.sharplabs.com (8.8.4/8.8.4) with ESMTP id NAA01023 for ; Wed, 2 Apr 1997 13:44:21 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by slafw.sharplabs.com (8.8.4/8.7.3) with ESMTP id NAA00697 for ; Wed, 2 Apr 1997 13:51:01 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA19877; Wed, 2 Apr 1997 16:36:00 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id QAA17582 for disman-out; Wed, 2 Apr 1997 16:31:29 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA17573 for ; Wed, 2 Apr 1997 16:31:26 -0500 (EST) Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA19848 for ; Wed, 2 Apr 1997 16:32:01 -0500 (EST) Received: by dresden.bmc.com (1.40.112.8/16.2) id AA036556614; Wed, 2 Apr 1997 15:30:15 -0600 Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma003595; Wed, 2 Apr 97 15:30:08 -0600 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id PAA05476 for ; Wed, 2 Apr 1997 15:31:49 -0600 (CST) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA253096707 for ; Wed, 2 Apr 1997 13:31:47 -0800 Date: Wed, 2 Apr 1997 13:31:47 -0800 From: Randy Presuhn Message-Id: <199704022131.AA253096707@dorothy.peer.com> To: disman@nexen.com Subject: Re: My Internet Drafts Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Hi - > Message-Id: > Date: Wed, 2 Apr 1997 08:04:13 -0500 > To: Distributed Management WG > From: Bob Stewart > Subject: My Internet Drafts > > I apologize that my Internet Drafts haven't been published. I followed the > published rules and behaved politely and the result is it's a week later > and I didn't even find out I'd been declared too late until Monday. > > So I'll just email them to the list, one at a time. I had them ready to go > a week ago, in time for the deadline... > > Bob Bob will be making a presentation on this work in a disman session at the IETF meeting. If there are any points in these drafts you find unclear, please let him know so he can address these in his presentation. Similarly, please let the authors of the other drafts know if there are specific concerns you would like them to address in their presentations. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- --------------2D4D586D4199-- From harryl at us.ibm.com Mon Apr 7 19:01:23 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> Job MIB related files Message-ID: <5030100001226858000002L082*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I think we came to some fairly stable agreements at the Austin meeting and we need to get things in shape quickly for the IETF submission. Tom, Ron and I stayed a few hrs after the meeting, Friday, to jump start the presentation. While Tom's document is ultimately the most authoritative, it is also very detailed and may take quite a lot of work to bring around. Thus, I composed a brief .PDF document which I am calling an "explanation". In it, I tried to share more of our prototype experience with some findings on table size etc. I also updated the presentation I gave at the meeting. Both are available on the server now. ftp.pwg.org/pub/pwg/jmp/contributions/Jmpexp.pdf (the explanation) /pwgjm.PDF (presentation) Both of these are intended to accurately reflect the consensus reached at Friday's meeting and may be useful in approaching the IETF. I have placed these documents at the disposal of the PWG for this purpose and to aid in understanding the Job MIB. Please let me know if there are any corrections, comments etc. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Thu Apr 10 10:10:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:03 2009 Subject: JMP> RE: jmGeneralLeastActiveIndex Message-ID: <5030100001291569000002L092*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems Oops... so many subgroups! Thanks, Bob. ---- Forwarded by Harry Lewis/Boulder/IBM on 04/10/97 08:08 AM --- bpenteco@boi.hp.com 04/09/97 06:59 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: Subject: RE: PMP> jmGeneralLeastActiveIndex Harry, You might want to send this to "JMP" instead of "PMP". Bob ---------- From: Harry Lewis[SMTP:harryl@us.ibm.com] Sent: Wednesday, April 09, 1997 5:21 PM To: pmp@pwg.org Subject: PMP> jmGeneralLeastActiveIndex Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems There was quite a bit of discussion upon adding this to the jmGeneral table last week in Austin. After reviewing back here, we still don't see how this value serves it's purpose. Does someone have a write-up of exactly what this object is supposed to do? We feel another object is also required... basically something like jmGeneralHighestActiveIndex otherwise it is very difficult to avoid walking the whole table. We feel that these should be named jmGeneralOldestActiveIndex jmGeneralNewestActiveIndex this helps get around the wrap problem. Using these two objects, an application should be about to determine where to start in the table (Oldest) and where to stop (Newest) and should also know there will be a wrap if Newest is a smaller number than oldest. I don't think we felt we'd fully solved this problem in Austin. If we did, can someone explain how it works? Harry Lewis. From STUART at KEI-CA.CCMAIL.CompuServe.COM Thu Apr 10 16:08:19 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:03 2009 Subject: JMP> jmGeneralLeastActiveIndex In-Reply-To: jmGeneralLeastActiveIndex> Message-ID: <5030100001291569000002L092*@MHS> On 4/9/97 at 8:15 PM, Harry Lewis said ... There was quite a bit of discussion upon adding this to the jmGeneral table last week in Austin. After reviewing back here, we still don't see how this value serves it's purpose. Does someone have a write-up of exactly what this object is supposed to do? We feel another object is also required... basically something like jmGeneralHighestActiveIndex otherwise it is very difficult to avoid walking the whole table. We feel that these should be named jmGeneralOldestActiveIndex jmGeneralNewestActiveIndex this helps get around the wrap problem. Using these two objects, an application should be about to determine where to start in the table (Oldest) and where to stop (Newest) and should also know there will be a wrap if Newest is a smaller number than oldest. SWR>> I think you are right. jmGeneralLeastActiveIndex tells where to start scanning the table, but not where to stop. I am in favor of this change, and I think the names Oldest and Newest are an improvement. Stuart From hastings at cp10.es.xerox.com Fri Apr 11 05:07:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:03 2009 Subject: JMP> jmGeneralLeastActiveIndex In-Reply-To: jmGeneralLeastActiveIndex> Message-ID: <9704110910.AA06311@zazen.cp10.es.xerox.com> The idea in Austin, was that the jmGeneralLowestActiveIndex (or jmGeneralSmallestActiveIndex for those whose memory grows upward), pointed to the smallest job index that was active. When wrap occurs, the agent sets that value back to 1, where the agent puts the newest job arrival when a wrap occurs. In any case, the management app scans the job table starting with this value looking for active jobs. When it has found the number of active jobs indicated by jmGeneralNumberOfActiveJobs, the management app knows it can stop looking. So during a wrap condition where some active jobs are at the small end of the table and some are at the large end of the table, our management app has to scan all the intervening (completed) jobs in order to find all the active jobs. With the new proposal, the management app always starts with the oldest job, even during the wrap condition. The agents job is somewhat harder, for the case of processing job out of order, in that when a job completes, the agent has to scan backward (newer to older) down the table (and possibly reverse wrap) to find the newest still active job. But that isn't too difficult. I still think that we should keep jmGeneralNumberOfActiveJobs, since it provides a quick way to find out how busy a printer is. I'll edit in this new proposal, unless I hear disagreement. Ok? Thanks, Tom At 13:08 04/10/97 PDT, STUART@kei-ca.ccmail.compuserve.com wrote: >On 4/9/97 at 8:15 PM, Harry Lewis said ... > >There was quite a bit of discussion upon adding this to the jmGeneral table >last week in Austin. After reviewing back here, we still don't see how this >value serves it's purpose. Does someone have a write-up of exactly what this >object is supposed to do? > >We feel another object is also required... basically something like >jmGeneralHighestActiveIndex otherwise it is very difficult to avoid walking the >whole table. > >We feel that these should be named > > jmGeneralOldestActiveIndex > jmGeneralNewestActiveIndex > >this helps get around the wrap problem. > >Using these two objects, an application should be about to determine where to >start in the table (Oldest) and where to stop (Newest) and should also know >there will be a wrap if Newest is a smaller number than oldest. > >SWR>> I think you are right. jmGeneralLeastActiveIndex tells where to start >scanning the table, but not where to stop. I am in favor of this change, and >I think the names Oldest and Newest are an improvement. > >Stuart > > > > From hastings at cp10.es.xerox.com Fri Apr 11 05:45:46 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> IETF JMP Slides posted Message-ID: <9704110948.AA06327@zazen.cp10.es.xerox.com> I've posted the slides that I presented at the IETF meeting in: ftp://ftp.pwg.org/pub/pwg/jmp/slides/ -rw-r--r-- 1 pwg pwg 30576 Apr 11 09:15 jmpietf1.pdf -rw-r--r-- 1 pwg pwg 141312 Apr 11 09:17 jmpietf1.ppt I took Harry's slides that he presented in Austin and retypeed most of them in Power Point and added some more text and a few more slides. The version posted has a few bugs fixed that were noted during the presentation, so it isn't exactly identical to the handouts at the meeting, but pretty close. Tom From rbergma at dpc.com Fri Apr 11 15:59:46 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:04 2009 Subject: JMP> Minutes for Printer MIB Working Group at IETF Meeting Message-ID: <9704110948.AA06327@zazen.cp10.es.xerox.com> Printer MIB Working Group IETF Meeting Minutes 4/8/97 Reported by: Ron Bergman The meeting was called to order by Lloyd Young at 1:05 PM CST on April 8th at the Peabody Hotel in Memphis, Tennessee. The Printer MIB Working Group presently developing two printer related MIBs. The first is the Printer MIB and the second is the Job Monitoring MIB. The Working Group Chairs are: Chris Wellens chrisw@iwl.com Lloyd Young lpyoung@lexmark.com PLANNED AGENDA: 1. Review of the Printer MIB interoperability testing. 2. Report on status of the Job Monitoring MIB. Printer MIB: The Printer MIB is presently a Proposed Standard and the current efforts are to advance to Draft Standard. One of the prime requirements for advancement to Draft Standard is to demonstrate interoperability. This test was performed in February 1997. A brief report was presented by Lloyd Young as to the test methods and results of these tests. A copy of Interoperability test results was provided to all interested attendees. 1. Static variables were tested using the Castle Rock SNMPc product. 2. Dynamic variables used the Castle Rock SNMPc product for Alerts. 3. Additional testing was performed using the InterWorking Labs MIB Test Suite. 4. Application testing used: IBM's NetCube Underscore's Print Alert QUESTION: Why was Castle Rock's package used instead of OpenView or others? ANSWER: This package was recommend by several of the participating vendors and Castle Rock provide free licenses for the test. The current schedule for completing the Printer MIB: - Last comments must be submitted by May 2 - New Internet draft ready for Working Group review by May 16 - Final comments cutoff date is May 30 - Final draft submission to IESG by June 2 Job Monitoring MIB: The current status of the MIB was presented by Tom Hastings. The MIB has been simplified to a total of 13 objects, all of which are mandatory. The emphasis is on a Client - Server - Printer configuration. The MIB currently contains four groups / tables. No traps are included in the MIB. - The General group contains 5 objects - The Job Id group contains 2 objects - The Job State group contains 4 objects - Attribute group contains 2 objects QUESTION: Is this a Job MIB intended for servers in general or just print servers? ANSWER: The MIB is being designed for Printers but other functions such as faxing could use the MIB with extensions. QUESTION: The Job Monitoring MIB seems to be focusing on some of the same areas as IPP. Is there any coordination between the two projects? ANSWER: Yes, the IPP and Job Monitoring programs are both being developed by the same people. The Printer MIB, the Job Monitoring MIB and Internet Printing Protocol projects are being coordinated to insure that they are compatible. There was an extended discussion on how the client creates the Job Submission Id for the job. The MIB now specifies a Client generated 32 octet Job Submission Id which is really only quasi unique. The Working Group believes that defined methods for this identification string result in an extremely low probability of duplicate strings. There was some concern in the audience that a 100% guarantee of uniqueness must be assured. Keith Moore expressed concern that SNMP should not be used for a User application. The Working Group is aware that SNMP is not the ideal solution for this problem. Long term IPP will provide a significantly better solution. This is intended to be a solution for current legacy systems. QUESTION: If the client job can be sent to one of several printers, how do I determine which printer received the job? ANSWER: The Job MIB has two objects jmPhysicalDeviceName and jmPhysicalDeviceIndex which specify which physical device received the job. QUESTION: How does the submission id get to the printer? ANSWER: The job submission can be either a header or wrapper to the job data or imbedded with the PDL of the job. The Working Group believes that the method will be vendor specific and will also be unique to the various hardware / software platforms that are supported. Steve Zilles commented about the definition of the Attribute Table attributes being Conditionally Mandatory. He was not sure as to the meaning of Conditionally Mandatory in this case. The MIB specification needs to fully define this meaning. The meeting was closed by Tom Hastings at 3:00 PM CST. From hastings at cp10.es.xerox.com Mon Apr 14 14:21:25 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> 4 tools to help produce IETF plain text documents (RFCs, MIBs) Message-ID: <9704141823.AA06971@zazen.cp10.es.xerox.com> Ira McDonald has added two more tools to the ones we had before in: ftp://ftp.pwg.org/pub/pwg/tools/ -rw-rw-r-- 1 pwg pwg 27360 Apr 14 18:14 cscan.exe -rw-rw-r-- 1 pwg pwg 26240 Apr 14 18:14 maxln.exe -rw-r--r-- 1 pwg pwg 30032 Apr 14 18:15 overx.exe -rw-rw-r-- 1 pwg pwg 1089 Dec 2 19:04 readme-maxln-cscan.txt -rw-r--r-- 1 pwg pwg 27440 Apr 14 18:16 strip.exe The new ones are: overx.exe undoes the overstriking that the generic text driver uses so that the generic text driver can be used to produce plain text from MS-WORD. strip.exe removes any bad control characters. The existing ones scan for bad characters and look for long lines. Could we put these tools on our PWG web page? Thanks much to Ira for this help!! Tom Return-Path: Date: Sat, 12 Apr 97 21:59:18 EDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) To: hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com Subject: Four Text Tools - 'overx' overstrike merge utility Hi Tom, Saturday (12 April 1997) I have just posted new copies of my little utilities to our file server in '/pub/mib/iratools/bin', including my new 'overx' utility (merges overstrike lines in text files). The others are: 'cscan' (count control characters and graphic characters in text files); 'maxln' (count lines longer than a 'fence' column in text files); and 'strip' (remove all control characters and graphic characters in text files). You are welcome to post these (16-bit) MS-DOS binaries to the PWG's server. Cheers, - Ira McDonald From hastings at cp10.es.xerox.com Thu Apr 17 17:38:17 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Comments on the Job MIB version 0.8 In-Reply-To: Message-ID: <9704172140.AA07959@zazen.cp10.es.xerox.com> Steve, We had some questions about the Job Monitoring MIB. I was copying the structure of the Printer MIB, but didn't know why some things were done in the Printer MIB. 1. Why the extra level of OID for each Group and table. If a group consists only of a table is it necessary to have the extra OID level? See below for extract of Printer MIB 2. Why was the first group assigned to printmib 5, instead of printmib 1? (printmib 2 is assigned to Conformance at the end). 3. Should the Job Monitoring MIB do 1 and 2 the same as the Printer MIB or not? Thanks, Tom >Date: Wed, 16 Apr 1997 00:22:12 -0700 >To: Ron Bergman >From: Tom Hastings >Subject: Re: Comments on the Job MIB version 0.8 >Cc: harryl@us.ibm.com, bpenteco@boi.hp.com > >At 18:12 04/15/97 PDT, Ron Bergman wrote: >>These are just some comments on the structure of the MIB. I believe >>that the text will require some real "wordsmithing" and maybe this >>can be best accomplished in a conference call. >> >> 1. We have the objects jmGeneral, jmJobId, jmJobState, and jmAttribute >> which appear to be just titles for the defined groups. Each of >> these objects has an associated table. I am not sure why these >> exist, as I have never noticed a similar structure in any other >> MIB. These do add an extra number to every OID in the MIB. What >> other purpose do these objects serve? >> >> If there is not a valid justification for these objects, I would >> recommend that they be removed and have the tables at the level >> immediately below jobMonMib. > >I don't know why the extra level of OIDs is done, but I was just following >the precedence in RFC 1759, which has for the General group (and all the >other groups): > >-- The General Printer Group >-- >-- The general printer sub-unit is responsible for the overall control >-- and status of the printer. There is exactly one general printer >-- sub-unit in a printer. >-- >-- Implementation of every object in this group is mandatory. > >prtGeneral OBJECT IDENTIFIER ::= { printmib 5 } > >prtGeneralTable OBJECT-TYPE > SYNTAX SEQUENCE OF PrtGeneralEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of general information per printer. > Objects in this table are defined in various > places in the MIB, nearby the groups to > which they apply. They are all defined > here to minimize the number of tables that would > otherwise need to exist." > ::= { prtGeneral 1 } > >prtGeneralEntry OBJECT-TYPE > SYNTAX PrtGeneralEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > >> From stevew at INS.COM Thu Apr 17 17:59:32 1997 From: stevew at INS.COM (Steve Waldbusser) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Comments on the Job MIB version 0.8 In-Reply-To: <9704172140.AA07959@zazen.cp10.es.xerox.com> Message-ID: <9704172140.AA07959@zazen.cp10.es.xerox.com> On Thu, 17 Apr 1997, Tom Hastings wrote: > I was copying the structure of the Printer MIB, but didn't know > why some things were done in the Printer MIB. > > 1. Why the extra level of OID for each Group and table. > > If a group consists only of a table is it necessary to have the > extra OID level? See below for extract of Printer MIB Yes, every table MUST be structured prefix.table.entry.object. There is also a convention to have the MIB divided into groups, each with a subtree. > 2. Why was the first group assigned to printmib 5, instead of printmib 1? > > (printmib 2 is assigned to Conformance at the end). I don't remember. Did we delete some groups at the beginning? > 3. Should the Job Monitoring MIB do 1 and 2 the same as the Printer MIB >or not? Definitely on #1, maybe on #2 (depends on whether it was for a good reason). Steve > > Thanks, > Tom > > >Date: Wed, 16 Apr 1997 00:22:12 -0700 > >To: Ron Bergman > >From: Tom Hastings > >Subject: Re: Comments on the Job MIB version 0.8 > >Cc: harryl@us.ibm.com, bpenteco@boi.hp.com > > > >At 18:12 04/15/97 PDT, Ron Bergman wrote: > >>These are just some comments on the structure of the MIB. I believe > >>that the text will require some real "wordsmithing" and maybe this > >>can be best accomplished in a conference call. > >> > >> 1. We have the objects jmGeneral, jmJobId, jmJobState, and jmAttribute > >> which appear to be just titles for the defined groups. Each of > >> these objects has an associated table. I am not sure why these > >> exist, as I have never noticed a similar structure in any other > >> MIB. These do add an extra number to every OID in the MIB. What > >> other purpose do these objects serve? > >> > >> If there is not a valid justification for these objects, I would > >> recommend that they be removed and have the tables at the level > >> immediately below jobMonMib. > > > >I don't know why the extra level of OIDs is done, but I was just following > >the precedence in RFC 1759, which has for the General group (and all the > >other groups): > > > >-- The General Printer Group > >-- > >-- The general printer sub-unit is responsible for the overall control > >-- and status of the printer. There is exactly one general printer > >-- sub-unit in a printer. > >-- > >-- Implementation of every object in this group is mandatory. > > > >prtGeneral OBJECT IDENTIFIER ::= { printmib 5 } > > > >prtGeneralTable OBJECT-TYPE > > SYNTAX SEQUENCE OF PrtGeneralEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table of general information per printer. > > Objects in this table are defined in various > > places in the MIB, nearby the groups to > > which they apply. They are all defined > > here to minimize the number of tables that would > > otherwise need to exist." > > ::= { prtGeneral 1 } > > > >prtGeneralEntry OBJECT-TYPE > > SYNTAX PrtGeneralEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > > >> > > From jkm at underscore.com Thu Apr 17 18:09:36 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Comments on the Job MIB version 0.8 In-Reply-To: Re: Comments on the Job MIB version 0.8> Message-ID: <199704172209.SAA18220@uscore.underscore.com> Hi Steve, No real issue with your statement below, only a bit of curiosity: > Yes, every table MUST be structured prefix.table.entry.object. There is > also a convention to have the MIB divided into groups, each with a > subtree. Can this rationale be briefly described? Or perhaps a pointer to a relevant discussion be given? We know you're very busy, so anything you can say would be appreciated. ...jay From stevew at INS.COM Thu Apr 17 19:45:38 1997 From: stevew at INS.COM (Steve Waldbusser) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Comments on the Job MIB version 0.8 In-Reply-To: <199704172209.SAA18220@uscore.underscore.com> Message-ID: <199704172209.SAA18220@uscore.underscore.com> This is a requirement that is dictated by the SMI and is thus required by MIB compilers. The rules dictate a structure that looks like: ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber." ::= { interfaces 2 } ifEntry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular interface." INDEX { ifIndex } ::= { ifTable 1 } IfEntry ::= SEQUENCE { ifIndex INTEGER, ifDescr DisplayString, ifType INTEGER, ifMtu INTEGER, ... } Steve On Thu, 17 Apr 1997, JK Martin wrote: > Hi Steve, > > No real issue with your statement below, only a bit of curiosity: > > > Yes, every table MUST be structured prefix.table.entry.object. There is > > also a convention to have the MIB divided into groups, each with a > > subtree. > > Can this rationale be briefly described? Or perhaps a pointer to a > relevant discussion be given? > > We know you're very busy, so anything you can say would be appreciated. > > ...jay > From harryl at us.ibm.com Fri Apr 18 13:08:22 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Comments on the Job MIB version 0.8 In-Reply-To: Message-ID: <5030100001545103000002L032*@MHS> Classification: Prologue: Epilogue: Harry Lewis - IBM Printing Systems I think Steve Waldbusser may have written this, but I'm not sure since my e-mail did not capture his address... >> 2. Why was the first group assigned to printmib 5, instead of printmib 1? >> >> (printmib 2 is assigned to Conformance at the end). > >I don't remember. Did we delete some groups at the beginning? Hey! Am I the *only* one who remembers this bit of Printer MIF/MIB trivia? We began the printmib at 5 for compatibility with the MIF, in that the MIF REQUIRED additional groups. Every MIF must start with a "Component ID Group" then I had to find a way to add in something analogous to the Interfaces, Storage and Device tables since DMTF had no hrMIB to relate to. Thus... the General group starting at 5! > >> 3. Should the Job Monitoring MIB do 1 and 2 the same as the Printer MIB >>or not? > >Definitely on #1, maybe on #2 (depends on whether it was for a good reason). > >Steve If anything, we'd start at 2 to make room for the Component ID, but, since we're not doing a Job MIF, I don't think it matters. Harry Lewis. From hastings at cp10.es.xerox.com Fri Apr 25 13:48:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> MOD - Combinations of attributes and tags from Model 2.0 doc Message-ID: <9704251750.AA01779@zazen.cp10.es.xerox.com> I've posted a 2-page MS-Word table that shows the combinations of IPP attributes and tags from the Model 2.0 document. I think it can be a useful tool as we evolve the tag concept into structured attribute names. The columns in the table still indicate the valid combinations that are allowed and should become part of the spec. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 24576 Apr 25 17:45 ipptag20.doc -rw-r--r-- 1 pwg pwg 20891 Apr 25 17:45 ipptag20.pdf Lets see if it helps with this afternoon's telecon. Thanks, Tom From don at lexmark.com Mon Apr 28 11:07:48 1997 From: don at lexmark.com (Don Wright) Date: Wed May 6 14:00:04 2009 Subject: JMP> Boston Meeting Message-ID: <199704281510.AA09229@interlock2.lexmark.com> Sorry for the multiple postings but there seem to still be some people who s*bscribe to one of the project lists without s*bscribing to the PWG's administrative list. In the future, all meeting notices, etc. will only go out one to the PWG mailing list; please s*bscribe to it NOW!! (Well I guess I am past line 5 now and can say the word subscribe and not have the filter reject my mail!!!) J. Martin of Underscore has graciously agreed to arrange the details for the Boston meeting. He will forward them to the PWG list as soon as possible. Since both the 1394 printing effort and the IPP effort would like 2 day meetings in Boston, the following schedule is mandated: June 23/24 1394 Printing June 25/26 IPP June 27 JMP, etc. Best regards! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From hastings at cp10.es.xerox.com Mon Apr 28 21:19:46 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Job Monnitoring MIB I-D posted Message-ID: <9704290121.AA02660@zazen.cp10.es.xerox.com> I've posted the Internet Draft based on our agreements at the Austin meeting as version 0.81: ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 189247 Apr 29 01:00 draft-ietf-printmib-job-monitor-00.txt and sent it off to internet-drafts@ietf.org It compiles with one warning with SMICng, Epilogue, and Mosy compilers. I avoided using the new BITS data type, by assigning four 31-bit attributes to jobStateReasons: jobStateReason1, jobStateReason2, jobStateReasons3, jobStateReasons4 and defining the bit values as hexadecimal in the DESCRIPTION, so that we aren't forced into newer versions of the compilers. The one warning is about the assignment of the experimental OID which happens between the BEGIN and the MODULE-IDENTITY where nothing is supposed to be. I kept the original 00 file name that didn't quite make the deadline. We made a lot of changes following Harry's suggestions. I've attached the change history to show the changes. Harry and Ron have fed back some comments which I've incorporated, but I'm sure they (and the rest of you) will have more. I've also posted more readable versions as: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 422912 Apr 29 00:34 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 348534 Apr 29 00:35 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 275477 Apr 29 00:36 jmp-mibv.pdf -rw-r--r-- 1 pwg pwg 6595 Apr 29 00:36 jmp.dic -rw-r--r-- 1 pwg pwg 13312 Apr 29 00:36 mibvaria.dot The jmp-mibv.pdf is without revision marks and has all variable pitch font (TimesRoman font). See what a MIB looks like with a variable pitch font. The jmp-mibr.pdf is with revision marks to show the changes since the Austin meeting. I'll post the issues list tommorrow. I've also included the .doc file with the revision marks. If you want to make comments by editing the .doc file, please accept revisions FIRST, and then turn on revision marks while editing, so we can see your changes. Thanks, Tom P.S. With Ira McDonald's tools, I was able to produce the flat ASCII text file directly from the jmp-mibr.doc file using the generic text printer driver. I'll write up the steps as to how for those other PWG editors that are doing the same thing with other specs. I also used his maxln to find that four lines had exceeded 72 characters by 1 character (I have to move the right margin on a table in by a character). 15. Change History (not to be included in the Internet Draft) All future changes will be recorded here in reverse chronological order by version. 15.1 Changes to version 0.8, dated 4/4/97 to make version 0.81, dated 4/24/97 1. Deleted the JmTimeIntervalTC and used just Integer with the spec saying seconds for jmGeneralJobPersistence and jmGeneralAttributePersistence and jobProcessingCPUTime. 2. Changed the name of JmTimeTC to JmTimeStampTC to following the name in SMIv2, but for which we need to define in our spec because its in seconds and is defined as an integer, not an APPLICATION 3 IMPLICIT INTEGER, so that it can be a value of jmAttribteValueAsInteger. 3. Removed repetitious and redunant material as per Ron Bergman's suggestions. 4. Add the following textual conventions in order to add some attributes suggested by Harry: JmFinishingTC, JmPrintQualityTC, JmTonerEconomyTC, JmTonerDensityTC, JmMediumTypeTC. 5. Added unknown(2) to JmJobStateTC and renumberd the states. 6. Added the following attributes: jobHoldUntil to align with IPP 7. Removed "jmJob" and "OrQueue" from jmJobDeviceNameOrQueueRequested to yield deviceNameRequested and added queueNameRequested, so that they are separate and so an application can give the best display to the user. 8. Added the following attributes from Harry's list: serverAssignedJobName, jobSourcePlatformType, submittingServerName, submittingApplicationName, finishing, printQualityRequested, printQualityUsed, tonerEcomonyRequested, tonerEcomonyUsed, tonerDensityRequested, tonerDensityUsed. 9. Added mediumRequestedType and added "Name" to mediumConsumedName, so that implementation could use enums or strings as with other attributes. 10. Added numberOfDocuments object. 11. Changed documentFormatEnum to documentFormatType, to be consistent with other attributes that define types using enums. 12. Added jobKOctetsTransferred per Ron's request, since some implementation don't really know when Octets have been processed or printed. 13. Split up jobSubmissionDateAndTime into jobSubmissionToServerDateAndTime and jobSubmissionToDeviceDateAndTime and aded "ToDevice" to make jobSubmissionToDeviceTimeStamp. 14. Indicated that -2 can be used to mean unknow for integer values, or the attribute can be omitted from the table. 15. Broke jobStateReasons attribute into four: jobStateReasons1, jobStateReasons2, jobStateReasons3, and jobStateReasons4 attributes, with corresponding JmJobStateReasons1TC, JmJobStateReasons1TC, JmJobStateReasons1TC, and JmJobStateReasons1TC, textual conventions that define the bits in a 32-bit integer, so that we don't need to use the new BITS data type in RFC 1903 which most implementors are not yet using. 16. Defined JmJobServiceTypesTC as bits in an integer as well, so that we don't need to use BITS data type. 17. Clarified that it is jmGeneralNewestActiveJobIndex that needs to be persistent across power cycles, not all of the values of jmJobIndex. Thus after power up, old jmJobIndex values are not used until the implementation wraps jmJobIndex. 15.2 Changes to version 0.71, dated 3/26/97 to make version 0.8, dated 4/4/97 1. Corresponds to the changes agreed to at the JMP meeting, 04/04/97 in Austin. Harry Lewis's changes to eliminate the Queue and Completed tables and to replace the Job table with the Job ID and Job State table have been incorporated. 2. Added more of a summary to the Introduction 3. Added section 1.2, Types of Job Montoring Applications talked about in Austin and described (1) monitoring a single job, (2) monitoring all active jobs, (3) collect usage data for accounting or system utilization. 4. Clarified that an implementation with only a single job set can hard code the Job Set Index as 1. 5. Deleted redundant material that is also within the BEGIN END, such as the definitions of the job states. Also deleted the copy of the picture that is in the Printer MIB and just made a reference to it in Section 3. 6. Changed section 4 on Job Identification to reflect the new Job ID table and the Job Submission ID mechanism that allows a client to directly find the jmJobIndex for a particular job, form the Job Submission ID, without having to scan the whole job table. 7. Added the following TC: JmTimeTC, JmTimeIntervalTC 8. Simplified the job states by removing: preProcessing, printing, paused, interrupted and retained. Add job state reasons to represent these sub-states of held and completed. 9. Renamed the terminating job state to canceled and clarifed that a job winds up in either completed or canceled, as per Harry's proposal that we reviewed in Austin. 10. Made each of the objects in the jmJobStateTable also appear as attributes in the jmAttributeTable, so that an accounting or usage application can make a single sweep through one table. Also moved the objects from the deleted tables that we agreed to keep in Austin. So the following attributes were added: jobState, jobStateAssociatedValue, jobStateReasons, numberOfInterveningJobs, deviceAlertCode, jobName, jobServiceTypes, jobOwner, jobDeviceNameOrQueueRequested, jobPriority, jobProcessafterDateAndTime, jobKOctetsRequested, jobKOctetsCompleted, and jobStartedBeingHeldTime. 11. Moved jmJobSetIndex and jmJobIndex to the jmJobIDTable 12. Changed the name of the jmGeneralJobCompletedPolicy object to jmGeneralJobPersistence as per Harry's proposal and added the jmGeneralAttributePersistence object, so that the length of time for the accounting program to poll is clear and the time that the mandatory attributes and jmJobStateTable and jmJobIdTable data stay around. 13. Deleted the jmGeneralMaxNumberOfJobs, since not needed 14. Added jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex to help applications find the active jobs more quickly without having to scan over the completed/canceled jobs. 15. Deleted the JmQueueGroup and table and the jmCompleterGroup and table. The jmJobID and jmJobState group/table are simpler and do the job with the deleted objects moving to the attribute table. 16. Added the jmJobIdGroup and table. 17. Added the jmJobStateGroup and table. 18. Fixed the conformance to agree with the above changes with all groups being mandatory and some attributes being mandatory (as comments). 19. Added the monitoring application conformance requirement to accept either form of time attribute, if it supports a time attribute. From harryl at us.ibm.com Tue Apr 29 01:52:17 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Job MIB Comments Message-ID: <5030100001984378000003L083*@MHS> Classification: Tom, thank you for the fine work on the Job MIB draft. I am sure we will make rapid progress from this point. I've done a very quick review and have the following initial comments (working from the jmp-mibv.pdf draft): 1. Line 1175 - I do not think we should start the MIB at jobmonMIB5. I understand, this is a hold-over from the printer MIB where we needed to align with a printer MIF and you just didn't have time to correct this. I want to mention it as a comment to this draft so it will surely be addressed. I think leaving space for the conformance statement is a good idea, so I propose starting the job MIB at jobmonMIB2. 2. Line 1197 - What possessed you to rearrange the order of the jmGeneralEntry sequence? Your previous draft had JobSetName, JobPersistence, AttributePersistence, NumberActive, Oldest, Newest. The reordering just makes busy work for anyone who has been trying to keep up with a prototype (unless there is a good reason, of course). 3. Line 1350 - I don't think the name of an OID should necessarily contain the word "index" if the name is otherwise fully self describing. For instance, jmJobSubmissionID is sufficient to NAME this OID, even though it is used as an index. 4. Line 1483 - Is there an SNMP rule that every name in a table has to start with the same set of words. For example, why do we need the word STATE in jmJobStateKOctetsCompleted and jmJobStateImpressionsCompleted? 5. Line 1602 - Again, I think it is very confusing to tag the word "index" onto the end of the object names jmAttributeTypeIndex and jmAttributeInstanceIndex, just because these objects are used to index the table. I think the names should be shortened to jmAttributeType and jmAttributeIndex. Tom, I know it's a lot of work to produce this draft. My comments may seem like "nits"... I hope you take this as a good sign... if this is the extent of all our comments then it means we have come very close to consensus on the Job Monitoring MIB - FINALLY!! Harry Lewis - IBM Printing Systems objects happen to be used to index the table. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue Apr 29 15:46:51 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Issues remaining with the Job Monitoring MIB Message-ID: <9704291948.AA02846@zazen.cp10.es.xerox.com> I've posted the few remaining issues for the Job Monitoring MIB, V0.81, (same as Internet-Draft 00), along with all of the closed issues and the reasoning for each decision: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-rw-r-- 1 pwg pwg 50176 Apr 29 19:29 issues.doc -rw-rw-r-- 1 pwg pwg 58405 Apr 29 19:30 issues.pdf -rw-r--r-- 1 pwg pwg 59706 Apr 29 19:30 issues.pdr The .pdf file has (black) revision marks to show the changes to the issues from version 0.7. The .pdr is the same PDF file with red revision marks, as opposed to the black revision marks for screen viewing (or printing on a highlight color printer). *************************************************************************** ** Lets start the discussion about the issues on the e-mail list, so we can ** have a running start on the JMP meeting next week. Especially, ISSUES ** 67, 68, and 69, which require SNMP experts familiar with Get Next accessing ** sparse tables with 4 indexes. *************************************************************************** I've also posted the MIB with *red* revision marks for looking at the PDF file on your screen (or a highlight printer) to compare with version 0.7 that was input to the Austin meeting: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 358881 Apr 29 19:32 jmp-mibr.pdr Here are the open issues from issues.pdf: 1. Open Issues Issue 61 - Need to clarify the semantics of each object and attribute with respect to Configuration 1, 2, and 3. See Bob Pentecost EMail of 3/10 (HP internal review). Most objects refer to the jobs as they exist in the server or printer that the agent embedded in, i.e., is instrumenting. A few objects, represent information that comes from upstream places in the case of configuration 1 from the client, in the case of configuration 2, the client as well, and in the case of configuration 3, the server and maybe even the client as well. ACTION ITEM (Tom): Analyze the existing attributes to see if the semantics need clarification depending on which configuration and send to the DL. [NOTE: some of this has been done in version 0.81 - TNH] ISSUE 67 - Delete the three objects in the Job State table that duplicate attributes? jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, and jmJobStateAssociatedValue? An app can get all of these from the AttributeTable directlly: jobStateKOctetsCompleted, jobStateImpressionsCompleted, and jobStateAssociatedValue. ISSUE 68 - Delete the Job State Group/Table all together, since all objects are also duplicated as attributes? If ISSUE 67 does delete the 3 objects from the Job State table, then only the jmJobState object remains. But that is also available in the Attribute Table as the jobState attribute. ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any difference? Would it help if the mandatory attributes were first, so that Get Next would pick them up first? ISSUE 70 - Add some simple general device alert TC, instead of using the Printer MIB Alert Codes. The PrtAlertCodeTC generic values are much good to an end user without knowing which subunit. For example, SubUnitEmpty isn't very informative by itself. If an implementation also has the Printer MIB, then a lot more information is available, so a copy of the Printer Alert isn't very useful. If the implementation doesn't have the Printer MIB, then the Printer Alert codes aren't informative enough. ISSUE 71 - Are there any attributes that need to be clarified as to which apply to servers and which apply to devices and which apply to either? ACTION ITEM (Tom): Send to the DL, if find other attributes that are different between the server and the printer. ISSUE 72 - What should happen to jmGeneralNewestActiveJobIndex when all the active jobs complete? Shall agent set it to 0 or leave it alone as a pointer to increment when the next job is accepted? If it is reset to 0 (to indicate that there are no more active jobs), what remembers where to put the next received job? What is remembered across power cycles, so that jmJobIndex values are not immediately re-assigned upon power up? If the newest active job is comleted before an older one, shall the agent search back to find the newest still active job and decrement jmGeneralNewestJobIndex to point to it? Or should this object really be left alone after the newest job completes and be called jmGeneralNewestJobIndex, since the newest job may no longer be active? From hastings at cp10.es.xerox.com Tue Apr 29 16:04:12 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Job MIB comments and questions In-Reply-To: Message-ID: <9704292006.AA02860@zazen.cp10.es.xerox.com> At 14:21 04/28/97 PDT, case@snmp.com wrote: > >ok, you didn't understand steve's answer, i don't understand my question :-) > >now that we are communicating, let me try this answer to what question(s) >i think you have > >please forgive me if i "insult" you by telling you what you already know > >please forgive me if i don't answer the right questions > >all disclaimers in place, we go on now > >there is no reason i know of to skip over oid arcs > >first, my understanding is that rfc 1759 uses > > mib-2.43 printmib > prtGeneral mib-2.43.5 > prtCover mib-2.43.6 } > prtLocalization mib-2.43.7 > prtInput mib-2.43.8 > prtOutput mib-2.43.9 > prtMarker mib-2.43.10 > prtMarkerSupplies mib-2.43.11 > prtMarkerColorant mib-2.43.12 > prtMediaPath mib-2.43.13 > prtChannel mib-2.43.14 > prtInterpreter mib-2.43.15 > prtConsoleDisplayBuffer mib-2.43.16 > prtConsoleLights mib-2.43.17 > prtAlert mib-2.43.18 > prtMIBConformance mib-2.43.2 > >no, i have to tell you that this is a bit odd ... usually, one would do >this > foomib > foomib.1 foomibobjects > foomib.1.1 group 1 > foomib.1.1.1 first object or table in group 1 of foomib > etc > foomib.1.2.1 first object or table in group 1 of foomib > etc > foomib.2 foomibconformance > etc For the Job Monitoring MIB this would be: jobmonMIB jobmonMIB.1 jobmonMIBobjects jobmonMIB.1.1 jmGeneral jobmonMIB.1.2 jmJobID jobmonMIB.1.3 jmJobState jobmonMIB.1.4 jmAttribute jobmonMIB.2 jobmonMIBconformance Correct? > >i think if you history buffs will dig a bit, you will recall that >the mib had prtGeneral at 1 and the MIF had GeneralPrinter at 2 > >this caused a mismatch/skew > >as a result, prtGeneral was moved to { printmib 2 } sometime around june of '94 > >steve was consulted, and he said it wouldn't violate any rules, and he >updated the draft accordingly > >sometime later, it got moved "farther to the right" as in { printmib 5 } >and my ability to recollect is imperfect, but i believe it was again >for the purposes of alignment with the dmtf mif > >also, if i remember correctly, at least the early drafts of the printer >mib predate compliance and conformance statements and were stuck in later > >i don't know why it was put at 2 instead of 19, but it really just does >not matter > >it is syntactically correct, it is semantically correct ... it just looks >and feels a bit wierd > >i also agree with steve's response about the need for a dot for the >Table and for the Entry, and that the entry dot is always .1, but i >perceive that his answer is the right answer to a different question > >so, the short answer to > >>Is there any reason to skip over the first few OID arcs and to use >>arc 2 for the conformance at the end? > >is no > >what i don't understand is why you aren't using 19, 20, 21, etc ... things >"after" the end of the printer mib rather than counting from 1 again You mean that the Job Monitoring MIB should be using the arcs after the Printer MIB? I had thought it would be its own MIB, even though it is being done by the printmib WG. > >regards, >jdc > > From case at snmp.com Tue Apr 29 16:17:33 1997 From: case at snmp.com (case@snmp.com) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Job MIB comments and questions In-Reply-To: Message-ID: <199704292017.QAA25194@seymour4.snmp.com> >... >[snip] >For the Job Monitoring MIB this would be: > > jobmonMIB > jobmonMIB.1 jobmonMIBobjects > jobmonMIB.1.1 jmGeneral > jobmonMIB.1.2 jmJobID > jobmonMIB.1.3 jmJobState > jobmonMIB.1.4 jmAttribute > jobmonMIB.2 jobmonMIBconformance > >Correct? yes, if 1. jobmon is not somewhere under printmib 2. you don't have something like jobmonMIB.2 jobmonNotifications in which case then jobmonMIB.3 jobmonMIBconformance would move down one arc >... >[snip] >You mean that the Job Monitoring MIB should be using the arcs >after the Printer MIB? not my decision, but it would be my best guess that it will end up there >I had thought it would be its own MIB, even though it is being done by >the printmib WG. it might go either way ... but you shouldn't worry about that ... you should worry about getting the stuff after the prefix right and the prefix should get taken care of when you move from internet draft to rfc and the parent of jobmobMIB is determined (it is probably { experimental something } right now, right? regards, jdc From hastings at cp10.es.xerox.com Tue Apr 29 17:27:21 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Job MIB Comments In-Reply-To: Message-ID: <9704292129.AA02889@zazen.cp10.es.xerox.com> At 22:52 04/28/97 PDT, Harry Lewis wrote: >Classification: > >Tom, thank you for the fine work on the Job MIB draft. I am sure we will make >rapid progress from this point. > >I've done a very quick review and have the following initial comments (working >from the jmp-mibv.pdf draft): > > 1. Line 1175 - I do not think we should start the MIB at jobmonMIB5. > I understand, this is a hold-over from the printer MIB where we > needed to align with a printer MIF and you just didn't have time > to correct this. I want to mention it as a comment to this draft > so it will surely be addressed. I think leaving space for the > conformance statement is a good idea, so I propose starting the > job MIB at jobmonMIB2. See Jeff Case's e-mail where he said: >no, i have to tell you that this is a bit odd ... usually, one would do >this > foomib > foomib.1 foomibobjects > foomib.1.1 group 1 > foomib.1.1.1 first object or table in group 1 of foomib > etc > foomib.1.2.1 first object or table in group 1 of foomib > etc > foomib.2 foomibconformance > etc For the Job Monitoring MIB this would be: jobmonMIB jobmonMIB.1 jobmonMIBObjects jobmonMIB.1.1 jmGeneral jobmonMIB.1.1.1 jmGeneralTable jobmonMIB.1.1.1.1 jmGeneralEntry jobmonMIB.1.1.1.1.1 jmGeneralNumberOfActiveJobs jobmonMIB.1.1.1.1.2 jmGeneralOldestActiveJobIndex .. jobmonMIB.1.2 jmJobID .. jobmonMIB.1.3 jmJobState .. jobmonMIB.1.4 jmAttribute .. jobmonMIB.2 jobmonMIBConformance jobmonMIB.2.1 jobmonMIBCompliance jobmonMIB.2.2 jobmonMIBGroups Correct? This would add another level of OID arcs to the ones in the Internet-Draft (V0.81). > > 2. Line 1197 - What possessed you to rearrange the order of the > jmGeneralEntry sequence? Your previous draft had JobSetName, > JobPersistence, AttributePersistence, NumberActive, Oldest, > Newest. The reordering just makes busy work for anyone who > has been trying to keep up with a prototype (unless there is > a good reason, of course). Sorry about that. I put the more important items first and the jmJobSetName last, which isn't of interest on systems that have only one Job Set and hard code the Job Set Index as 1. I thought that might help. But if it doesn't, I can change the order back. Or is it better to leave it as it is, since changing it back would be yet another change? In the future I'll not make such "gratutous" changes. I think this was the only change that wasn't based on some e-mail message, or by attempting to clarify something that someone had a question about or confusion that someone had, or related to one of the open issues. > > 3. Line 1350 - I don't think the name of an OID should necessarily > contain the word "index" if the name is otherwise fully self > describing. For instance, jmJobSubmissionID is sufficient to > NAME this OID, even though it is used as an index. I agree that jmJobSubmissionIDIndex could be changed to just jmJobSubmissionID, since there aren't any other objects, such as jmJobSubmissionName that it could be confused with. On the other hand, being consistent in always appending the word Index if it is used as an index is helpful to implementors. On the other hand, this Index is not your usual index, since it is up to 32 octets, not the normal 16-bit or 32-bit Integer. So I agree that jmJobSubmissionIDIndex could drop the Index and even remain consistent with the convention that the word Index is used as a suffix, but for integer indexes only. Ok? > > 4. Line 1483 - Is there an SNMP rule that every name in a table > has to start with the same set of words. For example, why > do we need the word STATE in jmJobStateKOctetsCompleted and > jmJobStateImpressionsCompleted? I'm not certain whether it is a rule or just a convention. [On this particular issue, I hope we can do away with the entire State table, since each of its objects are also replicated in the Attribute table. See ISSUE 68 (and 67),] For example, the corresponding attributes are already shorter: jobKOctetsCompleted and jobImpressionsCompleted for the objects whose names you want to shorten. If we could delete the Job State Table entirely, the resolution of this issue would become moot. > > 5. Line 1602 - Again, I think it is very confusing to tag the word > "index" onto the end of the object names jmAttributeTypeIndex and > jmAttributeInstanceIndex, just because these objects are used to > index the table. I think the names should be shortened to > jmAttributeType and jmAttributeIndex. Lets let the group decide. My suggestion is to keep the Index, because these are 32-bit and 16-bit indexes respectively. On the other hand, I don't feel too strongly about these, since there aren't other objects with similer names that these might be confused with. Thought knowing that these objects are indexes is pretty key to understanding the Attribute Table. > >Tom, I know it's a lot of work to produce this draft. My comments may >seem like "nits"... I hope you take this as a good sign... if this >is the extent of all our comments then it means we have come very >close to consensus on the Job Monitoring MIB - FINALLY!! Thanks for the comments. I finally have the .doc file so that changes are easy to make that the group wants. Seems like we are close enough to agreement to only make future changes that are agreed to by the group via e-mail, telecon, or at the meeting. The one big issue left, as far as I'm concerned is getting rid of the Job State table altogether (ISSUE 68). All of the objects in the Job State table are duplicated as attributes in the Attribute table, including the jmJobStateAssociatedValue object which is duplicated as the jobStateAssociatedValue attribute. So deleting the Job State table loses no information. And the jmGeneralOldestActiveJobIndex allows an application to start right with the first active job in the Attribute table. Maintaining one table, instead of two, seems a lot simpler for an agent, reduces the number of objects, and simplifies understanding, and increases the chances that different agent implementations will present the same interface to application software. A second issue (which I didn't add to the issue list, but should) is if we do agree to delete the Job State Table, do we really need the jobStateAssociatedValue which is a copy of the pertinent attribute depending on the job's state. Or can an application access the attributes that it wants directly, perhaps independent of state and then pick which attribute to use based on the state that came back? A third issue (which I didn't add to the issues list, but should) is that the current jmJobStateAssociatedValue object (and jobStateAssociatedValue attribute) has a fixed idea about the processing and printing states. There are different kinds of (high end) printers for which separate states for processing and printing is very natural. On the other hand, most desktop printers interpret and mark together, perhaps offset by a short paper path of 1-6 impressions), will not show the job in processing for the first 1-6 impressions and then transition the job to printing for the remaining impressions (which would replace the copy of the jobKOctetsRequested attribute value with the copy of the impressionsRequested attribute value. Such desktop printers will use only one job state. In other words, while the AssociatedValue object/attribute could reduce the number of octets transferred somewhat, I'm concerned about the complexity of the agent, and the fact that the Associated Value concept is another example of where there are two ways to access the same data (three ways if we keep the Job State Table). I'm also concerned that this complexity might increase the chances of different agent implementations that present a different interface to application software that might confuse such software that was attempting to interwork with agents from different vendors. Getting rid of the jobStateAssociatedValue attribute (and corresponding object in the Job State Table), would solve this third issue. > >Harry Lewis - IBM Printing Systems > objects happen to be used to index the table. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Wed Apr 30 11:23:10 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? Message-ID: <5030100002038725000003L053*@MHS> Classification: We're making very good progress on the Job MIB, hopefully, bringing it to closure soon. Great! There are some remaining issues, 2 that concern me, namely the Job State Table and jmJobStateValue. With this note, I'd like to address the issue regarding whether or not to "do away with" the Job State Table. As a refresher, the job state table is indexed by jmJobSetIndex and jmJobIndex and each entry consists of the State, Octets completed, Impressions completed and associated State Value which is tailored to contain the most pertinent information for the current STATE (we'll discuss this separately). The "argument" for elimination is that all the information in the State Table can be obtained from attributes in the Attribute Table. I will try to articulate why I think we should keep the Job State Table. 1. Persistence. The JobState table has a longer persistence than the Attribute table. It is simpler for the agent to manage groups of objects on a per job basis associated with a given table persistence than it is to manage each object with a separate persistence value. 2. Job Monitoring (progress, completion etc.) vs. Job Accounting. We used to call the Attribute Table the Accounting Table. The Job State table can be thought of as facilitating Job Monitoring while the Attribute table serves the Accounting application. I think we should ask ourselves if there is any value in some printer that implements the State table but not the Attribute Table - i.e. facilitates Job Monitoring but not accounting. If so, then the separate Job State table could really be of value to "low end" implementation. Recall the Attribute table will be the largest consumer of memory for the agent and has a more complex indexing scheme. 3. Dynamics - Maybe we are operating from a mind set established back when we used to call the Attribute Table the Resource Accounting Group... but we view the JobState table as a group where objects are updated dynamically as the job progresses but the Attribute (Accounting) table as something that is updated upon job completion. Accounting applications are not interested in the PROGRESS of a job - only the resulting details. An accounting application wants to determine Job Complete (State Table) and then "harvest" the accounting (attribute) information - ONCE. Dynamic objects, which have not reached their final state or value, are of little value to an accounting application. All three statements reflect one "philosophy". The job MIB lets you Monitor and do Accounting. Does anyone think it has another purpose? Since these purposes are distinct, the structure of the MIB reflects this. The argument that everything can be found in the Attribute table and separate persistence values can be given to each object etc. may be a good one and perhaps it reflects better knowledge of SNMP than we had during design of the Printer MIB but - to draw an analogy - why isn't the printer MIB just one big table of printer Attributes instead of input, output, marker etc. groups? We think the 4 groups - General, ID, State and Attribute - are the optimal arrangement of objects for Job Monitoring and Accounting. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed Apr 30 14:33:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? In-Reply-To: Why have a Job State Table ?> Message-ID: <9704301835.AA03199@zazen.cp10.es.xerox.com> At 08:23 04/30/97 PDT, Harry Lewis wrote: >Classification: > >We're making very good progress on the Job MIB, hopefully, bringing it to >closure soon. Great! >There are some remaining issues, 2 that concern me, namely the Job State Table >and jmJobStateValue. [I changed the name to jmJobStateAssociatedValue, because some reviewers though that jmJobStateValue was the actual value of the state.] > >With this note, I'd like to address the issue regarding whether or not to "do >away with" the Job State Table. I agree it is the biggest issue(s) remaining. > >As a refresher, the job state table is indexed by jmJobSetIndex and jmJobIndex >and each entry consists of the State, Octets completed, Impressions completed >and associated State Value which is tailored to contain the most pertinent >information for the current STATE (we'll discuss this separately). The >"argument" for elimination is that all the information in the State Table can >be obtained from attributes in the Attribute Table. > >I will try to articulate why I think we should keep the Job State Table. Very helpful. > >1. Persistence. The JobState table has a longer persistence than the Attribute >table. It is simpler for the agent to manage groups of objects on a per job >basis associated with a given table persistence than it is to manage each >object with a separate >persistence value. But the attributes in the Attribute table is the same data as the objects in the Job State table (unless you take the view which you have later on that the agent only fills in the Attribute table after the job completes or is canceled - but most of the attribute table has stuff that is known (and required to be filled in) while the job is pending and processing, so I think this view is out of date). So if the data is shared between the two tables, and the persistence is different between the two tables, the Attribute table has to point to the data in the State table for the data that is shared. For the Attribute table that is not shared, the data is in the Attribute table only with the shorter persistence. So whats the difference, if we have only the Attribute table. The data that is persistent for longer, the agent can put it into a different area of memory, such as if it were in the State table, but there is no State table accessible vis SNMP. I'm sure there are other methods of persistence management that clever agent implementors will come up with as well. We also have more felixibility in specifying which attribute have the longer persistence, if all the attributes are only in the Attribute table. We can just change the spec and say which attributes require the longer persistence; we don't have to add any objects to the State table (because there isn't a State table). SO the agent has to manage one subset of the data with a different persistence than the rest. Its not on per attribute basis. The implementation could just have two regions of memory, one that holds the attributes that have a longer persistence than the other, but from the application programs point of view it is one table. If it helps, we could allocate the jmAttributeTypeTC enums so that the longer persistent attributes were assigned together at the lower end of the enum range. > >2. Job Monitoring (progress, completion etc.) vs. Job Accounting. We used to >call the Attribute Table the Accounting Table. The Job State table can be >thought of as facilitating Job Monitoring while the Attribute table serves the >Accounting application. I think we should ask ourselves if there is any value >in some printer that implements the State table but not the Attribute Table - >i.e. facilitates Job Monitoring but not accounting. If so, then the separate >Job State table could really be of value to "low end" implementation. Recall >the Attribute table will be the largest consumer of memory for the agent and >has a more complex indexing scheme. There are attributes that a monitoring program must have that are not in the Job State table, such as jobOwner, etc. So the idea that an implementation could get away with not implementing the Attribute table is not valid, even if that implementation was not designed to do accounting. Also we agreed that the Attribute Table is mandatory with a small number of attributes as mandatory. > >3. Dynamics - Maybe we are operating from a mind set established back when we >used to call the Attribute Table the Resource Accounting Group... but we view >the JobState table as a group where objects are updated dynamically as the job >progresses but the Attribute (Accounting) table as something that is updated >upon job completion. Accounting applications are not interested in the PROGRESS >of a job - only the resulting details. An accounting application wants to >determine Job Complete (State Table) and then >"harvest" the accounting (attribute) information - ONCE. Dynamic objects, which >have not reached their final state or value, are of little value to an >accounting application. Thinking that the Attribute table was only for accounting program is one of the reasons I was so keen to change the name from AcountingTable to AttributeTable in order to avoid misleading people into thinking that the attribute table was only for accounting. There are a great many attributes that we all agreed that only make sense for monitoring programs, not accounting programs, such as pagesCompleted, any of the xxxRequested, any of xxxCompletredCurrentCopy, any of the xxxRequested (why would an accounting program care about requested as opposed to completed or consumed?). > >All three statements reflect one "philosophy". The job MIB lets you Monitor and >do Accounting. Does anyone think it has another purpose? Since these purposes >are distinct, the structure of the MIB reflects this. I disgree completely. Furthermore, the State table has flaws in that a monitoring program may need an Associated value for the processing state (impressionsRequested) when the job has changee to the printing state and so is no longer available to the monitoring application for its impression thermometer. I think it is much better to have a single structure that works for all applications with pointers to where the active jobs begin (since monitoring programs are only interested in active jobs), rather than designing copies of the data structures for two different applications. Having the same data accessible by different OIDs is just asking for trouble in implementation of the agent. > >The argument that everything can be found in the Attribute table and separate >persistence values can be given to each object etc. may be a good one and >perhaps it reflects better knowledge of SNMP than we had during design of the >Printer MIB but - to draw an analogy - why isn't the printer MIB just one big >table of printer Attributes instead of input, output, marker etc. groups? Because the objects are mandatory. The Attribute table allows a lot of conditionally mandatory attributes, depending on what kind of a print system you are monitoring jobs for. > >We think the 4 groups - General, ID, State and Attribute - are the optimal >arrangement of objects for Job Monitoring and Accounting. I disagree. Rebuttal invited. Lets here from others too. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed Apr 30 15:06:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> GWD: Job Monitoring MIB announced as an Internet Draft Message-ID: <9704301908.AA03233@zazen.cp10.es.xerox.com> >Return-Path: >To: IETF-Announce@ietf.org >Cc: pwg@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-00.txt >Date: Wed, 30 Apr 1997 07:19:49 PDT >Sender: owner-pwg@pwg.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Printer MIB Working Group of > the IETF. > > Title : Job Monitoring MIB - V0.81 > Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis > Filename : draft-ietf-printmib-job-monitor-00.txt > Pages : 78 > Date : 04/29/1997 > >This Internet-Draft specifies a set of 13 SNMP MIB objects for (1) >monitoring the status and progress of print jobs (2) obtaining resource >requirements before a job is processed, (3) monitoring resource consumption >while a job is being processed and (4) collecting resource accounting data >after the completion of a job. This MIB is intended to be implemented (1) >in a printer or (2) in a server that supports one or more printers. Use of >the object set is not limited to printing. However, support for services >other than printing is outside the scope of this Job Monitoring MIB. >Future extensions to this MIB may include, but are not limited to, fax >machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-00.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-00.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. >Content-Type: text/plain >Content-ID: <19970429141239.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-00.txt >Content-Type: text/plain >Content-ID: <19970429141239.I-D@ietf.org> > From harryl at us.ibm.com Wed Apr 30 18:35:37 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue Message-ID: <5030100002063141000003L013*@MHS> Classification: Whether we have a state table or not, the reasoning behind jmJobStateValue is to reduce polling. Without jmJobStateValue, which is a DEFINITION of which attribute is most "important" to a MONITORING application given a particular state, there are two alternatives, neither of which is as effective, and results in more network traffic.. 1. Poll twice, once to determine the state and then to get the more meaningful value 2. Poll for all the (potentially meaningful) objects. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed Apr 30 18:41:39 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? In-Reply-To: Why have a Job State Table ?> Message-ID: <5030100002063348000003L083*@MHS> Classification: Tom, thanks for your comments. We need input from some others to help us finally reach a decision (don't we?)! I'd just like to clarify one thing. I didn't mean to portray the Attribute table as only having valid entries for completed jobs. I should rather describe it as a table of STATIC values as opposed to the state table which is a table of DYNAMIC values. An object like jobName would be in the Attribute table as soon as the job is in any recognizable state. JobName is static and will not change. An object like ImpressionsCompleted, however, will change throughout the job and makes no sense to be in the Attribute table until it reaches it's FINAL value. This was my distinction of the State table as a table of DYNAMIC values and the attribute table as a table of STATIC values. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 04/30/97 04:32 PM ----- hastings@cp10.es.xerox.com 04/30/97 01:37 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org@internet Subject: Re: JMP> Why have a Job State Table ? At 08:23 04/30/97 PDT, Harry Lewis wrote: >Classification: > >We're making very good progress on the Job MIB, hopefully, bringing it to >closure soon. Great! >There are some remaining issues, 2 that concern me, namely the Job State Table >and jmJobStateValue. [I changed the name to jmJobStateAssociatedValue, because some reviewers though that jmJobStateValue was the actual value of the state.] > >With this note, I'd like to address the issue regarding whether or not to "do >away with" the Job State Table. I agree it is the biggest issue(s) remaining. > >As a refresher, the job state table is indexed by jmJobSetIndex and jmJobIndex >and each entry consists of the State, Octets completed, Impressions completed >and associated State Value which is tailored to contain the most pertinent >information for the current STATE (we'll discuss this separately). The >"argument" for elimination is that all the information in the State Table can >be obtained from attributes in the Attribute Table. > >I will try to articulate why I think we should keep the Job State Table. Very helpful. > >1. Persistence. The JobState table has a longer persistence than the Attribute >table. It is simpler for the agent to manage groups of objects on a per job >basis associated with a given table persistence than it is to manage each >object with a separate >persistence value. But the attributes in the Attribute table is the same data as the objects in the Job State table (unless you take the view which you have later on that the agent only fills in the Attribute table after the job completes or is canceled - but most of the attribute table has stuff that is known (and required to be filled in) while the job is pending and processing, so I think this view is out of date). So if the data is shared between the two tables, and the persistence is different between the two tables, the Attribute table has to point to the data in the State table for the data that is shared. For the Attribute table that is not shared, the data is in the Attribute table only with the shorter persistence. So whats the difference, if we have only the Attribute table. The data that is persistent for longer, the agent can put it into a different area of memory, such as if it were in the State table, but there is no State table accessible vis SNMP. I'm sure there are other methods of persistence management that clever agent implementors will come up with as well. We also have more felixibility in specifying which attribute have the longer persistence, if all the attributes are only in the Attribute table. We can just change the spec and say which attributes require the longer persistence; we don't have to add any objects to the State table (because there isn't a State table). SO the agent has to manage one subset of the data with a different persistence than the rest. Its not on per attribute basis. The implementation could just have two regions of memory, one that holds the attributes that have a longer persistence than the other, but from the application programs point of view it is one table. If it helps, we could allocate the jmAttributeTypeTC enums so that the longer persistent attributes were assigned together at the lower end of the enum range. > >2. Job Monitoring (progress, completion etc.) vs. Job Accounting. We used to >call the Attribute Table the Accounting Table. The Job State table can be >thought of as facilitating Job Monitoring while the Attribute table serves the >Accounting application. I think we should ask ourselves if there is any value >in some printer that implements the State table but not the Attribute Table - >i.e. facilitates Job Monitoring but not accounting. If so, then the separate >Job State table could really be of value to "low end" implementation. Recall >the Attribute table will be the largest consumer of memory for the agent and >has a more complex indexing scheme. There are attributes that a monitoring program must have that are not in the Job State table, such as jobOwner, etc. So the idea that an implementation could get away with not implementing the Attribute table is not valid, even if that implementation was not designed to do accounting. Also we agreed that the Attribute Table is mandatory with a small number of attributes as mandatory. > >3. Dynamics - Maybe we are operating from a mind set established back when we >used to call the Attribute Table the Resource Accounting Group... but we view >the JobState table as a group where objects are updated dynamically as the job >progresses but the Attribute (Accounting) table as something that is updated >upon job completion. Accounting applications are not interested in the PROGRESS >of a job - only the resulting details. An accounting application wants to >determine Job Complete (State Table) and then >"harvest" the accounting (attribute) information - ONCE. Dynamic objects, which >have not reached their final state or value, are of little value to an >accounting application. Thinking that the Attribute table was only for accounting program is one of the reasons I was so keen to change the name from AcountingTable to AttributeTable in order to avoid misleading people into thinking that the attribute table was only for accounting. There are a great many attributes that we all agreed that only make sense for monitoring programs, not accounting programs, such as pagesCompleted, any of the xxxRequested, any of xxxCompletredCurrentCopy, any of the xxxRequested (why would an accounting program care about requested as opposed to completed or consumed?). > >All three statements reflect one "philosophy". The job MIB lets you Monitor and >do Accounting. Does anyone think it has another purpose? Since these purposes >are distinct, the structure of the MIB reflects this. I disgree completely. Furthermore, the State table has flaws in that a monitoring program may need an Associated value for the processing state (impressionsRequested) when the job has changee to the printing state and so is no longer available to the monitoring application for its impression thermometer. I think it is much better to have a single structure that works for all applications with pointers to where the active jobs begin (since monitoring programs are only interested in active jobs), rather than designing copies of the data structures for two different applications. Having the same data accessible by different OIDs is just asking for trouble in implementation of the agent. > >The argument that everything can be found in the Attribute table and separate >persistence values can be given to each object etc. may be a good one and >perhaps it reflects better knowledge of SNMP than we had during design of the >Printer MIB but - to draw an analogy - why isn't the printer MIB just one big >table of printer Attributes instead of input, output, marker etc. groups? Because the objects are mandatory. The Attribute table allows a lot of conditionally mandatory attributes, depending on what kind of a print system you are monitoring jobs for. > >We think the 4 groups - General, ID, State and Attribute - are the optimal >arrangement of objects for Job Monitoring and Accounting. I disagree. Rebuttal invited. Lets here from others too. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Thu May 1 20:07:07 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Output Bin Problems Message-ID: <5030100002129188000002L082*@MHS> Classification: Tom, a couple comments related to Output Bin and the Job MIB using draft v.81. 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for state COMPLETED cannot be outputBinName, as you have specified. I had specified outputBinIndex, not Name. 2. Pg 35. jmStateAssociatedValue is SINGULAR. You have defined attributes outputBinIndex and outputBinName as Multi-Row. This is probably ok for the Attribute table but, for the JobStateTable, we need a single value to represent outputBin when the job is completed. I had specified a simple method as follows: -1 Unknown -2 Multi prtOutputIndex I believe, as I've stated many times, the jmJobStateTable is very useful for JOB STATUS MONITORING (not job accounting). For accounting, I can (sorta) see where you might be interested in the multi-bin facet of outputs used. But, if you've submitted a job, I believe you want to know it's state, it's progress and it's final destination. If you asked for collated copies, that final destination might be (-2 Multi). I think that's enough to know, at that point. I'd like us to go back to my proposal for outputbin on jmJobStateValue. 3. Pg. 41 You have separate attributes defined for output bin name and number. Yet, the attribute table is structured such that an attribute type (output bin) can have either an Integer or String representation. It is not necessary to have two enums. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Fri May 2 12:20:48 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Attribute Persistence Message-ID: <5030100002146218000002L082*@MHS> Classification: Tom, on page 34, you have a list of "mandatory attributes" which relate to the attributes "behind" the jmJobStateValue (if your will). On page 61, line 1289, you describe that "Attributes shared between State and Attribute tables shall be governed by the longer persistence" (paraphrase). Actually, this is not necessarily true except for the StateValue for Completed state (bin). Other StateValue attributes only need to persist as long as the State itself persists. First, recall the persistence relates to the amount of time an entry remains AFTER THE JOB IS COMPLETED. Next, take numberofInterveningJobs (the state value for pending state) for example. There is no need for this attribute to take on the overall (longer) persistence of the state table. It will be (to coin a phrase) HISTORY by the time the job reaches COMPLETED state. I think, if we follow this reasoning, we'll conclude only outputBinIndex needs the persistence linkage you described. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Fri May 2 13:20:37 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: (no subject) Message-ID: <5030100002151586000002L062*@MHS> Classification: I would like to see some thought given to the syntax of jobSubmissionToDeviceDateandTime as it would be carried in a PJL command. Tom points out that DateandTime is an 8 or 11 octet binary encoded year, month, day, hour, minute, second and deci-second with optional offset from UTC. Wouldn't this have to be converted to a hex string to work inside PJL? Then the agent would have to convert to the binary syntax. I know that Bob has mentioned the possibility of a PJL command for jmJobSubmissionID. I'm not asking Bob to necessarily define PJL commands for all the Job MIB attributes (although that would be NICE!), but I imagine PJL (among other methods) *will* be used in some form to carry many of these attributes. It would be good if we gain an understanding of how this should work. I would invite the same discussion for PS. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon May 5 19:45:30 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobID Table Indexing Message-ID: <5030100002224932000003L023*@MHS> Tom, in v1, there were inconsistent implementations when using strings as an index. In some cases, the octet string would be preceded by it's length e.g. get-request jmJobIndex.5.h.a.r.r.y In other cases, the length of the octet string would be IMPLIED by the length of the OID, so the 'length' indication wasn't included. get-request jmJobIndex.h.a.r.r.y I think v2 tried to address this inconsistency by Adding 'IMPLIED' to the declaration which clearly indicates the 'length' should be omitted. jmJobIDEntry OBJECT-TYPE ... INDEX { IMPLIED jmJobSubmissionIDIndex } ... I would like to request that you change the definition of jmJobIDEntry as such. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon May 5 20:27:17 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: (no subject) Message-ID: <5030100002225868000002L082*@MHS> Tom, I'm trying to understand why you chose two different ways to represent kOctets. See jobKOctetsRequested(48) v.81 pg. 42 where 1-1024 is represented as 1 vs. jobKOctetsTransferred(49) and jobKOctetsCompleted(50) v.81 pg. 43 where 1-1023 is represented as 1 vs. Is this just a typo? Harry Lewis - IBM Printing Systems From jkm at underscore.com Tue May 6 14:28:42 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Meeting room assignments for the San Diego meetings Message-ID: <199705061828.OAA27808@uscore.underscore.com> The previously published meeting room assignments for the upcoming San Diego meetings have been slightly changed. The May IEEE/PWG meetings will now be held in the following rooms at the Marriott Suites in San Diego: P1284.3 May 8-9 Maestro Room P1284.4 May 12-13 Symphony Bay 1 1394PWG May 14 Symphony Bay 1,2,3 IPP May 15 Symphony Bay 1,2,3 JMP/PWG May 16 Symphony Bay 1 ...jay PS: Sorry for the massive cross-posting; we don't quite yet have a policy/mechanism for sending messages of this type to a single list. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- Date: Mon, 05 May 1997 09:25:26 -0700 To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org From: Larry Stein The May IEEE/PWG meetings will be held in the following rooms at the Marriott Suites: P1284.3 May 8-9 Maestro Room P1284.4 May 12-13 Maestro Room 1394PWG May 14 Symphony Bay 1&2 IPP May 15 Symphony Bay 1&2 JMP/PWG May 16 Maestro Room The weathers great in San Diego, dress casual and comfortable. -Larry ***************************************************************************** Larry A. Stein Phone: (619)292-2740 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************************** ----- End Included Message ----- From hastings at cp10.es.xerox.com Tue May 6 14:19:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: rounding up in jobKOctetsRequested(48) vs. In-Reply-To: Message-ID: <9705061821.AA05223@zazen.cp10.es.xerox.com> At 17:27 05/05/97 PDT, Harry Lewis wrote: >Tom, I'm trying to understand why you chose two different ways to represent >kOctets. >See jobKOctetsRequested(48) v.81 pg. 42 where 1-1024 is represented as 1 vs. >jobKOctetsTransferred(49) and jobKOctetsCompleted(50) v.81 pg. 43 where 1-1023 >is represented as 1 vs. > >Is this just a typo? > >Harry Lewis - IBM Printing Systems > > Oops! The latter two are typos. All three should be the same as follows: Actual octets Rounded K value ------------- --------------- 0 0 1-1024 1 1025-2048 2 2049-3072 3 3073-4096 4 etc. In other words, if the actual value is an integral number of K (1024) then the number of K is the value. If the actual value is more than an integral number of K, then round up to the next higher number of K. This can be computed simply as: 1 + IntegerPartOf((ActualOctets-1)/1024) Is it sufficient if I change the descriptions of jobKOctetsTransferred(49) and jobKOctetsCompleted(50) on page 43 to: The agent shall round the actual number of octets [transferred/completed] up to the next higher K. Thus 0 octets shall be represented as 0, 1-1024 octets shall be reprsented as 1, 1025-2048 octets shall be represented as 2, 2049-3072 octets shall be represented as 3, etc. Or do we need a more rigorous mathematical expression, such as the one above or is there a better way to say this in words? Thanks, Tom From hastings at cp10.es.xerox.com Tue May 6 15:10:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: JobID Table Indexing [change to IMPLIED In-Reply-To: Message-ID: <9705061912.AA05310@zazen.cp10.es.xerox.com> At 16:45 05/05/97 PDT, Harry Lewis wrote: >Tom, in v1, there were inconsistent implementations when using strings as an >index. In some cases, the octet string would be preceded by it's length > > e.g. get-request jmJobIndex.5.h.a.r.r.y > >In other cases, the length of the octet string would be IMPLIED by >the length of the OID, so the 'length' indication wasn't included. > > get-request jmJobIndex.h.a.r.r.y > >I think v2 tried to address this inconsistency by Adding 'IMPLIED' >to the declaration which clearly indicates the 'length' should be omitted. > > jmJobIDEntry OBJECT-TYPE > ... > INDEX { IMPLIED jmJobSubmissionIDIndex } > ... > >I would like to request that you change the definition of jmJobIDEntry as such. > >Harry Lewis - IBM Printing Systems > > I made the change to add IMPLIED, and it compiles with the compilers that are doing the 1400 series SMIv2, so it shouldn't cause anyone any problems. However, in order to get the SMICng compiler to accept it, I had to change the lower bound on the jmJobSubmissionIDIndex OCTET STRING index from 0 to 1, which seems like a good idea anyway. So I've made the change in the next version, unless anyone objects. ISSUE: Should we add a sentence explaining that the length shall not be included in the OCTET STRING, or is that well known, given the IMPLIED statement? Thanks, Tom From hastings at cp10.es.xerox.com Wed May 7 06:27:44 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Output Bin Problems In-Reply-To: Output Bin Problems> Message-ID: <9705071029.AB05539@zazen.cp10.es.xerox.com> At 17:07 05/01/97 PDT, Harry Lewis wrote: >Classification: > >Tom, a couple comments related to Output Bin and the Job MIB using draft v.81. > > 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for >state COMPLETED cannot be outputBinName, as you have specified. I had specified >outputBinIndex, not Name. I agree I created a problem. We can't fit an OctetString into 32-bits. But changing the jobStateAssociatedValue to use outputBinIndex brings up another issue, which I'm calling issue 73: Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue object and attribute require it, but an implementation doesn't have the Printer MIB, the agent has to put 0 as the value. Should we add one more attribute: outputBinNumber, which is just a number, not an index into the Printer MIB? If we do, which should be mandatory? Just one more reason to get rid of the AssociatedValue object and attribute, which is forcing us to pick a particular outputBin implementation and make it mandatory. If we got rid of the AssociatedValue object/attribute, we could forget about making any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute mandatory. If we get rid of the AssociatedValue object/attribute, then we don't need to add the outputBinNumber attribute either, since an implementation can just put in the ASCII digits for the bin number into the outputBinName attribute. > > 2. Pg 35. jmStateAssociatedValue is SINGULAR. You have defined attributes >outputBinIndex and outputBinName as Multi-Row. This is probably ok for the >Attribute table but, for the JobStateTable, we need a single value to represent >outputBin when the job is completed. I had specified a simple method as follows: > > -1 Unknown > -2 Multi > prtOutputIndex > >I believe, as I've stated many times, the jmJobStateTable is very useful for >JOB STATUS MONITORING (not job accounting). For accounting, I can (sorta) see >where you might be interested in the multi-bin facet of outputs used. But, if >you've submitted a job, I believe you want to know it's state, it's progress >and it's final destination. If you asked for collated copies, that final >destination might be (-2 Multi). I think that's enough to know, at that point. > >I'd like us to go back to my proposal for outputbin on jmJobStateValue. If we keep the jmJobStateAssociatedValue object and jobStateAssociatedValue attribute, and agree to have something that fits into 32 bits, we should have the minus values as you suggest. (Though I would think we should use -1 for multi (other), and -2 for unknown, as we do elsewhere in this MIB and the Printer MIB. On the other hand, ISSUE 73 is still with us, even if we put in the negative values. > >3. Pg. 41 You have separate attributes defined for output bin name and number. >Yet, the attribute table is structured such that an attribute type (output bin) >can have either an Integer or String representation. It is not necessary to >have two enums. I agree, that it isn't necessary to have two enums. We could have just one enum, say, outputBin, which allows either the jmAttributeValueAsOctets (for output bin name) or jmAttributeValueAsInteger (for output bin index). We could even allow both to be used for the same row. On the other hand, I think we considered this and decided that it was cleaner and simpler to have two separate enums, one for the Integer value and the other for the Octets value. However, since you raised the issue, I've added it as Issue 74: ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? Analysis of the 78 attributes shows that there are 8 attribute pairs that could be collapsed into one attribute with the implementation using either the Integer or the Octets value (or both) to represent the attribute. The application would have to query both value objects. But if it is using GetNext, it has to get both each time anyway. Only if it is directly accessing an attribute would it have to get both values. On the other hand, it would be fewer Gets than having two attributes as we have now. The 8 paris are: physicalDeviceIndex physicalDeviceName outputBinIndex outputBinName mediumRequestedType mediumRequestedName colorantRequestedIndex colorantRequestedName colorantConsumedIndex colorantConsumedName jobSubmissionToDeviceDateAndTime jobSubmissionToDeviceTimeStamp jobStartedProcessingDateAndTime jobStartedProcessingTimeStamp jobCompletedDateAndTime jobCompletedTimeStamp Should we collapse them into the following: physicalDevice outputBin mediumRequested colorantRequested colorantConsumed jobSubmissiontToDeviceTime jobStartedProcessingTime jobCompletedTime Should we allow an implementation to fill in both with meaningful values? > > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed May 7 06:27:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? In-Reply-To: Why have a Job State Table ?> Message-ID: <9705071030.AB05539@zazen.cp10.es.xerox.com> At 15:41 04/30/97 PDT, Harry Lewis wrote: >Classification: > >Tom, thanks for your comments. We need input from some others to help us >finally reach a decision (don't we?)! We sure do need others input. In the meantime, lets keep up the dialog, because I think that we still have some different understandings about this MIB and the dialog will help flush out those different understandings. > >I'd just like to clarify one thing. I didn't mean to portray the Attribute >table as only having valid entries for completed jobs. I should rather describe >it as a table of STATIC values as opposed to the state table which is a table >of DYNAMIC values. > >An object like jobName would be in the Attribute table as soon as the job is in >any recognizable state. JobName is static and will not change. An object like >ImpressionsCompleted, however, will change throughout the job and makes no >sense to be in the Attribute table until it reaches it's FINAL value. This was >my distinction of the State table as a table of DYNAMIC values and the >attribute table as a table of STATIC values. To test your assertion that the Attribute table could be clarifed as only having values after they reach a final STATIC value, here is the entire TOC. I've labeled with S or D each attribute to indicate STATIC versus DYNAMIC test your assertion that the Attribute table only contains STATIC attribute and the Job State table should be the only place for DYNAMIC attributes. The entries with D* are also accessible through the Job State table. However, there are 26 DYNAMIC attributes, i.e., 26 attribute are likely to have their value change as the job progresses out of a total of 78 attributes. The current Job State table only provides access to 9 DYNAMIC attributes out of a possible 26. Therefore, I do not see the Attribute table as only containing STATIC values after they reach a final value and the job state table being the only place that changes the values as the job progresses, i.e, the only place for DYNAMIC values. So unless we change our minds and throw away 26-9=15 of these 26 DYNAMIC attributes, a monitoring program is going to be very interested in the attribute table and the attributes in it that are changing. That is why I have been questioning the wisdom of also having the Job State Table. Besides I'd also like to see us reduce the number of mandatory objects by another 30%, (go from 13 to 10, by dropping the Job State table), have only one way to access information (the Attributes Table), and avoid the agent complexity of the same data appearing in more than one table. S=STATIC, D=DYNAMIC, D*=DYNAMIC and accessible through the Job State Table JmAttributeTypeTC - attribute type definitions 34 other 37 unknown 38 Job State attributes 38 D* jobState (mandatory) 38 D* jobStateAssociatedValue 38 D jobStateReasons1 39 D jobStateReasons2 40 D jobStateReasons3 40 D jobStateReasons4 41 D* numberOfInterveningJobs (mandatory) 41 D* deviceAlertCode (mandatory) 41 D processingMessage 41 Job Identification attributes 41 S serverAssignedJobName 41 S jobName 42 S jobServiceTypes 42 S jobOwner 43 S jobAccountName 43 S jobSourceChannelIndex 43 S jobSourcePlatformType 43 S submittingServerName 44 S submittingApplicationName 44 S deviceNameRequested 44 S queueNameRequested 44 S physicalDeviceIndex 44 S physicalDeviceName 45 S numberOfDocuments 45 S fileName 45 S documentName 45 S jobComment 45 S documentFormatIndex 46 S documentFormatType 46 Job Parameter attributes 47 S jobPriority 47 S jobProcessAfterDateAndTime 47 S jobHoldUntil 48 S outputBinIndex 48 S outputBinName (mandatory) 48 S sides 48 S finishing 48 Image Quality attributes (requested and used) 48 S printQualityRequested 48 S printQualityUsed 49 S tonerEcomonyRequested 49 S tonerEcomonyUsed 49 S tonerDensityRequested 49 S tonerDensityUsed 49 Job Progress attributes (requested and consumed) 49 S jobCopiesRequested 49 D jobCopiesCompleted 49 S documentCopiesRequested 50 D documentCopiesCompleted 50 S jobKOctetsRequested (mandatory) 50 D jobKOctetsTransferred (mandatory) 51 D* jobKOctetsCompleted (mandatory) 51 Impression attributes (requested and consumed) 52 D impressionsSpooled 52 D impressionsSentToDevice 52 D impressionsInterpreted 52 S impressionsRequested (mandatory) 52 D* impressionsCompleted (mandatory) 52 D impressionsCompletedCurrentCopy 53 Page attributes (requested and consumed) 53 S pagesRequested 53 D pagesCompleted 53 D pagesCompletedCurrentCopy 53 Sheet attributes (requested and consumed) 53 S sheetsRequested 54 D sheetsCompleted 54 D sheetsCompletedCurrentCopy 54 Resource attributes (requested and consumed) 54 S mediumRequestedType 54 S mediumRequestedName 54 D mediumConsumedName 55 S colorantRequestedIndex 55 S colorantRequestedName 55 D colorantConsumedIndex 55 D colorantConsumedName 55 Time attributes (set by server or device) 56 S jobSubmissionToServerDateAndTime 56 S jobSubmissionToDeviceDateAndTime 56 S jobSubmissionToDeviceTimeStamp 56 S jobStartedBeingHeldTimeStamp 57 S jobStartedProcessingDateAndTime 57 S jobStartedProcessingTimeStamp 57 S jobCompletedDateAndTime 57 S jobCompletedTimeStamp 57 D jobProcessingCPUTime 57 > >Harry Lewis - IBM Printing Systems > > >------ Forwarded by Harry Lewis/Boulder/IBM on 04/30/97 04:32 PM ----- > > hastings@cp10.es.xerox.com > 04/30/97 01:37 PM > > >To: Harry Lewis/Boulder/IBM@IBMUS >cc: jmp@pwg.org@internet >Subject: Re: JMP> Why have a Job State Table ? > >At 08:23 04/30/97 PDT, Harry Lewis wrote: >>Classification: >> >>We're making very good progress on the Job MIB, hopefully, bringing it to >>closure soon. Great! > >>There are some remaining issues, 2 that concern me, namely the Job State Table >>and jmJobStateValue. > >[I changed the name to jmJobStateAssociatedValue, because some reviewers >though that jmJobStateValue was the actual value of the state.] > >> >>With this note, I'd like to address the issue regarding whether or not to "do >>away with" the Job State Table. > >I agree it is the biggest issue(s) remaining. > >> >>As a refresher, the job state table is indexed by jmJobSetIndex and jmJobIndex >>and each entry consists of the State, Octets completed, Impressions completed >>and associated State Value which is tailored to contain the most pertinent >>information for the current STATE (we'll discuss this separately). The >>"argument" for elimination is that all the information in the State Table can >>be obtained from attributes in the Attribute Table. >> >>I will try to articulate why I think we should keep the Job State Table. > >Very helpful. > >> >>1. Persistence. The JobState table has a longer persistence than the Attribute >>table. It is simpler for the agent to manage groups of objects on a per job >>basis associated with a given table persistence than it is to manage each >>object with a separate >>persistence value. > >But the attributes in the Attribute table is the same data as the >objects in the Job State table (unless you take the view which you have >later on that the agent only fills in the Attribute table after the job >completes or is canceled - but most of the attribute table has stuff that >is known (and required to be filled in) while the job is pending and >processing, so I think this view is out of date). > >So if the data is shared between the two tables, and the persistence is >different between the two tables, the Attribute table has to point to >the data in the State table for the data that is shared. For the Attribute >table that is not shared, the data is in the Attribute table only with >the shorter persistence. > >So whats the difference, if we have only the Attribute table. The data >that is persistent for longer, the agent can put it into a different >area of memory, such as if it were in the State table, but there is >no State table accessible vis SNMP. I'm sure there are other methods >of persistence management that clever agent implementors will come up with >as well. > >We also have more felixibility in specifying which attribute have the longer >persistence, if all the attributes are only in the Attribute table. >We can just change the spec and say which attributes require the longer >persistence; we don't have to add any objects to the State table (because >there isn't a State table). > >SO the agent has to manage one subset of the data with a different >persistence than the rest. Its not on per attribute basis. >The implementation could just have two regions >of memory, one that holds the attributes that have a longer persistence >than the other, but from the application programs point of view it is >one table. > >If it helps, we could allocate the jmAttributeTypeTC enums so that >the longer persistent attributes were assigned together at the lower >end of the enum range. > > >> >>2. Job Monitoring (progress, completion etc.) vs. Job Accounting. We used to >>call the Attribute Table the Accounting Table. The Job State table can be >>thought of as facilitating Job Monitoring while the Attribute table serves the >>Accounting application. I think we should ask ourselves if there is any value >>in some printer that implements the State table but not the Attribute Table - >>i.e. facilitates Job Monitoring but not accounting. If so, then the separate >>Job State table could really be of value to "low end" implementation. Recall >>the Attribute table will be the largest consumer of memory for the agent and >>has a more complex indexing scheme. > >There are attributes that a monitoring program must have that are not >in the Job State table, such as jobOwner, etc. So the idea that an >implementation could get away with not implementing the Attribute table >is not valid, even if that implementation was not designed to do accounting. >Also we agreed that the Attribute Table is mandatory >with a small number of attributes as mandatory. > > >> >>3. Dynamics - Maybe we are operating from a mind set established back when we >>used to call the Attribute Table the Resource Accounting Group... but we view >>the JobState table as a group where objects are updated dynamically as the job >>progresses but the Attribute (Accounting) table as something that is updated >>upon job completion. Accounting applications are not interested in the PROGRESS >>of a job - only the resulting details. An accounting application wants to >>determine Job Complete (State Table) and then >>"harvest" the accounting (attribute) information - ONCE. Dynamic objects, which >>have not reached their final state or value, are of little value to an >>accounting application. > >Thinking that the Attribute table was only for accounting program is one of >the reasons I was so keen to change the name from AcountingTable to >AttributeTable >in order to avoid misleading people into thinking that the attribute table >was only for accounting. There are a great many attributes that we all >agreed that only make sense for monitoring programs, not accounting programs, >such as pagesCompleted, any of the xxxRequested, any of >xxxCompletredCurrentCopy, any of the xxxRequested >(why would an accounting program care about requested as opposed to completed >or consumed?). > > > >> >>All three statements reflect one "philosophy". The job MIB lets you Monitor and >>do Accounting. Does anyone think it has another purpose? Since these purposes >>are distinct, the structure of the MIB reflects this. > >I disgree completely. Furthermore, the State table has flaws in that >a monitoring program may need an Associated value for the processing >state (impressionsRequested) when the job has changee to the printing >state and so is no longer available to the monitoring application >for its impression thermometer. > >I think it is much better to have a single structure that works for >all applications with pointers to where the active jobs begin (since >monitoring programs are only interested in active jobs), >rather than designing copies of the data structures for two different >applications. Having the same data accessible by different OIDs is >just asking for trouble in implementation of the agent. > >> >>The argument that everything can be found in the Attribute table and separate >>persistence values can be given to each object etc. may be a good one and >>perhaps it reflects better knowledge of SNMP than we had during design of the >>Printer MIB but - to draw an analogy - why isn't the printer MIB just one big >>table of printer Attributes instead of input, output, marker etc. groups? > >Because the objects are mandatory. The Attribute table allows a lot >of conditionally mandatory attributes, depending on what kind of a print >system you are monitoring jobs for. > >> >>We think the 4 groups - General, ID, State and Attribute - are the optimal >>arrangement of objects for Job Monitoring and Accounting. > >I disagree. > >Rebuttal invited. > >Lets here from others too. > >> >>Harry Lewis - IBM Printing Systems >> >> > > > > > > From jkm at underscore.com Wed May 7 09:51:30 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Where are all the Job MIB prototypers? Message-ID: <199705071351.JAA00862@uscore.underscore.com> Tom Hastings wrote: > At 15:41 04/30/97 PDT, Harry Lewis wrote: > >Classification: > > > >Tom, thanks for your comments. We need input from some others to help us > >finally reach a decision (don't we?)! > > We sure do need others input. In the meantime, lets keep up the dialog, > because I think that we still have some different understandings about this > MIB and the dialog will help flush out those different understandings. Where are all the other vendors trying to implement the Job Monitoring MIB? Are those vendors having the same problems as well? Can *anyone* else make any comments/suggestions/observations at this point? Tom: what has Xerox's experience been along these lines? ...jay From jkm at underscore.com Wed May 7 13:03:32 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Mandatory objects, Printer MIB relationship and more Message-ID: <199705071703.NAA01090@uscore.underscore.com> Oops...this message was originally sent to the wrong list. ----- Begin Included Message ----- Date: Wed, 7 May 1997 10:12:37 -0400 (EDT) From: JK Martin To: hastings@cp10.es.xerox.com Subject: PMP> Mandatory objects, Printer MIB relationship and more Cc: pmp@pwg.org Tom, > But changing the jobStateAssociatedValue to use outputBinIndex > brings up another issue, which I'm calling issue 73: > > Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue > object and attribute require it, but an implementation doesn't have the > Printer MIB, the agent has to put 0 as the value. Should we add one more > attribute: outputBinNumber, which is just a number, not an index into the > Printer MIB? If we do, which should be mandatory? Just one more reason to > get rid of the AssociatedValue object and attribute, which is forcing us to > pick a particular outputBin implementation and make it mandatory. If we got > rid of the AssociatedValue object/attribute, we could forget about making > any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute > mandatory. > > If we get rid of the AssociatedValue object/attribute, then we don't > need to add the outputBinNumber attribute either, since an implementation > can just put in the ASCII digits for the bin number into the outputBinName > attribute. I'm sorry, but this is getting to be just plain scarry. When I read "If outputBinIndex is made mandatory...", it makes me realize that I don't have a good handle for exactly what the minimum conforming implementation is at this point. Can you post a simple text-only table of all the mandatory elements of the Job MIB? (Something like one line per mandatory element would be great.) Tom, we are really getting down to the wire on the Job MIB (right????). When you write words like: "Just one more reason to get rid of the AssociatedValue object and attribute..." it makes me think the basic Job MIB functional model is not completely thought out. It this stage of the game, we need to have the functional model complete, wouldn't you agree? Another key question we've danced around over the years is how closely is the Printer MIB related to the Job MIB? Didn't we come to the consensus where an agent supporting the Job MIB did not necessarily have support for the Printer MIB? That is, there should no binding between the Job MIB and the Printer MIB. Do I have that right? I certainly understand the desire to keep the two MIBs conceptually the same, at least in terms of modeling characteristics, terminology, etc. It's the explicit binding between the two that I'm asking about here. > On the other hand, I think we considered this and decided that it was > cleaner and simpler to have two separate enums, one for the Integer > value and the other for the Octets value. > > [...] > > ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? > > Analysis of the 78 attributes shows that there are 8 attribute > pairs that could be collapsed into one attribute with the implementation > using either the Integer or the Octets value (or both) to represent > the attribute. The application would have to query both value objects. > But if it is using GetNext, it has to get both each time anyway. > Only if it is directly accessing an attribute would it have to get > both values. On the other hand, it would be fewer Gets than having > two attributes as we have now. > > [...] > > Should we allow an implementation to fill in both with meaningful values? Can someone state the fundamental rationale for taking the approach of having two enums, one for Integer and one for Octets? This is very confusing to me. A few words of explanation might help here. Why, oh why is the Job MIB so COMPLEX ??? To solve the #1 problem of "Is my job done yet?", we have devolved into one of the most complex MIB definitions yet. Doesn't this concern anyone else? (Hopefully some of the other vendors doing a prototype can respond here.) ...jay ----- End Included Message ----- From harryl at us.ibm.com Wed May 7 14:05:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? In-Reply-To: Why have a Job State Table ?> Message-ID: <5030100002277854000002L042*@MHS> Tom... I thought you'd never ask! >However, there are 26 DYNAMIC attributes, i.e., 26 attribute are likely >to have their value change as the job progresses out of a total of 78 >attributes. The current Job State table only provides access to 9 DYNAMIC >attributes out of a possible 26. Therefore, I do not see the Attribute table >as only containing STATIC values after they reach a final value and the job >state table being the only place that changes the values as the job progresses, >i.e, the only place for DYNAMIC values. And, I never thought you'd be so Bold! ;-) >So unless we change our minds and throw away 26-9=15 of these 26 DYNAMIC >attributes, a monitoring program is going to be very interested in the attribute >table and the attributes in it that are changing. I'm using some levity, of course, but, honestly, Tom, as I was reading your msg, before I even got to your list, I was betting you had done an excellent job categorizing which attributes are clogging the Job MIB arteries. And you HAVE, almost to a tee. With this posting, I think you've really hit the nail squarely and reveled the key remaining discussion topic. I've been uneasy about all these attributes but I always suppress it with the argument I know I'll hear... attributes are not mandatory so why not "PILE ON". And, why limit the MIB - if someone wants to use it to shoot printers into outerspace - let them. I've even thought about adding a few attributes to try and make my point... let's see... For starters, how about jobStateReasons5,6,7,8 and 9? Then we could add... currentOctetBeingExaminedByPDLInterpreter Tom, my "jovial" disposition is probably not coming across well in this note. This is not meant as a "slap". I just hardly know where to take this, anymore. While you and I are in strong agreement for most of the Job MIB, it should be obvious, we have vastly differing opinions regarding use of the State and Attribute tables. I understand how bogged down we all get with this PWG mail, so we may not really hear from others until the meeting next week. I'd like to encourage anyone interested in resolution of the topic to consider these issues and come prepared with your position to the meeting. Below, I'll do *my* categorization of the 29 attributes you listed as dynamic and having no home if we try to keep the Attribute table static. Category A - "Why does this need to be Dynamic?" Yes, the attributes in this category are "dynamic", but are the dynamics really interesting or useful? I consider these attributes static, or at least discrete... in that they are not changing as the job progresses as much as they have some (potentially) useful meaning any time the job STOPS progressing. D jobStateReasons1 39 D jobStateReasons2 40 D jobStateReasons3 40 D jobStateReasons4 41 Is the REASON that a job is pending, printing, processing or completed an interesting attribute? I say NO! Perhaps we should change the StateValue for HELD to REASON rather than TIME, I could live with that (*please* don't say there could be 10 reasons why the job got held!). In the NeedsAttention state, we already have a StateValue showing the alert code. The only remaining state is Canceled - final state - where the REASONS are not going to CHANGE. D processingMessage 41 Similarly - are we wanting to catch messages as they fly by during normal operation? NO! D sheetsCompleted 54 D sheetsCompletedCurrentCopy 54 D mediumConsumedName 55 D colorantConsumedIndex 55 D colorantConsumedName 55 D jobProcessingCPUTime 57 Category X - "Who needs this Anyway" D jobKOctetsTransferred (mandatory) 51 I thought we had agreed that Octets were too elusive for most agents and we would focus on impressions. Also, this brings us into the granularity discussion. There go my octets... they're being transferred... now they're buffered... oh, look, they are entering the PDL interpreter... and finally being laid to rest on the drum... making a fine impression, indeed. D pagesCompleted 53 D pagesCompletedCurrentCopy 53 I thought we had pretty much agreed pages were too elusive for most agents and we would focus on impressions. D impressionsSpooled 52 D impressionsSentToDevice 52 D impressionsInterpreted 52 (This is the only one I might agree with you on). D documentCopiesCompleted 50 Category Y - "I think these are covered by StateValues." D jobCopiesCompleted 49 D impressionsCompletedCurrentCopy 53 The StateValue for printing that I had defined was CurrentCopy. Somehow, it got changed in your MIB to impressionsRequested... which is a STATIC attribute. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed May 7 14:13:18 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Output Bin Problems In-Reply-To: Output Bin Problems> Message-ID: <5030100002278101000002L012*@MHS> Tom, ... why can't an implementation that does not have the job mib just say "unknown" for the output bin. Wouldn't this, indeed, be the case? Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 05/07/97 12:07 PM -------- jmp-owner@pwg.org 05/07/97 04:33 AM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: JMP@pwg.org @ internet Subject: Re: JMP> Output Bin Problems At 17:07 05/01/97 PDT, Harry Lewis wrote: >Classification: > >Tom, a couple comments related to Output Bin and the Job MIB using draft v.81. > > 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for >state COMPLETED cannot be outputBinName, as you have specified. I had specified >outputBinIndex, not Name. I agree I created a problem. We can't fit an OctetString into 32-bits. But changing the jobStateAssociatedValue to use outputBinIndex brings up another issue, which I'm calling issue 73: Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue object and attribute require it, but an implementation doesn't have the Printer MIB, the agent has to put 0 as the value. Should we add one more attribute: outputBinNumber, which is just a number, not an index into the Printer MIB? If we do, which should be mandatory? Just one more reason to get rid of the AssociatedValue object and attribute, which is forcing us to pick a particular outputBin implementation and make it mandatory. If we got rid of the AssociatedValue object/attribute, we could forget about making any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute mandatory. If we get rid of the AssociatedValue object/attribute, then we don't need to add the outputBinNumber attribute either, since an implementation can just put in the ASCII digits for the bin number into the outputBinName attribute. Harry Lewis - IBM Printing Systems From jkm at underscore.com Wed May 7 14:46:15 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? In-Reply-To: Why have a Job State Table ?> Message-ID: <199705071846.OAA01487@uscore.underscore.com> Harry, As you know all too well, I'm in general agreement with the overall nature of your message. It was hard for me to tell, based on your text, whether you were proposing that some of the defined attributes should be removed. Is this the case? Or were you suggesting those attributes should be placed in a new "home" (ie, somewhere else in the MIB)? > D sheetsCompleted 54 > D sheetsCompletedCurrentCopy 54 > D mediumConsumedName 55 > D colorantConsumedIndex 55 > D colorantConsumedName 55 > D jobProcessingCPUTime 57 > > Category X - "Who needs this Anyway" I believe *some* of these attributes are very useful: sheetsCompleted Perhaps the only meaningful value to the end-user in terms of estimating when the job will finish, given that client software sending the job to the printer often has no idea of the total sheets to be printed. (This value reflects the *total* sheets printed for job thus far, right?) mediumConsumedName For accounting purposes, this may be the most processable element to account for media costs/planning. Consider the infamous PWG example of "Hillary's pink letterhead"; even though the media size may be Letter, the cost of this media may very well be higher than plain old 20-pound Letter copier paper. jobProcessingCPUTime One of my personal favorites. A 20-sheet job from a software engineering department is usually quite a bit different from a 20-page job from a Graphic Arts department. When it comes to capacity planning purposes, this value can be extremely useful in determining resource requirements based on application usage. When I step back and look what I've just written, it occurs to me that one of the biggest problems I have with the Job MIB draft is that it provides a plethora of descriptive text telling the reader WHAT the object is...yet very seldom tells the reader WHY it's important, or HOW it can be used to solve common critical problems. (Or is such knowledge considered to be a "proprietary advantage" by some?) > D jobCopiesCompleted 49 > D impressionsCompletedCurrentCopy 53 > > The StateValue for printing that I had defined was CurrentCopy. Somehow, > it got changed in your MIB to impressionsRequested... which is a STATIC > attribute. This kind of situation happens all too frequently, IMHO. It has also caused significant delay in progressing this effort, while others in the group "discover" such changes in the text. Let us NOT DO THIS anymore. By the way, I'm still hoping to see a simple summary of minimum conformance published, whereby all mandatory items can be identified so as to give us an idea of the level of effort to develop a minimum conforming implementation. ...jay From harryl at us.ibm.com Wed May 7 16:46:51 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> PMP> Mandatory objects, Printer MIB relationship and more Message-ID: <5030100002282734000002L042*@MHS> I appreciate the recent comments from Jay. I know how difficult it is these days for the same basic set of folks to follow all the PWG activities! I will be no surprise to any of you that I herald and support Jay's plea for a "simple" Job MIB . I do think we have made much progress in the recent weeks and now we're focusing mainly on the dispute over Job State Table and number of attributes... so we're getting somewhere... but I'd certainly like to close faster than we are. One comment Jay made was: >Another key question we've danced around over the years is how closely >is the Printer MIB related to the Job MIB? >Didn't we come to the consensus where an agent supporting the Job MIB >did not necessarily have support for the Printer MIB? That is, there >should no binding between the Job MIB and the Printer MIB. Do I have >that right? I would like to say that the only reason we even broached this topic is due to the "Job MIB in the SERVER" model. Why would a printer ever go so far as to implement an SNMP agent to do a Job MIB but not implement the printer MIB as well? So I really don't support the notion of totally uncoupling the MIBs when, for printer implementations, it makes greater sense to allow this association. Am I wrong about why we wanted to uncouple? Harry Lewis - IBM Printing Systems From jkm at underscore.com Wed May 7 16:54:15 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> PMP> Mandatory objects, Printer MIB relationship and more In-Reply-To: PMP> Mandatory objects, Printer MIB relationship and more> Message-ID: <199705072054.QAA02552@uscore.underscore.com> Harry, > >Another key question we've danced around over the years is how closely > >is the Printer MIB related to the Job MIB? > > >Didn't we come to the consensus where an agent supporting the Job MIB > >did not necessarily have support for the Printer MIB? That is, there > >should no binding between the Job MIB and the Printer MIB. Do I have > >that right? > > I would like to say that the only reason we even broached this topic is > due to the "Job MIB in the SERVER" model. Why would a printer ever go so > far as to implement an SNMP agent to do a Job MIB but not implement the > printer MIB as well? So I really don't support the notion of totally > uncoupling the MIBs when, for printer implementations, it makes > greater sense to allow this association. Am I wrong about why we wanted > to uncouple? You ask: "Why would a printer ever go so far as to implement an SNMP agent to do a Job MIB but not implement the printer MIB as well?" This sounds totally cogent to me. However, we would like to pursue Job MIB support in non-printers (such as spooling servers) to allow LPD and System V printing systems to be "visible" via SNMP and the Job MIB. And, as you might imagine, we certainly don't want to be in the position of also implementing the Printer MIB in those cases. Let me ask a more pointed question, one that I would like to see Tom answer: "Does the Job Monitoring MIB require an agent to simultaneously support the Printer MIB, and if so, what exactly is the binding?" A quick table or list (in text, please) would suffice. If there is no binding, then great. If there is, then the PMP group had better be totally cognizant of that fact, and critical clarifications should exist in the MIB draft to explain those bindings. Hopefully the only bindings are those dealing with Textual Conventions. ...jay From harryl at us.ibm.com Wed May 7 19:22:48 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> PMP> Mandatory objects, Printer MIB relationship an In-Reply-To: PMP> Mandatory objects, Printer MIB relationship an> Message-ID: <5030100002288415000002L052*@MHS> Jay asked... >"Does the Job Monitoring MIB require an agent to simultaneously > support the Printer MIB, and if so, what exactly is the binding?" The answer should be NO. Tom has been pretty thorough in covering this (Tom, can you provide the list Jay has requested?) The way he's handled it is to add "redundant" attributes to cover both bases. So, if an attribute is something like prtOutputBinIndex that works for a printer, Tom will add a "sister attribute" (my term) like OutputBinName... to be used by the server. It is undefined how the Server determines this information. I commend Tom on his efforts to preserve both scenarios. But, this does add to the number of attributes. This is one reason I tried to come up with a state table which indexes readily into a "most useful" set. Tom would argue you should just use the Attribute table. I think we should really make it a point to RESOLVE this issue in San Diego so we can move on! From hastings at cp10.es.xerox.com Thu May 8 19:07:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <9705082309.AA06206@zazen.cp10.es.xerox.com> Agreed. At 15:35 04/30/97 PDT, Harry Lewis wrote: >Classification: > >Whether we have a state table or not, the reasoning behind jmJobStateValue is >to reduce polling. Without jmJobStateValue, which is a DEFINITION of which >attribute is most "important" to a MONITORING application given a particular >state, there are two alternatives, neither of which is as effective, and >results in more network traffic. Agreed. And the state is even required by an ACCOUNTING application, so the jmJobStateValue is replicated in the Attribute Table as jobState(3) attribute, so that an accounting application can skip over jobs that are not yet completed. > > 1. Poll twice, once to determine the state and then to get the more meaningful >value > > 2. Poll for all the (potentially meaningful) objects. I wonder if it would help the discussion to specify exactly what an application specifies in a Get or GetNext for 1 and 2 with both the Job State Table and the Attribute table versus with only the Attribute Table. I suspect that even a minimal monitoring application has to get to the Attribute table at least once for each STATIC attribute, such as jobOwner(15), and maybe documentName(27). > >Harry Lewis - IBM Printing Systems > > From jkm at underscore.com Thu May 8 19:29:47 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <199705082329.TAA06926@uscore.underscore.com> Tom, > And the state is even required by an ACCOUNTING application, > so the jmJobStateValue is replicated in the Attribute Table as > jobState(3) attribute, so that an accounting application can skip over > jobs that are not yet completed. Whoa, here. Replication of MIB values is an explicit non-goal of traditional MIB design, right? At least this is what Steve Waldbusser has repeatedly stated (and for good reason). If you're replicating values to somehow make it easier for a mgmt app, then I'd suggest the MIB is too complicated. ...jay From hastings at cp10.es.xerox.com Thu May 8 20:19:15 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <9705090021.AA06247@zazen.cp10.es.xerox.com> At 16:29 05/08/97 PDT, JK Martin wrote: >Tom, > >> And the state is even required by an ACCOUNTING application, >> so the jmJobStateValue is replicated in the Attribute Table as >> jobState(3) attribute, so that an accounting application can skip over >> jobs that are not yet completed. > >Whoa, here. Replication of MIB values is an explicit non-goal of >traditional MIB design, right? At least this is what Steve Waldbusser >has repeatedly stated (and for good reason). > >If you're replicating values to somehow make it easier for a mgmt app, >then I'd suggest the MIB is too complicated. I agree completely that the same information should not have two ways to be accessed. That is why I have been suggesting getting rid of the Job State table altogether. > > ...jay > > From harryl at us.ibm.com Thu May 8 20:42:57 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Persistence and Table management Message-ID: <5030100002323117000002L072*@MHS> We have persistence defined for JobID, JobState and JobAccounting tables. Suppose the printer has been idle for longer than the largest persistence value... what do we expect the tables to look like? Will they be empty? Or should some minimum number of jobs always be in the tables? Or is it up to the implementation? I suggest that there is really no problem with "empty" tables - and indeed, we can't prevent them on initialization. I just want to bring this out for anyone who may be considering applications target at the Job MIB. Harry Lewis - IBM Printing Systems From jkm at underscore.com Thu May 8 20:40:38 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <199705090040.UAA07111@uscore.underscore.com> Tom, > >Whoa, here. Replication of MIB values is an explicit non-goal of > >traditional MIB design, right? At least this is what Steve Waldbusser > >has repeatedly stated (and for good reason). > > > >If you're replicating values to somehow make it easier for a mgmt app, > >then I'd suggest the MIB is too complicated. > > I agree completely that the same information should not have two ways to > be accessed. That is why I have been suggesting getting rid of > the Job State table altogether. This is what Harry explicitly does NOT want to do, right? (I'm asking just to make sure I've got these threads straight.) Tom, does removing the Job State Table result in the following: * Does not decrease the functionality needed to monitor job state, the number ONE reason for having the Job MIB in the first place * Makes the Job MIB less COMPLEX, and therefore easier to use by management apps and agents alike Pending Harry's comments, I could get behind your position if your proposed changes are in line with the above statements. We all know that Harry and the others at IBM are busy working on a full working version of the Job MIB for their products. How about you folks at Xerox? We know that Xerox has a job MIB (or two) of their own, but what can you tell us about Xerox's experience in prototyping this version of the standard Job Monitoring MIB? If you're not prototyping the Job MIB, I would imagine it is difficult to understand some of the problems raised by Harry and his group. ...jay From harryl at us.ibm.com Thu May 8 21:23:43 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <5030100002323790000002L002*@MHS> You don't have to replicate jmJobState in the Attribute table since the State table is defined to have greater persistence. >> >Whoa, here. Replication of MIB values is an explicit non-goal of >> >traditional MIB design, right? At least this is what Steve Waldbusser >> >has repeatedly stated (and for good reason). >> > >> >If you're replicating values to somehow make it easier for a mgmt app, >> >then I'd suggest the MIB is too complicated. >> >> I agree completely that the same information should not have two ways to >> be accessed. That is why I have been suggesting getting rid of >> the Job State table altogether. Further, Jay asked- >This is what Harry explicitly does NOT want to do, right? (I'm asking >just to make sure I've got these threads straight.) Right, Jay. I do NOT want to get rid of the State Table. (I apologize, the thread can get confusing). >Tom, does removing the Job State Table result in the following: > * Does not decrease the functionality needed to monitor job state, > the number ONE reason for having the Job MIB in the first place > * Makes the Job MIB less COMPLEX, and therefore easier to use by > management apps and agents alike It can be argued that moving ALL attributes (including State) to the Attribute Table and removing the State Table will not reduce function. What it will do is make it more difficult to monitor job progress (my opinion). Why? Because the State Table is designed for easy index (via jmJobIndex) into a row which contains the State and pertinent associated information. This pertinent information changes per state. If state is pending, you don't need to know which copy you are currently printing. If state is printing, you don't need to know the number of intervening jobs. If everything is lumped into the attribute table, you either have to determine STATE and then go back for the pertinent information OR you need to grab a set of POSSIBLE pertinent objects whenever you go for STATE and hope they all fit in your varbind. Actually, there is a pretty good possibility that they will, I believe. But, this is one of the problems the State table trys to address. The only other reason I say an Attribute only solution would be functionally equivalent but more difficult is due to the more complex indexing of the attribute table. Attributes are indexed by JobSet, JobIndex, AttributeType, and AttributeIndex (I may not have used the correct words here... another dispute). The Job State Table is indexed by JobSet and JobIndex. If you are using the "grab the state and 9 potentially meaningful values" method described above, we think the response will be quite a bit slower due to the agent handling all this indexing. Slower response and complex indexing may be OK for the accounting application (where we've always seen the greatest use for the attribute table), but the job progress monitor may want quicker. Really, it may not even be a matter of who can tolerate slow response as much as a matter of how many clients or servers could be polling for job progress vs. the (fewer) number of accounting apps putting the agent through it's paces on the attribute table. >what can you tell us about Xerox's experience in prototyping this version >of the standard Job Monitoring MIB? Yes, I would like to hear anyone's response to the above in terms of their prototype experience. I have been trying to share our findings rather openly. Harry Lewis - IBM Printing Systems. From hastings at cp10.es.xerox.com Thu May 8 18:57:31 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Mandatory objects, Printer MIB relationship and more In-Reply-To: Message-ID: <9705082259.AA06197@zazen.cp10.es.xerox.com> At 07:12 05/07/97 PDT, Jay Martin wrote: >Tom, > >> But changing the jobStateAssociatedValue to use outputBinIndex >> brings up another issue, which I'm calling issue 73: >> >> Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue >> object and attribute require it, but an implementation doesn't have the >> Printer MIB, the agent has to put 0 as the value. Should we add one more >> attribute: outputBinNumber, which is just a number, not an index into the >> Printer MIB? If we do, which should be mandatory? Just one more reason to >> get rid of the AssociatedValue object and attribute, which is forcing us to >> pick a particular outputBin implementation and make it mandatory. If we got >> rid of the AssociatedValue object/attribute, we could forget about making >> any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute >> mandatory. >> >> If we get rid of the AssociatedValue object/attribute, then we don't >> need to add the outputBinNumber attribute either, since an implementation >> can just put in the ASCII digits for the bin number into the outputBinName >> attribute. > >I'm sorry, but this is getting to be just plain scarry. > >When I read "If outputBinIndex is made mandatory...", it makes me realize >that I don't have a good handle for exactly what the minimum conforming >implementation is at this point. > >Can you post a simple text-only table of all the mandatory elements of >the Job MIB? (Something like one line per mandatory element would be >great.) Here is lines 1007-1016 from the Internet-Draft 00 (V0.81: The mandatory attributes are: jobState(3) numberOfInterveningJobs(9) deviceAlertCode(10) jobKOctetsRequested(48) jobKOctetsCompleted(50) impressionsRequested(54) impressionsCompleted(55) outputBinName(35) [but as Harry pointed out, has to be an integer to fit with the AssociatedValue object] However, I have added Issue 76: So should jobName, jobOwner, and one of deviceNameRequested or queueNameRequested be made Mandatory? because they were mandatory when we had a Job Table, but when we deleted the job table and moved them into the Attribute table, we didn't make them Mandatory. > >Tom, we are really getting down to the wire on the Job MIB (right????). >When you write words like: > > "Just one more reason to get rid of the AssociatedValue object > and attribute..." > >it makes me think the basic Job MIB functional model is not completely >thought out. It this stage of the game, we need to have the functional >model complete, wouldn't you agree? I'm not sure what you mean by "functional model". Lines 286-319, "1.2 Types of Job Monitoring Applications" has the three models for applications: monitor one active job, monitor all active jobs on a printer or server, and gather accounting or usage information on completed jobs on a printer or server. Lines 406-556, "3. Configurations for the Job Monitoring MIB", has the three system configurations that the MIB is designed to support. The current draft has two ways to access the 8 mandatory items: a. The Job State Table represents 3 as mandatory objects and the other 5 with the "multi-plexed" AssociatedValue object which has a representation that depends on the state of the job, i.e., which is a "fan out" to 5 different attributes depending on which of the 7 job states the job is in. b. The same 8 mandatory items ALSO exist as mandatory attributes in the Attribute Table. So an application can access the same information either by using the Job State table or the Attribute table. > > >Another key question we've danced around over the years is how closely >is the Printer MIB related to the Job MIB? > >Didn't we come to the consensus where an agent supporting the Job MIB >did not necessarily have support for the Printer MIB? That is, there >should no binding between the Job MIB and the Printer MIB. Do I have >that right? Almost. We agreed that a conforming agent did not need to implement the Printer MIB. Therefore, we shouldn't have any Mandatory attributes that require the Printer MIB. On the other hand, for Conditionally Mandatory attributes there is no problem with them being tightly coupled with the Printer MIB, say, by being indexes into the Printer MIB. Then an implementation that does include the Printer MIB can get tight coupling. In other words, we are trying for a win-win here. Implementations that also have the Printer MIB will be able to take advantage of that. Implementations that don't have the Printer MIB will not be unduly short changed in what they can express. > >I certainly understand the desire to keep the two MIBs conceptually the >same, at least in terms of modeling characteristics, terminology, etc. >It's the explicit binding between the two that I'm asking about here. I hope my answer helps. > > >> On the other hand, I think we considered this and decided that it was >> cleaner and simpler to have two separate enums, one for the Integer >> value and the other for the Octets value. >> >> [...] >> >> ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? >> >> Analysis of the 78 attributes shows that there are 8 attribute >> pairs that could be collapsed into one attribute with the implementation >> using either the Integer or the Octets value (or both) to represent >> the attribute. The application would have to query both value objects. >> But if it is using GetNext, it has to get both each time anyway. >> Only if it is directly accessing an attribute would it have to get >> both values. On the other hand, it would be fewer Gets than having >> two attributes as we have now. >> >> [...] >> >> Should we allow an implementation to fill in both with meaningful values? > >Can someone state the fundamental rationale for taking the approach of >having two enums, one for Integer and one for Octets? This is very >confusing to me. A few words of explanation might help here. First, not every attribute comes in two flavors: integer and octets. Only 8 out of 78 do. Most attributes are by their nature, either an integer or an octet string. File names and DateAndTime data types are reprsented as octet strings. Counts, counters, and enums are represented as integers. > > >Why, oh why is the Job MIB so COMPLEX ??? > >To solve the #1 problem of "Is my job done yet?", we have devolved into >one of the most complex MIB definitions yet. Gee, I think it is one of the simplest MIBs!. It has only 4 groups, all mandatory, with a total of 13 object. No read-write, no trapping. True, in addition there are 8 mandatory attributes, and 70 conditionally mandatory attributes, but implementations can do just the 8 mandatory attribute or can do as many more as they want. We could even simplify further, if we get rid of the Job State table and the AssociatedValue multi-plexed attribute)! It would be only three groups, all mandatory, for a total of 10 objects. > >Doesn't this concern anyone else? (Hopefully some of the other vendors >doing a prototype can respond here.) Are you concerned about the implementation of agents or applications, I'm not sure which. If you could give some specific concern about complexity, that would help us understand your concerns. > > ...jay > > From hastings at cp10.es.xerox.com Thu May 8 20:16:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Why have a Job State Table ? [ISSUE: 'printing' state In-Reply-To: Why have a Job State Table ? [ISSUE: 'printing' state> Message-ID: <9705090018.AA06243@zazen.cp10.es.xerox.com> At 11:46 05/07/97 PDT, JK Martin wrote: >Harry, > >As you know all too well, I'm in general agreement with the overall >nature of your message. snip... >> D jobCopiesCompleted 49 >> D impressionsCompletedCurrentCopy 53 >> >> The StateValue for printing that I had defined was CurrentCopy. Somehow, >> it got changed in your MIB to impressionsRequested... which is a STATIC >> attribute. > >This kind of situation happens all too frequently, IMHO. It has also >caused significant delay in progressing this effort, while others in >the group "discover" such changes in the text. Let us NOT DO THIS anymore. Harry, I checked both your slides (jmfoil.ppt) and the great jmpexp.pdf tutorial explanation that you did. The slides says "Total number of impressions" and the jmpexp.pdf says "Total Impressions" for the state value for the "printing" state. Where did I mess up in editing "total [number of] impressions" into "impressionsRequested" in the MIB spec? I thought that "total number" was somewhat ambiguous in that it could mean either (1) the STATIC value that is the number to be printed or the current number already printed. But since the Job State table already has the jmJobStateImpressionsCompleted object, I thought that the only interpretation of "total number" must be impressions requested, not impressions completed. And no where did I see "current copy" in either your foils or jmpexp.pdf. We certainly can change the state value to impressionsCompletedCurrentCopy from the STATIC value: impressionsRequested. Should we? But that means that the monitoring application can't find out the number of impression requested without going to the 'dreaded' Attribute table. But since impresssionRequested is a STATIC attribute a MONITORING program only has to go to the Attribute table once to get the value for the thermometer for a particular job. I had thought that the reason that you put the STATIC "total impressions" state value into the Job State table was so that the monitoring program didn't have to go the Attribute table at all. If we change the state value for the 'printing' state from a STATIC attribute to a dynamic attribute, it seems somewhat strange that the state value for the 'processing' state would remain a STATIC value: octetsRequested. Since the foils and jmpexp.pdf had "total [number of] octets", did you mean "octetsRequested" or "octetsCompleted" for the 'processing' state value? Thanks, Tom From hastings at cp10.es.xerox.com Thu May 8 19:33:38 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Output Bin Problems [Resolution to Issue 73 and 74] In-Reply-To: Output Bin Problems [Resolution to Issue 73 and 74]> Message-ID: <9705082335.AA06224@zazen.cp10.es.xerox.com> At 11:13 05/07/97 PDT, Harry Lewis wrote: >Tom, ... why can't an implementation that does not have the job mib just say >"unknown" for the output bin. Good simplifing suggestion. I agree. I think using unknown is good enough for an agent that isn't implementing the printer MIB. Such an agent is unlikely to be instrumenting a printer, if it isn't implementing the Printer MIB (configuration 2). So for configuration 2, the agent is unlikely to know which output bin(s) the job wound up in and would plug-in unknown(-2). So we don't need to add outputBinNumber as a new attribute (Issue 73). Also I suggest that we don't collapse outputBinIndex(34) and outputBinName(35) into a single attribute that is either integer or octet string (or both) which resolved Issue 74). Finally, I agree that for the rare case of a job going into multiple output bins, the monitoring program can just say multi(-1), which is a specific form of "other(1)". >Wouldn't this, indeed, be the case? > >Harry Lewis - IBM Printing Systems > > >------- Forwarded by Harry Lewis/Boulder/IBM on 05/07/97 12:07 PM -------- > > jmp-owner@pwg.org > 05/07/97 04:33 AM >Please respond to jmp-owner@pwg.org @ internet > > >To: Harry Lewis/Boulder/IBM@IBMUS >cc: JMP@pwg.org @ internet >Subject: Re: JMP> Output Bin Problems > >At 17:07 05/01/97 PDT, Harry Lewis wrote: >>Classification: >> >>Tom, a couple comments related to Output Bin and the Job MIB using draft v.81. >> >> 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for >>state COMPLETED cannot be outputBinName, as you have specified. I had specified >>outputBinIndex, not Name. > >I agree I created a problem. We can't fit an OctetString into 32-bits. > >But changing the jobStateAssociatedValue to use outputBinIndex >brings up another issue, which I'm calling issue 73: > >Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue >object and attribute require it, but an implementation doesn't have the >Printer MIB, the agent has to put 0 as the value. Should we add one more >attribute: outputBinNumber, which is just a number, not an index into the >Printer MIB? If we do, which should be mandatory? Just one more reason to >get rid of the AssociatedValue object and attribute, which is forcing us to >pick a particular outputBin implementation and make it mandatory. If we got >rid of the AssociatedValue object/attribute, we could forget about making >any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute >mandatory. > >If we get rid of the AssociatedValue object/attribute, then we don't >need to add the outputBinNumber attribute either, since an implementation >can just put in the ASCII digits for the bin number into the outputBinName >attribute. > > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Fri May 9 04:47:03 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Mandatory objects, Printer MIB relationship and more In-Reply-To: Mandatory objects, Printer MIB relationship and more> Message-ID: <9705090849.AA06395@zazen.cp10.es.xerox.com> At 13:54 05/07/97 PDT, JK Martin wrote: >Harry, snip... >Let me ask a more pointed question, one that I would like to see Tom >answer: > > "Does the Job Monitoring MIB require an agent to simultaneously > support the Printer MIB, and if so, what exactly is the binding?" > I agree with Harry's response, that we are not requiring that an agent implement the Printer MIB since it would be hard in a server (configuration 2). But at the same time we want a Printer that does implement the Printer MIB to be able to take advantage of the data in the Printer MIB when implementing the Job Monitoring MIB in a Printer. Hence the introduction of the pairs of attributes ("sisters") where one is used when implementing the Printer MIB because it is tightly coupled with the Printer MIB, i.e., an index into the Printer MIB and the other attribute is used when not implementing the Printer MIB. >A quick table or list (in text, please) would suffice. If there is >no binding, then great. If there is, then the PMP group had better >be totally cognizant of that fact, and critical clarifications should >exist in the MIB draft to explain those bindings. I've posted a table of attribute properties in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 31744 May 9 08:25 attr-tab.doc -rw-r--r-- 1 pwg pwg 45940 May 9 08:26 attr-tab.pdf One of the columns specifies linkage to the Printer MIB. The other columns specify properties of attributes that will help understand the usage of the attributes by monitoring applications and accounting/utilization applications. The table may help us with the debate over the Job State Table as well. Here is the legend to the table: # = enum value for jmAttributeTypeIndex, e.g., JmAttributeTypeIndexTC I/O: Integer vs. OCTET STRING I = Integer32(-2..2147483647) O = OCTET STRING(SIZE(0..63)) I/O = Integer OR OCTET STRING I+O = Integer AND OCTET STRING TC: Integer is a textual-convention in this or the Printer MIB M: Mandatory >1: MULTI-ROW (more than one row allowed) M/A: Application program usage M = Monitoring application will use A = Accounting (or system utilization) application will use MA = both a Monitoring and an Accounting application will use. S/D: STATIC vs. DYNAMIC S = STATIC (doesn't usually change, ModifyJob operation may change) D = DYNAMIC (expected to change during the life time of the job) S/P/D/A: When is the STATIC or DYNAMIC value first assigned: S = submission time P = start of processing D = during processing and/or printing C = completion a = any time. states = job state(s) in which the value is of interest: H = held Pen = Pending Pro = Processing Pri = Printing N = needsAttention Can = canceled Com = completed a = all states. L = linked with the Printer MIB, such that the Printer MIB must be implemented for this attribute to provide a meaningful value to the application. Printer MIB textual-conventions are not flagged as linked. > >Hopefully the only bindings are those dealing with Textual Conventions. There are some Job Monitoring MIB attributes whose values are textual conventions defined in the Printer MIB, such as PrtInterpreterLangFamilyTC. However, use of such a textual convention in an attribute does not require that the agent implement the Printer MIB. > > ...jay > > From hastings at cp10.es.xerox.com Fri May 9 05:38:13 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Reposting of JMP Attribute Properties (attr-tab.doc .pdf) Message-ID: <9705090940.AA06414@zazen.cp10.es.xerox.com> I added a column to indicate the attributes that are accessible through the Job State table (the S column). This may help everyone understand the Job State Table better and its relationship to the Attributes table. I've reposted as: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc -rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf Here is the updated column headings in the table and the table entries: Col Heading Description # enum value for jmAttributeTypeIndex, e.g., JmAttributeTypeIndexTC I/O Integer vs. OCTET STRING: I = Integer32(-2..2147483647) O = OCTET STRING(SIZE(0..63)) I/O = Integer OR OCTET STRING I+O = Integer AND OCTET STRING TC Integer is a textual-convention in this or the Printer MIB M Conformance requirements for an agent: M = Mandatory = Conditionally Mandatory >1 MULTI-ROW (more than one row allowed): >1 = MULTI-ROW = one one row allowed for this attribute S Accessible through Job State Table (and the Attributes Table) = only in the Attributes table L linked with the Printer MIB, such that the Printer MIB must be implemented for this attribute to provide a meaningful value to the application. Printer MIB textual-conventions are not flagged as linked. M/A Application program usage: M = Monitoring application will use A = Accounting (or system utilization) application will use MA = both a Monitoring and an Accounting application will use. S/D STATIC vs. DYNAMIC: S = STATIC (doesn't usually change, ModifyJob operation may change) D = DYNAMIC (expected to change during the life time of the job) S/P/D/A When is the STATIC or DYNAMIC attribute value first assigned: S = submission time P = start of processing D = during processing and/or printing C = completion a = any time. states = job state(s) in which the attribute value is of interest: H = held Pen = Pending Pro = Processing Pri = Printing N = needsAttention Can = canceled Com = completed a = all states. From harryl at us.ibm.com Fri May 9 12:04:50 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: PMP> Re: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <5030100002337350000002L002*@MHS> Jay Martin wrote (to the JMP group) >One question that we all must come to grips with: > If a vendor wants to create a product used to monitor jobs, > will the choice of access be SNMP and the Job MIB, or IPP? >We are, after all, in the process of trying to solve the very same problem >in two completely different ways...at least when it comes to job status. >This doesn't feel good. Thank you, Jay! I've tried to point this out several times in the past. The PWG is not working together in this vein. IPP has taken an all encompassing approach, basically ignoring the fact that printer configuration and status can be handled via the printer MIB - a standard which is already implemented in at least 6 vendors printers and has the support of several printer management software products. IPP as a standard job submission protocol is a great idea. I guess there is nothing wrong with also making it an all encompassing status and configuration protocol... but, at least, we should be doing some sort of mapping back to the Printer and Job MIBs. Harry Lewis - IBM Printing Systems From SISAACSON at novell.com Fri May 9 12:50:07 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:04 2009 Subject: IPP> PMP> Re: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: >>> Harry Lewis 05/09 10:04 AM >>> > Thank you, Jay! I've tried to point this out several times in the past. > The PWG is not working together in this vein. IPP has taken an all > encompassing approach, basically ignoring the fact that printer > configuration and status can be handled via the printer MIB - a standard > which is already implemented in at least 6 vendors printers and has the > support of several printer management software products. > > IPP as a standard job submission protocol is a great idea. I guess there > is nothing wrong with also making it an all encompassing status and > configuration protocol... but, at least, we should be doing some sort > of mapping back to the Printer and Job MIBs. Harry, I have thought some about this - "Why not let IPP just be job submission and do a better job of integrate the end user's client software with the Job MIB and Printer MIB for job and printer status.?" I keep coming back to one main thought: I do not envision a SNMP stack on every end user client. It seems to heavy weight for me. I see SNMP enable apps on every manager/operator client, but that is typically a different configuration. I say let the MIBs stay on the course they are on, which is a good one in my view, because they are oriented towards "print device management". There is a big difference between "printing system management" and "print device management." There is some overlap between the two, but let IPP (non-SNMP based at all) be a full solution for the end user even when the end user starts to take on the role of a "jr. manager" their own jobs and devices in order to make job submission decisions. These are all printing system kinds of things, not just device kinds of things. Since there is overlap, there must be (SHALL be to use better conformance language) consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP. In the IPP requirements we say only a subset of the end user requirements are satisfied in V1.0. I expect much better integration (and less overlap) with the MIBs when we talk about solving the manager requirements. For administrative requirements, I don't see the MIBs being involved very much. Scott From bwagner at digprod.com Fri May 9 13:19:50 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:04 2009 Subject: IPP> PMP> Re: JMP> JobStateValue In-Reply-To: PMP> Re: JMP> JobStateValue> Message-ID: Scott, When we agonize about IPP disregarding the MIB's, it is not SNMP that is the question but rather the parameters used in IPP versus those in the MIB's. There is nothing to say that the MIB objects need only be accessible via SNMP. It is indeed things such as "consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP" that is the point of concern." Your opinion that "For administrative requirements, I don't see the MIBs being involved very much." is very interesting in that I believe that administration is exactly the purpose of the MIB's. To suggest that IPP should be a more universal solution handling device management as well as job submission may not be to the advantage of IPP either, since it burdens IPP with an additional, non-trivial functionality. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> PMP> Re: JMP> JobStateValue Author: Scott Isaacson at Internet Date: 5/9/97 10:50 AM >>> Harry Lewis 05/09 10:04 AM >>> > Thank you, Jay! I've tried to point this out several times in the past. > The PWG is not working together in this vein. IPP has taken an all > encompassing approach, basically ignoring the fact that printer > configuration and status can be handled via the printer MIB - a standard > which is already implemented in at least 6 vendors printers and has the > support of several printer management software products. > > IPP as a standard job submission protocol is a great idea. I guess there > is nothing wrong with also making it an all encompassing status and > configuration protocol... but, at least, we should be doing some sort > of mapping back to the Printer and Job MIBs. Harry, I have thought some about this - "Why not let IPP just be job submission and do a better job of integrate the end user's client software with the Job MIB and Printer MIB for job and printer status.?" I keep coming back to one main thought: I do not envision a SNMP stack on every end user client. It seems to heavy weight for me. I see SNMP enable apps on every manager/operator client, but that is typically a different configuration. I say let the MIBs stay on the course they are on, which is a good one in my view, because they are oriented towards "print device management". There is a big difference between "printing system management" and "print device management." There is some overlap between the two, but let IPP (non-SNMP based at all) be a full solution for the end user even when the end user starts to take on the role of a "jr. manager" their own jobs and devices in order to make job submission decisions. These are all printing system kinds of things, not just device kinds of things. Since there is overlap, there must be (SHALL be to use better conformance language) consistency between job attributes in the Job Monitoring MIB and IPP and printer attributes in the Printer MIB and IPP. In the IPP requirements we say only a subset of the end user requirements are satisfied in V1.0. I expect much better integration (and less overlap) with the MIBs when we talk about solving the manager requirements. For administrative requirements, I don't see the MIBs being involved very much. Scott From masinter at parc.xerox.com Fri May 9 13:21:58 1997 From: masinter at parc.xerox.com (Larry Masinter) Date: Wed May 6 14:00:04 2009 Subject: IPP> PMP> Re: JMP> JobStateValue In-Reply-To: PMP> Re: JMP> JobStateValue> Message-ID: There was a proposal floating around to do SNMP -> HTTP proxy standard, so that there could be a standard way that a HTTP client could play SNMP. If so, then maybe IPP's HTTP-based submit could return the URL of the SNMP->HTTP based job monitoring? Where are the descriptions of the job management MIB and the printer MIB? Larry -- http://www.parc.xerox.com/masinter From SISAACSON at novell.com Fri May 9 13:51:14 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:04 2009 Subject: IPP> PMP> Re: JMP> JobStateValue In-Reply-To: PMP> Re: JMP> JobStateValue> Message-ID: >>> Bill Wagner 05/09 11:19 AM >>> I agree that there can be many ways at getting at a piece of information - SNMP GET, IPP query, PDL specific query, etc. If they are all trying to get the "same" peice of info, then the printer just has to implement it once and support multiple views. If we state that IPP requires one piece of info and the Printer MIB requires something different, and they are closely related semantically but just different enough that it requires the Printer to implement two things, this would not good - think that we are all ok on that. > > Your opinion that "For administrative requirements, I don't see the > MIBs being involved very much." is very interesting in that I believe > that administration is exactly the purpose of the MIB's. I was trying to make a distinction bewteen what an "administrator" does (in the IPP requirements) document and what a "manager" does. I often use these terms almost interchangeable, but sometimes I try to make a clear distinction. If an adminstrator does things like: - create a new "printer" (name it, advertise it, register it, etc) - set access control rights - define the authentication and other security mechanisms - configure it to service one or more channels - etc. how would SNMP and MIBs help with that? > To suggest that IPP should be a more universal solution handling > device management as well as job submission may not be to the > advantage of IPP either, since it burdens IPP with an additional, > non-trivial functionality. I really did not mean to imply that IPP should be used for device management. Thanks for clarifying. The end user only needs to know about Printer status in order to make job submission decisions. I DO NOT see IPP as encompassing the MIB scope. Sorry if I caused confusion. Scott From harryl at us.ibm.com Fri May 9 13:53:34 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: IPP> PMP> Re: JMP> JobStateValue In-Reply-To: JobStateValue> Message-ID: <5030100002342328000002L082*@MHS> Scott, >I have thought some about this - "Why not let IPP just be job submission and >do a better job of integrate the end user's client software with the Job MIB >and Printer MIB for job and printer status.?" I keep coming back to one >main thought: >I do not envision a SNMP stack on every end user client. It seems to heavy >weight for me. I see SNMP enable apps on every manager/operator client, but >that is typically a different configuration. You make a good point, but I wonder just how (relatively) heavy it is? HP can correct me if I'm wrong, but I think every Mopier and/or 5si driver that installs out there today brings in an SNMP stack (at least I saw some SNMP related file names flash by as I was loading the Mopier Driver onto my w95 client). IBM's drivers do the same. Lexmark's drivers might not load SNMP on the client but they have to load NPAP. Is IPP really going to lighten the load? >I say let the MIBs stay on the course they are on, which is a good one in my >view, because they are oriented towards "print device management". There >is a big difference between "printing system management" and "print device >management." There is some overlap between the two, but let IPP (non-SNMP >based at all) be a full solution for the end user even when the end user >starts to take on the role of a "jr. manager" their own jobs and devices >in order to make job submission decisions. These are all printing system >kinds of things, not just device kinds of things. You really can't say the Job MIB is oriented toward device mgt. It's Job all the way and heavily oriented to end-users. >Since there is overlap, there must be (SHALL be to use better conformance >language) consistency between job attributes in the Job Monitoring MIB and >IPP and printer attributes in the Printer MIB and IPP. No argument here! I think the PWG will have failed if there is no conformance. Scott, I do follow your main point (I think) and that is that every client will naturally have HTTP and every Administrator will most likely have SNMP. And, since there is overlap between end-user and admin (printing) functions, we can't really have two distinct architectures. It's not hard for me to imaging a future devoid of SNMP and everything happening "on the web"... but, as we get carried away with this idea... we at least have to realize that IPP can't really seem to agree on whether HTTP is really the right protocol and printers have already implemented the Printer MIB and some will most likely also embrace the Job MIB (after all... Job MIB hasn't been dropped from the PWG venue, even though IPP is now some 8 or so months old). Another way to imagine the future is one where a standard IPP (non-HTTP, perhaps) protocol exists for print submission and the SNMP Printer and Job MIBs facilitate status and configuration of the printer and job. Harry Lewis From STUART at KEI-CA.CCMAIL.CompuServe.COM Fri May 9 14:02:21 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:04 2009 Subject: JMP> Comments from a novice Message-ID: <5030100002342328000002L082*@MHS> Jay, Harry, and Tom, I just had to respond so you guys didn't think no one else is paying attention... ;-) I have been reluctant to comment due to my lack of overall understanding of the job MIB. Although I have been following the e-mail and attending recent meetings, I do not have a deep understanding of many of the issues. I decided that at the risk of showing off my ignorance, it may be useful to ask some rather basic questions which might occur to someone unfamiliar with the project as they first dive in to do an implementation. Also, I'm am concerned about the complexity of the Job MIB (I think Jay also commented about this once or twice ;-) ). It must be frustrating to Tom to have us say that it is too complex without giving concrete suggestions for simplifying it. Let me put it another way. It seems too complex because when I read it I'm as confused as heck, but I can't give any real constructive criticism if I don't understand it very well! But, I will can at least comment on a few things that I find confusing. 1) Tom says there are only 8 mandatory attributes. But the rest are conditionally mandatory, as in "shall implement each conditionally mandatory attribute, if the server or device that the agent is instrumenting has the feature represented by the conditionally mandatory attribute." Does this mean that for an agent in a printer, attributes which can always be known by a printer, such as printQualityUsed, tonerEconomyUsed, jobCopiesCompleted, jobDocumentsCompleted, pagesCompleted, sheetsCompleted, etc., must always be implemented? This seems to disguise how many items are actually mandatory. 1a) Related to this is the question, if there is no indication to the agent whether the job contains multiple documents, does the agent implement just jobCopiesCompleted? or also jobDocumentsCompleted with the same value since it assumed to be a 1 document job? 2) Roughly 15% of the job MIB document is spent describing JobStateReasons. As an agent, do I really have to differentiate between all these reasons? How do I implement just a small subset of possible JobStateReasons? 3) There are some attributes in the job MIB that an agent can obtain from the data stream, such as jobCopiesRequested. Others relate to the printer MIB or hr MIB. But with many of the attributes it is not clear how the agent gets passed the information. For items such as jobOwner, jobName, submittingServerName, etc. where does the agent get this information? Some of this stuff is now sometimes sent with the job via PJL or PostScript. Are we hoping that PJL and PostScript (and other job control languages?) will be used to send this information? Will it be ubiquitous? Accounting information will not be very useful if only 50% of the jobs contain jobOwner information for example. 4) I think the Attribute Table design using AttributeType textual conventions has reduced the number of objects in the MIB, but has made it more confusing. The number of OIDs is less, but it does make for a daunting Attribute Table! I don't have enough implementation experience to really know which is better or easier to implement. Harry is the Attribute Table as much of a beast as it appears to be? Sorry this is so long winded, I'll just make one more comment. Jay said he is starting to like the sound of a Job State MIB and a Job Attribute MIB. Maybe this isn't as far fetched as it sounds. Like Harry, I view the monitoring and accounting aspects of the MIB as addressing distinctly different needs. Perhaps we should separate the MIB to meet these different needs. We sure could make a simple Job State MIB which would likely be implemented across the board! Thanks for listening. Stuart Rowley Kyocera Electronics From jkm at underscore.com Fri May 9 15:01:38 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job MIB into two MIBs Message-ID: <199705091901.PAA09323@uscore.underscore.com> At this risk of ticking off our fine chairman (Ron Bergman), I'd like to ask everyone to participate in a quick-and-dirty straw vote. Stuart Rowley commented: > Jay said he is starting to like the sound of a Job State MIB and a Job > Attribute MIB. Maybe this isn't as far fetched as it sounds. Like > Harry, I view the monitoring and accounting aspects of the MIB as > addressing distinctly different needs. Perhaps we should separate the > MIB to meet these different needs. We sure could make a simple Job > State MIB which would likely be implemented across the board! How many others feel this way? (And how many others are opposed?) Would it be possible for all list participants to post their one-word opinion/vote on this question: Are you in favor of the JMP group exploring the potential for splitting the current Job Monitoring MIB into two separate MIBs, one that focuses on job status and the other for job accounting? Just a simple "Yes" or "No" is being requested; if you want to add something to the discussion, then great! But let's at least see whether this is a topic worth investigating *before* the San Diego meetings next week. ...jay From bwagner at digprod.com Fri May 9 15:46:42 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job In-Reply-To: Straw vote request: interest in splitting the Job> Message-ID: <199705091901.PAA09323@uscore.underscore.com> Are you in favor of the JMP group exploring the potential for splitting the current Job Monitoring MIB into two separate MIBs, one that focuses on job status and the other for job accounting? No. Bill Wagner, DPI/Osicom From hastings at cp10.es.xerox.com Fri May 9 19:45:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Persistence and Table management In-Reply-To: Persistence and Table management> Message-ID: <9705092347.AA06757@zazen.cp10.es.xerox.com> I agree that the tables should (recommendation) become empty after the persistence time period has elapsed. However, the persistence objects are only minimums, so its not required that the tables become empty. When the tables are empty jmGeneralOldestActiveIndex shall be 0, since an empty table is just a special case of no active jobs. So an application that is monitoring active jobs or is accounting jobs, needs to first check jmGeneralOldestActiveIndex for a 0 value, on each poll cycle. Tom At 17:42 05/08/97 PDT, Harry Lewis wrote: >We have persistence defined for JobID, JobState and JobAccounting tables. >Suppose the printer has been idle for longer than the largest persistence >value... what do we expect the tables to look like? Will they be empty? Or >should some minimum number of jobs always be in the tables? Or is it up to the >implementation? I suggest that there is really no problem with "empty" tables - >and indeed, we can't prevent them on initialization. I just want to bring this >out for anyone who may be considering applications target >at the Job MIB. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon May 12 11:07:46 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job In-Reply-To: Straw vote request: interest in splitting the Job> Message-ID: <9705121509.AB06985@zazen.cp10.es.xerox.com> No. Lets not separate the monitoring and the accounting MIB. If you buy the catergorization of the attributes in attr-tab, there are only 4 out of 78 attributes that are there only for accounting-only (A): jobAccountName(16), printQualityUsed(39), tonerEconomyUsed(41), and tonerDensityUsed(43). The rest are there for monitoring jobs only (M) or are there for both monitoring and accounting (MA). There are 31 attributes for monitoring only (M), and 43 for monitoring and accounting (MA). So separating into a monitoring MIB would have 74 attributes and the accounting MIB would have the additional 4 attributes, assuming that the accounting MIB augmented the monitoring MIB, so that when doing accounting, you also had to implment the monitoring MIB. Not a very convincing argument to separate the MIB into montirong and accounting! # Attribute I/O TC M >1 L S M/A S/D S/P/D/A states 16 jobAccountName O A S S a 39 printQualityUsed I TC >1 A S D Com 41 tonerEcomonyUsed I TC >1 A S D Com 43 tonerDensityUsed I >1 A S D Com At 12:01 05/09/97 PDT, JK Martin wrote: >At this risk of ticking off our fine chairman (Ron Bergman), I'd >like to ask everyone to participate in a quick-and-dirty straw vote. > >Stuart Rowley commented: > >> Jay said he is starting to like the sound of a Job State MIB and a Job >> Attribute MIB. Maybe this isn't as far fetched as it sounds. Like >> Harry, I view the monitoring and accounting aspects of the MIB as >> addressing distinctly different needs. Perhaps we should separate the >> MIB to meet these different needs. We sure could make a simple Job >> State MIB which would likely be implemented across the board! > >How many others feel this way? (And how many others are opposed?) > >Would it be possible for all list participants to post their one-word >opinion/vote on this question: > > Are you in favor of the JMP group exploring the potential for > splitting the current Job Monitoring MIB into two separate MIBs, > one that focuses on job status and the other for job accounting? > >Just a simple "Yes" or "No" is being requested; if you want to add >something to the discussion, then great! But let's at least see >whether this is a topic worth investigating *before* the San Diego >meetings next week. > > ...jay > > From jkm at underscore.com Mon May 12 11:07:25 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Mandatory objects, Printer MIB relationship and In-Reply-To: Re: Mandatory objects, Printer MIB relationship and> Message-ID: <9705121509.AA06985@zazen.cp10.es.xerox.com> [This reply from Jay to me was inadvertantly cc'd to PMP, instead of JMP. So I've re-directed it to JMP.] Tom, Thanks for taking the time to help me understand the Job MIB. I appreciate it. (I really do!) I realize some of my questions sound like I'm asking you to spoon-feed me on some of these issues and topics. Please be patient and indulge me for a moment. Imagine I'm a newbie to the Job MIB, one who is thinking about using the Job MIB to solve a problem surrounding job state monitoring. > >Can you post a simple text-only table of all the mandatory elements of > >the Job MIB? (Something like one line per mandatory element would be > >great.) > > Here is lines 1007-1016 from the Internet-Draft 00 (V0.81: > > The mandatory attributes are: > > jobState(3) > numberOfInterveningJobs(9) > deviceAlertCode(10) > jobKOctetsRequested(48) > jobKOctetsCompleted(50) > impressionsRequested(54) > impressionsCompleted(55) > outputBinName(35) [but as Harry pointed out, has to > be an integer to fit with the > AssociatedValue object] Sorry, but I probably didn't state the question correctly. When I asked for a list of mandatory "elements", I meant MIB objects, not just attributes. (You discuss such mandatory elements later in your message.) Here I am asking: What is the minimum skin I have to put in the game to get going? I look at the Job MIB and it looks, well...real complicated. I'm just trying to see where to get going in solving my problem. > However, I have added Issue 76: So should jobName, jobOwner, and one of > deviceNameRequested or queueNameRequested be made Mandatory? > because they were mandatory when we had a Job Table, but when we deleted > the job table and moved them into the Attribute table, we didn't make > them Mandatory. Sounds funny to ask "should jobName and jobOwner be mandatory?" How does my app identify the jobs currently in the table? > At this stage of the game, we need to have the functional > >model complete, wouldn't you agree? > > [...] > > I'm not sure what you mean by "functional model". Thanks for the fine pointers to the spec. I'll admit that it's been a while since I had last read them, so I'll take another look. However, here's a very explicit example of the complexities in the Job MIB; this text was in your descriptions of the pointers for me to examine for "functional model": > The current draft has two ways to access the 8 mandatory items: > > a. The Job State Table represents 3 as mandatory objects and the other 5 > with the "multi-plexed" AssociatedValue object which has a representation > that depends on the state of the job, i.e., which is a "fan out" to 5 > different attributes depending on which of the 7 job states the job is > in. Say what??? Can I have that in English, please? ;-) Really, though, this kind of "description" scares the bejeezes out of us. Pray tell, is the term "multi-plexed" a common SNMP-related term? Or was it expressly invented for use in the Job MIB? ;-) > b. The same 8 mandatory items ALSO exist as mandatory attributes in the > Attribute Table. So an application can access the same information > either by using the Job State table or the Attribute table. Hmmm, let me state that last question is bit differently, albeit in a hypothetical manner: So an application can access the same information either by using the Job State MIB or the Job Accounting MIB. I'm starting to like that statement a lot better, actually. > >Another key question we've danced around over the years is how closely > >is the Printer MIB related to the Job MIB? > > [...] > > Almost. We agreed that a conforming agent did not need to implement the > Printer MIB. Therefore, we shouldn't have any Mandatory attributes that > require the Printer MIB. On the other hand, for Conditionally Mandatory > attributes there is no problem with them being tightly coupled with the > Printer MIB, say, by being indexes into the Printer MIB. > Then an implementation that does include the Printer MIB can get tight > coupling. In other words, we are trying for a win-win here. Implementations > that also have the Printer MIB will be able to take advantage of that. > Implementations that don't have the Printer MIB will not be unduly short > changed in what they can express. Sounds like a good plan, Tom. Just to make sure I understand your above explanation: Those objects in the Job MIB having a corresponding relationship in the Printer MIB have values that are entirely independent of the Printer MIB. That is, an application using the Job MIB does not need to know anything about the Printer MIB in any way in order to take advantage of all the features provided by the Job MIB. Is this correct? > >Can someone state the fundamental rationale for taking the approach of > >having two enums, one for Integer and one for Octets? This is very > >confusing to me. A few words of explanation might help here. > > First, not every attribute comes in two flavors: integer and octets. > Only 8 out of 78 do. Most attributes are by their nature, either an > integer or an octet string. File names and DateAndTime data types are > reprsented as octet strings. Counts, counters, and enums are represented > as integers. Sorry, but I don't think you answered my question. You state that only 8 out of 78 (!) attributes have both integer and string forms. But you didn't say WHY having multiple forms was necessary in the first place. > >Why, oh why is the Job MIB so COMPLEX ??? > > > >To solve the #1 problem of "Is my job done yet?", we have devolved into > >one of the most complex MIB definitions yet. > > Gee, I think it is one of the simplest MIBs!. It has only 4 groups, all > mandatory, with a total of 13 object. No read-write, no trapping. > True, in addition there are 8 mandatory attributes, and 70 conditionally > mandatory attributes, but implementations can do just the 8 mandatory > attribute or can do as many more as they want. Your description certainly paints a decent picture of simplicity. However, why are the threads between yourself and Harry over the last couple of weeks so gawd-awfully convoluted? For something so simple, it sure looks so complex. Speaking of those "8 mandatory attributes": > jobState(3) > numberOfInterveningJobs(9) > deviceAlertCode(10) > jobKOctetsRequested(48) > jobKOctetsCompleted(50) > impressionsRequested(54) > impressionsCompleted(55) > outputBinName(35) Why is outputBinName mandatory, yet the same is not true for the input tray name? > We could even simplify further, if we get rid of the Job State table and the > AssociatedValue multi-plexed attribute)! It would be only three groups, all > mandatory, for a total of 10 objects. Hey, when I repeatedly asked for a "small number of objects", I didn't mean for the Job MIB to turn into the virtual Rubick's Cube of MIB technology. I mean, all this "multi-plexed AssociatedValue" stuff is just too much, IMHO. And speaking of opinions, I sure wish others besides yourself, Harry and myself spoke up about these issues. If my opinions represent a minority view, then I'd sure like to know. > >Doesn't this concern anyone else? (Hopefully some of the other vendors > >doing a prototype can respond here.) > > Are you concerned about the implementation of agents or applications, > I'm not sure which. If you could give some specific concern about > complexity, that would help us understand your concerns. I'm glad you asked, Tom. I'm concerned whether any other vendors are planning on implementing this Job MIB, or will it go the same route as NPAP. (It took three years to nail down NPAP...and the Job MIB will soon be approaching that same period.) Sure, I'm concerned with application implementation, that's our business. But without implementations in the marketplace, we can't ship diddly. Look how long it's taken to get a fair number of Printer MIB-capable printers in the marketplace. Until only recently, Underscore has been able to go after the market...after some three years of MIB development. And now, with the rapid development of IPP, it's starting to look like the Job MIB may never really have an impact in the marketplace at all. Yep, I'm sure Xerox will eventually ship an implementation for the standard Job MIB (along with their other implementations), but this is a critical mass problem we're dealing with. Without a reasonably large number of players, viable, attractive application solutions are not possible. Again, thanks for taking the time to explain things, Tom. ...jay From harryl at us.ibm.com Mon May 12 12:04:21 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job In-Reply-To: Straw vote request: interest in splitting the Job> Message-ID: <5030100002385800000002L002*@MHS> NO. I don't support separating the MIBs into accounting and monitoring - I think one rather simple mib should be able to address both. This is why we included a set of 4 tables - one for General information about the other tables in the MIB, one for Job ID, one for Job State (progress, monitoring) and one for Job Attributes (describing resources used by the job). Nor do I agree with the following statement (not sure who wrote this - my mailer did not find any name attached) >If you buy the categorization of the attributes in attr-tab, there are only >4 out of 78 attributes that are there only for accounting-only (A): >jobAccountName(16), printQualityUsed(39), tonerEconomyUsed(41), and >tonerDensityUsed(43). The rest are there for monitoring jobs only (M) or >are there for both monitoring and accounting (MA). I don't "buy" that only 4 of 78 are for accounting only. We obviously have some major philosophical differences regarding the use of the Job MIB which need to be address in San Diego. Harry Lewis - IBM Printing Systems From rbergma at dpc.com Mon May 12 11:07:39 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job MIB into two MIBs In-Reply-To: <199705091901.PAA09323@uscore.underscore.com> Message-ID: <5030100002385800000002L002*@MHS> Jay, I would vote NO to split the Job MIB. The functionality of the Job Monitoring and Job Accounting are so closely related that it would be foolish to try to separate. Also, we are so very close to completion, it would most likely take longer to perform a split. (I agree that this point is subject to different opinions.) I believe that the issues that are currently open are not as serious as some folks perceive and will be quickly solved. The MIB is now very small even though the document is very large. The document does contain a large amount of descriptive text, some of which could be eliminated. Suggestions here are encouraged. A significant portion of the document is devoted to the job attributes. While I agree that most of these attributes are not useful to present day printers, they may be useful in future products that are IPP compatible. I have not objected to the inclusion of the many attributes in an attempt to maintain compatibility with IPP. The attribute list is similar to the Channel Table enums in the printer MIB, where only a small percentage of the available values are actually used. Ron Bergman Dataproducts Corp On Fri, 9 May 1997, JK Martin wrote: > At this risk of ticking off our fine chairman (Ron Bergman), I'd > like to ask everyone to participate in a quick-and-dirty straw vote. > > Stuart Rowley commented: > > > Jay said he is starting to like the sound of a Job State MIB and a Job > > Attribute MIB. Maybe this isn't as far fetched as it sounds. Like > > Harry, I view the monitoring and accounting aspects of the MIB as > > addressing distinctly different needs. Perhaps we should separate the > > MIB to meet these different needs. We sure could make a simple Job > > State MIB which would likely be implemented across the board! > > How many others feel this way? (And how many others are opposed?) > > Would it be possible for all list participants to post their one-word > opinion/vote on this question: > > Are you in favor of the JMP group exploring the potential for > splitting the current Job Monitoring MIB into two separate MIBs, > one that focuses on job status and the other for job accounting? > > Just a simple "Yes" or "No" is being requested; if you want to add > something to the discussion, then great! But let's at least see > whether this is a topic worth investigating *before* the San Diego > meetings next week. > > ...jay > From hastings at cp10.es.xerox.com Mon May 12 12:51:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Issues list (19 issues) posted for 5/16 JMP meeting in San Message-ID: <9705121653.AA07038@zazen.cp10.es.xerox.com> I've updated the Issues list with issues raised on the mailing list. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-rw-r-- 1 pwg pwg 65024 May 12 16:41 issues.doc -rw-rw-r-- 1 pwg pwg 78642 May 12 16:42 issues.pdf -rw-r--r-- 1 pwg pwg 80293 May 12 16:42 issues.pdr The posted files have a lot more descriptive material about each issue. Please read that document as preparation for the San Diego meeting. We want to close on all of them and produce the final MIB out of the meeting. Please send comments on any of the issues (after reading the issues file) BEFORE the meeting to get the discussion going. Here is a synopsis of the issues from the issues file that are open followed by the closed issues that haven't yet been put into a document: The outstanding issues are: Issue 61 - Need to clarify the semantics of each object and attribute with respect to Configuration 1, 2, and 3. ISSUE 67 - Delete the three objects in the Job State table that duplicate attributes? jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, and jmJobStateAssociatedValue? ISSUE 68 - Delete the Job State Group/Table all together, since all objects are also duplicated as attributes? ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any difference? ISSUE 70 - Add some simple general device alert TC, instead of using the Printer MIB Alert Codes. ISSUE 71 - Are there any attributes that need to be clarified as to which apply to servers and which apply to devices and which apply to either? ISSUE 72 - What should happen to jmGeneralNewestActiveJobIndex when all the active jobs complete? ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? ISSUE 75 - Should the Attribute enum values be grouped so additions could be added in the appropriate section? Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or queueNameRequested be made Mandatory? Issue 77 - Should jobCompletedDateAndTime/TimeStamp be canceled time too, or add jobCanceledDateAndTime/TimeStamp? Issue 78 - Should the "multiplexor" jobStateAssociatedValue(4) attribute be removed from the Job Attribute Table and the equivalent jmJobStateAssociatedValue object be removed from the Job State table? Issue 79 - Should the 'printing' state be combined into the 'processing' state, like IPP? Issue 80 - How handle IPP "sides" attribute which has 3 enum values? Issue 81 - Add IPP "numberUp" attribute? ISSUE 82 - Change the OID assignment as Jeff Case suggests so no holes? ISSUE 83 - Can some attributes be deleted before the jmGeneralAttributePersistence expires? ISSUE 84 - Change Associated Value for 'printing' state to impressionsCompletedCurrentCopy(56)? ISSUE 85 - Break the MIB into a monitoring and an accounting MIB? 2. Closed Issues - not yet reflected in the current draft The following issues have been closed and have been incorporated into the Internet Draft 00 and version 0.71 or earlier: Issue 12 - What is the SNMPv1 and SNMPv2 error that an agent shall return if there is no instrumentation for an object? Closed: There is no such SNMP error. ALL uninstrumented objects in mandatory groups of any MIB should always correctly return 'read-only' static values specified in 'DEFVAL' clauses. 'DEFVAL' is a perfectly good SMIv2 feature intended to cover this situation. Returning ANY SNMP error for ANY object in a mandatory group with a legal instance qualifier (i.e., set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol spec (RFC 1905, page 10, in 'Get-Request PDU' handling). That's what 'shall implement ALL the objects in this group' means! So add DEFVAL clauses to all objects. Issue 64 - Need to fill out Appendix A on mapping from the job submission protocols to the Job Monitoring MIB for each of the three configurations. Closed: Put into a separate document. ACTION ITEM (all): Write up your job submission protocol mapping to the Job Monitoring MIB. Issue 65 - What Appendices should remain, which should be separate Internet Drafts and/or informational RFCs and which should disappear? Closed: No appendices for the Job Monitoring MIB, except for supplemental information about the semantics of job states. Put any other information into a separate informational RFC, such as mapping to ISO DPA, mapping to IPP, mapping to other job submission protocols, etc. Issue 73 - Is there a problem with outputBinIndex being made mandatory? If outputBinIndex is made mandatory, but an implementation doesn't have the Printer MIB, the agent has to put 0 as the value. Should we add one more attribute: outputBinNumber, which is just a number, not an index into the Printer MIB? If we do, which should be mandatory? Just one more reason to get rid of the jmStateTable, which is forcing us to pick a particular outputBin implementation and make it mandatory. If we got rid of the JobState table, we could forget about making any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute mandatory. Closed: Don't add outputBinNumber. Just add other(-1), unknown(-2), and multi(-3) values and keep outputBinIndex as mandatory. This does also mean that jmAttributeValueAsInteger needs a lower bound of -3, not -2. From harryl at us.ibm.com Mon May 12 13:03:01 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Comments from a novice Message-ID: <5030100002388479000002L092*@MHS> Stuart, far from appearing as if they are coming from a "novice", your questions are very useful in guiding our Job MIB discussion. I thank you for coming forward, letting us know you are interested, and participating in the discussion. Please let me address several of your questions, if I may... >1) Tom says there are only 8 mandatory attributes. But the rest are > conditionally mandatory (snip)...Does this mean that for an agent in a > printer, attributes which can always be known by a printer, such as > printQualityUsed, tonerEconomyUsed, jobCopiesCompleted, > jobDocumentsCompleted, pagesCompleted, sheetsCompleted, etc., must > always be implemented? This seems to disguise how many items are > actually mandatory. The simple answer is YES. The base interpretation of "conditionally mandatory" is sorta "if you know it or can do it... you must not consider it optional". Regarding your particular choices, however, I would say it is not always "possible" for the SNMP AGENT in the printer to understand each of the attributes you have listed. For example, we find that impressionsCompleted is a much more manageable attribute than pagesCompleted. >1a) Related to this is the question, if there is no indication to the > agent whether the job contains multiple documents, does the agent > implement just jobCopiesCompleted? or also jobDocumentsCompleted with > the same value since it assumed to be a 1 document job? Nested Jobs (or Documents within a job) has been one of the major "sore points" in developing the Job MIB, right from the start. Nested jobs is one of the reasons we ended up with a huge set of attributes. Originally, we tried to "hard code" the notion of Jobs and Documents into ID and State tables in the MIB but later realized, as you have pointed out, that many implementations would be unaware of nested jobs. Thus began the trend to make things (like documents) conditionally mandatory and move them to the attribute table. This was a good move on part of the JMP team. But the crux of the nested job problem lies mainly in the job submission protocol... not the job MIB. And most of what we call nested jobs is really little more than a separator sheet being placed with the job - something which the end-user gains very little from having this distinguished in the monitoring behavior of the MIB. >2) Roughly 15% of the job MIB document is spent describing >JobStateReasons. As an agent, do I really have to differentiate >between all these reasons? How do I implement just a small subset of >possible JobStateReasons? OK, Stuart. Here's where you ARE showing your Novice status. You obviously have never heard of DPA, have you? (I'm kidding...). The huge number of job state reasons is probably the most obvious indication of philosophical differences between Job MIB designers. This list is the herald of Server vs. Printer implementation differences. I have to give Tom credit for yielding, however, and, again, specifying the job State Reasons as attributes - thus not "forcing" them into every implementation. Are you beginning to see why the Attribute table has become a "catch-all" table? In trying to simplify the Job MIB, every item which appeared unrelated to a simple printer implementation has ended up as an attribute. To answer your question directly, I don't think there is anything preventing a printer from implementing a subset of JobStateReasons - or *no* JobStateReasons. >3) There are some attributes in the job MIB that an agent can obtain > from the data stream, such as jobCopiesRequested. Others relate to the > printer MIB or hr MIB. But with many of the attributes it is not clear > how the agent gets passed the information. For items such as jobOwner, > jobName, submittingServerName, etc. where does the agent get this > information? Some of this stuff is now sometimes sent with the job via > PJL or PostScript. Are we hoping that PJL and PostScript (and other > job control languages?) will be used to send this information? Will it > be ubiquitous? Accounting information will not be very useful if only > 50% of the jobs contain jobOwner information for example. You've hit the "mother lode" of JMP problems with this question. Before IPP was even a speck on anyone's white paper, the JMP was calling for a "standard submission protocol". I made a proposal a year ago for a simple "Job Attribute Wrapper" (not what I called it, but might wish I had) to accompany submission. Your observation is correct. Accounting will be hamstrung without these submission attributes. As recently as two meetings ago, Bob Pentecost of HP made some overture regarding possible extensions to PJL with this regard and has discussed jmJobSubmissionID here, on the mail list. I think Bob is doing the right thing in considering standard PJL extensions to support the Job MIB. I haven't heard anything from Adobe regarding this topic. Also, obviously, IPP could become the standard submission protocol we're looking for, but I doubt it will become the one-and-only protocol and I don't think we're doing a very good job as PWG of coordinating IPP and the Job MIB, so there might be some holes to patch. >4) I think the Attribute Table design using AttributeType textual > conventions has reduced the number of objects in the MIB, but has made > it more confusing. The number of OIDs is less, but it does make for a > daunting Attribute Table! I don't have enough implementation > experience to really know which is better or easier to implement. > Harry is the Attribute Table as much of a beast as it appears to be? The attribute table implementation is not so daunting. In fact, if we did away with the JobStateTable as Tom would have it, that would make one less group to implement and JobState has the jmJobAssociatedValue object which is a bit "tricky" as SNMP goes, because the value depends on the state. But there is a trade-off. The daunting part of the attribute table is the indexing. The agent must be implemented, I don't think there is any desire to completely do away with the attribute table... but, indexing into the attribute table will have a cost in terms of performance (we don't have any really measure of this just yet). We feel the JobStateTable is a more straightforward and optimized means of obtaining a good indication of job progress and current state. The main downside of the JobStateTable that I see is that it's definition will be rigid. If everything is an attribute, and you can get enough attributes on one GET, then some applications could get jmJobState along with their 12 favorite attributes while others could just go after JobState plus 9. With the JobStateTable and the jmJobAssociatedValue... there is a fixed relationship... PENDING - QUEUE POSITION; PRINTING - CURRENT COPY; COMPLETED - OUTPUT BIN... etc. I want everyone to realize this and especially I'd like app writers to comment. The main trade-off is ease of indexing vs. flexibility (a pretty traditional engineering scenario)! Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Mon May 12 19:25:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Straw vote request: interest in splitting the Job In-Reply-To: Straw vote request: interest in splitting the Job> Message-ID: <9705122327.AA07185@zazen.cp10.es.xerox.com> At 09:04 05/12/97 PDT, Harry Lewis wrote: Snip.. >Nor do I agree with the following statement (not sure who wrote this - my >mailer did not find any name attached) Harry, I wrote that. See the file attr-tab.doc .pdf that I posted in the /pub/pwg/jmp/contributions sub-directory last Friday. > >>If you buy the categorization of the attributes in attr-tab, there are only >>4 out of 78 attributes that are there only for accounting-only (A): >>jobAccountName(16), printQualityUsed(39), tonerEconomyUsed(41), and >>tonerDensityUsed(43). The rest are there for monitoring jobs only (M) or >>are there for both monitoring and accounting (MA). > >I don't "buy" that only 4 of 78 are for accounting only. We obviously have some >major philosophical differences regarding the use of the Job MIB which need to >be address in San Diego. I'd be interested in which additional attributes you think are for accounting *only*, i.e. are not also useful for job monitoring? Take a look at the attr-tab.doc .pdf file. Should we put review of the attr-tab.doc .pdf file on the agenda for San Diego? > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Tue May 13 17:13:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Mapping of IPP to JMP attributes and objects Message-ID: <9705132115.AA07395@zazen.cp10.es.xerox.com> I've posted a comparison of IPP job and printer attributes with the JMP Monitoring MIB: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 22528 May 13 21:05 ipp-jmp.doc -rw-r--r-- 1 pwg pwg 25853 May 13 21:06 ipp-jmp.pdf Is does show a small number of places where the Job Monitoring MIB could be enhanced to create greater compatibility with IPP. Ron and I would like to discuss it as one of the JMP agenda topics this Friday. Tom From hastings at cp10.es.xerox.com Tue May 13 17:26:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Agenda for JMP meeting, Fri, 5/16/97, San Diego Message-ID: <9705132128.AA07403@zazen.cp10.es.xerox.com> Ron and I propose the following agenda for the JMP meeting, 5/16/97: The objective is to get final agreement on the Job Monitoring MIB at the meeting. Agenda: 1. Review the classification of JMP attributes (attr-tab.pdf) 2. Review the IPP to JMP mapping (ipp-jmp.pdf) 3. Review issues list (issues.pdf) We may want to re-order the issues, since some are dependent on others 4. Any other issues with the MIB document (jmp-mibv.pdf) Here are the files in ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc -rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf -rw-r--r-- 1 pwg pwg 22528 May 13 21:05 ipp-jmp.doc -rw-r--r-- 1 pwg pwg 25853 May 13 21:06 ipp-jmp.pdf -rw-rw-r-- 1 pwg pwg 66048 May 13 21:06 issues.doc -rw-rw-r-- 1 pwg pwg 79381 May 13 21:07 issues.pdf -rw-r--r-- 1 pwg pwg 81065 May 13 21:07 issues.pdr -rw-r--r-- 1 pwg pwg 94358 Apr 7 22:33 Jmpexp.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 422912 Apr 29 00:34 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 348534 Apr 29 00:35 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 358881 Apr 29 19:32 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 275477 Apr 29 00:36 jmp-mibv.pdf From STUART at KEI-CA.CCMAIL.CompuServe.COM Tue May 13 20:16:48 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:04 2009 Subject: JMP> Comments from a novice In-Reply-To: Comments from a novice> Message-ID: <9705132128.AA07403@zazen.cp10.es.xerox.com> Harry, Thanks for your thorough response. I'm still not sure about this "conditionally mandatory" business. You said: >The base interpretation of "conditionally mandatory" is sorta "if you know it >or can do it... you must not consider it optional". Regarding your particular >choices, however, I would say it is not always "possible" for the SNMP AGENT >in the printer to understand each of the attributes you have listed. For >example, we find that impressionsCompleted is a much more manageable attribute >than pagesCompleted. Ok, pagesCompleted may be ambiguous to the agent because it might be printing 4 up without knowing it, but what about sheetsCompleted? It is not mandatory, but a printer will always know this, therefore wouldn't it be considered mandatory for all printers which implement the job MIB? Later, you said: >To answer your question directly, I don't think there is anything preventing a >printer from implementing a subset of JobStateReasons - or *no* >JobStateReasons." With reasons such as "successfulCompletion" I don't understand how JobStateReasons could be conditionally mandatory. It may be useful to list which attributes would normally be considered mandatory in a printer agent and which would normally be considered mandatory in a server agent. >OK, Stuart. Here's where you ARE showing your Novice status. You obviously have >never heard of DPA, have you? Hey, I resent that! I've been a member of the Drug Prevention Association for years! >You've hit the "mother lode" of JMP problems with this question. Before IPP was >even a speck on anyone's white paper, the JMP was calling for a "standard >submission protocol". I made a proposal a year ago for a simple "Job Attribute >Wrapper" (not what I called it, but might wish I had) to accompany submission. >Your observation is correct. Accounting will be hamstrung without these >submission attributes. >As recently as two meetings ago, Bob Pentecost of HP made some overture >regarding possible extensions to PJL with this regard and has discussed >jmJobSubmissionID here, on the mail list. I think Bob is doing the right thing >in considering standard PJL extensions to support the Job MIB. I haven't heard >anything from Adobe regarding this topic. Also, obviously, IPP could become the >standard submission protocol we're looking for, but I doubt it will become the >one-and-only protocol and I don't think we're doing a very good job as PWG of >coordinating IPP and the Job MIB, so there might be some holes to patch. I remember discussing the PJL extension for JobSubmissionID. PJL and PS extensions are definitely a step in the right direction, but I think we need to focus more energy in this area. With no clear standard job submission protocol the job MIB will be pretty impotent. Until the JMP group articulates its plans in this area more clearly, I believe it will be a BIG impediment to wide spread implementation of the job MIB. If IPP is going to become THE standard job submission protocol, the JMP group needs to carefully evaluate how this will impact the JMP effort. Unfortunately, aside from Tom, I don't think many of the IPP group is much aware of what's going on in JMP. Regarding the attribute table vs. the JobStateTable... Of course, we are going to discuss this in San Diego. I don't profess to understand all the issues, but I like the concept of a separate JobStateTable that provides quick easy access to the most commonly needed information. I also see that the JobStateAssociatedValue attribute is complex and may be tricky to implement and there is also the issue of duplication with the AttributeTable. Let's see how the others feel. Stuart Rowley Kyocera Electronics From hastings at cp10.es.xerox.com Wed May 14 02:33:12 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Harry's Job Monitoring MIB explanation document Message-ID: <9705140635.AA07478@zazen.cp10.es.xerox.com> Harry contributed a very helpful explanation of the Job Monitoring MIB just after the Austin meeting. For those of you who are having trouble with understanding the Job Monitoring MIB (or who are trying to understand it by reading the e-mail that discussing issues about it), you should read Harry's explanation. Its only 15 pages long and has some nice summary tables. I'm bringing copies with me to the meeting for those who didn't see it. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 94358 Apr 7 22:33 Jmpexp.pdf Also it would help a great deal for those attending the JMP meeting this Friday to please read the MIB itself: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 275477 Apr 29 00:36 jmp-mibv.pdf Tom >Return-Path: >From: Harry Lewis >To: >Subject: JMP> Job MIB related files >Date: Mon, 7 Apr 1997 16:01:23 PDT >Sender: jmp-owner@pwg.org > >Classification: >Prologue: >Epilogue: Harry Lewis - IBM Printing Systems > >I think we came to some fairly stable agreements at the Austin meeting and we >need to get things in shape quickly for the IETF submission. Tom, Ron and I >stayed a few hrs after the meeting, Friday, to jump start the presentation. >While Tom's document is ultimately the most authoritative, it is also very >detailed and may take quite a lot of work to bring around. Thus, I composed a >brief .PDF document which I am calling an "explanation". In it, I tried to >share more of our prototype experience with some findings on table size etc. I >also updated the presentation I gave at the meeting. Both are available on the >server now. > > ftp.pwg.org/pub/pwg/jmp/contributions/Jmpexp.pdf (the explanation) > /pwgjm.PDF (presentation) > >Both of these are intended to accurately reflect the consensus reached at >Friday's meeting and may be useful in approaching the IETF. I have placed these >documents at the disposal of the PWG for this purpose and to aid in >understanding the Job MIB. Please let me know if there are any corrections, >comments etc. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Thu May 15 05:46:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Question about assigning OIDs for the Job Monitoring MIB Message-ID: <9705150948.AA07687@zazen.cp10.es.xerox.com> Jeff, Just to make sure that we are assigning our OIDs properly for the Job Monitoring MIB we have: ISSUE 82 - Change the OID assignment as Jeff Case suggests: Quoted from Jeff Case's reply (lines without > are my understanding of how we are to assign all of the OIDs to the Job Monitoring MIB): > jobmonMIB > jobmonMIB.1 jobmonMIBObjects > jobmonMIB.1.1 jmGeneral jobmonMIB.1.1.1 jmGeneralTable jobmonMIB.1.1.1.1 jmGeneralEntry jobmonMIB.1.1.1.1.1 jmGeneralNumberOfActiveJobs jobmonMIB.1.1.1.1.2 jmGeneralOldestActiveJobIndex jobmonMIB.1.1.1.1.3 jmGeneralNewestActiveJobIndex jobmonMIB.1.1.1.1.4 jmGeneralJobPersistence jobmonMIB.1.1.1.1.5 jmGeneralAttributePersistence jobmonMIB.1.1.1.1.6 jmGeneralJobSetName > jobmonMIB.1.2 jmJobID jobmonMIB.1.1.1 jmJobIDTable jobmonMIB.1.1.1.1 jmJobIDEntry jobmonMIB.1.1.1.1.1 jmJobSubmissionIDIndex jobmonMIB.1.1.1.1.2 jmJobSetIndex jobmonMIB.1.1.1.1.3 jmJobIndex > jobmonMIB.1.3 jmJobStateG jobmonMIB.1.1.1 jmJobStateTable jobmonMIB.1.1.1.1 jmJobStateEntry jobmonMIB.1.1.1.1.1 jmJobState jobmonMIB.1.1.1.1.2 jmJobStateKOctetsCompleted jobmonMIB.1.1.1.1.3 jmJobStateImpressionsCompleted jobmonMIB.1.1.1.1.4 jmJobStateAssociatedValue > jobmonMIB.1.4 jmAttribute jobmonMIB.1.1.1 jmAttributeTable jobmonMIB.1.1.1.1 jmAttributeEntry jobmonMIB.1.1.1.1.1 jmAttributeTypeIndex jobmonMIB.1.1.1.1.2 jmAttributeInstanceIndex jobmonMIB.1.1.1.1.3 jmAttributeValueAsInteger jobmonMIB.1.1.1.1.4 jmAttributeValueAsOctets > jobmonMIB.2 jobmonMIBConformance jobmonMIB.2.1 jobmonMIBCompliance jobmonMIB.2.2 jmMIBGroups jobmonMIB.2.2.1 jmGeneralGroup jobmonMIB.2.2.2 jmJobIDGroup jobmonMIB.2.2.3 jmJobStateGroup jobmonMIB.2.2.4 jmAttributeGroup NOTE: I had to add "G" to the jmJobState group arc name, since the first object (column) in the jmJobStateTable is also named jmJobState. Some of us were wondering whether we could eliminate an arc, since each of our groups is exactly one table, i.e., assign the table OID instead of a group OID at the .1.1 position?: > jobmonMIB > jobmonMIB.1 jobmonMIBObjects > jobmonMIB.1.1 jmGeneralTable jobmonMIB.1.1.1 jmGeneralEntry jobmonMIB.1.1.1.1 jmGeneralNumberOfActiveJobs jobmonMIB.1.1.1.2 jmGeneralOldestActiveJobIndex jobmonMIB.1.1.1.3 jmGeneralNewestActiveJobIndex jobmonMIB.1.1.1.4 jmGeneralJobPersistence jobmonMIB.1.1.1.5 jmGeneralAttributePersistence jobmonMIB.1.1.1.6 jmGeneralJobSetName > jobmonMIB.1.2 jmJobIDTable jobmonMIB.1.1.1 jmJobIDEntry jobmonMIB.1.1.1.1 jmJobSubmissionIDIndex jobmonMIB.1.1.1.2 jmJobSetIndex jobmonMIB.1.1.1.3 jmJobIndex > jobmonMIB.1.3 jmJobStateTable jobmonMIB.1.1.1 jmJobStateEntry jobmonMIB.1.1.1.1 jmJobState jobmonMIB.1.1.1.2 jmJobStateKOctetsCompleted jobmonMIB.1.1.1.3 jmJobStateImpressionsCompleted jobmonMIB.1.1.1.4 jmJobStateAssociatedValue > jobmonMIB.1.4 jmAttributeTable jobmonMIB.1.1.1 jmAttributeEntry jobmonMIB.1.1.1.1 jmAttributeTypeIndex jobmonMIB.1.1.1.2 jmAttributeInstanceIndex jobmonMIB.1.1.1.3 jmAttributeValueAsInteger jobmonMIB.1.1.1.4 jmAttributeValueAsOctets > >Correct? >yes, if > 1. jobmon is not somewhere under printmib > 2. you don't have something like > jobmonMIB.2 jobmonNotifications > in which case then > jobmonMIB.3 jobmonMIBconformance > would move down one arc Suppose that we were to add trapping in a future revision. Would we have a problem, since jobmonMIBConformace is already allocated as jobmonMIB.2. Would we then add jobmonMIBNotifications as jobmonMIB.3? Thanks, Tom From hastings at cp10.es.xerox.com Thu May 15 05:46:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issues Message-ID: <9705150948.AB07687@zazen.cp10.es.xerox.com> I've posted an 8-page analysis of the utlization of the jmJobStateTable and the jmAttributeTable in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc -rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf in order to attempt to resolve the biggest issues remaining in the Job Monitorng MIB regarding the redundance between the jmJobStateTable and the jmAttributeTable and whether we could get rid of the jmJobStateTable and use just the jmAttributeTable or not. Harry, Ron, and I discussed the issue over lunch today. Then I wrote this paper to capture the discussion, but they have not had a chance to review the paper. If there are mistakes in the paper, they are mine. Please review the paper to see if my understanding of SNMP Get and Get Next is correct when used with tables. Please send comments on this paper today, Thursday, 5/15, so that we may consider them during our JMP meeting, tommorrow, Friday, 5/16. One way to send comments is to use MS-WORD, turn on revision marks, and may comments directly in the .doc file. If the comments are sparse, an e-mail will do. The .pdf file has line numbers, so that you can refer to specific lines in an e-mail mesage, perhaps even cutting and pasting the relevant paragraph. The conclusions in the paper are: The jmJobStateTable is very useful because its lowest order index is jmJobIndex, so that any number of selected objects can be obtained using multiple Get Next operations in a single PDU for the *next* job, skipping over jobs that have been removed from the table. A subsequent PDU can contain multiple Get operations for any attributes desired using the returned jmJobIndex value. If the mandatory attributes are all put into the jmJobStateTable as objects, and not in the jmAttributeTable as attributes, it is clear by SNMP rules that all of the mandatory objects shall be instantiated at the same time when the new job row is put into the jmJobStateTable. Also the persistence time is clearly separated by which table the information is contained. The jmAttributeTable only contains conditionally mandatory attributes, no mandatory attributes, so that the jmAttributeTable itself can be conditionally mandatory, thereby allowing a very small implementation to only implement the jmJobStateTable and not the jmAttributeTable. From Angelo_Caruso at wb.xerox.com Thu May 15 08:40:52 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:04 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Message-ID: <9705150948.AB07687@zazen.cp10.es.xerox.com> Tom, Oops! I think you meant: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.doc ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.pdf NOT: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.doc ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.pdf I agree with all of your conclusions and was just about to type up a long mailnote with a similar argument. Thanks for saving me the work. I do have some additional comments, also. I will send these in a seperate note. Ang ---------- From: jmp-owner@pwg.org To: jmp@pwg.org Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issu Date: Thursday, May 15, 1997 12:00AM I've posted an 8-page analysis of the utlization of the jmJobStateTable and the jmAttributeTable in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc -rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf in order to attempt to resolve the biggest issues remaining in the Job Monitorng MIB regarding the redundance between the jmJobStateTable and the jmAttributeTable and whether we could get rid of the jmJobStateTable and use just the jmAttributeTable or not. Harry, Ron, and I discussed the issue over lunch today. Then I wrote this paper to capture the discussion, but they have not had a chance to review the paper. If there are mistakes in the paper, they are mine. Please review the paper to see if my understanding of SNMP Get and Get Next is correct when used with tables. Please send comments on this paper today, Thursday, 5/15, so that we may consider them during our JMP meeting, tommorrow, Friday, 5/16. One way to send comments is to use MS-WORD, turn on revision marks, and may comments directly in the .doc file. If the comments are sparse, an e-mail will do. The .pdf file has line numbers, so that you can refer to specific lines in an e-mail mesage, perhaps even cutting and pasting the relevant paragraph. The conclusions in the paper are: The jmJobStateTable is very useful because its lowest order index is jmJobIndex, so that any number of selected objects can be obtained using multiple Get Next operations in a single PDU for the *next* job, skipping over jobs that have been removed from the table. A subsequent PDU can contain multiple Get operations for any attributes desired using the returned jmJobIndex value. If the mandatory attributes are all put into the jmJobStateTable as objects, and not in the jmAttributeTable as attributes, it is clear by SNMP rules that all of the mandatory objects shall be instantiated at the same time when the new job row is put into the jmJobStateTable. Also the persistence time is clearly separated by which table the information is contained. The jmAttributeTable only contains conditionally mandatory attributes, no mandatory attributes, so that the jmAttributeTable itself can be conditionally mandatory, thereby allowing a very small implementation to only implement the jmJobStateTable and not the jmAttributeTable. From Angelo_Caruso at wb.xerox.com Thu May 15 10:39:22 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:04 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Message-ID: <9705150948.AB07687@zazen.cp10.es.xerox.com> Ron, Harry, and Tom, As I mentioned in my previous posting I agree with the conclusions in the 'sepstate.doc' paper. Namely, the mandatory attributes should become distinct objects in the jmJobStateTable, making it the "basic" table for low-end implementations, and the jmAttributeTable then becomes conditionally mandatory. Having implemented a table similar to the jmAttributeTable in a Xerox proprietary MIB (Xerox people read: XCMI Comms Options table), I know that these are tricky things to get right, particularly for low-end implementations. Along this line of thinking, I believe the second comformance requirement in the internet draft (page 15) of the job MIB is too strong. It states: "A conforming agent: ...2.shall implement each conditionally mandatory attributes, if the server or device that the agent is instrumenting has the feature represented by the conditionally mandatory attribute.." This says to me, for example, that if a printer implements the Printer MIB, then the jobSourceChannelIndex attribute is mandatory since it indexes a mandatory table in the Printer MIB. Therefore, for any implementation that implements the Printer MIB, the jmAttributeTable is automatically mandatory. If you're not satisfied with this example I can come up with lots more. I suggest that the comformance requirement above be ammended to read as: "A conforming agent: ...2.shall implement each conditionally mandatory attribute, if the server or device that the agent is instrumenting has the feature represented by the conditionally mandatory attribute and the device provides similar instrumentation of this attribute using some other interface or protocol." Then, if the device made the information about a job's source channel available through some other interface like DPA or IPP, then and only then would the jobSourceChannelIndex attribute become mandatory. This would allow the jmAttributeTable to actually not be mandatory for low end implementations. Having not followed the JMP discussions closely over the last several months I don't understand why it was decided that outputBinIndex (previously ouputBinName) is mandatory? Speaking as an end user of several networked printers, when I walk over to pick up my job I typically find it sitting on top of the stack of jobs in the single output tray of the printer. If not there, then it is usually in a stack of jobs that someone was too lazy to sort, or, less frequently, someone has been kind enough to file it in some alphabetically organized filing contraption. So why does this value need to be mandatory? The only case I can think of where it is really useful is for devices with a mailbox type output device, but those are the exception rather than the rule. I certainly think that attributes like jobName and jobOwner are much more deserving of mandatory status since they appear in most current job/queue monitoring applications (e.g. PCONSOLE, Win95 print manager, etc). But since they are conditionally mandatory, outputBinIndex should be also. Lastly, I would like to request two new attribute be added for accounting purposes with color capable devices. Color devices typically cannot measure the exact amount of colorant consumed per job, but can easily measure the number of color impressions. This is important for accurate accounting since color impressions cost more than black impressions with most current marking technologies. I have included the ASN.1 here for your convenience: fullColorImpressions(??), -- Integer32(-2..2147483647) -- INTEGER: The total number of full color impressions -- completed by the device for this job so far. For printing, the -- impressions completed includes interpreting, marking, and -- stacking the output. For other types of job services, -- the number of impressions completed includes the number -- of impressions processed. Full color impressions are -- typically defined as those requiring 3 or more colorants, -- but this may vary by implementation. highlightColorImpressions(??), -- Integer32(-2..2147483647) -- INTEGER: The total number of highlight color impressions -- completed by the device for this job so far. For printing, the -- impressions completed includes interpreting, marking, and -- stacking the output. For other types of job services, -- the number of impressions completed includes the number -- of impressions processed. Highlight color impressions are -- typically defined as those requiring black plus one other -- colorant, but this may vary by implementation. Thanks, Angelo From case at snmp.com Thu May 15 18:41:30 1997 From: case at snmp.com (case@snmp.com) Date: Wed May 6 14:00:04 2009 Subject: JMP> Re: Question about assigning OIDs for the Job Monitoring MIB In-Reply-To: Message-ID: <199705152241.SAA21512@seymour4.snmp.com> >Jeff, hi tom, everybody >Just to make sure that we are assigning our OIDs properly for the >Job Monitoring MIB we have: >... >[snip] what you sent me looks ok ... i didn't see anything out-of-the-ordinary >NOTE: I had to add "G" to the jmJobState group arc name, since the first >object (column) in the jmJobStateTable is also named jmJobState. that looked pretty weird ... i suggest you at least put on a comment that says "no, this is not a typo" or you will be creating a "frequently asked question" >Some of us were wondering whether we could eliminate an arc, since >each of our groups is exactly one table, i.e., assign the table OID >instead of a group OID at the .1.1 position?: i suggest you not do this ... you have only one table in each clump now, but you do not know what the future holds ... we added things to groups in mib 2 after we got some experience ... maybe unlikely to happen to smart guys like printer mib designers, and we have more experience now that we had back then, but, for me, the engineering tradeoff between the possibility that you will want to add to a group is pretty good, and the savings you get by supressing an oid fragment are pretty small -- does not seem like a good tradeoff in my book, but this is a judgement call that could go either way argue it until you get tired, then pick one ... i'd leave the extra level in >Suppose that we were to add trapping in a future revision. Would we >have a problem, since jobmonMIBConformace is already allocated as >jobmonMIB.2. Would we then add jobmonMIBNotifications as jobmonMIB.3? you can either: move jobmonMIBConformance "over" one to .3 now and reserve jobmonMIB.2 for notifications or you can add jobmonMIBNotifications as jobmonMIB.3 later both are syntactically correct both are semantically correct the former is somewhat preferred as more "look and feel" correct but has momentum against it -- but, you have not yet published as an rfc, so it is no big deal i'd probably move it and put in the reserved for future use thing, but this is not worth a major fight ... we are mainly into the real of taste with this item regards, jdc From hastings at cp10.es.xerox.com Fri May 16 01:03:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:04 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Message-ID: <9705160505.AA07885@zazen.cp10.es.xerox.com> I gave the wrong file name to the analysis paper. I've also added a .txt form: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 39936 May 15 09:37 sepstate.doc -rw-r--r-- 1 pwg pwg 43087 May 15 09:38 sepstate.pdf -rw-r--r-- 1 pwg pwg 26237 May 16 05:01 sepstate.txt Tom >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Thu, 15 May 1997 02:46:34 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issues >Sender: jmp-owner@pwg.org > >I've posted an 8-page analysis of the utlization of the jmJobStateTable >and the jmAttributeTable in: > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc >-rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf > >in order to attempt to resolve the biggest issues remaining in the >Job Monitorng MIB regarding the redundance between the jmJobStateTable and >the jmAttributeTable and whether we could get rid of the jmJobStateTable and >use just the jmAttributeTable or not. > >Harry, Ron, and I discussed the issue over lunch today. Then I wrote this >paper to capture the discussion, but they have not had a chance to review >the paper. If there are mistakes in the paper, they >are mine. Please review the paper to see if my understanding of SNMP >Get and Get Next is correct when used with tables. > >Please send comments on this paper today, Thursday, 5/15, so that we >may consider them during our JMP meeting, tommorrow, Friday, 5/16. > >One way to send comments is to use MS-WORD, turn on revision marks, >and may comments directly in the .doc file. If the comments are >sparse, an e-mail will do. The .pdf file has line numbers, so that you >can refer to specific lines in an e-mail mesage, perhaps even cutting >and pasting the relevant paragraph. > > >The conclusions in the paper are: > >The jmJobStateTable is very useful because its lowest order index is >jmJobIndex, so that any number of selected objects can be obtained using >multiple Get Next operations in a single PDU for the *next* job, skipping >over jobs that have been removed from the table. A subsequent PDU can >contain multiple Get operations for any attributes desired using the >returned jmJobIndex value. > >If the mandatory attributes are all put into the jmJobStateTable as objects, >and not in the jmAttributeTable as attributes, it is clear by SNMP rules >that all of the mandatory objects shall be instantiated at the same time >when the new job row is put into the jmJobStateTable. Also the persistence >time is clearly separated by which table the information is contained. > >The jmAttributeTable only contains conditionally mandatory attributes, no >mandatory attributes, so that the jmAttributeTable itself can be >conditionally mandatory, thereby allowing a very small implementation to >only implement the jmJobStateTable and not the jmAttributeTable. > > > From harryl at us.ibm.com Mon May 19 14:24:39 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:04 2009 Subject: JMP> Job Queue Status Message-ID: <5030100002637918000002L082*@MHS> Harrish, you had two questions. First... 'what's going on'... with Job MIB changes? The Job MIB has undergone changes from the January draft based on experience learned from prototyping. I believe this is a very beneficial part of the IETF process. If you review the current draft, I think you will agree that all the desired Job MIB function is still present but operations have been improved. Second... 'would like to see Job Queue Status put back in... The JobStateTable (renamed to JobTable at Friday's meeting) should provide you with the queue status you are looking for. Using this table, you can determine the number of intervening jobs for you particular job and also the State or every job in the queue. The one thing we did remove was an indication or how the queue, itself, is managed. Like, is the queue a fifo, shortest job first etc. Is this what you are asking for? Recall that is would be a r/o object. We could probably add this back to the General table if necessary. It would likely be "hardcoded" to fifo for many printers. Harrish, if you have questions about the latest Job MIB draft, please feel free to post them or e-mail me, Ron or Tom directly if we can be of assistance. We are into the home stretch on this MIB. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Mon May 19 17:51:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Job Queue Status In-Reply-To: Job Queue Status> Message-ID: <9705192153.AA08406@zazen.cp10.es.xerox.com> There are some more "queue status objects": 1. The General table has the jmGeneralNumberOfActiveJobs object which indicates the number of jobs that are in any state but canceled or completed. 2. The General table has the jmGeneralJobSetName object which could be used for the queue name in a server that has multiple queues, one per job set. So any of the General group/table objects are "queue related" in a system that implements queues. I plan to have an updated version of the Job Monitoring MIB for comments later this week with the final agreements reached last week. Tom At 11:24 05/19/97 PDT, Harry Lewis wrote: >Harrish, you had two questions. > >First... 'what's going on'... with Job MIB changes? > >The Job MIB has undergone changes from the January draft based on experience >learned from prototyping. I believe this is a very beneficial part of the IETF >process. If you review the current draft, I think you will agree that all the >desired Job MIB function is still present but operations have been improved. > >Second... 'would like to see Job Queue Status put back in... > >The JobStateTable (renamed to JobTable at Friday's meeting) should provide you >with the queue status you are looking for. Using this table, you can determine >the number of intervening jobs for you particular job and also the State or >every job in the queue. > >The one thing we did remove was an indication or how the queue, itself, is >managed. Like, is the queue a fifo, shortest job first etc. Is this what you >are asking for? Recall that is would be a r/o object. We could probably add >this back to the General table if necessary. It would likely be "hardcoded" to >fifo for many printers. > >Harrish, if you have questions about the latest Job MIB draft, please feel free >to post them or e-mail me, Ron or Tom directly if we can be of assistance. We >are into the home stretch on this MIB. > > > >Harry Lewis - IBM Printing Systems > > From jkm at underscore.com Mon May 19 18:17:40 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Job Queue Status In-Reply-To: Job Queue Status> Message-ID: <199705192217.SAA16509@uscore.underscore.com> Tom, > I plan to have an updated version of the Job Monitoring MIB for comments > later this week with the final agreements reached last week. Thanks in advance for quickly updating the draft. Would it be possible for you to first post a summary of the changes agreed upon at last week's JMP meeting in San Diego. Without such a summary, reviewing the draft will be a lot harder. ...jay From hastings at cp10.es.xerox.com Mon May 19 18:33:03 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Message-ID: <9705192235.AA08452@zazen.cp10.es.xerox.com> In going over my notes, I see that we didn't process the last part of paper number 9 at the 5/16 JMP meeting. Does any one have a problem if I add the following two attributes to the Attribute table [with the suffix "Completed" added] as: Lastly, I would like to request two new attribute be added for accounting purposes with color capable devices. Color devices typically cannot measure the exact amount of colorant consumed per job, but can easily measure the number of color impressions. This is important for accurate accounting since color impressions cost more than black impressions with most current marking technologies. I have included the ASN.1 here for your convenience: fullColorImpressionsCompleted(??), -- Integer32(-2..2147483647) -- INTEGER: The total number of full color impressions -- completed by the device for this job so far. For printing, the -- impressions completed includes interpreting, marking, and -- stacking the output. For other types of job services, -- the number of impressions completed includes the number -- of impressions processed. Full color impressions are -- typically defined as those requiring 3 or more colorants, -- but this may vary by implementation. highlightColorImpressionsCompleted(??), -- Integer32(-2..2147483647) -- INTEGER: The total number of highlight color impressions -- completed by the device for this job so far. For printing, the -- impressions completed includes interpreting, marking, and -- stacking the output. For other types of job services, -- the number of impressions completed includes the number -- of impressions processed. Highlight color impressions are -- typically defined as those requiring black plus one other -- colorant, but this may vary by implementation. >Return-Path: >Date: Thu, 15 May 1997 07:39:22 PDT >From: "Caruso,Angelo" >Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable >To: jmp@pwg.org >Posting-Date: Thu, 15 May 1997 10:49:50 -0400 >Priority: normal >Hop-Count: 3 >Sender: jmp-owner@pwg.org > >Ron, Harry, and Tom, > >As I mentioned in my previous posting I agree with the conclusions in > the 'sepstate.doc' paper. Namely, the mandatory attributes should > become distinct objects in the jmJobStateTable, making it the "basic" > table for low-end implementations, and the jmAttributeTable then > becomes conditionally mandatory. Having implemented a table similar to > the jmAttributeTable in a Xerox proprietary MIB (Xerox people read: > XCMI Comms Options table), I know that these are tricky things to get > right, particularly for low-end implementations. > >Along this line of thinking, I believe the second comformance > requirement in the internet draft (page 15) of the job MIB is too > strong. It states: > >"A conforming agent: >...2.shall implement each conditionally mandatory attributes, if the > server or device that the agent is instrumenting has the feature > represented by the conditionally mandatory attribute.." > >This says to me, for example, that if a printer implements the Printer > MIB, then the jobSourceChannelIndex attribute is mandatory since it > indexes a mandatory table in the Printer MIB. Therefore, for any > implementation that implements the Printer MIB, the jmAttributeTable > is automatically mandatory. If you're not satisfied with this example > I can come up with lots more. I suggest that the comformance > requirement above be ammended to read as: > >"A conforming agent: >...2.shall implement each conditionally mandatory attribute, if the > server or device that the agent is instrumenting has the feature > represented by the conditionally mandatory attribute and the > device provides similar instrumentation of this attribute using > some other interface or protocol." > >Then, if the device made the information about a job's source channel > available through some other interface like DPA or IPP, then and only > then would the jobSourceChannelIndex attribute become mandatory. This > would allow the jmAttributeTable to actually not be mandatory for low > end implementations. > >Having not followed the JMP discussions closely over the last several > months I don't understand why it was decided that outputBinIndex > (previously ouputBinName) is mandatory? Speaking as an end user of > several networked printers, when I walk over to pick up my job I > typically find it sitting on top of the stack of jobs in the single > output tray of the printer. If not there, then it is usually in a > stack of jobs that someone was too lazy to sort, or, less frequently, > someone has been kind enough to file it in some alphabetically > organized filing contraption. So why does this value need to be > mandatory? The only case I can think of where it is really useful is > for devices with a mailbox type output device, but those are the > exception rather than the rule. I certainly think that attributes like > jobName and jobOwner are much more deserving of mandatory status since > they appear in most current job/queue monitoring applications (e.g. > PCONSOLE, Win95 print manager, etc). But since they are conditionally > mandatory, outputBinIndex should be also. > >Lastly, I would like to request two new attribute be added for > accounting purposes with color capable devices. Color devices > typically cannot measure the exact amount of colorant consumed per > job, but can easily measure the number of color impressions. This is > important for accurate accounting since color impressions cost more > than black impressions with most current marking technologies. I have > included the ASN.1 here for your convenience: > > fullColorImpressions(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of full color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Full color impressions are > -- typically defined as those requiring 3 or more colorants, > -- but this may vary by implementation. > > highlightColorImpressions(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of highlight color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Highlight color impressions are > -- typically defined as those requiring black plus one other > -- colorant, but this may vary by implementation. > >Thanks, >Angelo > > From hastings at cp10.es.xerox.com Mon May 19 18:48:47 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Job Queue Status In-Reply-To: Job Queue Status> Message-ID: <9705192250.AA08474@zazen.cp10.es.xerox.com> Ok, I'll first post the changes that we agreed to. That will be good to make sure we agree on what we agreed to. Also Harry's minutes should be coming soon. Tom At 15:17 05/19/97 PDT, you wrote: >Tom, > >> I plan to have an updated version of the Job Monitoring MIB for comments >> later this week with the final agreements reached last week. > >Thanks in advance for quickly updating the draft. > >Would it be possible for you to first post a summary of the changes >agreed upon at last week's JMP meeting in San Diego. Without such >a summary, reviewing the draft will be a lot harder. > > ...jay > > From hastings at cp10.es.xerox.com Tue May 20 04:38:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Resolving IPP/JMP job-state and job-state-reasons differences: Message-ID: <9705200840.AA08588@zazen.cp10.es.xerox.com> For the IPP telecon, Wed, 5/21, 1-3 pm PDT (4-6 pm EDT). The Job Monitoring MIB project is nearling completion and we wanted to make sure that the JMP model of a print job covered IPP. In other words, an SNMP agent will have to map the IPP semantics onto the JMP representation of a job. The JMP wanted to meet with the IPP folks to resolve these differences. Since JMP will be monitoring output devices and servers that implement different protocols, JMP may need to be a superset of IPP, not one-to-one. However, an SNMP agent must be able to map the semantics of an IPP server or printer into the JMP semantics. I've posted a detailed comparison of the IPP job-state and job-state-reasons attributes with the JMP jmJobState object and the jobStateReasons1 attribute in both sub-directories: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 52224 May 20 08:25 ippstate.doc -rw-r--r-- 1 pwg pwg 50264 May 20 08:26 ippstate.pdf -rw-r--r-- 1 pwg pwg 34760 May 20 08:26 ippstate.txt The document lists the differencs, and lists alternatives for resolving the differences. Then it lists the entire IPP or JMP specification for these attributes, as modified last week by both the IPP and JMP projects. Take a look. Thanks, Tom From hastings at cp10.es.xerox.com Tue May 20 13:23:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> RESEND: MOD - Resolving IPP/JMP job-state and Message-ID: <9705201725.AA08672@zazen.cp10.es.xerox.com> For the IPP telecon, Wed, 5/21, 1-3pm PDT (4-6 EDT). As stated in my mail yesterday, the JMP meeting assigned me the action item to put the harmonization of IPP and JMP job-state and job-state-reasons on the IPP agenda. I've replaced the 3 files with some added material: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 61952 May 20 17:04 ippstate.doc -rw-r--r-- 1 pwg pwg 70651 May 20 17:04 ippstate.pdf -rw-r--r-- 1 pwg pwg 40971 May 20 17:04 ippstate.txt and updated the date to 5/20/97. I copied in the job state transition table from the Job Monitoring MIB appendix, since an IPP issue suggests that we need such a table. Also I copied in the table that shows which job states, each job-state-reason can be used with from the Job Monitoring MIB. IPP should have such a table as well. Sorry for the repost. Thanks, Tom P.S. We are not sure of the phone number for tommorrow's IPP call, since the attached mail was only for the previous 3 calls: >Return-Path: >To: "ipp%pwg.org" >From: Don Wright >Date: Tue, 22 Apr 1997 12:13:56 PDT >Subject: IPP> ADM> Conference Call Schedule >Sender: ipp-owner@pwg.org > >I have reserved lines for the usual Wednesday conference >calls for April 23, April 30 and May 7. All the details >are the same as always but just for anyone new: > >Dial-in Number: 1-423-673-6712 >Access code: 190148 >Date: 4/23, 4/30 and 5/7 >Time: 4PM Eastern, 1PM Pacific >Duration: 2.5 hours >Participants: 20 Max > >Don > > >************************************************************* >* Don Wright (don@lexmark.com) Lexmark International * >* Manager Strategic Alliances * >* 740 New Circle Rd Phone: 606-232-4808 * >* Lexington, KY 40511 Fax: 606-232-6740 * >************************************************************* >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Tue, 20 May 1997 01:38:00 PDT >To: ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: > for Wed 5/21 IPP telecon, 1-3pm PDT (4-6pm EDT) >Sender: ipp-owner@pwg.org > >For the IPP telecon, Wed, 5/21, 1-3 pm PDT (4-6 pm EDT). > >The Job Monitoring MIB project is nearling completion and we wanted to make >sure that the JMP model of a print job covered IPP. In other words, an SNMP >agent will have to map the IPP semantics onto the JMP representation of a >job. The JMP wanted to meet with the IPP folks to resolve these differences. >Since JMP will be monitoring output devices and servers that implement >different protocols, JMP may need to be a superset of IPP, not one-to-one. >However, >an SNMP agent must be able to map the semantics of an IPP server or printer >into the JMP semantics. > >I've posted a detailed comparison of the IPP job-state and job-state-reasons >attributes with the JMP jmJobState object and the jobStateReasons1 attribute >in both sub-directories: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 52224 May 20 08:25 ippstate.doc >-rw-r--r-- 1 pwg pwg 50264 May 20 08:26 ippstate.pdf >-rw-r--r-- 1 pwg pwg 34760 May 20 08:26 ippstate.txt > >The document lists the differencs, and lists alternatives for resolving the >differences. Then it lists the entire IPP or JMP specification for these >attributes, as modified last week by both the IPP and JMP projects. > >Take a look. > >Thanks, >Tom > > > From Robert.Herriot at Eng.Sun.COM Tue May 20 15:01:49 1997 From: Robert.Herriot at Eng.Sun.COM (Robert Herriot) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: IPP> Resolving IPP/JMP job-state and job-state-reasons differences: In-Reply-To: Resolving IPP/JMP job-state and job-state-reasons differences:> Message-ID: <199705201901.MAA00044@woden.eng.sun.com> Good analysis Tom. The following is my opinion on what should change to align IPP and JobMIB. I think that IPP and the JobMIB each offer some good ideas. I would like to keep the job states very simple and make sure that they go in a simple progression with detours handled by job-state-reasons. We mostly did that in IPP, but the JobMIB did a better job at the end of the job. I suggest that the IPP (and JobMIB) state progression be: ---> completed pending -> processing - | ---> canceled Even though canceled could be handled by a job-state-reason under completed, I think that it is an important reminder that the job didn't complete for some reason, hopefully explained in the job-state-reasons. This means that there are the following job-state-reasons: o job-held during the pending state o printer-stopped during the pending or processing state o job-retained during the completed or canceled state. It also means that the follow IPP states go away: o terminating becomes canceled which has a longer duration o retained becomes a job-state-reasons job-retained I would prefer that both IPP and the JobMIB adopt these states. It requires changes for both, but I think it is a better solution than either currently offers. Bob Herriot From harryl at us.ibm.com Tue May 20 18:17:47 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> JobStateReasons - Octet or Integer Message-ID: <5030100002682493000002L032*@MHS> Tom, in v0.81, on pg. 35, jobStateReasons is defined with syntax OTECTS but the TCs which are referenced (pg. 49) are INTEGER. STATES over STATE Reasons... but that's another matter).;-). Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed May 21 00:21:31 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: JobStateReasons - Octet or Integer In-Reply-To: Message-ID: <9705210423.AA08876@zazen.cp10.es.xerox.com> Harry, When we were going to use the new RFC 19xx SMI with the BITS, jobStateReasons was going to be a single bit string (max length 128 bits). However, it seemed much simpler just to define four integers, so I made jobStateReasonsN where N=1..4. The important bits are in jobStateReasons1, so if you only need those bits, you need only implement one integer's worth of bits. But I missed changing the specification from OCTETS to INTEGER on page 35 and 36 for each of the four jobStateReasonsN attributes. I'll fix in the next version that I'm editing now. Thanks, Tom to define fourAt 15:17 05/20/97 PDT, Harry Lewis wrote: >Tom, in v0.81, on pg. 35, jobStateReasons is defined with syntax OTECTS but the >TCs which are referenced (pg. 49) are INTEGER. > >>From an embedded controller perspective we prefer INTEGER (actually we prefer >STATES over STATE Reasons... but that's another matter).;-). > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed May 21 02:11:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: IPP> Resolving IPP/JMP job-state and job-state-reasons In-Reply-To: Resolving IPP/JMP job-state and job-state-reasons> Message-ID: <9705210613.AA08928@zazen.cp10.es.xerox.com> I agree with Bob's suggestions for both IPP and the Job Monitoring MIB for simplifying the job-state and using job-state-reasons to indicate information about the state. I have a refinement concerning the job-held reason. If a job has no reasons that jobs are held in the pending state, then the job-held reason need not be implemented at all. If an implementation has only one reason that jobs are held while in the pending state, then that implemenation shall implement and return at least the job-held reason. However, if there are several reasons, then that implementation shall implement (and return) the job-held reason *in combination* with the other more specific reason(s). Then an application that doesn't understand all the reasons that jobs can be held, can at least know that the job isn't going to be scheduled if the job-held reason is present (and perhaps flag that job in some distinguishing way to its user). The additional more-specific reasons for holding a job are: IPP JMP job-incomplete becoming: job-spooling? job-sending-to-output-device job-queued-in-output-device job-hold-until-specified job-hold-until-specified required-resources-not-ready required-resource-not-ready documents-needed job-hold-set job-process-after-specified job-pre-processing job-paused job-interrupted ... I think that the IPP reasons need review, and then should be added to JMP. The JMP reasons do not need to be added to IPP though, since JMP is attempting to monitor other systems in addition to IPP. Tom At 12:01 05/20/97 PDT, Robert Herriot wrote: > >Good analysis Tom. > >The following is my opinion on what should change to align IPP and JobMIB. >I think that IPP and the JobMIB each offer some good ideas. > >I would like to keep the job states very simple and make sure that >they go in a simple progression with detours handled by job-state-reasons. >We mostly did that in IPP, but the JobMIB did a better job at the end of >the job. > >I suggest that the IPP (and JobMIB) state progression be: > > ---> completed >pending -> processing - | > ---> canceled > >Even though canceled could be handled by a job-state-reason under completed, >I think that it is an important reminder that the job didn't complete >for some reason, hopefully explained in the job-state-reasons. > >This means that there are the following job-state-reasons: > > o job-held during the pending state > o printer-stopped during the pending or processing state > o job-retained during the completed or canceled state. > >It also means that the follow IPP states go away: > > o terminating becomes canceled which has a longer duration > o retained becomes a job-state-reasons job-retained > >I would prefer that both IPP and the JobMIB adopt these states. It >requires changes for both, but I think it is a better solution than >either currently offers. > >Bob Herriot > > > > From hastings at cp10.es.xerox.com Wed May 21 10:07:24 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Resend: IPP> Resolving IPP/JMP job-state and job-state-reasons Message-ID: <9705211409.AB09004@zazen.cp10.es.xerox.com> I wasn't very clear in my previous reply to Bob (attached) about why there is a need for the generic job-held reason to indicate that the job isn't a candidate for scheduling. We only need the job-held reason, IFF there are any reasons in the pending state that are not holding up the job. In IPP, the reasons: job-sending-to-output-device and job-queued-in-output-device are reasons that the job is in the pending state, but is not being held up. So an application program that is flagging jobs to its user that are not candidates for processing (i.e., are being held), would NOT want to flag a job that was being sent to the output device or was already queued in the output device. Since IPP has a need for the generic job-held reason, so does JMP. Tom At 23:11 05/20/97 PDT, Tom Hastings wrote: >I agree with Bob's suggestions for both IPP and the Job Monitoring MIB >for simplifying the job-state and using job-state-reasons to indicate >information about the state. > >I have a refinement concerning the job-held reason. > >If a job has no reasons that jobs are held in the pending state, then >the job-held reason need not be implemented at all. > >If an implementation has only one reason that jobs are held while in the >pending state, then that implemenation shall implement and return at least >the job-held reason. However, if there are several reasons, then that >implementation shall implement (and return) the job-held reason >*in combination* with the other more specific reason(s). Then an application >that doesn't understand all the reasons that jobs can be held, can at least >know that the job isn't going to be scheduled if the job-held reason is >present (and perhaps flag that job in some distinguishing way to its user). > >The additional more-specific reasons for holding a job are: > > IPP JMP >job-incomplete becoming: job-spooling? >job-sending-to-output-device >job-queued-in-output-device >job-hold-until-specified job-hold-until-specified >required-resources-not-ready required-resource-not-ready > documents-needed > job-hold-set > job-process-after-specified > job-pre-processing > job-paused > job-interrupted > ... > >I think that the IPP reasons need review, and then should be added to JMP. >The JMP reasons do not need to be added to IPP though, since JMP is attempting >to monitor other systems in addition to IPP. > >Tom > > >At 12:01 05/20/97 PDT, Robert Herriot wrote: >> >>Good analysis Tom. >> >>The following is my opinion on what should change to align IPP and JobMIB. >>I think that IPP and the JobMIB each offer some good ideas. >> >>I would like to keep the job states very simple and make sure that >>they go in a simple progression with detours handled by job-state-reasons. >>We mostly did that in IPP, but the JobMIB did a better job at the end of >>the job. >> >>I suggest that the IPP (and JobMIB) state progression be: >> >> ---> completed >>pending -> processing - | >> ---> canceled >> >>Even though canceled could be handled by a job-state-reason under completed, >>I think that it is an important reminder that the job didn't complete >>for some reason, hopefully explained in the job-state-reasons. >> >>This means that there are the following job-state-reasons: >> >> o job-held during the pending state >> o printer-stopped during the pending or processing state >> o job-retained during the completed or canceled state. >> >>It also means that the follow IPP states go away: >> >> o terminating becomes canceled which has a longer duration >> o retained becomes a job-state-reasons job-retained >> >>I would prefer that both IPP and the JobMIB adopt these states. It >>requires changes for both, but I think it is a better solution than >>either currently offers. >> >>Bob Herriot >> >> >> >> > > > From hastings at cp10.es.xerox.com Wed May 21 10:29:32 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> MOD - simplified legal state transition diagram Message-ID: <9705211431.AA09037@zazen.cp10.es.xerox.com> So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From Angelo_Caruso at wb.xerox.com Wed May 21 15:48:07 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:05 2009 Subject: JMP> MOD - simplified legal state transition diagram Message-ID: <9705211431.AA09037@zazen.cp10.es.xerox.com> Tom, To test my understanding: you are suggesting that the 'retained' sate be removed from IPP, the 'terminating' state in IPP be renamed 'canceled', and the 'needsAttention' state ne removed from the Job MIB. Correct? Note, this will have the side effect of requiring that the jobStateReasons1 attribute in the Job MIB become mandatory (for sake of the 'printer-stopped' bit). The original motivation for the 'needsAttention' state was that a job monitoring application could quickly determine that the device needs operator intervention without having to poll the job state reasons. Even so, I am in favor of making the change in order for the IPP and JMP job state models to be as identical as possible. I just want to make sure everyone is aware of the trade off being made here. If this change is agreed to, then should we move the newly-mandatory jobStateReasons1 attribute to the job table? Thanks, Angelo ---------- From: jmp-owner@pwg.org To: ipp@pwg.org; jmp@pwg.org Subject: JMP> MOD - simplified legal state transition diagram Date: Wednesday, May 21, 1997 12:00AM So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From bwagner at digprod.com Wed May 21 17:02:30 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: IPP> MOD - simplified legal state transition diagram In-Reply-To: MOD - simplified legal state transition diagram> Message-ID: <9705211431.AA09037@zazen.cp10.es.xerox.com> I apologize if I missed a step or two in this exchange. Of course, I agree with the objective and believe the states listed are adequate. However, the 'unknown' state, within general MIB use at least, has been more a reflection on the state of the equipment than the job. That is, the state of a job is unknown because of some sensing difficulty or sequence difficulty with the equipment, not because it is a normal state in the sequence of handling a job. It would be quite possible for a unit to report no state other than unknown. It seems it would also be possible for a unit to recognize a state after it has previously been unknown. For example, if a job can be identified, it can be canceled and the state is then likely to be canceled and not unknown. In short, I suggest that unknown is a wild card rather than a job state that exists before pending and processing and after canceled and completed. If something is necessary for the pre-pending and post complete states, what about Other? Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> MOD - simplified legal state transition diagram Author: Tom Hastings at Internet Date: 5/21/97 7:29 AM So the simplified legal state transition diagram for IPP and JMP would become, following Bob's proposal: New state Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) unknown(2) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes completed(6) yes A blank entry indicates impossible transitions. Self loops are not indicated, such as a Get-Attributes operation on a job, since they aren't a job state transition. For IPP we need to consider which job states and job state transtions are required for conformance and which are optional. JMP requires that processing(4), canceled(5), and completed(6) are mandatory, so that pending(3) is optional. What about unknown(2)? The former needsAttention state was also mandatory, so that the new job-state reason: printer-stopped, should become a mandator job state reason, correct? For IPP and JMP, all transitions into the canceled state should be required. However, the transition from processing back to pending (a job-held situation) is optional. From hastings at cp10.es.xerox.com Thu May 22 02:43:25 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Changes agreed to for Job Monitoring MIB last week, 5/16/97 Message-ID: <9705220645.AA09448@zazen.cp10.es.xerox.com> I've posted the changes that I'm making to the Job Monitoring MIB that we agreed to last week in San Diego: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 22016 May 22 06:23 iss-list.doc -rw-r--r-- 1 pwg pwg 19414 May 22 06:23 iss-list.pdf -rw-r--r-- 1 pwg pwg 12629 May 22 06:24 iss-list.txt We had a good meeting today resolving the job-state and job-state-reasons differences with IPP, but not too many JMP people were present. So I'll send out those changes separately to see if there is any problems with them. I've also attached the iss-list.txt. NOTE: the .txt file does not have revision marks, that the .doc and .pdf file have. For the .txt file, the revisions have been accepted. Tom Subj: Synopsis of Issue Resolution at the JMP Meeting, 5/16/97 From: Tom Hastings Date: 5/16/97 File: iss-list.doc Summary of the major decisions: 1. No duplication between attributes and objects. 2. Any attributes that are mandatory will be in the Job Status table (renamed back to Job table), except the mandatory jobOwner attribute, which is a string and will remain as a mandatory attribute in the Attribute table. The Attribute table has a shorter lifetime than the Job table. Also the jobOwner is a STATIC attribute, so that a monitoring application is unlikely to need to get it on each poll cycle, only the first. However, the value of keeping jmJobTable entries without the jobOwner only works for systems that have the jmJobSubmissionID that is known to the client. The 7 mandatory objects in the jmJobTable are: jmJobState jmJobKOctetsRequested jmJobKOctetsProcessed (by the interpreter) [name change from xxxCompleted] jmJobImpressionsRequested jmJobImpressionsCompleted (stacked) jmJobSheetsCompleted (stacked) jmNumberOfInterveningJobs The mandatory attributes are: jobOwner (63 octet string) The deviceAlertCode and outputBinIndex attributes will remain in the jmAttributeTable and will NOT be mandatory attributes. 3. The multiplexed object/attribute jmJobStateAssociatedValue/jobStateAssociatedValue has been deleted from both tables. 4. Any attribute that is implemented shall be instantiated when the job is instantiated. The agent shall not add attributes as the job is processed. If the agent doesn't know the value at submit time, the agent shall fill in the "unknown" value. This allows a management app that has once discovered what attributes are implemented by an agent to request multiple attributes in a single PDU and not have one of them bomb out because the agent had not yet put it in the table. 5. We reviewed the comparison with IPP (ipp-jmp.doc) and made the following decisions: a. Don't add "number-up" as an attribute - number up usage can be better determined from comparing the conditionally mandatory jobPagesCompleted attribute with the jmImpressionsCompleted object. b. Add "printer-resolution" with keyword/enum values from IPP which are: normal, 'res-100', 'res-200', 'res-240', 'res-300', 'res-600', 'res-800', 'res-1200', 'res-1800', 'res-100x200', 'res-300x600', 'res-600x300', 'res-400x800', 'res-800x400', 'res-600x1200', 'res-1200x600', and 'res-1800x600'. c. Add "job-originating-host" from IPP with the same meaning that it is only the end-user host, not an intermediate server host. d. We did not agree to add the IPP job-state-message, though the JMP processingMessage(11) is pretty similar. e. The remaining issue is that the jmJobState object and the jobStateReason1 attribute don't align with IPP's job-state and job-state-reasons attributes. In JMP, jmJobState object is mandatory, but the jobStateReasons1 attribute is conditionally mandatory, while in IPP, both the job-state and the job-state-reasons attributes are mandatory. JMP jmJobState object values are: other, unknown, held, pending, processing, [printing was dropped to agree with IPP], needsAttention, canceled, and completed. IPP job-state attribute valeus are: unknown, pending, processing, terminating, retained, completed. IPP represents the 'held' state with various "job-state-reasons" attribute values while the job is in the 'pending' state. IPP represents the 'needsAttention' state with the "job-state-reasons"='printer-stopped attribute' IPP 'terminating' is like JMP 'canceled's states, except that IPP 'terminating' transitions into 'retained' then 'completed', while JMP 'canceled' is a final state, as is the 'completed' state. JMP represents IPP's 'retained' state using the "jobStateReasons"='jobRetained' attribute. We decided to put this issue on the IPP agenda for this coming Wednesday, 1-3pm PDT. ********************************************************************* Since most of the JMP participants were not present at the Wed IPP call, I'll send out those agreements separately for approval of the JMP participants. ********************************************************************* 6. We made a few changes to the paper entitled: "Property Table of JMP attributes" (attr-tab.doc). Then we agreed that it would be kept a separate document and referred to from the web page and the FAQ. ACTION ITEM (Tom): Update and re-post. Get web page to cite. 7. Here are the resolutions to the specific issues. Issues with ???? were not covered and are still issues. If you want more description of the issue, see the issues.doc and issues.pdf file in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ Issue 61 - Need to clarify the semantics of each object and attribute with respect to Configuration 1, 2, and 3. ???? ISSUE 67 - Delete the three objects in the Job State table that duplicate attributes? jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, and jmJobStateAssociatedValue? Closed: Delete the duplicates from the Attributes Table instead. ISSUE 68 - Delete the Job State Group/Table all together, since all objects are also duplicated as attributes? Closed: No, the Job State Table is useful to scan for jobs using Get Next and select the desired columns. ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any difference? Closed: No, can't use Get Next to step through jobs. The requester can specify which attributes using Get, since the agent is now required to materialize each supported attribute when the job is accepted. So the application can supply a number of Gets in a single PDU without fear of a error, once the application has learned which attributes the agent implements. ISSUE 70 - Add some simple general device alert TC, instead of using the Printer MIB Alert Codes. Closed: No, use the alert codes. ISSUE 71 - Are there any attributes that need to be clarified as to which apply to servers and which apply to devices and which apply to either? ???? ISSUE 72 - What should happen to jmGeneralNewestActiveJobIndex when all the active jobs complete? Closed: the agent shall reset it to 0 and keep an internal variable for the next row to assign. That internal variable shall be persistent across power cycles. Also the agent shall find the next newest active job, when the newest is canceled or completes and there are still active jobs in the tables. ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? Closed: Yes, and allow agents to implement one, the other, or both values. Making it easy for an agent to do both will make such an application that doesn't want to depend on the Printer MIB being implemented, i.e., the application wants to work with all three configurations. ISSUE 75 - Should the Attribute enum values be grouped so additions could be added in the appropriate section? Closed: Yes. Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or queueNameRequested be made Mandatory? Closed: Only jobOwner is made manadatory, but it will remain in the Attribute table, rather than being moved to the Job table. Issue 77 - Should jobCompletedDateAndTime/TimeStamp be canceled time too, or add jobCanceledDateAndTime/TimeStamp? ???? Issue 78 - Should the "multiplexor" jobStateAssociatedValue(4) attribute be removed from the Job Attribute Table and the equivalent jmJobStateAssociatedValue object be removed from the Job State table? Closed: Yes. The application can request each object and/or attribute directly and it will fit into a single PDU (20 objects or attributes). Now that attributes are required to be instantiated as the same time as the job is received, whether the value is known then or not, avoids the problem that a PDU with multiple gets would get aborted because the agent hadn't instantiated the attribute in the table. Issue 79 - Should the 'printing' state be combined into the 'processing' state, like IPP? Closed: Yes, but the other differences between JMP and IPP need discussion with IPP. Issue 80 - How handle IPP "sides" attribute which has 3 enum values? Closed: Don't inculde the IPP values; the agent can map them to 1 or 2. Issue 81 - Add IPP "numberUp" attribute? Closed: No. Can get whether number up is being used by comparing the conditionally mandatory jobPagesCompleted attribute with the jmImpressionsCompleted object. ISSUE 82 - Change the OID assignment as Jeff Case suggests so no holes? Closed: Yes, including reserving an OID for traps, in case we need them in the future. ISSUE 83 - Can some attributes be deleted before the jmGeneralAttributePersistence expires? Closed: No. All attributes shall be instantiated at the same time and deleted at the same time. Then applications can requrest any number of objects and attributes in a single PDU and not get an error back on one that has been implemented but hasn't been put in the table. The values may change at any time. ISSUE 84 - Change Associated Value for 'printing' state to impressionsCompletedCurrentCopy(56)? Closed: Since the AssociatedValue object/attribute is being deleted, this issue is moot. ISSUE 85 - Break the MIB into a monitoring and an accounting MIB? Closed: No. There are too many attributes that are used for both monitoring and accounting. ISSUE 86 - Clarify jobCopiesRequrested(44) vs. documentCopiesRequested(46) Closed: Use jobCopiesRequested for single document jobs for both systems that support only one documen t per job and ones that support mujltiple documents. Only use documentCopiesRequested, when a multiple document job actually specifies that individual documents are to be made copies. 2. Closed Issues - not yet reflected in the current draft The following issues have been closed and have been incorporated into the Internet Draft 00 and version 0.71 or earlier: Issue 12 - What is the SNMPv1 and SNMPv2 error that an agent shall return if there is no instrumentation for an object? Closed: There is no such SNMP error. ALL uninstrumented objects in mandatory groups of any MIB should always correctly return 'read-only' static values specified in 'DEFVAL' clauses. 'DEFVAL' is a perfectly good SMIv2 feature intended to cover this situation. Returning ANY SNMP error for ANY object in a mandatory group with a legal instance qualifier (i.e., set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol spec (RFC 1905, page 10, in 'Get-Request PDU' handling). That's what 'shall implement ALL the objects in this group' means! So add DEFVAL clauses to all objects. Issue 64 - Need to fill out Appendix A on mapping from the job submission protocols to the Job Monitoring MIB for each of the three configurations. Closed: Put into a separate document. ACTION ITEM (all): Write up your job submission protocol mapping to the Job Monitoring MIB. Issue 65 - What Appendices should remain, which should be separate Internet Drafts and/or informational RFCs and which should disappear? Closed: No appendices for the Job Monitoring MIB, except for supplemental information about the semantics of job states. Put any other information into a separate informational RFC, such as mapping to ISO DPA, mapping to IPP, mapping to other job submission protocols, etc. Issue 73 - Is there a problem with outputBinIndex being made mandatory? If outputBinIndex is made mandatory, but an implementation doesn't have the Printer MIB, the agent has to put 0 as the value. Should we add one more attribute: outputBinNumber, which is just a number, not an index into the Printer MIB? If we do, which should be mandatory? Just one more reason to get rid of the jmStateTable, which is forcing us to pick a particular outputBin implementation and make it mandatory. If we got rid of the JobState table, we could forget about making any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute mandatory. Closed: Don't add outputBinNumber. Also keep outputBinIndex as a MULTI-ROW attribute, so don't need to add multi(-3) enum value. From hastings at cp10.es.xerox.com Thu May 22 02:46:52 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> RFC 2119, March 1997 has conformance language spec Message-ID: <9705220649.AA09453@zazen.cp10.es.xerox.com> Thanks Larry, Tom >Return-Path: >Date: Wed, 21 May 1997 23:08:45 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Subject: Re: IPP> MOD - 5/14 mintues >References: <9705220435.AB09386@zazen.cp10.es.xerox.com> > >RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >-- > >Larry >-- >http://www.parc.xerox.com/masinter > > From hastings at cp10.es.xerox.com Thu May 22 03:31:11 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: RFC 2119, March 1997 has conformance language spec In-Reply-To: Message-ID: <9705220733.AA09489@zazen.cp10.es.xerox.com> I just read the RFC and it defines the following terms and suggests that the following phrase be put early in the document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Happily, the "shall", "should", and "may" terms are as the PWG has been using in its Printer MIB, Job Monitoring MIB, and IPP documents. It also has "must" as a synonym for "shall". I suggest that we continue to use "shall", rather than switching over or using a mixture, in order to keep our PWG standards using the same terminology. Ok? It also says: "These words are often capitalized." I've sent mail to Scott Bradner asking whether it is recommended to capitalize. Seems like it would make these terms stand out more. Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring MIB? What about IPP documents? Thanks, Tom At 23:46 05/21/97 PDT, Tom Hastings wrote: >Thanks Larry, > >Tom > >>Return-Path: >>Date: Wed, 21 May 1997 23:08:45 PDT >>From: Larry Masinter >>Organization: Xerox PARC >>To: Tom Hastings >>Subject: Re: IPP> MOD - 5/14 mintues >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> >> >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >>-- >> >>Larry >>-- >>http://www.parc.xerox.com/masinter >> >> > > > From rbergma at dpc.com Thu May 22 09:52:02 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: RFC 2119, March 1997 has conformance language spec In-Reply-To: <9705220733.AA09489@zazen.cp10.es.xerox.com> Message-ID: <9705220733.AA09489@zazen.cp10.es.xerox.com> Tom, I would recommend that these terms be capitalized only if absolutely required or if strongly recommended by Scott Bradner. Otherwise, lets leave well-enough alone. Ron Bergman On Thu, 22 May 1997, Tom Hastings wrote: > I just read the RFC and it defines the following terms and suggests that > the following phrase be put early in the document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119. > > Happily, the "shall", "should", and "may" terms are as the PWG has been using > in its Printer MIB, Job Monitoring MIB, and IPP documents. > > It also has "must" as a synonym for "shall". I suggest that we continue > to use "shall", rather than switching over or using a mixture, in order > to keep our PWG standards using the same terminology. Ok? > > It also says: "These words are often capitalized." > I've sent mail to Scott Bradner asking whether it is recommended to > capitalize. Seems like it would make these terms stand out more. > > Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring > MIB? What about IPP documents? > > Thanks, > Tom > > At 23:46 05/21/97 PDT, Tom Hastings wrote: > >Thanks Larry, > > > >Tom > > > >>Return-Path: > >>Date: Wed, 21 May 1997 23:08:45 PDT > >>From: Larry Masinter > >>Organization: Xerox PARC > >>To: Tom Hastings > >>Subject: Re: IPP> MOD - 5/14 mintues > >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> > >> > >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. > >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) > >>-- > >> > >>Larry > >>-- > >>http://www.parc.xerox.com/masinter > >> > >> > > > > > > > > From rbergma at dpc.com Thu May 22 09:57:44 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable In-Reply-To: <9705192235.AA08452@zazen.cp10.es.xerox.com> Message-ID: <9705220733.AA09489@zazen.cp10.es.xerox.com> Tom, I have no objection to the addition of the two attributes. Ron Bergman On Mon, 19 May 1997, Tom Hastings wrote: > In going over my notes, I see that we didn't process the last part of paper > number 9 at the 5/16 JMP meeting. > > Does any one have a problem if I add the following two attributes > to the Attribute table [with the suffix "Completed" added] as: > > From Paper number 9: > > Lastly, I would like to request two new attribute be added for > accounting purposes with color capable devices. Color devices > typically cannot measure the exact amount of colorant consumed per > job, but can easily measure the number of color impressions. This is > important for accurate accounting since color impressions cost more > than black impressions with most current marking technologies. I have > included the ASN.1 here for your convenience: > > fullColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of full color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Full color impressions are > -- typically defined as those requiring 3 or more colorants, > -- but this may vary by implementation. > > highlightColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of highlight color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Highlight color impressions are > -- typically defined as those requiring black plus one other > -- colorant, but this may vary by implementation. > From harryl at us.ibm.com Thu May 22 11:28:27 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> JMP May Minutes Message-ID: <5030100002742662000002L022*@MHS> I have posted minutes from the San Diego meeting. You can find them at ftp.pwg.org/pub/pwg/jmp/Minutes/jmp-0597.txt and .pdf. Harry Lewis - IBM Printing Systems From jkm at underscore.com Thu May 22 12:07:26 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Changes agreed to for Job Monitoring MIB last week, 5/16/97 In-Reply-To: Changes agreed to for Job Monitoring MIB last week, 5/16/97> Message-ID: <199705221607.MAA00472@uscore.underscore.com> Tom, Thanks for posting the summary. A couple of quick comments: > The mandatory attributes are: > > jobOwner (63 octet string) Is this the _only_ mandatory attribute? I thought there were a couple more (although I don't remember which ones). Or are you saying here that jobOwner is now added to the mandatory list? More on the issue of "jobOwner as an attribute vs. an object" later in this message... > In JMP, jmJobState object is mandatory, but the jobStateReasons1 > attribute is conditionally mandatory, while in IPP, both the job-state > and the job-state-reasons attributes are mandatory. You know, not mandating a "reason" string with the job state doesn't feel good, given that the state may not really say what's going on with the job. This topic was touched on during yesterday's IPP telecon in which we talked about job attributes wrt IPP vs. JMP definitions. We might want to mandate jobStateReasons1, and not let it fall into the "conditionally mandatory" void, since it supports the #1 target requirement for "tell me what my job is doing". Comments on this? > IPP 'terminating' is like JMP 'canceled's states, except that IPP > 'terminating' transitions into 'retained' then 'completed', while JMP > 'canceled' is a final state, as is the 'completed' state. Tom, as you know, I had to leave the IPP telecon early yesterday. I don't recall the discussion about a job going into a "retained" state, then transitioning to "completed" for IPP. Was this discussed and decided after I left the telecon? If so, can you describe what this is all about? (That is, I don't understand the value of having a short- term "retained" state.) > JMP represents IPP's 'retained' state using the > "jobStateReasons"='jobRetained' attribute. > > We decided to put this issue on the IPP agenda for this coming Wednesday, > 1-3pm PDT. This is good. We really, really must strive to align IPP and JMP to the maximum possible extent. > Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or > queueNameRequested be made Mandatory? > Closed: Only jobOwner is made manadatory, but it will remain in the > Attribute table, rather than being moved to the Job table. Hmmm... Is this really what we agreed to? I submitted that jobOwner should be a fundamental part of job identification (and gave lots of examples of existing systems where this value is the only meaningful identification item across multiple types of spooling systems). By making jobOwner an "attribute", there is a serious risk of losing this information when the agent "ages out" attribute information. (The reader should recall that "attributes" are designed primarily for accounting purposes, and these values are able to be removed from the agent's store in a faster manner than the jobState values.) I worry that an agent will age-out the jobOwner too soon, thereby making it impossible to identify jobs for a target user. Can we please discuss this issue on the list asap? > Issue 77 - Should jobCompletedDateAndTime/TimeStamp be canceled time too, or > add jobCanceledDateAndTime/TimeStamp? > ???? We didn't get to this issue, right? In any case, why would we need a date/timestamp for Cancel? I suggest that we just leave the Completed time intact for both situations. > Issue 64 - Need to fill out Appendix A on mapping from the job submission > protocols to the Job Monitoring MIB for each of the three configurations. > > Closed: Put into a separate document. > ACTION ITEM (all): Write up your job submission protocol mapping to the Job > Monitoring MIB. Do we have specific personnel assignments for these mapping documents? ...jay From jkm at underscore.com Thu May 22 12:17:20 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Message-ID: <199705221617.MAA00538@uscore.underscore.com> I agree with Ron that Tom's two proposed attributes should be included in the Job MIB. Any serious objections from anyone? If so, please speak up, as we are really getting down to the wire on this draft. ...jay ----- Begin Included Message ----- Date: Thu, 22 May 1997 06:57:44 -0700 (PDT) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable X-X-Sender: rbergma@it.dpc.com Tom, I have no objection to the addition of the two attributes. Ron Bergman On Mon, 19 May 1997, Tom Hastings wrote: > In going over my notes, I see that we didn't process the last part of paper > number 9 at the 5/16 JMP meeting. > > Does any one have a problem if I add the following two attributes > to the Attribute table [with the suffix "Completed" added] as: > > From Paper number 9: > > Lastly, I would like to request two new attribute be added for > accounting purposes with color capable devices. Color devices > typically cannot measure the exact amount of colorant consumed per > job, but can easily measure the number of color impressions. This is > important for accurate accounting since color impressions cost more > than black impressions with most current marking technologies. I have > included the ASN.1 here for your convenience: > > fullColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of full color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Full color impressions are > -- typically defined as those requiring 3 or more colorants, > -- but this may vary by implementation. > > highlightColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of highlight color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Highlight color impressions are > -- typically defined as those requiring black plus one other > -- colorant, but this may vary by implementation. > ----- End Included Message ----- From harryl at us.ibm.com Thu May 22 16:55:47 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTa Message-ID: <5030100002756886000002L062*@MHS> I have no problem with adding Tom's proposed color printing attributes. Harry Lewis - IBM Printing Systems ----- Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 02:50 PM ------- jmp-owner@pwg.org 05/22/97 12:08 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTa I agree with Ron that Tom's two proposed attributes should be included in the Job MIB. Any serious objections from anyone? If so, please speak up, as we are really getting down to the wire on this draft. ...jay ----- Begin Included Message ----- Date: Thu, 22 May 1997 06:57:44 -0700 (PDT) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable X-X-Sender: rbergma@it.dpc.com Tom, I have no objection to the addition of the two attributes. Ron Bergman On Mon, 19 May 1997, Tom Hastings wrote: > In going over my notes, I see that we didn't process the last part of paper > number 9 at the 5/16 JMP meeting. > > Does any one have a problem if I add the following two attributes > to the Attribute table [with the suffix "Completed" added] as: > > From Paper number 9: > > Lastly, I would like to request two new attribute be added for > accounting purposes with color capable devices. Color devices > typically cannot measure the exact amount of colorant consumed per > job, but can easily measure the number of color impressions. This is > important for accurate accounting since color impressions cost more > than black impressions with most current marking technologies. I have > included the ASN.1 here for your convenience: > > fullColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of full color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Full color impressions are > -- typically defined as those requiring 3 or more colorants, > -- but this may vary by implementation. > > highlightColorImpressionsCompleted(??), -- Integer32(-2..2147483647) > -- INTEGER: The total number of highlight color impressions > -- completed by the device for this job so far. For printing, the > -- impressions completed includes interpreting, marking, and > -- stacking the output. For other types of job services, > -- the number of impressions completed includes the number > -- of impressions processed. Highlight color impressions are > -- typically defined as those requiring black plus one other > -- colorant, but this may vary by implementation. > ----- End Included Message ----- From harryl at us.ibm.com Thu May 22 17:44:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Changes agreed to for Job Monitoring MIB last week, In-Reply-To: Changes agreed to for Job Monitoring MIB last week,> Message-ID: <5030100002758793000002L032*@MHS> Somehow, I've received Jay's reply prior to Tom's summary... but I will try to address some of the questions raised by Jay. >> In JMP, jmJobState object is mandatory, but the jobStateReasons1 >> attribute is conditionally mandatory, while in IPP, both the job-state >> and the job-state-reasons attributes are mandatory. >You know, not mandating a "reason" string with the job state doesn't >feel good, given that the state may not really say what's going on >with the job. This topic was touched on during yesterday's IPP telecon >in which we talked about job attributes wrt IPP vs. JMP definitions. >We might want to mandate jobStateReasons1, and not let it fall into >the "conditionally mandatory" void, since it supports the #1 target >requirement for "tell me what my job is doing". >Comments on this? Yes, "Tell me what my job is doing", but please, just tell me what I want to know in a simple form that I can understand! Not 93 possible reasons for 7 possible states in 4 seemingly arbitrary categories! PENDING, PRINTING, CANCELED, COMPLETE. Obscure PRINTING by calling it PROCESSING and throw in HELD and NEEDS ATTENTION (with alert code) for good measure - isn't this enough? Jay, have you looked at the 7.5 page list of Job State Reasons in the Job MIB? I'm behind on mail so maybe this has all been changed but... given the current state, of the specification, I prefer to keep the reasons OPTIONAL! >> Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or >> queueNameRequested be made Mandatory? >> Closed: Only jobOwner is made mandatory, but it will remain in the >> Attribute table, rather than being moved to the Job table. >Hmmm... Is this really what we agreed to? I submitted that jobOwner >should be a fundamental part of job identification (and gave lots of >examples of existing systems where this value is the only meaningful >identification item across multiple types of spooling systems). >By making jobOwner an "attribute", there is a serious risk of losing >this information when the agent "ages out" attribute information. >(The reader should recall that "attributes" are designed primarily >for accounting purposes, and these values are able to be removed from >the agent's store in a faster manner than the jobState values.) >I worry that an agent will age-out the jobOwner too soon, thereby >making it impossible to identify jobs for a target user. >Can we please discuss this issue on the list asap? Yes, we realized after Dave and Jay had left the meeting, that the size of jmJobOwner blows away the notion of keeping the Job Table terse. In the minutes, which I posted this morning, I took the liberty to address this a bit. One, rather simple approach, if Job Owner really is a "meaningful id across multiple types of spooling systems", is to truncate it to 30 bytes and register it as one of the jmJobSubmissionID formats. I'm not sure how the format ID would get tacked on, however, but this can probably be worked out (have the NIC build it from the LPR control file?). An excerpt from my minutes asks: If the design point is to facilitate a job state notification broker that lives outside of the submission framework and correlates users (notification recipients) with print jobs strictly based on identification provided via LPR, we need to have this stated. Is this what we are worried about? There seem to be only two other major scenarios. If the job Monitor is involved with submission (as in an NT Port Driver for example), there is a place to couple submission and monitoring via jmJobSubmissionID. If the monitor is fundamentally an accounting application, then leaving jmJobOwner in the Attribute table should not be a problem. I guess we do loose the ability to guarantee showing the owners name in a simple overall queue view but this problem can be minimized by "fetching" the jmJobOwner from the Attribute table for Pending jobs and storing this association in the job Monitor application until the application is no longer concerned with the job. This assumes the owner's name is static, which will be the practical case. I think, if this is still an issue, we need to get more examples on the table. I had proposed some additional alleviates in my complete set of minutes. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Thu May 22 18:09:05 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: RFC 2119, March 1997 has conformance language s In-Reply-To: Re: RFC 2119, March 1997 has conformance language s> Message-ID: <5030100002760729000002L092*@MHS> In my opinion, it doesn't matter if these words are capitalize or not. I recommend against their use entirely. The very fact that these words need an RFC to define them indicates, to me, that they are too vague for use in a specification. As an example: Rather than say "... the Job Submission Attributes SHALL overide the PDL job attributes" it would be more concise to say "... the Job Submission Attributes overide the PDL job attributes". But, alas, I'm probably dabbling in IETF or Standards heresy, here, so ... on to other mail messages. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 03:43 PM ------ jmp-owner@pwg.org 05/22/97 10:27 AM Please respond to jmp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet cc: jmp@pwg.org @ internet Subject: Re: JMP> Re: RFC 2119, March 1997 has conformance language s Tom, I would recommend that these terms be capitalized only if absolutely required or if strongly recommended by Scott Bradner. Otherwise, lets leave well-enough alone. Ron Bergman On Thu, 22 May 1997, Tom Hastings wrote: > I just read the RFC and it defines the following terms and suggests that > the following phrase be put early in the document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119. > > Happily, the "shall", "should", and "may" terms are as the PWG has been using > in its Printer MIB, Job Monitoring MIB, and IPP documents. > > It also has "must" as a synonym for "shall". I suggest that we continue > to use "shall", rather than switching over or using a mixture, in order > to keep our PWG standards using the same terminology. Ok? > > It also says: "These words are often capitalized." > I've sent mail to Scott Bradner asking whether it is recommended to > capitalize. Seems like it would make these terms stand out more. > > Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring > MIB? What about IPP documents? > > Thanks, > Tom > > At 23:46 05/21/97 PDT, Tom Hastings wrote: > >Thanks Larry, > > > >Tom > > > >>Return-Path: > >>Date: Wed, 21 May 1997 23:08:45 PDT > >>From: Larry Masinter > >>Organization: Xerox PARC > >>To: Tom Hastings > >>Subject: Re: IPP> MOD - 5/14 mintues > >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> > >> > >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. > >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) > >>-- > >> > >>Larry > >>-- > >>http://www.parc.xerox.com/masinter > >> > >> > > > > > > > > From jkm at underscore.com Thu May 22 18:37:02 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Should jobStateReasons1 be mandatory? Message-ID: <199705222237.SAA04308@uscore.underscore.com> [I have changed the Subject line to better reflect the topic] Harry, Maybe I'm reading your response wrong, but your comments make it sound as if we have an excessively complex design for job state and the associated reason(s): > >You know, not mandating a "reason" string with the job state doesn't > >feel good, given that the state may not really say what's going on > >with the job. This topic was touched on during yesterday's IPP telecon > >in which we talked about job attributes wrt IPP vs. JMP definitions. > > >We might want to mandate jobStateReasons1, and not let it fall into > >the "conditionally mandatory" void, since it supports the #1 target > >requirement for "tell me what my job is doing". > > >Comments on this? > > Yes, "Tell me what my job is doing", but please, just tell me what > I want to know in a simple form that I can understand! Not 93 > possible reasons for 7 possible states in 4 seemingly arbitrary > categories! PENDING, PRINTING, CANCELED, COMPLETE. Obscure PRINTING > by calling it PROCESSING and throw in HELD and NEEDS ATTENTION (with > alert code) for good measure - isn't this enough? Jay, have you looked > at the 7.5 page list of Job State Reasons in the Job MIB? I'm behind > on mail so maybe this has all been changed but... given the current state, > of the specification, I prefer to keep the reasons OPTIONAL! Your comments lead me to believe you're saying that it's too damn difficult for the printer agent to say what the current "reason" is. Is this true? If it is, then I think we're in real deep water here... I just went thru the V0.81 draft, but couldn't find 7.5 pages of Job State Reasons in the MIB. Can you give me a better pointer? (Am I looking at the proper draft?) I did find some tables on various Reasons (pp. 57-58), but I guess I don't see the problem. Have pity on this poor fool and point me in the right direction... ;-) I do agree with you, though, that PROCESSING is bogus, and that PRINTING should have been the state we kept (and discard PROCESSING instead). which will be the practical case. ...jay From jkm at underscore.com Thu May 22 18:49:59 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Changes agreed to for Job Monitoring MIB last week, In-Reply-To: Changes agreed to for Job Monitoring MIB last week,> Message-ID: <199705222249.SAA04466@uscore.underscore.com> [I have changed the Subject line to better reflect the topic] Harry, This statement has me somewhat bothered regarding which master we are trying to serve with the Job MIB in general: > Yes, we realized after Dave and Jay had left the meeting, that the size > of jmJobOwner blows away the notion of keeping the Job Table terse. What do you want? Good grammer or good taste?... ;-} Seriously, some of us firmly believe in the importance of "out of band" job monitors (ie, processes monitoring job progression without being intrinsically part of the printing process, a la Unix and VMS). The only consistent way to indentify jobs is through jobOwner, and hence, this data must be available for as long as the job entry exists in the agent. Those who will be using the Job MIB as an intrinsic part of the printing process are lucky (eg, Windows, OS/2, etc). (We envy you, believe us!) If someone can state a justifiable case for being able to monitor jobs with jobOwner, then great! (And please do so soon!) Otherwise, we need that data for the duration of the job entry. ...jay ------------------------------------------------------------------------------ > >> Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or > >> queueNameRequested be made Mandatory? > >> Closed: Only jobOwner is made mandatory, but it will remain in the > >> Attribute table, rather than being moved to the Job table. > > >Hmmm... Is this really what we agreed to? I submitted that jobOwner > >should be a fundamental part of job identification (and gave lots of > >examples of existing systems where this value is the only meaningful > >identification item across multiple types of spooling systems). > > >By making jobOwner an "attribute", there is a serious risk of losing > >this information when the agent "ages out" attribute information. > >(The reader should recall that "attributes" are designed primarily > >for accounting purposes, and these values are able to be removed from > >the agent's store in a faster manner than the jobState values.) > > >I worry that an agent will age-out the jobOwner too soon, thereby > >making it impossible to identify jobs for a target user. > > >Can we please discuss this issue on the list asap? > > Yes, we realized after Dave and Jay had left the meeting, that the size > of jmJobOwner blows away the notion of keeping the Job Table terse. > In the minutes, which I posted this morning, I took the liberty to > address this a bit. One, rather simple approach, if Job Owner really > is a "meaningful id across multiple types of spooling systems", is to > truncate it to 30 bytes and register it as one of the jmJobSubmissionID > formats. I'm not sure how the format ID would get tacked on, however, > but this can probably be worked out (have the NIC build it from the LPR > control file?). > > An excerpt from my minutes asks: > > If the design point is to facilitate a job state notification broker that lives > outside of the submission > framework and correlates users (notification recipients) with print jobs > strictly based on identification > provided via LPR, we need to have this stated. > > Is this what we are worried about? There seem to be only two other > major scenarios. If the job Monitor is involved with submission (as in an > NT Port Driver for example), there is a place to couple submission and > monitoring via jmJobSubmissionID. If the monitor is fundamentally an > accounting application, then leaving jmJobOwner in the Attribute table > should not be a problem. > > I guess we do loose the ability to guarantee showing the owners name in > a simple overall queue view but this problem can be minimized by "fetching" > the jmJobOwner from the Attribute table for Pending jobs and storing this > association in the job Monitor application until the application is no > longer concerned with the job. This assumes the owner's name is static, > which will be the practical case. > > I think, if this is still an issue, we need to get more examples on the > table. I had proposed some additional alleviates in my complete set of > minutes. > > Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Thu May 22 19:28:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Instantiation Message-ID: <5030100002766165000002L052*@MHS> I would like to clarify something I think we agreed to in San Diego, but I'm not sure I understand it. I think we said something like... all mandatory attributes must be "instantiated" as soon as a job becomes Pending. The idea, here, is that we can't predict what combinations of attributes an application might stuff together in a varbind so there must be a valid response to (at least) the mandatory set. Meanwhile, we moved the alert code which would have been associated with state NeedsAttention out of the Job State Table and into the Attribute table... so, now I want to test the assumption by asking the question: Is the deviceAlertCode attribute only valid while the state is needsAttention? Should the agent return unknown(-1) while in other states? Or would the row disappear from the Attribute table? I think the answer is the row must be instantiated and the value -1 be returned, according to our agreement. This really doesn't seem very efficient, however, because there will be a deviceAlertCode row for every job in the Attribute table even though the vast majority of jobs will never need attention! Harry Lewis - IBM Printing Systems From jkm at underscore.com Thu May 22 19:30:02 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Instantiation In-Reply-To: Instantiation> Message-ID: <199705222330.TAA05056@uscore.underscore.com> Based on your analysis, I'd go for instantiating deviceAlertCode *only* if it is applicable (ie, jobState is NeedsAttention, etc). ...jay ----- Begin Included Message ----- From: Harry Lewis To: Subject: JMP> Instantiation Date: Thu, 22 May 1997 19:28:42 -0400 I would like to clarify something I think we agreed to in San Diego, but I'm not sure I understand it. I think we said something like... all mandatory attributes must be "instantiated" as soon as a job becomes Pending. The idea, here, is that we can't predict what combinations of attributes an application might stuff together in a varbind so there must be a valid response to (at least) the mandatory set. Meanwhile, we moved the alert code which would have been associated with state NeedsAttention out of the Job State Table and into the Attribute table... so, now I want to test the assumption by asking the question: Is the deviceAlertCode attribute only valid while the state is needsAttention? Should the agent return unknown(-1) while in other states? Or would the row disappear from the Attribute table? I think the answer is the row must be instantiated and the value -1 be returned, according to our agreement. This really doesn't seem very efficient, however, because there will be a deviceAlertCode row for every job in the Attribute table even though the vast majority of jobs will never need attention! Harry Lewis - IBM Printing Systems ----- End Included Message ----- From harryl at us.ibm.com Thu May 22 19:42:38 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <5030100002766736000002L062*@MHS> Some of the job state reasons for HELD seem like they would fit better as reasons for NEEDS-ATTENTION. For example: requiredResourcesNotReady 0x20 The job is in the held state because at least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. serviceOffLine 0x400000 The service/document transform is off-line and accepting no jobs. All pending jobs are put into the held state. This could be true if its input is impaired or broken. These reasons seem categorically different than "Someone put this job on Hold 'till midnight". I guess it is fairly clear that state NeedsAttention should pertain to actual DEVICE failures, but 0x400000, above, sounds like it could be just that to me. Harry Lewis - IBM Printing Systems From jkm at underscore.com Thu May 22 20:54:27 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <199705230054.UAA06698@uscore.underscore.com> You raise a good point, Harry. I think we really want the user to be able to distinguish between jobs not printing due to problems vs. administrative "hold" (no matter who put the job on hold). One definition we'll have to nail down is NEEDS-ATTENTION. Does that term imply device-only problems, or any kind of problem that keeps the job from printing (other than HELD)? Given your statements, I'd vote for having NEEDS-ATTENTION imply _any_ kind of problem, and not just device-related problems. Similarly, I'd suggest that HELD implies an administratively-set condition only. Quick comments/votes by the others? (Tick, tick, tick...) ...jay ----- Begin Included Message ----- From: Harry Lewis To: Subject: JMP> HELD vs NEEDS-ATTENTION Date: Thu, 22 May 1997 19:42:38 -0400 Some of the job state reasons for HELD seem like they would fit better as reasons for NEEDS-ATTENTION. For example: requiredResourcesNotReady 0x20 The job is in the held state because at least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. serviceOffLine 0x400000 The service/document transform is off-line and accepting no jobs. All pending jobs are put into the held state. This could be true if its input is impaired or broken. These reasons seem categorically different than "Someone put this job on Hold 'till midnight". I guess it is fairly clear that state NeedsAttention should pertain to actual DEVICE failures, but 0x400000, above, sounds like it could be just that to me. Harry Lewis - IBM Printing Systems ----- End Included Message ----- From rbergma at dpc.com Thu May 22 20:20:08 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> Instantiation In-Reply-To: <199705222330.TAA05056@uscore.underscore.com> Message-ID: <199705230054.UAA06698@uscore.underscore.com> Harry, I agree with Jay. deviceAlertCode should be conditionally-mandatory. Where the condition is jobState is NeedsAttention. Ron On Thu, 22 May 1997, JK Martin wrote: > Based on your analysis, I'd go for instantiating deviceAlertCode *only* > if it is applicable (ie, jobState is NeedsAttention, etc). > > ...jay > > ----- Begin Included Message ----- > > From jmp-owner@pwg.org Thu May 22 19:27 EDT 1997 > From: Harry Lewis > To: > Subject: JMP> Instantiation > Date: Thu, 22 May 1997 19:28:42 -0400 > > I would like to clarify something I think we agreed to in San Diego, but I'm > not sure I understand it. > > I think we said something like... all mandatory attributes must be > "instantiated" as soon as a job becomes Pending. The idea, here, is that we > can't predict what combinations of attributes an application might stuff > together in a varbind so there must be a valid response to (at least) the > mandatory set. > > Meanwhile, we moved the alert code which would have been associated with state > NeedsAttention out of the Job State Table and into the Attribute table... so, > now I want to test the assumption by asking the question: > > Is the deviceAlertCode attribute only valid while the state is > needsAttention? Should the agent return unknown(-1) while in other > states? Or would the row disappear from the Attribute table? > > I think the answer is the row must be instantiated and the value -1 be > returned, according to our agreement. This really doesn't seem very > efficient, however, because there will be a deviceAlertCode row for every > job in the Attribute table even though the vast majority of jobs will > never need attention! > > Harry Lewis - IBM Printing Systems > > > ----- End Included Message ----- > From Robert.Herriot at Eng.Sun.COM Thu May 22 21:53:40 1997 From: Robert.Herriot at Eng.Sun.COM (Robert Herriot) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <199705230153.SAA00465@woden.eng.sun.com> You might want to look at the changes that we made in the IPP job-state at yesterday's meeting. The current jobs states are: ---> canceled pending -> processing -|--> aborted ---> completed Normally a job progresses only from left to right through three states. held and retention became job-state-reasons. The job MIB concept of needs-attention is in IPP a job-state-reason: printer-stopped which a job can have as a value of job-state-reasons when its job-state is pending or processing. We hoped that the Job MIB group would consider these changes in the jobMIB as well. Bob Herriot > From jkm@underscore.com Thu May 22 17:56:58 1997 > > You raise a good point, Harry. I think we really want the user > to be able to distinguish between jobs not printing due to problems > vs. administrative "hold" (no matter who put the job on hold). > > One definition we'll have to nail down is NEEDS-ATTENTION. Does > that term imply device-only problems, or any kind of problem that > keeps the job from printing (other than HELD)? > > Given your statements, I'd vote for having NEEDS-ATTENTION imply > _any_ kind of problem, and not just device-related problems. > > Similarly, I'd suggest that HELD implies an administratively-set > condition only. > > Quick comments/votes by the others? (Tick, tick, tick...) > > ...jay > > ----- Begin Included Message ----- > > From jmp-owner@pwg.org Thu May 22 19:41 EDT 1997 > From: Harry Lewis > To: > Subject: JMP> HELD vs NEEDS-ATTENTION > Date: Thu, 22 May 1997 19:42:38 -0400 > > Some of the job state reasons for HELD seem like they would fit better as > reasons for NEEDS-ATTENTION. For example: > > requiredResourcesNotReady 0x20 > The job is in the held state because at least one of the > resources needed by the job, such as media, fonts, resource > objects, etc., is not ready on any of the physical devices > for which the job is a candidate. > > > serviceOffLine 0x400000 > The service/document transform is off-line and accepting no > jobs. All pending jobs are put into the held state. This > could be true if its input is impaired or broken. > > These reasons seem categorically different than "Someone put this > job on Hold 'till midnight". > > I guess it is fairly clear that state NeedsAttention should pertain to > actual DEVICE failures, but 0x400000, above, sounds like it could > be just that to me. > > Harry Lewis - IBM Printing Systems > > > ----- End Included Message ----- > From harryl at us.ibm.com Fri May 23 10:38:04 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Changes agreed to for Job Monitoring MIB last week, In-Reply-To: Changes agreed to for Job Monitoring MIB last week,> Message-ID: <5030100002780172000002L022*@MHS> Jay, I think you have answered my question... you *are* concerned about tracking job progress and notifying clients even though you are "out of band". Given this, I think I see why you need jobOwner to have the greatest persistence (although, honestly, I fear this is Pandora's box, and soon, we will learn that jobOwner is really not enough - if this is likely, I'd rather it surface NOW!). So, what about my proposal to add a new jmJobSubmissionID format for LPR JobOwner? The owner information would have to be truncated to 30 bytes and someone, most likely the NIC, would have to prepend the assigned jmJobSubmissionID format number to the attribute. By definition, the JobID table has the same persistence as the Job Table - each guaranteed to have the longest persistence. Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 06:11 PM --------------------------- jkm@underscore.com 05/22/97 05:56 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> Changes agreed to for Job Monitoring MIB last week, [I have changed the Subject line to better reflect the topic] Harry, This statement has me somewhat bothered regarding which master we are trying to serve with the Job MIB in general: > Yes, we realized after Dave and Jay had left the meeting, that the size > of jmJobOwner blows away the notion of keeping the Job Table terse. What do you want? Good grammer or good taste?... ;-} Seriously, some of us firmly believe in the importance of "out of band" job monitors (ie, processes monitoring job progression without being intrinsically part of the printing process, a la Unix and VMS). The only consistent way to indentify jobs is through jobOwner, and hence, this data must be available for as long as the job entry exists in the agent. Those who will be using the Job MIB as an intrinsic part of the printing process are lucky (eg, Windows, OS/2, etc). (We envy you, believe us!) If someone can state a justifiable case for being able to monitor jobs with jobOwner, then great! (And please do so soon!) Otherwise, we need that data for the duration of the job entry. ...jay Harry Lewis - From rbergma at dpc.com Fri May 23 11:06:32 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <5030100002780172000002L022*@MHS> I agree with all the changes proposed for alignment of the IPP and JMP job states except for the removal of "Needs Attention". This should be the most important state to indicate to a user since unless he takes action the job may never complete. I would think that this would also be very important for IPP as well. I also agree with Harry that "requiredResourcesNotReady" and "serviceOffLine" apply better to "Needs Attention" than "Held". (I also agree with Harry that "Printing" is a better description for a user than "Processing". Since this is an enum, a user or management ap can display whatever text that is deemed appropriate. So I will vote to keep "Processing" unless there is very strong support for "Printing".) (Didn't we discuss "serviceOffLine" in a previous meeting and determined that no one except Dataproducts has ever implemented such a capability? I also indicated that I had recently deleted the feature because I felt it was "stupid".) Also, I agree with Jay that "Needs Attention" should apply to all conditions, other than "Held", that prevents the job from printing. "Held" only implies an administratively set condition. Tom, since I could not participate in the Wednesday conference call, could you explain why "Needs Attention" was not accepted by IPP? It is very critical that JMP and IPP agree in this area and I would hope this can be resolved quickly. Ron Bergman Dataproducts Corp From rbergma at dpc.com Fri May 23 13:01:13 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC Message-ID: <5030100002780172000002L022*@MHS> Tom, In reviewing the Job MIB relative to the job states, I noticed that the descriptions for jmJobState and JmJobStateTC are almost identical. I would like the specification for jmJobState to appear only once, and only in the jmJobState description. I propose that these descriptions be revised as follows: jmJobState: ----------- "The current state of the job (pending, processing, held, etc.). The final value for this attribute shall be either completed or canceled, before the agent removes the job from the table. Management applications shall be prepared to receive all the standard job states. Servers and devices are not required to generate all job states, only those which are appropriate for the particular implementation. The corresponding attributes JmJobStateReasons1 through JmJobStateReasons5 provide additional information about the job states. While new job states cannot be added without impacting deployed clients, it is the intent that additional Job State Reasons enums can be defined without impacting deployed clients." JmJobStateTC: ------------- "Defines the current state of the job." A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC. Again, my recommendation is: jobStateReasons: ---------------- ---OCTETS: Additional information about the job's current state that augments jmJobState. The jobStateReasons1 attribute identifies the reason or reasons that the job is in the held, pending, processing, needsAttention, canceled, or completed state. The agent shall indicate the particular reason(s) by setting the value of the jobStateReasons1 attribute. When the job does not have any reasons for being in its current state, the agent shall set the value of the jobStateReasons1 attribute to 0. Companion job state reasons Textual Conventions: JmJobStateReasons2TC, JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an additional 93 job state reasons for use with the corresponding attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4. This is a type 2 bit definition. JmJobStateReasons1TC: --------------------- "This textual-convention is used with the jobStateReasons1 attribute to provides additional information regarding jmJobState. The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: If anyone objects to these changes, please respond by June 13. Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Fri May 23 14:40:03 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Should jobStateReasons1 be mandatory? Message-ID: <5030100002790497000002L072*@MHS> Yes, I'm saying that jobStateReasons is something a DPA server might know about but not (practically) many printers. >Your comments lead me to believe you're saying that it's too damn >difficult for the printer agent to say what the current "reason" is. >Is this true? If it is, then I think we're in real deep water here. There are 4 sets of jobStateReasons... just look at the first (presumably most importatn?) set... canceledByUser, canceledByOperator, abortedBySystem, logfilePending, jobRetained etc. >I just went thru the V0.81 draft, but couldn't find 7.5 pages of >Job State Reasons in the MIB. Can you give me a better pointer? >(Am I looking at the proper draft?) I did find some tables on >various Reasons (pp. 57-58), but I guess I don't see the problem. In v0.81 the PDF version (I think) see pages 49-56. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Fri May 23 15:37:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: IPP> MOD - simplified legal state transition diagram In-Reply-To: MOD - simplified legal state transition diagram> Message-ID: <9705231940.AB10103@zazen.cp10.es.xerox.com> Bill, I think you are right, that the 'unknown' job state should be used only when the agent doesn't know about the state of the job that exists. When the job doesn't exist anymore (or before the job exists) is not really a job state at all. I think that this problem can be easily fixed by changing the heading on the column from 'unknown' to something like , ok? Tom At 14:02 05/21/97 PDT, Bill Wagner wrote: >I apologize if I missed a step or two in this exchange. Of course, I agree >with the objective and believe the states listed are adequate. However, the >'unknown' state, within general MIB use at least, has been more a >reflection on the state of the equipment than the job. That is, the state >of a job is unknown because of some sensing difficulty or sequence >difficulty with the equipment, not because it is a normal state in the >sequence of handling a job. > >It would be quite possible for a unit to report no state other than >unknown. It seems it would also be possible for a unit to recognize a state >after it has previously been unknown. For example, if a job can be >identified, it can be canceled and the state is then likely to be canceled >and not unknown. In short, I suggest that unknown is a wild card rather >than a job state that exists before pending and processing and after >canceled and completed. > >If something is necessary for the pre-pending and post complete states, >what about Other? > >Bill Wagner, Osicom/DPI > > >______________________________ Reply Separator _________________________________ >Subject: IPP> MOD - simplified legal state transition diagram >Author: Tom Hastings at Internet >Date: 5/21/97 7:29 AM > > >So the simplified legal state transition diagram for IPP and JMP would become, >following Bob's proposal: > > New state >Old state unknown(2) pending(3) processing(4) canceled(5) completed(6) >unknown(2) yes yes >pending(3) yes yes >processing(4) yes yes yes >canceled(5) yes >completed(6) yes > >A blank entry indicates impossible transitions. Self loops are not >indicated, such as a Get-Attributes operation on a job, since they aren't >a job state transition. > >For IPP we need to consider which job states and job state transtions are >required for conformance and which are optional. > >JMP requires that processing(4), canceled(5), and completed(6) are >mandatory, so that pending(3) is optional. What about unknown(2)? >The former needsAttention state was also mandatory, so that the >new job-state reason: printer-stopped, should become a mandator job state >reason, correct? > >For IPP and JMP, all transitions into the canceled state should be required. >However, the transition from processing back to pending (a job-held situation) >is optional. > > > From hastings at cp10.es.xerox.com Fri May 23 15:37:59 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: RFC 2119, March 1997 has conformance language s In-Reply-To: Re: RFC 2119, March 1997 has conformance language s> Message-ID: <9705231940.AB10103@zazen.cp10.es.xerox.com> At 15:09 05/22/97 PDT, Harry Lewis wrote: >In my opinion, it doesn't matter if these words are capitalize or not. I >recommend against their use entirely. >The very fact that these words need an RFC to define them indicates, to me, >that they are too vague for >use in a specification. > >As an example: > >Rather than say "... the Job Submission Attributes SHALL overide the PDL job >attributes" it would be more >concise to say "... the Job Submission Attributes overide the PDL job >attributes". The problem is that your second sentence is stated as declaration of fact or a definition of "Job Submission Attribute", rather than of something that is required that an implementation do in order to conform to the standard. > >But, alas, I'm probably dabbling in IETF or Standards heresy, here, so ... on >to other mail messages. > >Harry Lewis - IBM Printing Systems > > >------ Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 03:43 PM ------ > > jmp-owner@pwg.org > 05/22/97 10:27 AM >Please respond to jmp-owner@pwg.org @ internet > > >To: hastings@cp10.es.xerox.com @ internet >cc: jmp@pwg.org @ internet >Subject: Re: JMP> Re: RFC 2119, March 1997 has conformance language s > >Tom, > >I would recommend that these terms be capitalized only if absolutely >required or if strongly recommended by Scott Bradner. Otherwise, lets >leave well-enough alone. > > Ron Bergman > > >On Thu, 22 May 1997, Tom Hastings wrote: > >> I just read the RFC and it defines the following terms and suggests that >> the following phrase be put early in the document: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> RFC 2119. >> >> Happily, the "shall", "should", and "may" terms are as the PWG has been using >> in its Printer MIB, Job Monitoring MIB, and IPP documents. >> >> It also has "must" as a synonym for "shall". I suggest that we continue >> to use "shall", rather than switching over or using a mixture, in order >> to keep our PWG standards using the same terminology. Ok? >> >> It also says: "These words are often capitalized." >> I've sent mail to Scott Bradner asking whether it is recommended to >> capitalize. Seems like it would make these terms stand out more. >> >> Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring >> MIB? What about IPP documents? >> >> Thanks, >> Tom >> >> At 23:46 05/21/97 PDT, Tom Hastings wrote: >> >Thanks Larry, >> > >> >Tom >> > >> >>Return-Path: >> >>Date: Wed, 21 May 1997 23:08:45 PDT >> >>From: Larry Masinter >> >>Organization: Xerox PARC >> >>To: Tom Hastings >> >>Subject: Re: IPP> MOD - 5/14 mintues >> >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> >> >> >> >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >> >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >> >>-- >> >> >> >>Larry >> >>-- >> >>http://www.parc.xerox.com/masinter >> >> >> >> >> > >> > >> > >> >> > > > > > > From STUART at KEI-CA.CCMAIL.CompuServe.COM Fri May 23 16:04:03 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <9705231940.AB10103@zazen.cp10.es.xerox.com> I agree that "Needs Attention" is an important state which should not be removed from jmJobState, but I think it is very important to have alignment with IPP. So we just have to get IPP to come around to our way of thinking :-) Ron, you didn't mention that the IPP job states do not include held (pending, processing, cancelled, aborted, and completed). I believe there is also an important distinction between held and pending and that there should be both held and pending states. I think the jmJobStates of Held, Pending, Processing, Needs Attention, Cancelled, and Completed are the best at providing the necessary information WITH A SINGLE OBJECT. As Harry has said, most printer agents can tell the whole story (as they know it) with just these job states. The JobStateReasons are things the printer agent typically doesn't know about. Perhaps IPP is hung up on the semantics such as that a hold is really a reason it is pending. I can perhaps see the theoretical justification for having held as a reason for the state pending. But, I believe users, as opposed to us grizzled standards developers, would immediately see the utility of having held as a separate state from pending, with pending applying only to jobs that are waiting and have not been put on administrative hold. The user may then choose to see the reason why it is held or pending. This same arguement applies to the Needs Attention state as opposed to making Needs Attention a reason under the one of the other states. It is just more useful to have Held and Needs Attention as job states rather than reasons! Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ I agree with all the changes proposed for alignment of the IPP and JMP job states except for the removal of "Needs Attention". This should be the most important state to indicate to a user since unless he takes action the job may never complete. I would think that this would also be very important for IPP as well. I also agree with Harry that "requiredResourcesNotReady" and "serviceOffLine" apply better to "Needs Attention" than "Held". (I also agree with Harry that "Printing" is a better description for a user than "Processing". Since this is an enum, a user or management ap can display whatever text that is deemed appropriate. So I will vote to keep "Processing" unless there is very strong support for "Printing".) (Didn't we discuss "serviceOffLine" in a previous meeting and determined that no one except Dataproducts has ever implemented such a capability? I also indicated that I had recently deleted the feature because I felt it was "stupid".) Also, I agree with Jay that "Needs Attention" should apply to all conditions, other than "Held", that prevents the job from printing. "Held" only implies an administratively set condition. Tom, since I could not participate in the Wednesday conference call, could you explain why "Needs Attention" was not accepted by IPP? It is very critical that JMP and IPP agree in this area and I would hope this can be resolved quickly. Ron Bergman Dataproducts Corp From jkm at underscore.com Fri May 23 16:57:09 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <199705232057.QAA10995@uscore.underscore.com> I agree wholeheartedly with Stuarts comments regarding the importance of distinguishing between HELD and PENDING. Nice job, Stuart. ...jay ----- Begin Included Message ----- From: STUART@KEI-CA.CCMAIL.CompuServe.COM Date: 23 May 97 16:04:03 EDT To: Subject: Re[2]: JMP> HELD vs NEEDS-ATTENTION I agree that "Needs Attention" is an important state which should not be removed from jmJobState, but I think it is very important to have alignment with IPP. So we just have to get IPP to come around to our way of thinking :-) Ron, you didn't mention that the IPP job states do not include held (pending, processing, cancelled, aborted, and completed). I believe there is also an important distinction between held and pending and that there should be both held and pending states. I think the jmJobStates of Held, Pending, Processing, Needs Attention, Cancelled, and Completed are the best at providing the necessary information WITH A SINGLE OBJECT. As Harry has said, most printer agents can tell the whole story (as they know it) with just these job states. The JobStateReasons are things the printer agent typically doesn't know about. Perhaps IPP is hung up on the semantics such as that a hold is really a reason it is pending. I can perhaps see the theoretical justification for having held as a reason for the state pending. But, I believe users, as opposed to us grizzled standards developers, would immediately see the utility of having held as a separate state from pending, with pending applying only to jobs that are waiting and have not been put on administrative hold. The user may then choose to see the reason why it is held or pending. This same arguement applies to the Needs Attention state as opposed to making Needs Attention a reason under the one of the other states. It is just more useful to have Held and Needs Attention as job states rather than reasons! Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ I agree with all the changes proposed for alignment of the IPP and JMP job states except for the removal of "Needs Attention". This should be the most important state to indicate to a user since unless he takes action the job may never complete. I would think that this would also be very important for IPP as well. I also agree with Harry that "requiredResourcesNotReady" and "serviceOffLine" apply better to "Needs Attention" than "Held". (I also agree with Harry that "Printing" is a better description for a user than "Processing". Since this is an enum, a user or management ap can display whatever text that is deemed appropriate. So I will vote to keep "Processing" unless there is very strong support for "Printing".) (Didn't we discuss "serviceOffLine" in a previous meeting and determined that no one except Dataproducts has ever implemented such a capability? I also indicated that I had recently deleted the feature because I felt it was "stupid".) Also, I agree with Jay that "Needs Attention" should apply to all conditions, other than "Held", that prevents the job from printing. "Held" only implies an administratively set condition. Tom, since I could not participate in the Wednesday conference call, could you explain why "Needs Attention" was not accepted by IPP? It is very critical that JMP and IPP agree in this area and I would hope this can be resolved quickly. Ron Bergman Dataproducts Corp ----- End Included Message ----- From bwagner at digprod.com Fri May 23 18:38:17 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <199705232057.QAA10995@uscore.underscore.com> Stuart, Of course you are right. It is the difference between a logical consideration and a popular perception. I agree that "needs attention" is not a state, it is a condition that may associate with any printing job state. But the distinction might not be obvious to a casual user. On another semantic difference of opinion, I think that processing is probably more applicable popularly than printing, because the common user might get concerned is his status is printing when the printer is grinding away on a recursive fish file. But it seems that this probably should be of more concern to the IPP, when it appears that the actual phases might be seen by the user, than with the Job Monitoring MIB, where a specific user interface will be present to put the information in appropriate terms. Also, I suggest that, particularly if the Printer MIB is not supported, some interesting information may be lost by not indicating the printing state at which the job needs attention. Regardless, I suggest that if the intent is to convince IPP to go with the popular terms, it must be on the basis that these will better serve the user, even if they are logically incorrect. (Who ever said users had to be logical?) Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re[2]: JMP> HELD vs NEEDS-ATTENTION Author: STUART@KEI-CA.CCMAIL.CompuServe.COM at Internet Date: 5/23/97 4:04 PM I agree that "Needs Attention" is an important state which should not be removed from jmJobState, but I think it is very important to have alignment with IPP. So we just have to get IPP to come around to our way of thinking :-) Ron, you didn't mention that the IPP job states do not include held (pending, processing, cancelled, aborted, and completed). I believe there is also an important distinction between held and pending and that there should be both held and pending states. I think the jmJobStates of Held, Pending, Processing, Needs Attention, Cancelled, and Completed are the best at providing the necessary information WITH A SINGLE OBJECT. As Harry has said, most printer agents can tell the whole story (as they know it) with just these job states. The JobStateReasons are things the printer agent typically doesn't know about. Perhaps IPP is hung up on the semantics such as that a hold is really a reason it is pending. I can perhaps see the theoretical justification for having held as a reason for the state pending. But, I believe users, as opposed to us grizzled standards developers, would immediately see the utility of having held as a separate state from pending, with pending applying only to jobs that are waiting and have not been put on administrative hold. The user may then choose to see the reason why it is held or pending. This same arguement applies to the Needs Attention state as opposed to making Needs Attention a reason under the one of the other states. It is just more useful to have Held and Needs Attention as job states rather than reasons! Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ I agree with all the changes proposed for alignment of the IPP and JMP job states except for the removal of "Needs Attention". This should be the most important state to indicate to a user since unless he takes action the job may never complete. I would think that this would also be very important for IPP as well. I also agree with Harry that "requiredResourcesNotReady" and "serviceOffLine" apply better to "Needs Attention" than "Held". (I also agree with Harry that "Printing" is a better description for a user than "Processing". Since this is an enum, a user or management ap can display whatever text that is deemed appropriate. So I will vote to keep "Processing" unless there is very strong support for "Printing".) (Didn't we discuss "serviceOffLine" in a previous meeting and determined that no one except Dataproducts has ever implemented such a capability? I also indicated that I had recently deleted the feature because I felt it was "stupid".) Also, I agree with Jay that "Needs Attention" should apply to all conditions, other than "Held", that prevents the job from printing. "Held" only implies an administratively set condition. Tom, since I could not participate in the Wednesday conference call, could you explain why "Needs Attention" was not accepted by IPP? It is very critical that JMP and IPP agree in this area and I would hope this can be resolved quickly. Ron Bergman Dataproducts Corp From imcdonal at eso.mc.xerox.com Sat May 24 11:04:58 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: RFC 2119, March 1997 has conformance language s In-Reply-To: Re: RFC 2119, March 1997 has conformance language s> Message-ID: <9705241504.AA22266@snorkel.eso.mc.xerox.com> Hi Harry and Tom, To amplify Tom's point below, a well-written standard is structured around statements like: "Conforming management [agents|stations] [shall|should|may] perform some action..." You want to state conformance requirements on implementations, not on the mere semantics/behavior of objects. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 >--------------------------- Included Message ---------------------------< Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA22137; Fri, 23 May 97 15:51:15 EDT Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA06462; Fri, 23 May 97 15:48:44 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <17708(9)>; Fri, 23 May 1997 12:48:47 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04905 for ; Fri, 23 May 1997 15:44:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 May 1997 15:41:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04703 for jmp-outgoing; Fri, 23 May 1997 15:40:29 -0400 (EDT) Message-Id: <9705231940.AB10103@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 12:37:59 PDT To: jmp@pwg.org, Harry Lewis From: Tom Hastings Subject: Re: JMP> Re: RFC 2119, March 1997 has conformance language s Sender: jmp-owner@pwg.org Status: R At 15:09 05/22/97 PDT, Harry Lewis wrote: >In my opinion, it doesn't matter if these words are capitalize or not. I >recommend against their use entirely. >The very fact that these words need an RFC to define them indicates, to me, >that they are too vague for >use in a specification. > >As an example: > >Rather than say "... the Job Submission Attributes SHALL overide the PDL job >attributes" it would be more >concise to say "... the Job Submission Attributes overide the PDL job >attributes". The problem is that your second sentence is stated as declaration of fact or a definition of "Job Submission Attribute", rather than of something that is required that an implementation do in order to conform to the standard. > >But, alas, I'm probably dabbling in IETF or Standards heresy, here, so ... on >to other mail messages. > >Harry Lewis - IBM Printing Systems > > >------ Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 03:43 PM ------ > > jmp-owner@pwg.org > 05/22/97 10:27 AM >Please respond to jmp-owner@pwg.org @ internet > > >To: hastings@cp10.es.xerox.com @ internet >cc: jmp@pwg.org @ internet >Subject: Re: JMP> Re: RFC 2119, March 1997 has conformance language s > >Tom, > >I would recommend that these terms be capitalized only if absolutely >required or if strongly recommended by Scott Bradner. Otherwise, lets >leave well-enough alone. > > Ron Bergman > > >On Thu, 22 May 1997, Tom Hastings wrote: > >> I just read the RFC and it defines the following terms and suggests that >> the following phrase be put early in the document: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> RFC 2119. >> >> Happily, the "shall", "should", and "may" terms are as the PWG has been using >> in its Printer MIB, Job Monitoring MIB, and IPP documents. >> >> It also has "must" as a synonym for "shall". I suggest that we continue >> to use "shall", rather than switching over or using a mixture, in order >> to keep our PWG standards using the same terminology. Ok? >> >> It also says: "These words are often capitalized." >> I've sent mail to Scott Bradner asking whether it is recommended to >> capitalize. Seems like it would make these terms stand out more. >> >> Should I capitalize SHALL, SHOULD, MAY (and NEED NOT) in the Job Monitoring >> MIB? What about IPP documents? >> >> Thanks, >> Tom >> >> At 23:46 05/21/97 PDT, Tom Hastings wrote: >> >Thanks Larry, >> > >> >Tom >> > >> >>Return-Path: >> >>Date: Wed, 21 May 1997 23:08:45 PDT >> >>From: Larry Masinter >> >>Organization: Xerox PARC >> >>To: Tom Hastings >> >>Subject: Re: IPP> MOD - 5/14 mintues >> >>References: <9705220435.AB09386@zazen.cp10.es.xerox.com> >> >> >> >>RFC 2119: Key words for use in RFCs to Indicate Requirement Level. S. >> >>Bradner. March 1997. (Format: TXT=4723 bytes) (Updated by BCP0014) >> >>-- >> >> >> >>Larry >> >>-- >> >>http://www.parc.xerox.com/masinter >> >> >> >> >> > >> > >> > >> >> > > > > > > From hastings at cp10.es.xerox.com Sun May 25 05:42:36 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <9705250944.AA10369@zazen.cp10.es.xerox.com> The current draft lists processing, needsAttention, canceled, and completed as Mandatory. Since needsAttention has gone away, that leaves three states as mandatory: processing, canceled, and completed. Since we added aborted, I assume that aborted should be added to the mandatory list. The complicance at the end of the Job MIB spec also lists these states. I assume that you didn't intend to remove that agreement. So I'd like to add back the description that some are mandatory and the rest are conditionally mandatory. I agree on removing redundant text. However, in this case, the description in jmJobState was simply a pointer to the textual convention (after deleteing the sentence: "The value of this object shall always be the same as that of the jobState attribute, so that this information appears in both the jmJobStateTable and the jmAttributeTable simultaneously". since we agreed to get rid of duplicates. So the real thrust of your comment was to move the description from the textual convention to the object. So I'll add the sentence about the mandatory states to the jmJobState object as well, ok? Tom At 10:01 05/23/97 PDT, Ron Bergman wrote: >Tom, > >In reviewing the Job MIB relative to the job states, I noticed that >the descriptions for jmJobState and JmJobStateTC are almost identical. >I would like the specification for jmJobState to appear only once, >and only in the jmJobState description. I propose that these >descriptions be revised as follows: > >jmJobState: >----------- >"The current state of the job (pending, processing, held, etc.). The >final value for this attribute shall be either completed or canceled. final value for this attribute shall be completed, canceled or aborted. >before the agent removes the job from the table. > >Management applications shall be prepared to receive all the standard >job states. Servers and devices are not required to generate all job >states, only those which are appropriate for the particular >implementation. The corresponding attributes JmJobStateReasons1 through >JmJobStateReasons4 provide additional information about the job states. >While new job states cannot be added without impacting deployed clients, >it is the intent that additional Job State Reasons enums can be defined >without impacting deployed clients." > >JmJobStateTC: >------------- >"Defines the current state of the job." > > >A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC. >Again, my recommendation is: I'm assuming that we have agreed to make jobStateReasons1 mandatory, in order that the 'printer-stopped' value will always be present (the new representation for the old needsAttention state that was removed). Since jobStateReasons1 is an INTEGER, not OCTETS, we will move it to the jmJobTable right after the jmJobState object, so that the descriptions will be next to each other. Its name will be jmJobStateReason1. I've done some further shortening of the description that you proposed. How does it look? > > >jobStateReasons: jmJobStateReasons1; >---------------- >---OCTETS: Additional information about the job's current state that Additional information about the job's current state that >augments jmJobState. The jobStateReasons1 attribute identifies the >reason or reasons that the job is in the held, pending, processing, >needsAttention, canceled, or completed state. The agent shall indicate >the particular reason(s) by setting the value of the jobStateReasons1 >attribute. augments jmJobState, including the reasons(s) that the job is in its current state. < When the job does not have any reasons for being in its >current state, the agent shall set the value of the jobStateReasons1 >attribute to 0. > >Companion job state reasons Textual Conventions: JmJobStateReasons2TC, >JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an >additional 93 job state reasons for use with the corresponding >attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4. Additional job state reasons may be represented by the attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4. See page xxx. >This is a type 2 bit definition. > >JmJobStateReasons1TC: >--------------------- >"This textual-convention is used with the jobStateReasons1 attribute to >provides additional information regarding jmJobState. > >The following standard values are defined (in hexadecimal) as powers of >two, since multiple values may be used at the same time: > > >If anyone objects to these changes, please respond by June 13. > > > Ron Bergman > Dataproducts Corp. > > > > From hastings at cp10.es.xerox.com Sun May 25 05:42:48 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <9705250945.AB10369@zazen.cp10.es.xerox.com> At 08:06 05/23/97 PDT, Ron Bergman wrote: > >I agree with all the changes proposed for alignment of the IPP and >JMP job states except for the removal of "Needs Attention". This >should be the most important state to indicate to a user since >unless he takes action the job may never complete. I would think >that this would also be very important for IPP as well. In IPP the job-state-reasons 'printer-stopped' is used instead of a separate job state called 'needs-attention'. The job can be in either the 'pending' or 'processing' state when the reason 'printer-stopped appears. If the job is in the pending state, it is some other job that is having the problem, but ALL pending jobs are affected, unless the printer problem is attended to. We have two choices for the Job Monitoring MIB: 1. Follow IPP and get rid of the needsAttention state and add the deviceStopped value to the JmJobStateReasons1TC. 2. Keep the needsAttention state. Don't add the deviceStopped value to the jmJobStateReasons1TC. When an agent is instrumenting IPP, the agent shall map the IPP 'processing' state to the JMP processing state, except when the IPP "job-state-reasons" contains 'printer-stopped'. Then the JMP agent shows the job in the JMP needsAttention state. When the IPP 'printer-stopped' value is removed from the IPP "printer-state-reasons" attribute, the JMP agent shall change the value of the job's jmJobState object from the needsAttention state to the processing state. The JMP jmJobStateReasons1 object would remain unchanged during this. >I also agree with Harry that "requiredResourcesNotReady" and >"serviceOffLine" apply better to "Needs Attention" than "Held". The IPP and JMP defintions of requiredResourcesNotReady, say "is not ready on any of the physical devices for which the job is a candidate" meaning before the job starts processing. Perhaps this reason should have a better name, like "requestedResourcesNotReady". IPP says that when the reason 'printer-stopped' is present, the client should check the printer-state and printer-state-reasons. For JMP the analoguous thing is to check the job's deviceAlert attributes and the associated device MIB. But the IPP/JMP meeting also got rid of the held state. IPP also renamed 'required-resources-not-ready' to 'job-hold-until-resources-are-ready'. The prefix "job-hold-" indicates that the job is held and will not process until the reason goes away. Again, JMP could still keep the held state, even though IPP doesn't have it. Which may be a good idea, since MIBs use enums, not keywords, so that an application can't tell from the enum code whether the job has to have the reason removed before it can be processed, or whether the reason is a less important one that doesn't affect whether the job will start processing or not. Then a JMP agent would represent the IPP 'pending' state with certain "job-state-reasons" value, such as 'job-hold-until-specified', and 'job-hold-until-required-resoureces-are-ready' as: the JMP 'held' state and also show the same jmJobStateReasons1 object values. >(I also agree with Harry that "Printing" is a better description >for a user than "Processing". Since this is an enum, a user or >management ap can display whatever text that is deemed >appropriate. So I will vote to keep "Processing" unless there >is very strong support for "Printing".) Thanks for being flexible. > >(Didn't we discuss "serviceOffLine" in a previous meeting and >determined that no one except Dataproducts has ever implemented >such a capability? I also indicated that I had recently deleted >the feature because I felt it was "stupid".) I don't remember this. Xerox has systems with service-off-line reason. The jobs that have been previously accepted are indicated as being in the held state with the serviceOffLine reason. Clients can still query the server since its the device that is really off-line, not the server. Perhaps we should rename the reason from serviceOffLine, to deviceOffLine and indicate that it is for configuration 2 in JMP? > >Also, I agree with Jay that "Needs Attention" should apply to all >conditions, other than "Held", that prevents the job from printing. >"Held" only implies an administratively set condition. How can the Needs Attention job state apply to all conditions (states)? It could if Needs Attention were a job state reason. In IPP we made Needs Attention a job state reason, but then renamed it to 'printer-stopped', because a device could need attention even though jobs were still progressing, such as toner low. So maybe you and Harry could support the IPP job-state-reason 'printer-stopped' as equivalent a Needs Attention job state reason and more flexible than if Needs Attention were a job state? > >Tom, since I could not participate in the Wednesday conference call, >could you explain why "Needs Attention" was not accepted by IPP? >It is very critical that JMP and IPP agree in this area and I would >hope this can be resolved quickly. As I explained above, IPP thought that Needs Attention was better as a job state reason, rather than a job state, and then we renamed the reason to printer-stopped to be clearer. I'm sorry that neither you nor Harry were able to call into the IPP call last Wednesday. The ball is in yours and Harry's court to see if you like the IPP approach and we can use it directly in JMP or whether JMP should perform a straight forward mapping when instrumenting an IPP system as I outlined above to the JMP held and/or JMP needsAttention states and some fiddling with job-state-reasons. > > > Ron Bergman > Dataproducts Corp > > > > From hastings at cp10.es.xerox.com Sun May 25 05:42:53 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> List of updated JMP objects and attributes Message-ID: <9705250945.AB10369@zazen.cp10.es.xerox.com> I've edited the list of Job Monitoring MIB objects and attributes according to the San Diego meeting and subsequent e-mail. Please review and make any comment ASAP. I'm editing these changes now. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 31232 May 25 09:32 obj-attr.doc -rw-r--r-- 1 pwg pwg 17717 May 25 09:31 obj-attr.pdf -rw-r--r-- 1 pwg pwg 4377 May 25 09:38 obj-attr.txt The .doc and .pdf files have revision marks. The .txt file does not and is also attached: SUBJ: UPDATED JOB MONITORING MIB OBJECT/ATTRIBUTE LIST From: Tom Hastings Date: 5/24/97 File: obj-attr.doc The list of agreed additions, deletions, and changes to the list of Job Monitoring MIB objects and attributes is shown below with revision marks since the Internet-Draft version 00 which corresponds to version 0.81. I've included some of the discussion that has occured on the e-mail list, since the 5/16/97 JMP meeting in San Diego. The table of contents indicates the Mandatory groups and attributes. If you have any comments, please send them ASAP, as this is what I'm editing the MIB to produce. 11. MIB SPECIFICATION Textual conventions for this MIB module JmTimeStampTC - simple time in seconds JmJobSourcePlatformTypeTC - operating system platform definitions JmFinishingTC - device finishing definitions JmPrintQualityTC - print quality JmPrinterResolution TC - printer resolution JmTonerEconomyTC - toner economy setting JmMediumTypeTC - medium type definitions JmJobStateTC - job state definitions JmAttributeTypeTC - attribute type definitions other unknown Job State attributes jobStateReasons2 jobStateReasons3 jobStateReasons4 deviceAlertCode processingMessage Job Identification attributes serverAssignedJobName jobName jobServiceTypes jobOwner (mandatory) jobAccountName jobSourceChannelIndex jobSourcePlatformType submittingServerName submittingApplicationName jobOriginatingHost deviceNameRequested queueNameRequested physicalDevice numberOfDocuments fileName documentName jobComment documentFormatIndex documentFormatType Job Parameter attributes jobPriority jobProcessAfterDateAndTime jobHoldUntil outputBin sides finishing Image Quality attributes (requested and used) printQualityRequested printQualityUsed printerResolutionRequested printerResolutionUsed tonerEcomonyRequested tonerEcomonyUsed tonerDensityRequested tonerDensityUsed Job Progress attributes (requested and consumed) jobCopiesRequested jobCopiesCompleted documentCopiesRequested documentCopiesCompleted jobKOctetsTransferred Impression attributes (requested and consumed) impressionsSpooled impressionsSentToDevice impressionsInterpreted impressionsCompletedCurrentCopy fullColorImpressionsCompleted highlightColorImpressionsCompleted Page attributes (requested and consumed) pagesRequested pagesCompleted pagesCompletedCurrentCopy Sheet attributes (requested and consumed) sheetsRequested sheetsCompleted sheetsCompletedCurrentCopy Resource attributes (requested and consumed) mediumRequested mediumConsumedName colorantRequested colorantConsumed Time attributes (set by server or device) jobSubmissionToServerDateAndTime jobTimeSinceSubmissionToDevice jobStartedBeingHeldTimeStamp jobTimeSinceStartedProcessing jobTimeSinceCompleted jobProcessingCPUTime JmJobServiceTypesTC - bit encoded job service type definitions JmJobStateReasons1TC - additional information about job states JmJobStateReasons2TC - More additional information about job states JmJobStateReasons3TC - More additional information about job states JmJobStateReasons4TC - More additional information about job states The General Group (Mandatory) jmGeneralNumberOfActiveJobs jmGeneralOldestActiveJobIndex jmGeneralNewestActiveJobIndex jmGeneralJobPersistence jmGeneralAttributePersistence jmGeneralJobSetName The Job ID Group (Mandatory) jmJobSubmissionID jmJobSetIndex jmJobIndex The Job Group (Mandatory) jmJobState jmJobStateReasons1 jmNumberOfInterventingJobs jmJobKOctertsRequested jmJobKOctetsProcessed jmJobImpressionsRequested jmJobImpressionsCompleted The Attribute Group (Mandatory) jmAttributeTypeIndex jmAttributeInstanceIndex jmAttributeValueAsInteger jmAttributeValueAsOctets From jkm at underscore.com Sun May 25 15:26:45 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?] In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?]> Message-ID: <199705251926.PAA18002@uscore.underscore.com> What happened to "pending" as a mandatory job state? I certainly hope we don't relegate this important state to the "Conditionally Mandatory" realm. > The current draft lists processing, needsAttention, canceled, and completed > as Mandatory. Since needsAttention has gone away, that leaves three > states as mandatory: processing, canceled, and completed. Since we added > aborted, I assume that aborted should be added to the mandatory list. > > The complicance at the end of the Job MIB spec also lists these states. > > [...snip...] > > Tom From jkm at underscore.com Sun May 25 15:50:02 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> Job state implementation questions for Unix-based print queues Message-ID: <199705251950.PAA18022@uscore.underscore.com> Sorry for the cross-post, but given that the PWG is desparately trying to reconcile common aspects between the Job MIB and IPP, both groups need to consider/review this topic. Print queues on Unix systems (both BSD and System V) provide ways for the system administrator to control an individual print queue: Enable/Disable Control whether jobs can be submitted to the queue by end users. (This is termed "Accept" and "Reject" on System V platforms.) Start/Stop Control the despooling of queued jobs to the target output device; if a queue is "stopped", then all queued jobs stay in a "pending" state until the queue is started. Also, a system administrator can selectively delete jobs from a target queue; on System V platforms the "cancel" command is used, while on BSD platforms either the "lprm" command or "lpc abort" command may be used. Some questions: 1. If a queue has been stopped, what should each job indicate for its job state? 2. If a queue is stopped, how can the user easily detect this critical queue-specific state? 3. Similarly, if a queue is disabled, how can the user detect this state? 4. If a system administrator deletes a job from a queue, what should the state and job reason(s) reflect? Thanks in advance for your advice and suggestions. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From imcdonal at eso.mc.xerox.com Tue May 27 09:39:29 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:05 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <9705271339.AA22801@snorkel.eso.mc.xerox.com> Hi Tom, Tuesday (27 May 1997) >Date: Sun, 25 May 1997 02:42:53 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> List of updated JMP objects and attributes > >I've edited the list of Job Monitoring MIB objects and attributes >according to the San Diego meeting and subsequent e-mail. > >Please review and make any comment ASAP. I'm editing these changes now. > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 31232 May 25 09:32 obj-attr.doc >-rw-r--r-- 1 pwg pwg 17717 May 25 09:31 obj-attr.pdf >-rw-r--r-- 1 pwg pwg 4377 May 25 09:38 obj-attr.txt > >The .doc and .pdf files have revision marks. The .txt file does not and >is also attached: Thanks for this summary list. My comments: 1) 'jobSourceChannelType' - request we add this attribute parallel to 'jobSourceChannelIndex' for support of systems which don't implement the Printer MIB - also much more useful attribute for accounting; 2) 'jmJobKOctertsRequested' - spelling error; Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 From harryl at us.ibm.com Tue May 27 12:29:43 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> Job state implementation questions for Unix-based print Message-ID: <5030100002851437000002L072*@MHS> Jay, these are good questions: >Some questions: > 1. If a queue has been stopped, what should each job indicate for its > job state? > 2. If a queue is stopped, how can the user easily detect this > critical queue-specific state? > 3. Similarly, if a queue is disabled, how can the user detect > this state? There is an analogous situation for the state NeedsAttention. One could ask, if the printer has an alert, should all the jobs in the printer buffer change to NeedsAttention state, or just the job which is currently printing. Our recommendation is not to ripple all jobs since this would be arduous for the agent. Rather, we envision the job monitoring application also having some indication of the overall health of the printer (Green, Yellow, Red). Only the job which is actually JAMMED (as an example) would reflect NeedsAttention state. Other jobs would be Pending on a "Red" printer. I would really like JMP and/or IPP confirmation of this approach for printer implementations and I offer it in response to your question about queue's as an analogy, presuming you could show overall queue status with a (Green, Yellow, Red) icon. As for your last question: > 4. If a system administrator deletes a job from a queue, what should > the state and job reason(s) reflect? I am not in favor of job state reasons as anything other than optional job attributes, but if I were to take a guess, here, I'd say that: State = CANCELED JobStateReasons1 = No reason (all zero's) JobStateRessons2 = deletedByAdministrator JobStateReasons3 = No reason JobStateReasons4 = No reason So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000? Harry Lewis. From SISAACSON at novell.com Tue May 27 12:28:52 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:05 2009 Subject: JMP> Re: IPP> Job state implementation questions for Unix-based In-Reply-To: Job state implementation questions for Unix-based> Message-ID: Here is how I see it.... >>> JK Martin 05/25 1:50 PM >>> > 1. If a queue has been stopped, what should each job indicate for its > job state? job-state = 'pending' with a job-state-reason = 'printer-stopped' > 2. If a queue is stopped, how can the user easily detect this > critical queue-specific state? printer-state = 'stopped', add a new reason to describe this - something like printer-state-reasons = 'stopped-by-operator'. > 3. Similarly, if a queue is disabled, how can the user detect > this state? The Printer has a boolean attribute called "printer-is-accepting-jobs". If the value is 'true' the Printer (and its queue have been enabled) otherwise the value is 'false'. > 4. If a system administrator deletes a job from a queue, what should > the state and job reason(s) reflect? We added the state 'cancelled' and the reason would be 'cancelled-by-operator'. job-state = 'cancelled', job-state-reasons = 'cancelled-by-operator' Scott From rbergma at dpc.com Tue May 27 11:29:30 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: <9705250945.AB10369@zazen.cp10.es.xerox.com> Message-ID: On Sun, 25 May 1997, Tom Hastings wrote: > At 08:06 05/23/97 PDT, Ron Bergman wrote: > > > >I agree with all the changes proposed for alignment of the IPP and > >JMP job states except for the removal of "Needs Attention". This > >should be the most important state to indicate to a user since > >unless he takes action the job may never complete. I would think > >that this would also be very important for IPP as well. > > In IPP the job-state-reasons 'printer-stopped' is used instead of a separate > job state called 'needs-attention'. The job can be in either the 'pending' > or 'processing' state when the reason 'printer-stopped appears. > If the job is in the pending state, it is some other job that is having > the problem, but ALL pending jobs are affected, unless the printer problem is > attended to. > > We have two choices for the Job Monitoring MIB: > > 1. Follow IPP and get rid of the needsAttention state and add the > deviceStopped value to the JmJobStateReasons1TC. > > 2. Keep the needsAttention state. Don't add the deviceStopped value to the > jmJobStateReasons1TC. When an agent is instrumenting IPP, > the agent shall map the IPP 'processing' state to the JMP processing state, > except when the IPP "job-state-reasons" contains 'printer-stopped'. Then the > JMP agent shows the job in the JMP needsAttention state. When the IPP > 'printer-stopped' value is removed from the IPP "printer-state-reasons" > attribute, the JMP agent shall change the value of the job's jmJobState object > from the needsAttention state to the processing state. The JMP > jmJobStateReasons1 object would remain unchanged during this. > RB> I would vote for number two if these were are only choices. > > >I also agree with Harry that "requiredResourcesNotReady" and > >"serviceOffLine" apply better to "Needs Attention" than "Held". > > The IPP and JMP defintions of requiredResourcesNotReady, say "is not > ready on any of the physical devices for which the job is a candidate" > meaning before the job starts processing. Perhaps this reason should > have a better name, like "requestedResourcesNotReady". > RB> I don't see any difference in "required" vs "requested". > IPP says that when the reason 'printer-stopped' is present, the client > should check the printer-state and printer-state-reasons. For JMP the > analoguous thing is to check the job's deviceAlert attributes and the > associated device MIB. > > But the IPP/JMP meeting also got rid of the held state. > RB> Have we eliminated too much? > IPP also renamed 'required-resources-not-ready' to > 'job-hold-until-resources-are-ready'. The prefix "job-hold-" indicates > that the job is held and will not process until the reason goes away. > > Again, JMP could still keep the held state, even though IPP doesn't have it. > Which may be a good idea, since MIBs use enums, not keywords, so that an > application can't tell from the enum code whether the job has to have the > reason removed before it can be processed, or whether the reason is a less > important one that doesn't affect whether the job will start processing or not. > > Then a JMP agent would represent the IPP 'pending' state with certain > "job-state-reasons" value, such as 'job-hold-until-specified', and > 'job-hold-until-required-resoureces-are-ready' as: > > the JMP 'held' state and also show the same jmJobStateReasons1 object values. > RB> I propose that we include the states that make sense for the Job MIB RB> even if they are not in IPP, as long as they can be mapped into RB> currently defined IPP states and reasons. > >(I also agree with Harry that "Printing" is a better description > >for a user than "Processing". Since this is an enum, a user or > >management ap can display whatever text that is deemed > >appropriate. So I will vote to keep "Processing" unless there > >is very strong support for "Printing".) > Thanks for being flexible. > > > > >(Didn't we discuss "serviceOffLine" in a previous meeting and > >determined that no one except Dataproducts has ever implemented > >such a capability? I also indicated that I had recently deleted > >the feature because I felt it was "stupid".) > > I don't remember this. Xerox has systems with service-off-line reason. > The jobs that have been previously accepted are indicated as being in the > held state with the serviceOffLine reason. Clients can still query the > server since its the device that is really off-line, not the server. > Perhaps we should rename the reason from serviceOffLine, to deviceOffLine > and indicate that it is for configuration 2 in JMP? > RB> I did not intend this to be a major issue. Leave it in. > > > >Also, I agree with Jay that "Needs Attention" should apply to all > >conditions, other than "Held", that prevents the job from printing. > >"Held" only implies an administratively set condition. > > How can the Needs Attention job state apply to all conditions (states)? > It could if Needs Attention were a job state reason. In IPP we made Needs > Attention a job state reason, but then renamed it to 'printer-stopped', > because a device could need attention even though jobs were still > progressing, such as toner low. > RB> Not States.. Conditions that prevent the job from printing, i.e. paper RB> out, paper jam, out of toner, printer unplugged, etc, etc, etc. Then RB> the "needsAttention" state applies. > So maybe you and Harry could support the IPP job-state-reason 'printer-stopped' > as equivalent a Needs Attention job state reason and more flexible than > if Needs Attention were a job state? > > > > >Tom, since I could not participate in the Wednesday conference call, > >could you explain why "Needs Attention" was not accepted by IPP? > >It is very critical that JMP and IPP agree in this area and I would > >hope this can be resolved quickly. > > As I explained above, IPP thought that Needs Attention was better as a > job state reason, rather than a job state, and then we renamed the reason > to printer-stopped to be clearer. > > I'm sorry that neither you nor Harry were able to call into the IPP > call last Wednesday. The ball is in yours and Harry's court to see if > you like the IPP approach and we can use it directly in JMP or whether > JMP should perform a straight forward mapping when instrumenting an IPP > system as I outlined above to the JMP held and/or JMP needsAttention states > and some fiddling with job-state-reasons. > RB> Again, I would support keeping both the needsAttention and held RB> states. These could easily be mapped to IPP. Comments? Ron Bergman Dataproducts Corp From hastings at cp10.es.xerox.com Tue May 27 12:36:25 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <9705271638.AA10573@zazen.cp10.es.xerox.com> If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom At 12:26 05/25/97 PDT, JK Martin wrote: >What happened to "pending" as a mandatory job state? I certainly hope >we don't relegate this important state to the "Conditionally Mandatory" >realm. > >> The current draft lists processing, needsAttention, canceled, and completed >> as Mandatory. Since needsAttention has gone away, that leaves three >> states as mandatory: processing, canceled, and completed. Since we added >> aborted, I assume that aborted should be added to the mandatory list. >> >> The complicance at the end of the Job MIB spec also lists these states. >> >> [...snip...] >> >> Tom > > From rbergma at dpc.com Tue May 27 11:37:28 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?] In-Reply-To: <199705251926.PAA18002@uscore.underscore.com> Message-ID: <9705271638.AA10573@zazen.cp10.es.xerox.com> Jay, The object jmJobState should be mandatory. All possible enums for this object must be reported if implemented and available to the agent. (I sent another email on this subject with more info earlier today.) Does this make more sense? Ron Bergman On Sun, 25 May 1997, JK Martin wrote: > What happened to "pending" as a mandatory job state? I certainly hope > we don't relegate this important state to the "Conditionally Mandatory" > realm. > > > The current draft lists processing, needsAttention, canceled, and completed > > as Mandatory. Since needsAttention has gone away, that leaves three > > states as mandatory: processing, canceled, and completed. Since we added > > aborted, I assume that aborted should be added to the mandatory list. > > > > The complicance at the end of the Job MIB spec also lists these states. > > > > [...snip...] > > > > Tom > From harryl at us.ibm.com Tue May 27 13:14:38 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <5030100002853647000002L072*@MHS> Good catch, Jay. Pending should certainly not have been removed from the mandatory list of job States. I assume this is just a slip-up. Tom, will you please confirm? >What happened to "pending" as a mandatory job state? I certainly hope >we don't relegate this important state to the "Conditionally Mandatory" >realm. >> The current draft lists processing, needsAttention, canceled, and completed >> as Mandatory. Since needsAttention has gone away, that leaves three >> states as mandatory: processing, canceled, and completed. Since we added >> aborted, I assume that aborted should be added to the mandatory list. Harry Lewis - IBM Printing Systems From jkm at underscore.com Tue May 27 13:17:36 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <199705271717.NAA07988@uscore.underscore.com> Ron, > > The IPP and JMP defintions of requiredResourcesNotReady, say "is not > > ready on any of the physical devices for which the job is a candidate" > > meaning before the job starts processing. Perhaps this reason should > > have a better name, like "requestedResourcesNotReady". > > > RB> I don't see any difference in "required" vs "requested". Yeah, I agree with you, unless someone can make a clear case for a difference in semantics between "requested" and "required" in this context. > > IPP says that when the reason 'printer-stopped' is present, the client > > should check the printer-state and printer-state-reasons. For JMP the > > analoguous thing is to check the job's deviceAlert attributes and the > > associated device MIB. > > > > But the IPP/JMP meeting also got rid of the held state. > > > RB> Have we eliminated too much? I'm wondering the same thing. (But have no opinion either way right now.) It just seems like we might be missing something here by eliminating HELD. > RB> Again, I would support keeping both the needsAttention and held > RB> states. These could easily be mapped to IPP. Comments? I tend to agree. However, exactly what is abstracted as a "state" versus a "reason" depends on exactly what problems we're trying to solve (and which paradigm to use to solve those problems), would you agree? We need to hash this out pretty quickly! ...jay From rbergma at dpc.com Tue May 27 11:08:38 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: <9705250944.AA10369@zazen.cp10.es.xerox.com> Message-ID: <199705271717.NAA07988@uscore.underscore.com> On Sun, 25 May 1997, Tom Hastings wrote: > The current draft lists processing, needsAttention, canceled, and completed > as Mandatory. Since needsAttention has gone away, that leaves three > states as mandatory: processing, canceled, and completed. Since we added > aborted, I assume that aborted should be added to the mandatory list. > RB> As you know, there is still some discussion regarding needsAttention. > The complicance at the end of the Job MIB spec also lists these states. > > I assume that you didn't intend to remove that agreement. > So I'd like to add back the description that some are mandatory and the > rest are conditionally mandatory. > RB> Exactly what does "mandatory" imply? Is the state only reported RB> if implemented? It seems like it would be difficult to report if it RB> is not implemented. Then what is the difference between "mandatory" RB> and "conditionally-mandatory"? I propose that jmJobState is really RB> what is "mandatory", not the possible values. All values possible RB> in an implementation must be supported. > I agree on removing redundant text. However, in this case, the > description in jmJobState was simply a pointer to the textual > convention (after deleteing the sentence: "The value of this object shall > always be the same as that of the jobState attribute, so that this information > appears in both the jmJobStateTable and the jmAttributeTable simultaneously". > since we agreed to get rid of duplicates. > RB> In trying to answer your question I cannot find where I saw the RB> duplicate text in jmJobState. I may have been looking at jobState RB> on page 35. Will this (jobState) be removed in the next draft? > So the real thrust of your comment was to move the description from > the textual convention to the object. So I'll add the sentence about > the mandatory states to the jmJobState object as well, ok? > RB> That was not my original intent, but it is a good move. See comment RB> above regarding mandatory. > Tom > > > > At 10:01 05/23/97 PDT, Ron Bergman wrote: > >Tom, > > > >In reviewing the Job MIB relative to the job states, I noticed that > >the descriptions for jmJobState and JmJobStateTC are almost identical. > >I would like the specification for jmJobState to appear only once, > >and only in the jmJobState description. I propose that these > >descriptions be revised as follows: > > > >jmJobState: > >----------- > >"The current state of the job (pending, processing, held, etc.). The > >final value for this attribute shall be either completed or canceled. > final value for this attribute shall be completed, canceled or aborted. > > >before the agent removes the job from the table. > > > >Management applications shall be prepared to receive all the standard > >job states. Servers and devices are not required to generate all job > >states, only those which are appropriate for the particular > >implementation. The corresponding attributes JmJobStateReasons1 through > >JmJobStateReasons4 provide additional information about the job states. > >While new job states cannot be added without impacting deployed clients, > >it is the intent that additional Job State Reasons enums can be defined > >without impacting deployed clients." > > > >JmJobStateTC: > >------------- > >"Defines the current state of the job." > > > > > >A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC. > >Again, my recommendation is: > > I'm assuming that we have agreed to make jobStateReasons1 mandatory, > in order that the 'printer-stopped' value will always be present (the > new representation for the old needsAttention state that was removed). > Since jobStateReasons1 is an INTEGER, not OCTETS, we will move it to > the jmJobTable right after the jmJobState object, so that the descriptions > will be next to each other. Its name will be jmJobStateReason1. > RB> It appears that this may occur, but I don't believe that an agreement RB> has been reached. We still need to resolve the "needsAttention" RB> issue. Note that These issues should not delay the posting of the RB> next draft update. > > I've done some further shortening of the description that you proposed. > How does it look? > > > > > > >jobStateReasons: > jmJobStateReasons1; > >---------------- > >---OCTETS: Additional information about the job's current state that > Additional information about the job's current state that > > >augments jmJobState. The jobStateReasons1 attribute identifies the > >reason or reasons that the job is in the held, pending, processing, > >needsAttention, canceled, or completed state. The agent shall indicate > >the particular reason(s) by setting the value of the jobStateReasons1 > >attribute. > augments jmJobState, including the reasons(s) that the job is in its > current state. > RB> Very good! > < When the job does not have any reasons for being in its > >current state, the agent shall set the value of the jobStateReasons1 > >attribute to 0. > > > >Companion job state reasons Textual Conventions: JmJobStateReasons2TC, > >JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an > >additional 93 job state reasons for use with the corresponding > >attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4. > Additional job state reasons may be represented by the attributes: > jobStateReasons2, jobStateReasons3, and jobStateReasons4. See page xxx. > > >This is a type 2 bit definition. > > > >JmJobStateReasons1TC: > >--------------------- > >"This textual-convention is used with the jobStateReasons1 attribute to > >provides additional information regarding jmJobState. > > > >The following standard values are defined (in hexadecimal) as powers of > >two, since multiple values may be used at the same time: > > > > > >If anyone objects to these changes, please respond by June 13. > > Ron Bergman Dataproducts Corp. From jkm at underscore.com Tue May 27 13:35:01 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <199705271735.NAA08751@uscore.underscore.com> Yep, you're right, Tom. If the device is totally single-threaded, then no job would ever be in a "pending" state. Your suggested wording (in the second paragraph) looks good to me. ...jay ----- Begin Included Message ----- Date: Tue, 27 May 1997 09:36:25 PDT To: jmp@pwg.org, JK Martin From: Tom Hastings Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?] Cc: ipp@pwg.org If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom At 12:26 05/25/97 PDT, JK Martin wrote: >What happened to "pending" as a mandatory job state? I certainly hope >we don't relegate this important state to the "Conditionally Mandatory" >realm. > >> The current draft lists processing, needsAttention, canceled, and completed >> as Mandatory. Since needsAttention has gone away, that leaves three >> states as mandatory: processing, canceled, and completed. Since we added >> aborted, I assume that aborted should be added to the mandatory list. >> >> The complicance at the end of the Job MIB spec also lists these states. >> >> [...snip...] >> >> Tom > > ----- End Included Message ----- From harryl at us.ibm.com Tue May 27 14:14:12 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <5030100002856254000002L042*@MHS> Even printers that don't spool or queue will typically "buffer" some number of pages. Given the possibility of single page jobs... then some jobs can be pending. I guess we should ask ourselves what it means to have a "mandatory" state. Just because a state is Mandatory does not mean an implementation must "force" jobs to enter that state. If that were so... I'd REALLY be in favor of eliminating the NeedsAttention state! ;-> Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 05/27/97 11:59 AM ------ jmp-owner@pwg.org 05/27/97 11:51 AM Please respond to jmp-owner@pwg.org @ internet To: jkm@underscore.com @ internet, jmp@pwg.org @ internet cc: ipp@pwg.org @ internet Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom From jkm at underscore.com Tue May 27 14:16:55 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?] In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?]> Message-ID: <199705271816.OAA10640@uscore.underscore.com> Ron, > The object jmJobState should be mandatory. All possible enums for this > object must be reported if implemented and available to the agent. (I > sent another email on this subject with more info earlier today.) > > Does this make more sense? Yes! I like your wording. Can everyone else agree to this? ...jay From harryl at us.ibm.com Tue May 27 14:41:32 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <5030100002857511000002L012*@MHS> Tom, you requested: >I've edited the list of Job Monitoring MIB objects and attributes >according to the San Diego meeting and subsequent e-mail. > >Please review and make any comment ASAP. I'm editing these changes now. Here are my comments: 1. What is the difference between jmJobSourcePlatformType and jobOriginatingHost? 2. I notice you deleted jobStateReasons1 and now treat it as a mandatory object in the JobTable. I don't recall this agreement. 3. Why did you remove Index from Physical device, OutputBin, colorant, and removed type from mediumRequested? Is this due to the fact that we have value as integer and octets? Harry Lewis - IBM Printing Systems From bwagner at digprod.com Tue May 27 14:47:04 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are t Message-ID: <5030100002857511000002L012*@MHS> I certainly can agree. I was rather wondering about all the discussion. It was my understanding that objects can be mandatory, not values of the object variable. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther Author: JK Martin at Internet Date: 5/27/97 2:16 PM Ron, > The object jmJobState should be mandatory. All possible enums for this > object must be reported if implemented and available to the agent. (I > sent another email on this subject with more info earlier today.) > > Does this make more sense? Yes! I like your wording. Can everyone else agree to this? ...jay From hastings at cp10.es.xerox.com Tue May 27 15:40:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> Updated IPP job-state/job-state-reasons & JMP Message-ID: <9705271942.AA10760@zazen.cp10.es.xerox.com> I've cross-posted 5 files dealing with the agreements and updated text on the IPP "job-state" and "job-state-reasons" attributes and the corresonding JMP jmJobState and jmJobStateReason1 objects in: ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 67224 May 27 19:17 jobstate.pdf -rw-r--r-- 1 pwg pwg 40694 May 27 19:31 jobstate.txt -rw-r--r-- 1 pwg pwg 102901 May 27 19:17 jobstatr.doc -rw-r--r-- 1 pwg pwg 121920 May 27 19:17 jobstatr.pdf -rw-r--r-- 1 pwg pwg 125261 May 27 19:18 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 67224 May 27 19:25 jobstate.pdf -rw-r--r-- 1 pwg pwg 40694 May 27 19:25 jobstate.txt -rw-r--r-- 1 pwg pwg 102912 May 27 19:25 jobstatr.doc -rw-r--r-- 1 pwg pwg 121956 May 27 19:26 jobstatr.pdf -rw-r--r-- 1 pwg pwg 125293 May 27 19:26 jobstatr.pdr The *.doc files are MS-WORD V6.0a The jobstate.* are with revisions accepted (i.e., no revisions marks). The jobstatr.* are with revisions marked from the current texts of IPP and JMP. The jobstatr.pdf has black revision marks and the jobstatr.pdr file has red revision marks. These results are from the joint IPP/JMP telecon last Wednesday, May 21. There is an IPP issue listed below and in the document which Carl-Uno said we could handle on the IPP telecon, tommorrow, Wed, May 28, if it takes a short time. If it takes longer, we will need to setup a separate IPP Model telecon, since the major discussion for the IPP telecon will be the new protocol document. There is also a JMP issue listed below that could be handled at this separate IPP Model telecon, if the JMP issue listed below need discussion. JMP people, Please read these files to make sure you agree with the agreements we reached last week on IPP and their impact on JMP. It would be good to see if we have agreement between IPP and JMP on these crucial job state and job state reasons attributes (which are JMP SNMP objects). If you have problems, please raise them on the IPP and JMP DLs so that we can decide how to process the issues at the IPP telecon tommorrow: May 28 ------ Call-in: 1-309-671-1035, 1-3pm PDT (4-6pm EDT) Access: 190148 NOTE: A different number from usual IPP numbers. Thanks, Tom Here is the beginning of the files that I posted (you'll have to pull the files to see the actual revised texts for IPP and JMP): Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 5/25/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) I carried out the JMP action item to schedule the discussion about aligning the job state and job state reasons between IPP and JMP, Wednesday, 21 May, 1-3pm PDT. We came to a good agreement taking the best ideas from each. Unfortunately, Ron and Harry were not in on the call. There is one IPP Issue and one JMP issue listed below. I'm attempting to include any rough consensus generated on the e-mail list since last Wednesday's meeting as well. I've included Ron's suggestions to eliminate duplication between the object and textual convention descriptions and to put more explanation in the objects and less in the textual conventions in the process. I've re-ordered the job-state-reasons to be in the order that jobs normally proceed by job states. This will help with understanding that Jay requested about "the day in the life of a job". I've also attempted to make each job state and job state reason more concise without changing the meaning. If any Job Monitoring MIB participants disagree with the agreements, please send e-mail ASAP, since I'm editing the agreements into the Job Monitoring MIB. Talking to Scott, I have taken the "job-state", "job-state-reasons", and "job-state-message" attribute sections from IPP and edited in the changes with revision marks. After each edited IPP section, I've edited corresponding Job Monitoring MIB TC and object or attribute section. I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP e-mail discussion indicated that it should be MANDATORY. The remaining jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as attributes in the jmAttributeTable. (No attributes in the attribute table are MANDATORY, except jobOwner, and we are discussing means to make jobOwner an object in a MANDATORY table, somehow, possibly using the jmJobIDTable.) IPP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the Internet-Draft, there is a conflict between the semantics of the 'processing' state specified under the "job-state" attribute and the "job-state-reasons" values: 'job-sending-to-output-device' and 'job-queued- in-output-device' which we agreed to combine into: 'job-outgoing'. JMP ISSUE - generic job-held job state reason vs. adding held job state ---------------------------------------------------------------------- when the job is in the pending state to allow job monitoring applications to be able to distinguish between job state reasons that prevent the job from being a candidate for processing from those that are just purely informational without knowing the particular reason (which may be a newly registered reason that the application couldn't have known about). IPP solves this problem by changing the keyword values for reasons that keep the job from being a candidate for processing to all begin with 'job-hold-'. But the Job Monitoring MIB uses enum codes, not keywords, so there isn't a good way for the agent to indicate such a distinction to an application. There are two possibilities: 1. Add a generic jobHeld value to the JMP JmJobStateReasons1TC which an agent shall set in addition to the specific reason that keeps the job from being a candidate for processing, i.e., the agent shall set jobHeld along with jobHoldUntilSpecified, jobProcessAfterSpecified, and jobHoldUntilResourcesAreReady reasons. 2. Instead of introducing the generic jobHeld value, add back the held job state to JMP (and leave IPP without the 'held' state, since the reason values are distinguishable to an application from the 'job-hold-' keyword prefix. I've written up alternative 1, since it is a superset of IPP. However, alternative 2 is a simple alternative. Since the JMP agent is only reflecting job state and not implementing a job state machine, the complexity of another job state is not such a problem for implementing an agent and is somewhat easier for the application. Summary of IPP and JMP job state and job state reasons agreements ------------------------------------------------------------------ Here is the summary of the job state and job state reasons agreements: 1. In JMP remove the 'held', 'printing', and 'needsAttention' states. 2. In both IPP and JMP add the 'aborted' state and make it a final state. 3. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 4. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' states and make 'canceled' and 'aborted' final states, like the JMP 'canceled' and 'completed' states. So the simplified state transition diagram for IPP and JMP was agreed to be: New state Old state (3) (4) 5) (6) (7) yes yes pending(3) yes yes processing(4) yes yes yes canceled(5) yes aborted(6) yes completed(7) yes Generally state transitions are from left to right. A blank entry indicates unlikely, but allowed, transitions. The following diagram is simpler to understand than the table, so lets replace the above table with the following in both IPP and JMP: +--> canceled / pending --> processing --+----> aborted \ +--> completed Normally a job progresses only from left to right through three states. Conformance Requirements for job states --------------------------------------- JMP requires that processing(4), aborted(6), and completed(7) are mandatory, so that pending(3), canceled(5), and unknown(2) are conditionally mandatory. (IPP level 1 does not have CancelJob, so we have to make the canceled state conditionally mandatory in JMP in order to instrument a level 1 IPP system.) The former JMP needsAttention state was also mandatory, so that the equivalent new job-state-reason: deviceStopped, is a mandatory value of the JMP jmJobStateReasons1 object. The deviceStopped value aligns with the IPP 'printer-stopped' value of the "job-state-reasons" attribute, but we are trying to be more general in JMP, so we use the word 'device', not 'printer'. If deviceStopped is a MANDATORY reason, then the jobStateReasons1 attribute becomes MANDATORY. Therefore, the jobStateReasons1 JMP attribute moves to the jmJobTable, since it is an Integer, not Octets, and will be called the jmJobStateReasons1 object. The other 3 jobStateReasonsN (N=2, 3, and 4) will remain in the jmJobAttributeTable as conditionally mandatory attributes. There were two major reasons that IPP replaced the 'needs-attention' state with the 'printer-stopped' job-state-reason: 1. IPP felt it was as important for a user to know that the printer that their job was waiting for was stopped, as it was for the user whose job was the current job. Therefore, whether the job was in the 'pending' or 'processing' state we wanted to indicate that the printer had stopped for the job. Therefore, need-attention is really a reason, not a state. If needs-attention were a job state, when the printer resumes, the job would go back to either 'pending' or 'processing', depending on which state the job had been in previously. Remembering which previous state was a problem. Also the user should know whether his job was the current one or some other users was the current job, since in an unattended shop, the onus might be on the current user to fix the problem. By keeping the job in the same state ('pending' or 'processing'), instead of moving the job to a different 'needs-attention' state and setting the job-state-reason, there was no need to remember the previous state. 2. The job state reason was renamed from 'needs-attention' to 'printer-stopped', because the printer might need attention but the current job could still make progress because the printer hasn't stopped. For example, toner low or media low or an input tray is empty, but the current job is not using that tray. Also the operator might have intentionally stopped the printer, so needs-attention would be misleading. You'll have to copy the files from ftp://ftp.pwg.org/pub/pwg/ cited above in order to see the actual text changes to IPP and JMP. Tom From peter_zehler at ocp.mc.xerox.com Tue May 27 15:45:27 1997 From: peter_zehler at ocp.mc.xerox.com (Peter Zehler) Date: Wed May 6 14:00:05 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the> Message-ID: <01BC6AB5.00D1B720@HORTON> Tom, You wrote: If a simple output device implements IPP and doesn't queue or spool, wouldn't the jobs in that output device never be in pending? Such a device would refuse acceptance of another job, while it was processing its current job. That is why pending is conditionally mandatory in IPP and therfore also in JMP. Would it help to indicate that if an implementation queues or spools, that it shall implement the 'pending' state jobs that are queued or spooled but are not yet processing? Tom [PZ] I am implementing IPP in a small printer that does not spool simple print jobs. There can be a time when an entire print job is accepted by the IPP printer and the back end of the physical printer is not yet ready to process the job. At this point the job is blocked pending service by the backend print system. The IPP channel may accept only one job at a time. The print device may service multiple print channels. From the time the job is accepted by the IPP printer until the job is passed onto the native print system the IPP state would be pending. I would not claim a job sitting in memory blocked on the submission to the native print system is queued or spooled. Pete From hastings at cp10.es.xerox.com Tue May 27 16:05:45 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <9705272007.AA10794@zazen.cp10.es.xerox.com> At 11:41 05/27/97 PDT, Harry Lewis wrote: >Tom, you requested: > >>I've edited the list of Job Monitoring MIB objects and attributes >>according to the San Diego meeting and subsequent e-mail. >> >>Please review and make any comment ASAP. I'm editing these changes now. > >Here are my comments: > >1. What is the difference between jmJobSourcePlatformType and > jobOriginatingHost? jobSourcePlatformType (and corresponding JmJobSourcePlatformTypeTC) is the type of system, and is an enum (one of the reasons that I like "Type" in the object or attribute name) e.g. UNIX, Windows, etc. jobOriginatingHost is the name of the host, not its type, e.g., a string that was assigned to the host by an administrator. See IPP. This was one of the IPP attributes that we agree to pick up into JMP at San Diego. >2. I notice you deleted jobStateReasons1 and now treat it as a mandatory > object in the JobTable. I don't recall this agreement. It was not agreed to at San Diego, but the resulting e-mail discussion seemed to indicate that a few values are mandatory, so I moved it from the attribute table to be a real object, since it was only an integer following our agreed principle in San Diego of moving mandatory attributes to the jmJobTable, at least the integer ones. If there is a problem with this, then I can move it back. But I think this is also involved with the needsAttention state vs. deviceStopped jmJobStateReasons1 value disucssion. >3. Why did you remove Index from Physical device, OutputBin, colorant, > and removed type from mediumRequested? Is this due to the fact that > we have value as integer and octets? Yes, as we agreed in San Diego to combine these. So I had to drop the data type from the name. Any other suggestions for the name? Do you find this confusing that the name doesn't indicate that there are two possibl representations and that both can be used together? > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Tue May 27 16:49:22 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:> Message-ID: <9705272051.AA00352@zazen.cp10.es.xerox.com> Peter, How long would a job be in the pending state in your non-queuing, non-spooling IPP system? If the time is not noticable to humans, e.g., 100s of miliseconds, I would think that there wan't much point in simplementin the IPP state of 'pending'. If it was longer, so that end-users would see it for a while, while nothing was happending on the printer, then it would be good to implemente the IPP 'pending' state for your Printer object. So your point was not that 'pending' must be a Mandatory state, but that in your implementation of a simple, non-queuing, non-spooling printer you wanted to be able to implement 'pending'. So we just have to find language that permits non-queuing, non-spooling printers to implement 'pending', but doesn't require it. On the other hand, it might be simpler to mandate the 'pending' state and for implementations that don't queue or spool, the state would never be visible or would be visible for a very short period of time. Tom At 12:45 05/27/97 PDT, Peter Zehler wrote: >Tom, >You wrote: >If a simple output device implements IPP and doesn't queue or spool, wouldn't >the jobs in that output device never be in pending? Such a device would >refuse acceptance of another job, while it was processing its current job. >That is why pending is conditionally mandatory in IPP and therfore also in >JMP. > >Would it help to indicate that if an implementation queues or spools, >that it shall implement the 'pending' state jobs that are queued or spooled >but are not yet processing? > >Tom > >[PZ] I am implementing IPP in a small printer that does not spool simple >print jobs. There can be a time when an entire print job is accepted by >the IPP printer and the back end of the physical printer is not yet ready to >process the job. At this point the job is blocked pending service by the >backend print system. >The IPP channel may accept only one job at a time. The print device may >service multiple print channels. From the time the job is accepted by the IPP >printer until the job is passed onto the native print system the IPP state would >be pending. I would not claim a job sitting in memory blocked on the submission >to the native print system is queued or spooled. >Pete > > From harryl at us.ibm.com Tue May 27 16:58:23 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:05 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <5030100002864230000002L002*@MHS> I like Ron's wording... > The object jmJobState should be mandatory. All possible enums for this > object must be reported if implemented and available to the agent. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue May 27 17:13:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <9705272115.AA00386@zazen.cp10.es.xerox.com> Harry, Here is some discussion on this topic that we had in IPP (and that appears in the jobstate.* files I posted today): Conformance Requirements for job states --------------------------------------- JMP requires that processing(4), aborted(6), and completed(7) are mandatory, so that pending(3), canceled(5), and unknown(2) are conditionally mandatory. (IPP level 1 does not have CancelJob, so we have to make the canceled state conditionally mandatory in JMP in order to instrument a level 1 IPP system.) The former JMP needsAttention state was also mandatory, so that the equivalent new job-state-reason: deviceStopped, is a mandatory value of the JMP jmJobStateReasons1 object. The deviceStopped value aligns with the IPP 'printer-stopped' value of the "job-state-reasons" attribute, but we are trying to be more general in JMP, so we use the word 'device', not 'printer'. If deviceStopped is a MANDATORY reason, then the jobStateReasons1 attribute becomes MANDATORY. Therefore, the jobStateReasons1 JMP attribute moves to the jmJobTable, since it is an Integer, not Octets, and will be called the jmJobStateReasons1 object. The other 3 jobStateReasonsN (N=2, 3, and 4) will remain in the jmJobAttributeTable as conditionally mandatory attributes. There were two major reasons that IPP replaced the 'needs-attention' state with the 'printer-stopped' job-state-reason: 1. IPP felt it was as important for a user to know that the printer that their job was waiting for was stopped, as it was for the user whose job was the current job. Therefore, whether the job was in the 'pending' or 'processing' state we wanted to indicate that the printer had stopped for the job. Therefore, need-attention is really a reason, not a state. If needs-attention were a job state, when the printer resumes, the job would go back to either 'pending' or 'processing', depending on which state the job had been in previously. Remembering which previous state was a problem. Also the user should know whether his job was the current one or some other users was the current job, since in an unattended shop, the onus might be on the current user to fix the problem. By keeping the job in the same state ('pending' or 'processing'), instead of moving the job to a different 'needs-attention' state and setting the job-state-reason, there was no need to remember the previous state. 2. The job state reason was renamed from 'needs-attention' to 'printer-stopped', because the printer might need attention but the current job could still make progress because the printer hasn't stopped. For example, toner low or media low or an input tray is empty, but the current job is not using that tray. Also the operator might have intentionally stopped the printer, so needs-attention would be misleading. To help distinguish between your interpretation of requiredResourcesNotReady, IPP changed the reason to jobHeldUntilResourcesAreReady with the following description: Optional. At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical printer's for which the job is a candidate. Usually such a condition is detected while the job is in the 'pending' state. If a job starts processing and encounters a resource that is not ready, there are two possible implementations: (1) the device is stopped and no jobs can run until the resource(s) are made ready, in which case the Printer shall keep the job in the 'processing' state and shall add the 'printer-stopped' reason to the job's "job-state-reasons" attribute (not the 'job-hold-until-resources-are-ready' value) OR (2) another job is found to use the device while the current job goes back to waiting for its turn and for the resources to be made ready, in which case the Printer shall change the job's "job-state" attribute to 'pending' and add the 'job-hold-until-resources-are-ready' value to the job's "job-state-reasons" attribute.Applicable job states: 'pending'. Here is the corresponding description that I put into the Job Monitoring MIB for the jobHeldUntilResourcesAreReady: At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate.Usually such a condition is detected while the job is in the pending state. If a job starts processing and encounters a resource that is not ready, there are two possible implementations: (1) the device is stopped and no jobs can run until the resource(s) are made ready, in which case the agent shall keep the job in the processing state and shall add the deviceStopped reason to the job's jmJobStateReasons1 object OR (2) another job is found to use the device while the current job goes back to waiting for its turn and for the resources to be made ready, in which case the Printer shall change the job's jmJobState object to pending and add the jobHoldUntilResourcesAreReady value to the job's jmJobStateReasons1 object. Job states: pending, jobHeld shall be set. Does this help? Tom At 16:42 05/22/97 PDT, Harry Lewis wrote: >Some of the job state reasons for HELD seem like they would fit better as >reasons for NEEDS-ATTENTION. For example: > > requiredResourcesNotReady 0x20 > The job is in the held state because at least one of the > resources needed by the job, such as media, fonts, resource > objects, etc., is not ready on any of the physical devices > for which the job is a candidate. > > > serviceOffLine 0x400000 > The service/document transform is off-line and accepting no > jobs. All pending jobs are put into the held state. This > could be true if its input is impaired or broken. > >These reasons seem categorically different than "Someone put this >job on Hold 'till midnight". > >I guess it is fairly clear that state NeedsAttention should pertain to >actual DEVICE failures, but 0x400000, above, sounds like it could >be just that to me. serviceOffLine is a particular type of device failure: the device is no longer contactable either because it is broken or because the operator has decided that it is down. Perhaps it has to be painted. The "could be true, is an example of why the device might be off-line, not the only reason. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Tue May 27 17:18:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <9705272120.AA00389@zazen.cp10.es.xerox.com> >Return-Path: >Date: Thu, 22 May 1997 17:54:27 PDT >From: JK Martin >To: harryl@us.ibm.com >Subject: Re: JMP> HELD vs NEEDS-ATTENTION >Cc: jmp@pwg.org >X-Sun-Charset: US-ASCII >Sender: jmp-owner@pwg.org > >You raise a good point, Harry. I think we really want the user >to be able to distinguish between jobs not printing due to problems >vs. administrative "hold" (no matter who put the job on hold). > >One definition we'll have to nail down is NEEDS-ATTENTION. Does >that term imply device-only problems, or any kind of problem that >keeps the job from printing (other than HELD)? > >Given your statements, I'd vote for having NEEDS-ATTENTION imply >_any_ kind of problem, and not just device-related problems. This confusion as to what "NEEDS-ATTENTION" might mean is why IPP change the name from needs-attention to printer-stopped and changed it from a job state to a job-state-reason, since the printer can stop whether you are the current job or just one of the hapless waiting in the pending state. > >Similarly, I'd suggest that HELD implies an administratively-set >condition only. In the updated IPP and JMP, we don't have a held state, but several of the job-state-reasons indicate that the job can't be run and usually because the user or the administrator took some action or specified some resource that isn't ready. Ok? Tom > >Quick comments/votes by the others? (Tick, tick, tick...) > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Thu May 22 19:41 EDT 1997 >From: Harry Lewis >To: >Subject: JMP> HELD vs NEEDS-ATTENTION >Date: Thu, 22 May 1997 19:42:38 -0400 > >Some of the job state reasons for HELD seem like they would fit better as >reasons for NEEDS-ATTENTION. For example: > > requiredResourcesNotReady 0x20 > The job is in the held state because at least one of the > resources needed by the job, such as media, fonts, resource > objects, etc., is not ready on any of the physical devices > for which the job is a candidate. > > > serviceOffLine 0x400000 > The service/document transform is off-line and accepting no > jobs. All pending jobs are put into the held state. This > could be true if its input is impaired or broken. > >These reasons seem categorically different than "Someone put this >job on Hold 'till midnight". > >I guess it is fairly clear that state NeedsAttention should pertain to >actual DEVICE failures, but 0x400000, above, sounds like it could >be just that to me. > >Harry Lewis - IBM Printing Systems > > >----- End Included Message ----- > > From hastings at cp10.es.xerox.com Tue May 27 17:35:13 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:05 2009 Subject: JMP> ISSUE: Putting jobOwner in the jmJobIDTable? In-Reply-To: ISSUE: Putting jobOwner in the jmJobIDTable?> Message-ID: <9705272137.AB00408@zazen.cp10.es.xerox.com> Jay, Does Harry's suggestion to put the jobOwner in the jmJobIDTable as another form of job submission ID> Presumably, the jobOwner would also go in the jmAttributeTable too, where it would be for any jobsubmission id format, ok? The reason for duplicating the jobOwner in the jmJobIDTable is because the persistence is longer (same as the jmJobTable) than in the jmAttributeTable. This idea will work for those systems that don't support the idea of a jobSubmissionID that is a unique ID generated by the client or the server/printer. So are there any applications that would need both the real job submission id and the job owner, after the jmAttributeTable entry as been deleted? If applications copy the jobOwner sometime while the job is pending, processing, or completed, before the attributes are deleted, there won't be a problem. But if applications are memoryless and don't copy the attribute table, then the jobOwner would be lost, except for systems that don't have a real job submission id and use the job owner as the job submission id. One BIG problem with Harry's solution is that if the same user submits another job, the jobOwner will be the same, so that that would replace the previous row in the jmJobIDTable, since jmJobSubmissionIndex is a 32-octet index into the table. A solution would be to add another index to the jmJobIDTable, which would be the jmJobIndex, so that the agent could guarrantee that each entry wouldn't overwrite a previous entry. We do this in our Xerox private Job Monitoring MIB. Comments? Tom At 07:38 05/23/97 PDT, Harry Lewis wrote: >Jay, I think you have answered my question... you *are* concerned about >tracking job progress and notifying clients even though you are "out of band". >Given this, I think I see why you need jobOwner to have the greatest >persistence (although, honestly, I fear this is Pandora's box, and soon, we >will learn that jobOwner is really not enough - if this is likely, I'd rather >it surface NOW!). > >So, what about my proposal to add a new jmJobSubmissionID format for LPR >JobOwner? The owner information would have to be truncated to 30 bytes and >someone, most likely the NIC, would have to prepend the assigned >jmJobSubmissionID format number to the attribute. > >By definition, the JobID table has the same persistence as the Job Table - each >guaranteed to have the longest persistence. > >Harry Lewis - IBM Printing Systems > > >---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 06:11 PM > --------------------------- > > jkm@underscore.com > 05/22/97 05:56 PM >Please respond to jkm@underscore.com @ internet > > >To: Harry Lewis/Boulder/IBM@IBMUS >cc: jmp@pwg.org @ internet >Subject: Re: JMP> Changes agreed to for Job Monitoring MIB last week, > >[I have changed the Subject line to better reflect the topic] > >Harry, > >This statement has me somewhat bothered regarding which master we >are trying to serve with the Job MIB in general: > >> Yes, we realized after Dave and Jay had left the meeting, that the size >> of jmJobOwner blows away the notion of keeping the Job Table terse. > >What do you want? Good grammer or good taste?... ;-} > >Seriously, some of us firmly believe in the importance of "out of band" >job monitors (ie, processes monitoring job progression without being >intrinsically part of the printing process, a la Unix and VMS). The >only consistent way to indentify jobs is through jobOwner, and hence, >this data must be available for as long as the job entry exists in the >agent. > >Those who will be using the Job MIB as an intrinsic part of the >printing process are lucky (eg, Windows, OS/2, etc). (We envy you, >believe us!) If someone can state a justifiable case for being able to >monitor jobs with jobOwner, then great! (And please do so soon!) >Otherwise, we need that data for the duration of the job entry. > > ...jay > >Harry Lewis - > > From Robert.Herriot at Eng.Sun.COM Tue May 27 17:39:37 1997 From: Robert.Herriot at Eng.Sun.COM (Robert Herriot) Date: Wed May 6 14:00:05 2009 Subject: JMP> IPP>MOD HELD vs NEEDS-ATTENTION Message-ID: <199705272139.OAA06575@woden.eng.sun.com> There has been a lot of discussion on the JMP list about the held and needs-attention state. Several people have stated that the primary reason for having 'held' and 'needs-attention' as job-states rather than job-state-reason is that the job-state should be all that most people need to look at. Keeping that in mind, here's is an slightly different view that we should perhaps consider. I put this forth for discussion and can see pro's and con's for keeping the simple 5 job-states of IPP versus adding these two additional states. The Proposal: Change the name of "needs-attention" to "stopped-printing" and define the "stopped-printing" state as an alternate view of the "processing" state. A job is in the "stopped-printing" state when certain job-state-reasons take it out of the "processing" state temporarily. When those reasons clear, the job goes back to the "processing" state. Likewise, the "held" job-state is an alternate view of the "pending" state. A job is in the "held" state when certain job-state-reasons take it out of the "pending" state temporarily. When those reasons clear, the job goes back to the "pending" state. Such reasons include "held-until" (aka "job-hold-until-specified"), "held-for-resources" (aka "required-resources-not-ready"), and "printer-stopped". Any reasons that keeps a job from making progress towards the printer put it in the "held" state. Any reasons that keep a job from processing put it in the "stopped-printing state. Note that the "printing-stopped" reason changes a "processing" job to "stopped-printing" and a "pending" job to a "held" job. If we want more regular names, then we should call "held", "pending-stopped" and we should call "stopped-printing", "processing-stopped". Note: I do not like the name "needs-attention" because it is the printer that needs attention and not the job. Furthermore, the printer may need attention even when a particular job is pending. Comments? Bob Herriot From hastings at cp10.es.xerox.com Tue May 27 17:38:12 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Should jobStateReasons1 be mandatory? In-Reply-To: Should jobStateReasons1 be mandatory?> Message-ID: <9705272140.AA00416@zazen.cp10.es.xerox.com> Harry, It was on this mail and Jay's that I concluded we had JMP agreement on making jobStateReasons1 attribute mandatory and I made the second step of moving it to the jmJobTable, as we agreed for all mandatory attributes in San Diego. Making it mandatory also agrees with IPP. Tom At 11:40 05/23/97 PDT, Harry Lewis wrote: >Yes, I'm saying that jobStateReasons is something a DPA server might know about >but not (practically) many printers. > >>Your comments lead me to believe you're saying that it's too damn >>difficult for the printer agent to say what the current "reason" is. >>Is this true? If it is, then I think we're in real deep water here. > >There are 4 sets of jobStateReasons... just look at the first (presumably >most importatn?) set... > > canceledByUser, canceledByOperator, abortedBySystem, logfilePending, > jobRetained etc. > >>I just went thru the V0.81 draft, but couldn't find 7.5 pages of >>Job State Reasons in the MIB. Can you give me a better pointer? >>(Am I looking at the proper draft?) I did find some tables on >>various Reasons (pp. 57-58), but I guess I don't see the problem. > >In v0.81 the PDF version (I think) see pages 49-56. > >Harry Lewis - IBM Printing Systems > > > > From hastings at cp10.es.xerox.com Tue May 27 17:49:08 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <9705272151.AA00449@zazen.cp10.es.xerox.com> At 13:04 05/23/97 PDT, STUART@kei-ca.ccmail.compuserve.com wrote: >I agree that "Needs Attention" is an important state which should not be >removed from jmJobState, but I think it is very important to have alignment >with IPP. So we just have to get IPP to come around to our way of thinking >:-) So we needed you on the agreed to joint IPP/JMP call last Wendesday. > >Ron, you didn't mention that the IPP job states do not include held >(pending, processing, cancelled, aborted, and completed). I believe there >is also an important distinction between held and pending and that there >should be both held and pending states. Again, JMP can have additional states, not in IPP, if we want to. So JMP could have the held state and the needs-attention state, if we want to with a clear mapping for an agent to use that is instrumenting an IPP system. However, I had the sense from JMP that we wanted to align more directly with IPP and only have additional reasons, not additional states, so that is what I have written up for JMP. > >I think the jmJobStates of Held, Pending, Processing, Needs Attention, >Cancelled, and Completed are the best at providing the necessary >information WITH A SINGLE OBJECT. As Harry has said, most printer agents >can tell the whole story (as they know it) with just these job states. But what about the pending job that is waiting for a printer that has stopped printing the current job? The problem with needs-attention as a state, in stead of a reason, is that it only can be for the current job, not the pending jobs (Unless all the pending jobs jump into the needs-attention state too, which I hadn't thought anyone wanted, since that would lose the information as to which job or jobs were actually currently printing). > The >JobStateReasons are things the printer agent typically doesn't know about. Isn't the job of the agent to map what ever state information it can get from the device to the MIB? So if the agent has to map the information to a reason or to a state, its the same amount of work. > >Perhaps IPP is hung up on the semantics such as that a hold is really a >reason it is pending. I can perhaps see the theoretical justification for >having held as a reason for the state pending. But, I believe users, as >opposed to us grizzled standards developers, would immediately see the >utility of having held as a separate state from pending, with pending >applying only to jobs that are waiting and have not been put on >administrative hold. The user may then choose to see the reason why it is >held or pending. This same arguement applies to the Needs Attention state >as opposed to making Needs Attention a reason under the one of the other >states. It is just more useful to have Held and Needs Attention as job >states rather than reasons! The MIB isn't the UI for the user (though many applications just map the MIB to a UI.) So an application could show any reason as a state, if it wanted to. > >Stuart Rowley >Kyocera Electronics, Inc. > > >______________________________ Reply Separator _________________________________ > > > >I agree with all the changes proposed for alignment of the IPP and >JMP job states except for the removal of "Needs Attention". This >should be the most important state to indicate to a user since >unless he takes action the job may never complete. I would think >that this would also be very important for IPP as well. > >I also agree with Harry that "requiredResourcesNotReady" and >"serviceOffLine" apply better to "Needs Attention" than "Held". >(I also agree with Harry that "Printing" is a better description >for a user than "Processing". Since this is an enum, a user or >management ap can display whatever text that is deemed >appropriate. So I will vote to keep "Processing" unless there >is very strong support for "Printing".) > >(Didn't we discuss "serviceOffLine" in a previous meeting and >determined that no one except Dataproducts has ever implemented >such a capability? I also indicated that I had recently deleted >the feature because I felt it was "stupid".) > >Also, I agree with Jay that "Needs Attention" should apply to all >conditions, other than "Held", that prevents the job from printing. >"Held" only implies an administratively set condition. > >Tom, since I could not participate in the Wednesday conference call, >could you explain why "Needs Attention" was not accepted by IPP? >It is very critical that JMP and IPP agree in this area and I would >hope this can be resolved quickly. > > > Ron Bergman > Dataproducts Corp > > > > > From Angelo_Caruso at wb.xerox.com Tue May 27 18:05:04 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:06 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <9705272151.AA00449@zazen.cp10.es.xerox.com> There seem to be two extremes on this whole issue. On the one side there are those who would like all their favorite states included in one easy to use job state object. On the other side are those who want to keep the job state object ultra simple and have lots of job state reasons. Both points of view have been backed up by many good arguments. Last week at the IPP teleconference it seemed that a reasonable COMPROMISE was reached. Unfortunately, several key JMP folks were not present for that discussion and now we're waffling on the whole issue again. Based on todays mail volume there does not appear to be any end in sight. For the record, here is my position. IPP and JMP should use EXACTLY the same set of job states and the same state reasons (the agreement reached at the last IPP/JMP teleconference seemed reasonable to me). How are we to expect the PWG to be taken seriously if we simultaneously create two specifications with different job models? The rest of the world expects and deserves a consistent set of standards from this working group! Please don't respond again how easy it is to map between the two different state models. I understand the mapping because I have been following the discussions. But the rest of the world will not find the mapping to be so obvious. If we learned anything from the Printer MIB interop testing it is that interpreting ONE model correctly is hard enough. Now, we are on the verge of generating two different models to represent the same thing. It's time to find a compromise. Thanks, Angelo From hastings at cp10.es.xerox.com Tue May 27 18:06:53 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <9705272209.AA00467@zazen.cp10.es.xerox.com> At 06:39 05/27/97 PDT, Ira Mcdonald x10962 wrote: >Hi Tom, Tuesday (27 May 1997) > >>Date: Sun, 25 May 1997 02:42:53 PDT >>To: jmp@pwg.org >>From: Tom Hastings >>Subject: JMP> List of updated JMP objects and attributes >> >>I've edited the list of Job Monitoring MIB objects and attributes >>according to the San Diego meeting and subsequent e-mail. >> >>Please review and make any comment ASAP. I'm editing these changes now. >> >>ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >>-rw-r--r-- 1 pwg pwg 31232 May 25 09:32 obj-attr.doc >>-rw-r--r-- 1 pwg pwg 17717 May 25 09:31 obj-attr.pdf >>-rw-r--r-- 1 pwg pwg 4377 May 25 09:38 obj-attr.txt >> >>The .doc and .pdf files have revision marks. The .txt file does not and >>is also attached: > >Thanks for this summary list. My comments: > >1) 'jobSourceChannelType' - request we add this attribute parallel to > 'jobSourceChannelIndex' for support of systems which don't implement > the Printer MIB - also much more useful attribute for accounting; I wanted to combine these too, but they are both integers, so we can't. We can only combine an integer attribute with an octets attribute. > >2) 'jmJobKOctertsRequested' - spelling error; Thanks. > >Cheers, >- Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > > From harryl at us.ibm.com Tue May 27 20:16:41 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Should jobStateReasons1 be mandatory? In-Reply-To: Should jobStateReasons1 be mandatory?> Message-ID: <5030100002874724000002L042*@MHS> So, let me understand... >Harry, >It was on this mail and Jay's that I concluded we had JMP agreement on >making jobStateReasons1 attribute mandatory and I made the second >step of moving it to the jmJobTable, as we agreed for all mandatory >attributes in San Diego. Making it mandatory also agrees with IPP. >Tom You are proposing that jmJobTable contain a mandatory OID for jobStateReasons1. But, if, of the 20 reasons specified, a printer can only "detect" the 4 that I have marked with (*), below, that's acceptable, right? *other *unknown *no reason (all zeros) documentsNeeded jobHoldSet jobProcessAfterSpecified requiredResourceNotReady *successfulCompletion completedWithWarnings completedWithErrors canceledByUser canceledByOperator abortedBySystem logfilePending logfileTransferring jobPreProcessing jobPaused jobInterrupted jobRetained jobHoldUntil Harry Lewis - IBM Printing Systems From imcdonal at eso.mc.xerox.com Tue May 27 21:27:12 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:06 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <9705280127.AA23159@snorkel.eso.mc.xerox.com> Hi Tom, I realize we can't combine two attributes of integer type. My point was that the (missing) attribute 'jobSourceChannelType' is generally more interesting than 'jobSourceChannelIndex' anyway, so could we please add it, separately? Thanks - Ira McDonald (outside consultant at Xerox) >-------------------------- Included Message ---------------------------< Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA23083; Tue, 27 May 97 18:18:49 EDT Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA08728; Tue, 27 May 97 18:16:11 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <16437(3)>; Tue, 27 May 1997 15:16:18 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03050 for ; Tue, 27 May 1997 18:12:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 27 May 1997 18:10:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02812 for jmp-outgoing; Tue, 27 May 1997 18:09:40 -0400 (EDT) Message-Id: <9705272209.AA00467@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 15:06:53 PDT To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) From: Tom Hastings Subject: Re: JMP> List of updated JMP objects and attributes Cc: jmp@pwg.org Sender: jmp-owner@pwg.org Status: R At 06:39 05/27/97 PDT, Ira Mcdonald x10962 wrote: >Hi Tom, Tuesday (27 May 1997) > >>Date: Sun, 25 May 1997 02:42:53 PDT >>To: jmp@pwg.org >>From: Tom Hastings >>Subject: JMP> List of updated JMP objects and attributes >> >>I've edited the list of Job Monitoring MIB objects and attributes >>according to the San Diego meeting and subsequent e-mail. >> >>Please review and make any comment ASAP. I'm editing these changes now. >> >>ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >>-rw-r--r-- 1 pwg pwg 31232 May 25 09:32 obj-attr.doc >>-rw-r--r-- 1 pwg pwg 17717 May 25 09:31 obj-attr.pdf >>-rw-r--r-- 1 pwg pwg 4377 May 25 09:38 obj-attr.txt >> >>The .doc and .pdf files have revision marks. The .txt file does not and >>is also attached: > >Thanks for this summary list. My comments: > >1) 'jobSourceChannelType' - request we add this attribute parallel to > 'jobSourceChannelIndex' for support of systems which don't implement > the Printer MIB - also much more useful attribute for accounting; I wanted to combine these too, but they are both integers, so we can't. We can only combine an integer attribute with an octets attribute. > >2) 'jmJobKOctertsRequested' - spelling error; Thanks. > >Cheers, >- Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > > From hastings at cp10.es.xerox.com Wed May 28 05:06:14 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> HELD vs NEEDS-ATTENTION In-Reply-To: HELD vs NEEDS-ATTENTION> Message-ID: <9705280908.AA00590@zazen.cp10.es.xerox.com> At 13:04 05/23/97 PDT, STUART@kei-ca.ccmail.compuserve.com wrote: >I agree that "Needs Attention" is an important state which should not be >removed from jmJobState, but I think it is very important to have alignment >with IPP. So we just have to get IPP to come around to our way of thinking >:-) I just noticed that a lot of this JMP comments to convince IPP of ... is only being sent to JMP, not to the IPP list. We are never going to convince IPP of anything if we don't send comments to IPP as well. Just cross post your messages. Tom From hastings at cp10.es.xerox.com Wed May 28 05:06:31 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <9705280908.AB00590@zazen.cp10.es.xerox.com> At 08:08 05/27/97 PDT, Ron Bergman wrote: > > >On Sun, 25 May 1997, Tom Hastings wrote: > >> The current draft lists processing, needsAttention, canceled, and completed >> as Mandatory. Since needsAttention has gone away, that leaves three >> states as mandatory: processing, canceled, and completed. Since we added >> aborted, I assume that aborted should be added to the mandatory list. >> >RB> As you know, there is still some discussion regarding needsAttention. Yes, but I have not heard anyone who favors needsAttention as a job state respond to the IPP reasoning that needsAttention or printerStopped applies equally well to the pending state as to the processing state and so should be a job state reason, not a distinct job state. Harry has pointed out that he doesn't like having a change in the printer state "ripple" though the pending jobs. However, one way to implement the job state reasons, is to only evaluate the printerStopped reason when an application actually does a Get for a particular job. This technique is sometimes called "lazy evaluation". The agent doesn't have to affect any of the other pending jobs, until the application actually does a Get for them. Then a change in state of the printer does NOT ripple through the pending jobs and is not an implementation problem for the agent. Instead, the user gets told that his job is the current job that is using or is in a queue for a stopped printer which IPP thinks is what users want to know. > >> The complicance at the end of the Job MIB spec also lists these states. >> >> I assume that you didn't intend to remove that agreement. >> So I'd like to add back the description that some are mandatory and the >> rest are conditionally mandatory. >> >RB> Exactly what does "mandatory" imply? Is the state only reported >RB> if implemented? No, that is what a Conditionally Mandatory state is. It seems like it would be difficult to report if it >RB> is not implemented. Then what is the difference between "mandatory" >RB> and "conditionally-mandatory"? I propose that jmJobState is really >RB> what is "mandatory", not the possible values. All values possible >RB> in an implementation must be supported. Lets stick with the SNMP definitions of mandatory and conditionally mandatory. Mandatory is something the agent shall do in order to conform. Conditionally mandatory is something that the agent shall do, only if the implementation that the agent is instrumenting does or has. So for example, if the canceled state is conditionaly mandatory, then the agent need only show the canceled state, if the printer that the agent is instrumenting supports an operation that cancels jobs. In fact, in IPP, level 1, the CancelJob operation is not present. Its only IPP level 2 that has the CancelJob operation. So the canceled state is mandatory only at IPP level 2 conformance. Similary in the JMP, we have agreed (I thought) that pending was conditionally mandatory. Only if a printer has jobs in a state where they are waiting to be processed, is it mandatory for the agent to show such jobs in the pending state. On other hand, in IPP the completed state is mandatory. So even if the printer doesn't keep jobs around after they are completed (most do not), the agent shall keep the job information around in its MIB tables (though the document data may have long gone). So because the completed state is mandatory, the agent is forced to do something that the actual output device probably doesn't have (unless it was implemented after the Job Monitoring MIB was around, so that the agent and the output device are an integrated design). > >> I agree on removing redundant text. However, in this case, the >> description in jmJobState was simply a pointer to the textual >> convention (after deleteing the sentence: "The value of this object shall >> always be the same as that of the jobState attribute, so that this information >> appears in both the jmJobStateTable and the jmAttributeTable simultaneously". >> since we agreed to get rid of duplicates. >> >RB> In trying to answer your question I cannot find where I saw the >RB> duplicate text in jmJobState. I may have been looking at jobState >RB> on page 35. Will this (jobState) be removed in the next draft? Yes, I've removed all of the attributes that have redundant objects in the jmJobTable. However, I've moved any text from the attribute description to the object, and made sure that there isn't any duplication in the TC. So I was doing what you suggest, namely to eliminate duplication and put most of the description in the object, instead of the TC. You might want to take a look at the JmAttributeTypeTC and jmAttributeTypeIndex because there is a lot of text in JmAttributeTypeTC that would seem hard to move to the jmAttributeTypeIndex object. > >> So the real thrust of your comment was to move the description from >> the textual convention to the object. So I'll add the sentence about >> the mandatory states to the jmJobState object as well, ok? >> >RB> That was not my original intent, but it is a good move. See comment >RB> above regarding mandatory. > >> Tom >> >> >> >> At 10:01 05/23/97 PDT, Ron Bergman wrote: >> >Tom, >> > >> >In reviewing the Job MIB relative to the job states, I noticed that >> >the descriptions for jmJobState and JmJobStateTC are almost identical. >> >I would like the specification for jmJobState to appear only once, >> >and only in the jmJobState description. I propose that these >> >descriptions be revised as follows: >> > >> >jmJobState: >> >----------- >> >"The current state of the job (pending, processing, held, etc.). The >> >final value for this attribute shall be either completed or canceled. >> final value for this attribute shall be completed, canceled or aborted. >> >> >before the agent removes the job from the table. >> > >> >Management applications shall be prepared to receive all the standard >> >job states. Servers and devices are not required to generate all job >> >states, only those which are appropriate for the particular >> >implementation. The corresponding attributes JmJobStateReasons1 through >> >JmJobStateReasons4 provide additional information about the job states. >> >While new job states cannot be added without impacting deployed clients, >> >it is the intent that additional Job State Reasons enums can be defined >> >without impacting deployed clients." >> > >> >JmJobStateTC: >> >------------- >> >"Defines the current state of the job." >> > >> > >> >A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC. >> >Again, my recommendation is: >> >> I'm assuming that we have agreed to make jobStateReasons1 mandatory, >> in order that the 'printer-stopped' value will always be present (the >> new representation for the old needsAttention state that was removed). >> Since jobStateReasons1 is an INTEGER, not OCTETS, we will move it to >> the jmJobTable right after the jmJobState object, so that the descriptions >> will be next to each other. Its name will be jmJobStateReason1. >> >RB> It appears that this may occur, but I don't believe that an agreement >RB> has been reached. We still need to resolve the "needsAttention" >RB> issue. Note that These issues should not delay the posting of the >RB> next draft update. Unfortunately, its hard to gauge "consensus" by a few email responses on an issue. Others may have not yet resonded, or may have no opinion. It will be easy to change jmJobStateReasons1 back to a mandatory attribute (or a conditionally mandatory) attribute after the next draft if that is what we agree on. But we really need some better way to bring up an issue, get some resonses and then declare a decision. Jay, Boy would AltaVistaForum help these discussion in JMP. Sigh. >> >> I've done some further shortening of the description that you proposed. >> How does it look? >> >> > >> > >> >jobStateReasons: >> jmJobStateReasons1; >> >---------------- >> >---OCTETS: Additional information about the job's current state that >> Additional information about the job's current state that >> >> >augments jmJobState. The jobStateReasons1 attribute identifies the >> >reason or reasons that the job is in the held, pending, processing, >> >needsAttention, canceled, or completed state. The agent shall indicate >> >the particular reason(s) by setting the value of the jobStateReasons1 >> >attribute. >> augments jmJobState, including the reasons(s) that the job is in its >> current state. >> >RB> Very good! > >> < When the job does not have any reasons for being in its >> >current state, the agent shall set the value of the jobStateReasons1 >> >attribute to 0. >> > >> >Companion job state reasons Textual Conventions: JmJobStateReasons2TC, >> >JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an >> >additional 93 job state reasons for use with the corresponding >> >attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4. >> Additional job state reasons may be represented by the attributes: >> jobStateReasons2, jobStateReasons3, and jobStateReasons4. See page xxx. >> >> >This is a type 2 bit definition. >> > >> >JmJobStateReasons1TC: >> >--------------------- >> >"This textual-convention is used with the jobStateReasons1 attribute to >> >provides additional information regarding jmJobState. >> > >> >The following standard values are defined (in hexadecimal) as powers of >> >two, since multiple values may be used at the same time: >> > >> > >> >If anyone objects to these changes, please respond by June 13. >> > > > > Ron Bergman > Dataproducts Corp. > > > From hastings at cp10.es.xerox.com Wed May 28 05:06:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <9705280909.AB00590@zazen.cp10.es.xerox.com> I agree with Ron, that JMP doesn't need to have the same states as IPP, as long as JMP can be easily mapped from IPP, so that a JMP agent can easily instrument an IPP system. So JMP coul have a held state, instead of the jobHeld generic state reason. One of the reasons that IPP merged the held job state into the pending job state, is the difficulty of doint state diagrams where there is a branch into two states, depending on the situation, such as a job going into held or pending depending on its attributes and the configuration of the printer. However a JMP agent isn't implementing the state machine, its only reflecting what the underlying printer implementation is doing. So the comlication of having two state: held and pending is a problem for the agent. The agent just represents to the application through the MIB, the underlying state of the implementation. So the agents doesn't have the problem of implementing the more complicated state machine with both a held and a pending state. For those of you into object modeling, the Shlaer-Mellor school only allows a decision when exiting a state, not when entering. So with Shlaer-Mellor implementation you have to introduce a temporary intermediate evaluating-hold state in which the exit from the state is whether the job goes into the held state or into the pending state. But with using job-state-reasons, instead, all this complication goes away, because the job is always in the pendin state. Its the job state reasons that prevent the implementation from choosing a job that can't be processed. At 08:29 05/27/97 PDT, Ron Bergman wrote: > > >On Sun, 25 May 1997, Tom Hastings wrote: > >> At 08:06 05/23/97 PDT, Ron Bergman wrote: >> > >> >I agree with all the changes proposed for alignment of the IPP and >> >JMP job states except for the removal of "Needs Attention". This >> >should be the most important state to indicate to a user since >> >unless he takes action the job may never complete. I would think >> >that this would also be very important for IPP as well. >> >> In IPP the job-state-reasons 'printer-stopped' is used instead of a separate >> job state called 'needs-attention'. The job can be in either the 'pending' >> or 'processing' state when the reason 'printer-stopped appears. >> If the job is in the pending state, it is some other job that is having >> the problem, but ALL pending jobs are affected, unless the printer problem is >> attended to. >> >> We have two choices for the Job Monitoring MIB: >> >> 1. Follow IPP and get rid of the needsAttention state and add the >> deviceStopped value to the JmJobStateReasons1TC. >> >> 2. Keep the needsAttention state. Don't add the deviceStopped value to the >> jmJobStateReasons1TC. When an agent is instrumenting IPP, >> the agent shall map the IPP 'processing' state to the JMP processing state, >> except when the IPP "job-state-reasons" contains 'printer-stopped'. Then the >> JMP agent shows the job in the JMP needsAttention state. When the IPP >> 'printer-stopped' value is removed from the IPP "printer-state-reasons" >> attribute, the JMP agent shall change the value of the job's jmJobState object >> from the needsAttention state to the processing state. The JMP >> jmJobStateReasons1 object would remain unchanged during this. >> >RB> I would vote for number two if these were are only choices. Alternative 2 is fine with me too, if we relax our zeal of trying to convince IPP to change. Can we agree to just make sure that it is easy for a JMP agent to map IPP to the MIB? Can you think of other alternatives? >> >> >I also agree with Harry that "requiredResourcesNotReady" and >> >"serviceOffLine" apply better to "Needs Attention" than "Held". >> >> The IPP and JMP defintions of requiredResourcesNotReady, say "is not >> ready on any of the physical devices for which the job is a candidate" >> meaning before the job starts processing. Perhaps this reason should >> have a better name, like "requestedResourcesNotReady". >> >RB> I don't see any difference in "required" vs "requested". You are right. You can't put everything into the spec. Does the following description help for the condition which has been further rename by IPP to: job-hold-until-resources-are-ready which in the MIB is jobHoldUntilResourcesAreReady: At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. Usually such a condition is detected while the job is in the pending state. If a job starts processing and encounters a resource that is not ready, there are two possible implementations: (1) the device is stopped and no jobs can run until the resource(s) are made ready, in which case the agent shall keep the job in the processing state and shall add the deviceStopped reason to the job's jmJobStateReasons1 object OR (2) another job is found to use the device while the current job goes back to waiting for its turn and for the resources to be made ready, in which case the Printer shall change the job's jmJobState object to pending and add the jobHoldUntilResourcesAreReady value to the job's jmJobStateReasons1 object. Job states: pending, jobHeld shall be set. > >> IPP says that when the reason 'printer-stopped' is present, the client >> should check the printer-state and printer-state-reasons. For JMP the >> analoguous thing is to check the job's deviceAlert attributes and the >> associated device MIB. >> >> But the IPP/JMP meeting also got rid of the held state. >> >RB> Have we eliminated too much? Maybe. But the jobHold generic state reason in JMP (not in IPP) is another way to represent the held state, but using the reason mechanism. It depends on whether it is more important for JMP to have the same state as IPP and JMP only have additional job state reasons, or whether JMP can also have additional job states that cleanly sub-divide an IPP job state. E.g., the IPP pending state maps to either the JMP held state or the JMP pending state, depending on the job state reasons that do or don't prevent the job from being a candidate for processing. > >> IPP also renamed 'required-resources-not-ready' to >> 'job-hold-until-resources-are-ready'. The prefix "job-hold-" indicates >> that the job is held and will not process until the reason goes away. >> >> Again, JMP could still keep the held state, even though IPP doesn't have it. >> Which may be a good idea, since MIBs use enums, not keywords, so that an >> application can't tell from the enum code whether the job has to have the >> reason removed before it can be processed, or whether the reason is a less >> important one that doesn't affect whether the job will start processing or not. >> >> Then a JMP agent would represent the IPP 'pending' state with certain >> "job-state-reasons" value, such as 'job-hold-until-specified', and >> 'job-hold-until-required-resoureces-are-ready' as: >> >> the JMP 'held' state and also show the same jmJobStateReasons1 object values. >> >RB> I propose that we include the states that make sense for the Job MIB >RB> even if they are not in IPP, as long as they can be mapped into >RB> currently defined IPP states and reasons. Makes sense to me also for IPP 'pending' to map to JMP held vs. pending. How can we get a "vote" on this? However, for needsAttention, we still haven't discussed the IPP point that as far as the user is concerned his/her pending job that is pending for a stopped printer is just as much affected as when his/her processing job is the current job that is using the printer when the printer stopped. Neither the pending job nor the processing job will finish until the printer attended to so that the printer is no longer stopped. > >> >(I also agree with Harry that "Printing" is a better description >> >for a user than "Processing". Since this is an enum, a user or >> >management ap can display whatever text that is deemed >> >appropriate. So I will vote to keep "Processing" unless there >> >is very strong support for "Printing".) >> Thanks for being flexible. >> >> > >> >(Didn't we discuss "serviceOffLine" in a previous meeting and >> >determined that no one except Dataproducts has ever implemented >> >such a capability? I also indicated that I had recently deleted >> >the feature because I felt it was "stupid".) >> >> I don't remember this. Xerox has systems with service-off-line reason. >> The jobs that have been previously accepted are indicated as being in the >> held state with the serviceOffLine reason. Clients can still query the >> server since its the device that is really off-line, not the server. >> Perhaps we should rename the reason from serviceOffLine, to deviceOffLine >> and indicate that it is for configuration 2 in JMP? >> >RB> I did not intend this to be a major issue. Leave it in. Done. > >> > >> >Also, I agree with Jay that "Needs Attention" should apply to all >> >conditions, other than "Held", that prevents the job from printing. >> >"Held" only implies an administratively set condition. >> >> How can the Needs Attention job state apply to all conditions (states)? >> It could if Needs Attention were a job state reason. In IPP we made Needs >> Attention a job state reason, but then renamed it to 'printer-stopped', >> because a device could need attention even though jobs were still >> progressing, such as toner low. >> >RB> Not States.. Conditions that prevent the job from printing, i.e. paper >RB> out, paper jam, out of toner, printer unplugged, etc, etc, etc. Then >RB> the "needsAttention" state applies. But what about the pending jobs? They are just as much affected by the printer needing attention as the job in the processing state. The jobs in the pending state won't get done until the printer is attended to either. > >> So maybe you and Harry could support the IPP job-state-reason 'printer-stopped' >> as equivalent a Needs Attention job state reason and more flexible than >> if Needs Attention were a job state? >> >> > >> >Tom, since I could not participate in the Wednesday conference call, >> >could you explain why "Needs Attention" was not accepted by IPP? >> >It is very critical that JMP and IPP agree in this area and I would >> >hope this can be resolved quickly. >> >> As I explained above, IPP thought that Needs Attention was better as a >> job state reason, rather than a job state, and then we renamed the reason >> to printer-stopped to be clearer. >> >> I'm sorry that neither you nor Harry were able to call into the IPP >> call last Wednesday. The ball is in yours and Harry's court to see if >> you like the IPP approach and we can use it directly in JMP or whether >> JMP should perform a straight forward mapping when instrumenting an IPP >> system as I outlined above to the JMP held and/or JMP needsAttention states >> and some fiddling with job-state-reasons. >> >RB> Again, I would support keeping both the needsAttention and held >RB> states. These could easily be mapped to IPP. Comments? Adding a JMP held state that is not in IPP is fine. The mapping from IPP to JMP done by the JMP agent is that any IPP job-state-reasons value keyword that starts with 'job-held-' would cause the agent to display the job in the held state, instead of the pending state. If there were no 'job-held-xxx' reason, then the IPP 'pending' state maps to the JMP pending state. As soon as all of the 'job-held-xxx' IPP reasons are gone, the agent would display the job in the pending state, instead of the held state. Again, the agent need not make the state change until an application makes a query of that job and then the agent performs a "lazy evaluation" of the job state by looking at the current IPP job-state-reasons attribute values. For mapping the IPP printerStopped job-state-reason, if JMP wants only the processing jobs have have a problem to be in the JMP needsAttention state, then the agent maps as follows: IPP state IPP job-state-reasons JMP state JMP jmJobStateReasons1 --------- --------------------- --------- ---------------------- pending printer-stopped pending - pending job-held-until-specified held jobHeldUntilSpecified processing printer-stopped needsAttention - processing job-printing processing jobPrinting Several tweaks to the above mapping table are: 1. Change the first "-" above to: deviceStopped. Then all the pending jobs get to see that they are waiting for a printer that is stopped. 2. Change the second "-" above to deviceStopped which would be redundant with the needsAttention state, but does preserve the job state reasons compatibility between JMP and IPP for this reason. > > > Ron Bergman > Dataproducts Corp > > > From hastings at cp10.es.xerox.com Wed May 28 05:06:55 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Job state implementation questions for Unix-based In-Reply-To: Job state implementation questions for Unix-based> Message-ID: <9705280909.AB00590@zazen.cp10.es.xerox.com> At 09:29 05/27/97 PDT, Harry Lewis wrote: >Jay, these are good questions: > >>Some questions: > >> 1. If a queue has been stopped, what should each job indicate for its >> job state? In IPP, the Printer's printer-state would have the value: 'stopped' the Printer's printer-state-reasons would have the value: 'paused' (or maybe 'shutdown', depending on how the queue was stopped by the operator). all the 'pending' jobs would have the job-state-reasons value: 'printerStopped' all the 'processing' jobs would have the job-state-reasons value: 'printerStopped' In JMP, the jobStateReasons2 attribute would have the serviceOffLine reason set (bit 0x400000) for all jobs in the pending state. Same for the JMP held state, if JMP has such a state. But JMP doesn't have a Printer, except the Printer MIB, so there isn't the same good stuff about the Printer that IPP has. > >> 2. If a queue is stopped, how can the user easily detect this >> critical queue-specific state? In IPP, the user gets back some Printer status when querying the job as well as job state. In JMP, its harder, since JMP only has the deviceAlert attribute which is the hardware alert code from the Printer MIB. No much about queues in the Printer MIB. We could add two objects to the JMP jmGeneralTable that mirror these two IPP Printer attributes: jmGeneralState jmGeneralStateReasons which indicate the state of the job set and the job set state reasons. The values from IPP printer-state and printer-state-reasons would be: jmGeneralState: unknown, idle, processing, stopped jmGeneralStateReasons: stopped-partly, stopped, media-needed, paper-jam, paused, shudown, connect-to-printer, timed-out, stopping Should we? > >> 3. Similarly, if a queue is disabled, how can the user detect >> this state? In IPP, the Printer has the boolean Mandaory attribute: printer-is-accepting-jobs Again, we don't have the equivalent in the JMP MIB. We could add a boolean object to the jmGeneralTable: jmGeneralIsAcceptingJobs to give the same information on a Job Set basis. Should we? > >There is an analogous situation for the state NeedsAttention. One could >ask, if the printer has an alert, should all the jobs in the printer buffer >change to NeedsAttention state, or just the job which is currently printing. IPP has been stating that the end user wants to know the bad news for his/her pending job, not just for his/her processing job. >Our recommendation is not to ripple all jobs since this would be arduous for >the agent. I agree that rippling would be arduous for the agent, so don't ripple. May I suggest that there is no ardor at all, if the agent just waits until the job is queried to return the jmJobStateReason1 value is deviceStopped, if the device is still stopped. If the device got going again before the 'pending' job was queried, then no extra work was done by the agent for that job. So there need be no "rippling at all". > Rather, we envision the job monitoring application also having >some indication of the overall health of the printer (Green, Yellow, Red). >Only the job which is actually JAMMED (as an example) would reflect >NeedsAttention state. Other jobs would be Pending on a "Red" printer. But the IPP 'printer-stopped' value in the "job-state-reasons attribute" is exactly the 'red' printer indication, but the indication comes more conviently with the job in the job-state-reasons attribute. The IPP printer-state is also stopped, if the user did query the Printer. The big advantage to JMP of using the same approach of the deviceStopped value of the jmJobStateReasons1 object, is that it works for all three of our supported JMP configurations, not just configuration 1 (client talks directly to the output device). So that the Printer MIB isn't needed in order for the user to get the "red" printer indication back. >I would really like JMP and/or IPP confirmation of this approach for printer >implementations and I offer it in response to your question about queue's as >an analogy, presuming you could show overall queue status with a (Green, >Yellow, Red) icon. > >As for your last question: > >> 4. If a system administrator deletes a job from a queue, what should >> the state and job reason(s) reflect? > >I am not in favor of job state reasons as anything other than optional job >attributes, but if I were to take a guess, here, I'd say that: >State = CANCELED >JobStateReasons1 = No reason (all zero's) Current and previsou spec has canceledByOperator or canceledByUser as values. Remember Jay's mail that the user needs to be able to tell whether the user, the operator or the system canceled his/her job. Now that IPP/JMP have the aborted state, the system canceled jobs is indicated by the 'aborted' job state, so that reason has gone away. He also wanted it to be mandatory, so I moved jobStateReason1 attribute to the jmJobTable and called it jmJobStateReason1. >JobStateRessons2 = deletedByAdministrator That is in jmJobStateReasons1 >JobStateReasons3 = No reason >JobStateReasons4 = No reason > >So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000? More like: 0x00002000 0x00000000 0x00000000 0x00000000 with job-state spec I just posted. > >Harry Lewis. > > From hastings at cp10.es.xerox.com Wed May 28 05:07:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <9705280909.AB00590@zazen.cp10.es.xerox.com> At 10:14 05/27/97 PDT, Harry Lewis wrote: >Good catch, Jay. Pending should certainly not have been removed from the >mandatory list of job States. I assume this is just a slip-up. Tom, will you >please confirm? I thought that we had agreed that an output device that doesn't queue and doesn't spool might not be forced to have a pending state for jobs, if the jobs are not delayed in any way. As Peter Zehler points out, a non-queueing, non-spooling printer might still want to have a pending state, if is can be for a user-visible length of time. But such an implementation should not be forced to have such as state, ok? But if there is any kind of delay between when a job is submitted and it is started to be processed, then a pending state is required for the jobs. Thats the meaning of Conditionally Mandatory. > >>What happened to "pending" as a mandatory job state? I certainly hope >>we don't relegate this important state to the "Conditionally Mandatory" >>realm. > >>> The current draft lists processing, needsAttention, canceled, and completed >>> as Mandatory. Since needsAttention has gone away, that leaves three >>> states as mandatory: processing, canceled, and completed. Since we added >>> aborted, I assume that aborted should be added to the mandatory list. > > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed May 28 05:07:15 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <9705280909.AB00590@zazen.cp10.es.xerox.com> At 11:16 05/27/97 PDT, JK Martin wrote: >Ron, > >> The object jmJobState should be mandatory. All possible enums for this >> object must be reported if implemented and available to the agent. (I >> sent another email on this subject with more info earlier today.) >> >> Does this make more sense? > >Yes! I like your wording. Can everyone else agree to this? No, Ron has used the definition for conditionally mandatory and called that definition what mandatory means. Most of the jobState enums are mandatory using the SNMP definition of Mandatory. A few are conditionally mandatory (see Ron's definition above). See my earlier mail messages on why, processing, completed, and aborted are mandatory, not conditionally mandatory, states and why 'pending' and 'canceled' are conditionally mandatory. > > ...jay > > From hastings at cp10.es.xerox.com Wed May 28 05:07:25 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are> Message-ID: <9705280909.AB00590@zazen.cp10.es.xerox.com> Bill, You are forgetting the prtGeneralReset object in the Printer MIB which is an enum. There are a few values that are mandatory and the Conformance in the back explicitly lists which values are mandatory. So we have the same situation for the JMP. Tom At 11:47 05/27/97 PDT, Bill Wagner wrote: > I certainly can agree. I was rather wondering about all the > discussion. It was my understanding that objects can be mandatory, not > values of the object variable. > > Bill Wagner, Osicom/DPI > > >______________________________ Reply Separator _________________________________ >Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther >Author: JK Martin at Internet >Date: 5/27/97 2:16 PM > > >Ron, > >> The object jmJobState should be mandatory. All possible enums for this >> object must be reported if implemented and available to the agent. (I >> sent another email on this subject with more info earlier today.) >> >> Does this make more sense? > >Yes! I like your wording. Can everyone else agree to this? > > ...jay > > From hastings at cp10.es.xerox.com Wed May 28 05:07:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <9705280910.AB00590@zazen.cp10.es.xerox.com> At 13:58 05/27/97 PDT, Harry Lewis wrote: >I like Ron's wording... > >> The object jmJobState should be mandatory. All possible enums for this >> object must be reported if implemented and available to the agent. Again, we will certainly confuse the IETF if we redefine what mandatory means by using the defintion for conditionally mandatory as Ron has. We must, as we did for the Printer MIB jmGeneralReset, decide which values an agent must implement whether the device does or not and which values the agent need only implement if the device does. We must label the former Mandatory and the latter Conditionally Mandatory. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed May 28 05:07:45 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Lets read the IPP/JMP job-state/job-state-reasons spec Message-ID: <9705280910.AB00590@zazen.cp10.es.xerox.com> Lets read the job-state/job-state-reasons spec for IPP and JMP that I posted Tuesday, 27-May, as the result from the telecon, last Wedneday. (Files: jobstatr.* and jobstate.*). There are page numbers and line numbers. Lets make comments on the spec referring to the page and line numbers that show problems. I think we can make a lot more progress that way. They were developed as a result of the agreement in principle from San Diego that IPP and JMP align. Then we had the IPP/JMP telecon on Wed, 5/21, as planned in San Diego at which Ron, Harry, and Stuart were regrettably absent. The joint spec will be on the IPP telecon, 5/28, for a short time to see if there is a need to have a separate IPP Model telecon or not. JMP people should call in for that part of the discussion if they want to try to convince IPP to make changes. IPP Phone number: (309)671-1035 code: 190148, time: 1-3pm PDT (4-6 EDT). After reviewing these specs, if JMP decides that it wants to add some job states to the Job Monitoring MIB so that a JMP agent that is instrumenting an IPP system can cleanly map, then lets decide to do so. But only after reading the spec and deciding that it isn't sufficient or isn't clear to the users of the applications or isn't what a Job Monitoring MIB application needs for handling our three configurations. So far the discussion seems to be (compared with the joint IPP/JMP spec): 1. whether to add a held job state. 2. whether to add a needAttention job state 3. how should pending jobs be handled when the printer stops/needs attention. There is also other discussions about mandatory and conditionally mandatory attributes and enums and whether jmJobStateReasons1 is an object or an attribute. Please read the spec first and then make comments based on it. Ok? Thanks, Tom From peter_zehler at ocp.mc.xerox.com Wed May 28 07:57:06 1997 From: peter_zehler at ocp.mc.xerox.com (Peter Zehler) Date: Wed May 6 14:00:06 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are> Message-ID: <01BC6B3C.BD780320@HORTON> Tom, The amount of time a job would be in the pending state on a non-queueing non-spooling printer could be noticable to humans. It is dependant on the size of the print jobs on the other channels. I think it would simplify things just to have the pending state mandatory. Implementations could step through this state so quickly it would never be noticable to humans. Pete Peter, How long would a job be in the pending state in your non-queuing, non-spooling IPP system? If the time is not noticable to humans, e.g., 100s of miliseconds, I would think that there wan't much point in simplementin the IPP state of 'pending'. If it was longer, so that end-users would see it for a while, while nothing was happending on the printer, then it would be good to implemente the IPP 'pending' state for your Printer object. So your point was not that 'pending' must be a Mandatory state, but that in your implementation of a simple, non-queuing, non-spooling printer you wanted to be able to implement 'pending'. So we just have to find language that permits non-queuing, non-spooling printers to implement 'pending', but doesn't require it. On the other hand, it might be simpler to mandate the 'pending' state and for implementations that don't queue or spool, the state would never be visible or would be visible for a very short period of time. Tom From harryl at us.ibm.com Wed May 28 11:20:01 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:> Message-ID: <5030100002894157000002L072*@MHS> Regarding this statement... >I think it would simplify things just to have the pending state mandatory. I think we should all agree, as (I think it was) Ron Bergman who pointed out, that it is jmJobState which is mandatory... *not* the underlying enums. I agree with the "spirit" of the concensus, however, that non-spooling devices *can* have jobs pending for significant periods of time. Harry Lewis - IBM Printing Systems From bwagner at digprod.com Wed May 28 11:23:17 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: A Message-ID: <5030100002894157000002L072*@MHS> Tom, Quite so. Yet I would not put reflecting job state in the same class as requiring the ability to implement a reset. That is, it is not reasonable to require that a printer implement a given set of states, only to report on the states that it does implement. I take this as the intent of Ron's suggestion and believe it to be most appropriate. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: A Author: Tom Hastings at Internet Date: 5/28/97 2:07 AM Bill, You are forgetting the prtGeneralReset object in the Printer MIB which is an enum. There are a few values that are mandatory and the Conformance in the back explicitly lists which values are mandatory. So we have the same situation for the JMP. Tom At 11:47 05/27/97 PDT, Bill Wagner wrote: > I certainly can agree. I was rather wondering about all the > discussion. It was my understanding that objects can be mandatory, not > values of the object variable. > > Bill Wagner, Osicom/DPI > > >______________________________ Reply Separator _________________________________ >Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther >Author: JK Martin at Internet >Date: 5/27/97 2:16 PM > > >Ron, > >> The object jmJobState should be mandatory. All possible enums for this >> object must be reported if implemented and available to the agent. (I >> sent another email on this subject with more info earlier today.) >> >> Does this make more sense? > >Yes! I like your wording. Can everyone else agree to this? > > ...jay > > From harryl at us.ibm.com Wed May 28 11:40:03 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are> Message-ID: <5030100002895066000002L062*@MHS> I wish I knew who wrote this... they did not sign it... I will insert comments with >HRL. >At 11:14 05/27/97 PDT, Harry Lewis wrote: >>Even printers that don't spool or queue will typically "buffer" some number of >>pages. >But isn't the definition of "queuing" on page 13, line 364, what you mean >by "buffering" some number of jobs? >HRL You could say that except the definition implies that the device can >HRL order - i.e. take some action regarding the order of jobs - whereas >HRL a buffer can only "stage" nor "order". We're splitting hairs. >>Given the possibility of single page jobs... then some jobs can be >>pending. I guess we should ask ourselves what it means to have a "mandatory" >>state. Just because a state is Mandatory does not mean an implementation must >>"force" jobs to enter that state. If that were so... I'd REALLY be in favor of >>eliminating the NeedsAttention state! ;-> >We keep getting confused by whether a MIB is talking about the printer >or is talking about what the agent shall show about the printer. >I claim that MIBs are all about the latter and nothing to do with >the former. >HRL You've mesmerized me, here. By the way... this is a *job* MIB. >See my early answer to Ron about the completed state. >HRL Who are you? >Most printers won't have such a state, the printer throws the job away as soon >as it >is printed. Its the agent that has to keep the job information in the >MIB tables for the time indicated in the jmGeneralJobPersistence object. >If the 'completed' state were conditionally mandatory, then an agent would >only have to show jobs in the 'completed' state, if the device implemented >the completed state. But we aren't going to allow agents off the hook. >The agent has to implement the 'completed' state. Same for 'aborted'. >HRL Now I'm slipping into a coma. We're talking about a *job* agent here >HRL that is *embedded* in the device, totally for the purpose of representing >HRL what is happening with the *job* in the device. Why are you making a >HRL distinction between the agent and the device? Besides. We can't go on >HRL discussing which jmJobState values are mandatory! The OID is mandatory, >HRL and there are a list of possible values. If that possibility never >HRL becomes reality, that object never assumes that value! >'canceled', is conditionally mandatory, because level 1 IPP doesn't require >the CancelJob operation. So we aren't going to force agents to show >a canceled state, except for printers that implement a CancelJob operation. >For needsAttention, is impossible to design a device that handles paper >that doesn't need attention some time (unless it plants, grows, harvests trees, >makes paper, and fixes all jams). So making needsAttention Mandatory forces >the agent to show jobs in the needsAttention state, if the printer jams. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed May 28 11:56:21 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Should jobStateReasons1 be mandatory? In-Reply-To: Should jobStateReasons1 be mandatory?> Message-ID: <9705281558.AA00759@zazen.cp10.es.xerox.com> At 17:16 05/27/97 PDT, Harry Lewis wrote: >So, let me understand... > >>Harry, > >>It was on this mail and Jay's that I concluded we had JMP agreement on >>making jobStateReasons1 attribute mandatory and I made the second >>step of moving it to the jmJobTable, as we agreed for all mandatory >>attributes in San Diego. Making it mandatory also agrees with IPP. > >>Tom > >You are proposing that jmJobTable contain a mandatory OID for >jobStateReasons1. But, if, of the 20 reasons specified, a printer >can only "detect" the 4 that I have marked with (*), below, that's acceptable, >right? Almost. Even though the jmJobStateReason1 object is mandatory because its in a Mandatory group, we get to decide on a enum by enum basis which ones are mandatory (agent shall implement whether printer has or not) which are conditionally mandatory (agent shall implement, but only if the printer has that behavior) and which ones are optional (agent doesn't have to imlement, even if the printer has that behavior) Most of the reasons are conditionally mandatory. The mandatory ones are indicate below with "Man": Please use the list in the joint IPP/JMP jobstate.* files that I posted yesterday: JMP jobStateReasons1 values other unknown Man jobIncoming OPT jobOutgoing jobHeld jobHoldSpecified, jobHeld jobHoldUntilSpecified, jobHeld jobHoldUntilResourcesAreReady,jobHeld jobProcessAfterSpecified, jobHeld OPT deviceStoppedPartly MAN deviceStopped OPT jobPrinting jobCanceledByUser jobCanceledByOperator OPT logfilePending OPT logfileTransferring MAN jobCompletedSuccessfully MAN jobCompletedWithWarnings MAN jobCompletedWithErrors jobPaused jobInterrupted jobRetained > >*other >*unknown >*no reason (all zeros) > documentsNeeded > jobHoldSet > jobProcessAfterSpecified > requiredResourceNotReady >*successfulCompletion > completedWithWarnings > completedWithErrors > canceledByUser > canceledByOperator > abortedBySystem > logfilePending > logfileTransferring > jobPreProcessing > jobPaused > jobInterrupted > jobRetained > jobHoldUntil > > >Harry Lewis - IBM Printing Systems > > From don at lexmark.com Wed May 28 12:06:42 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:06 2009 Subject: JMP> Separation of PWG and IETF activities Message-ID: <199705281606.AA06284@interlock2.lexmark.com> --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC Content-type: text/plain; charset=us-ascii (Embedded image moved to file: PIC29258.PCX) To: pwg@pwg.org, PMP@pwg.org, JMP@pwg.org, ipp@pwg.org, P1394@pwg.org cc: From: Don Wright @ LEXMARK@LEXMTA Date: 05/28/97 12:06:42 PM Subject: Separation of PWG and IETF activities Through the course of the last few weeks, there have been a number of cases where the activities of the PWG and the IETF have been confused. In order to clearly separate the two, I think the following needs to happen: 1) We need to add a disclaimer to the PWG home page clearly indicating: The contents of these WEB pages reflect work done by the people of the Printer Working Group which may or may not be submitted to the IETF, IEEE or other standards organizations. Official IETF, IEEE, or other standards organization documents, if available, will be found on their WEB page, FTP server or other service. 2) We need to clearly separate PWG administrative e-mail from IETF working groups technical and administrative e-mail. Therefore, according to my understanding, since meetings of the PWG are not "official" IETF activities, all future PWG meeting notices will ONLY be sent to the PWG mailing list and not to the PMP, JMP, or IPP lists. In contrast, the IEEE does sanction the regular meetings of a working group. Since the 1394 printing effort is a study group and hopefully soon an official working group, a more liberal policy will be applied to the P1394 mailing list. I am not sure how to handle the notices of meeting minutes but my first pass at it says that PWG meeting minutes for IPP, JMP and PMP should not be posted or acknowledged on these lists. (If a meeting "didn't happen" how can minutes exist?) Am I going too far? To insure the broadest possible distribution, I have posted this message to all the appropriate mailing lists and I encourage a BRIEF discussion of this proposal but ONLY on the PWG mailing list. Thanks! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC Content-type: application/octet-stream; name="PIC29258.PCX" Content-transfer-encoding: base64 CgMBAQAAAAA4AgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABSAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADl/9L/yf/F/8L/geUA0gDJAMUAAAGE5QDSAMkAxQAAAcHw5f/S/8n/xf/C /7g= --0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC-- From hastings at cp10.es.xerox.com Wed May 28 12:06:32 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> List of updated JMP objects and attributes In-Reply-To: List of updated JMP objects and attributes> Message-ID: <9705281608.AA00768@zazen.cp10.es.xerox.com> Anyone object if I add jobSourceChannelType as an attribute? Probably conditionally mandatory like all attributes except jobOwner. Or should it be OPTIONAL, since an implemenation that also has the Printer MIB, already has the source channel type in the Printer MIB. Tom At 21:27 05/27/97 EDT, Ira Mcdonald x10962 wrote: >Hi Tom, > >I realize we can't combine two attributes of integer type. My point >was that the (missing) attribute 'jobSourceChannelType' is generally >more interesting than 'jobSourceChannelIndex' anyway, so could we please >add it, separately? > >Thanks >- Ira McDonald (outside consultant at Xerox) > >>-------------------------- Included Message ---------------------------< >>From jmp-owner@pwg.org Tue May 27 18:18:50 1997 >Return-Path: >Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) > id AA23083; Tue, 27 May 97 18:18:49 EDT >Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) > id AA08728; Tue, 27 May 97 18:16:11 EDT >Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <16437(3)>; Tue, 27 May 1997 15:16:18 PDT >Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03050 for ; Tue, 27 May 1997 18:12:21 -0400 (EDT) >Received: by pwg.org (bulk_mailer v1.5); Tue, 27 May 1997 18:10:28 -0400 >Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02812 for jmp-outgoing; Tue, 27 May 1997 18:09:40 -0400 (EDT) >Message-Id: <9705272209.AA00467@zazen.cp10.es.xerox.com> >X-Sender: hastings@zazen >X-Mailer: Windows Eudora Pro Version 2.1.2 >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Date: Tue, 27 May 1997 15:06:53 PDT >To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) >From: Tom Hastings >Subject: Re: JMP> List of updated JMP objects and attributes >Cc: jmp@pwg.org >Sender: jmp-owner@pwg.org >Status: R > >At 06:39 05/27/97 PDT, Ira Mcdonald x10962 wrote: >>Hi Tom, Tuesday (27 May 1997) >> >>>Date: Sun, 25 May 1997 02:42:53 PDT >>>To: jmp@pwg.org >>>From: Tom Hastings >>>Subject: JMP> List of updated JMP objects and attributes >>> >>>I've edited the list of Job Monitoring MIB objects and attributes >>>according to the San Diego meeting and subsequent e-mail. >>> >>>Please review and make any comment ASAP. I'm editing these changes now. >>> >>>ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >>>-rw-r--r-- 1 pwg pwg 31232 May 25 09:32 obj-attr.doc >>>-rw-r--r-- 1 pwg pwg 17717 May 25 09:31 obj-attr.pdf >>>-rw-r--r-- 1 pwg pwg 4377 May 25 09:38 obj-attr.txt >>> >>>The .doc and .pdf files have revision marks. The .txt file does not and >>>is also attached: >> >>Thanks for this summary list. My comments: >> >>1) 'jobSourceChannelType' - request we add this attribute parallel to >> 'jobSourceChannelIndex' for support of systems which don't implement >> the Printer MIB - also much more useful attribute for accounting; > >I wanted to combine these too, but they are both integers, so we can't. > >We can only combine an integer attribute with an octets attribute. > >> >>2) 'jmJobKOctertsRequested' - spelling error; > >Thanks. > >> >>Cheers, >>- Ira McDonald (outside consultant at Xerox) >> High North Inc >> PO Box 221 >> Grand Marais, MI 49839 >> 906-494-2434 >> >> > > > > From hastings at cp10.es.xerox.com Wed May 28 12:13:55 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> RE: Should 'pending' be a mandatory state or not? Message-ID: <9705281615.AA00777@zazen.cp10.es.xerox.com> How about we keep pending as CONDITIONALLY MANDATORY, but state the condition: The pending state shall be implemented if jobs may not be able to be proessed for human noticable amount of time, such as a second or more, in certain circumstances. How about if the Job Monitoring spec states the condition: on all CONDITIONALLY MANDATORY attributes? On all CONDITIONALLY MANDATORY enum values? Tom At 04:57 05/28/97 PDT, Peter Zehler wrote: >Tom, >The amount of time a job would be in the pending state on a non-queueing > non-spooling printer could be noticable to humans. It is dependant on the >size of the print jobs on the other channels. >I think it would simplify things just to have the pending state mandatory. >Implementations could step through this state so quickly it would never be >noticable to humans. >Pete > > >Peter, > >How long would a job be in the pending state in your non-queuing, non-spooling >IPP system? > >If the time is not noticable to humans, e.g., 100s of miliseconds, I would >think that there wan't much point in simplementin the IPP state of 'pending'. >If it was longer, so that end-users would see it for a while, while nothing >was happending on the printer, then it would be good to implemente the >IPP 'pending' state for your Printer object. > >So your point was not that 'pending' must be a Mandatory state, but >that in your implementation of a simple, non-queuing, non-spooling printer >you wanted to be able to implement 'pending'. So we just have to find >language that permits non-queuing, non-spooling printers to implement >'pending', but doesn't require it. > >On the other hand, it might be simpler to mandate the 'pending' state >and for implementations that don't queue or spool, the state would >never be visible or would be visible for a very short period of time. > >Tom > > > > From rbergma at dpc.com Wed May 28 10:39:59 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: <9705280908.AB00590@zazen.cp10.es.xerox.com> Message-ID: <9705281615.AA00777@zazen.cp10.es.xerox.com> Tom, On Wed, 28 May 1997, Tom Hastings wrote: [snip .... snip] > >RB> As you know, there is still some discussion regarding needsAttention. > > Yes, but I have not heard anyone who favors needsAttention as a job state > respond to the IPP reasoning that needsAttention or printerStopped applies > equally well to the pending state as to the processing state and so should > be a job state reason, not a distinct job state. > > Harry has pointed out that he doesn't like having a change in the printer > state "ripple" though the pending jobs. However, one way to implement > the job state reasons, is to only evaluate the printerStopped reason > when an application actually does a Get for a particular job. This > technique is sometimes called "lazy evaluation". The agent > doesn't have to affect any of the other pending jobs, until the application > actually does a Get for them. Then a change in state of the > printer does NOT ripple through the pending jobs and is not an implementation > problem for the agent. Instead, the user gets told that his job is the current > job that is using or is in a queue for a stopped printer which IPP thinks > is what users want to know. > RB> See email from Bob Herriot late yesterday "RE: JMP> IPP>MOD HELD RB> vs NEEDS-ATTENTION". This appears to be a very well constructed RB> proposal and I hope will be discussed in todays IPP teleconference. RB> I will participate, but only for the first 1.5 hours. Please review RB> Bob's proposal. > > [snip .... snip] > >RB> Exactly what does "mandatory" imply? Is the state only reported > >RB> if implemented? > > No, that is what a Conditionally Mandatory state is. > > It seems like it would be difficult to report if it > >RB> is not implemented. Then what is the difference between "mandatory" > >RB> and "conditionally-mandatory"? I propose that jmJobState is really > >RB> what is "mandatory", not the possible values. All values possible > >RB> in an implementation must be supported. > > Lets stick with the SNMP definitions of mandatory and conditionally > mandatory. Mandatory is something the agent shall do in order to conform. > Conditionally mandatory is something that the agent shall do, only if the > implementation that the agent is instrumenting does or has. > > So for example, if the canceled state is conditionaly mandatory, then > the agent need only show the canceled state, if the printer that the agent > is instrumenting supports an operation that cancels jobs. In fact, in IPP, > level 1, the CancelJob operation is not present. Its only IPP level 2 > that has the CancelJob operation. So the canceled state is mandatory > only at IPP level 2 conformance. > > Similary in the JMP, we have agreed (I thought) that pending was conditionally > mandatory. Only if a printer has jobs in a state where they are waiting > to be processed, is it mandatory for the agent to show such jobs in the > pending state. > > On other hand, in IPP the completed state is mandatory. So even if the > printer doesn't keep jobs around after they are completed (most do not), > the agent shall keep the job information around in its MIB tables (though > the document data may have long gone). So because the completed state > is mandatory, the agent is forced to do something that the actual output > device probably doesn't have (unless it was implemented after the Job > Monitoring MIB was around, so that the agent and the output device are > an integrated design). > RB> Tom, I still have a hard time justifying that enums for an object RB> are "mandatory" or "conditionally-mandatory". It made some sense RB> for the Attribute Table but for objects in the Job State Table this RB> generating significant confusion. I still prefer that the *object* RB> jmJobState be "mandatory" and the enums for the object are implied RB> to be "conditionally mandatory". Ron Bergman Dataproducts Corp. > > > > > > > > From hastings at cp10.es.xerox.com Wed May 28 12:59:05 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> RE: Bob Herriot's IPP/JMP 2 new states proposal Message-ID: <9705281701.AA00845@zazen.cp10.es.xerox.com> Ron Bergman, Harry Lewis and I have reviewed Bob's proposal to add two new states: pending-stopped and processing-stopped. We all like it a lot. We think that the other JMP participants will too. Carl-Uno has agreed to cover the joint IPP/JMP job-state/job-state-reasons spec in the first 15 minutes of the IPP telecon today, so that JMP participants need not stay on the line for the major topic of the protocol. (We know that Harry can't make it, but gives his support). So JMP particpants please call in for 15 minutes at: May 28 ------ Call-in: 1-309-671-1035 Access: 190148 Time: 1-3pm PDT (4-6 EDT) So the updated state transition diagram would become: For IPP: The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. +--> canceled / pending -----> processing --+----> aborted ^ ^ \ | | +--> completed v v pending-stopped processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right. For JMP: -- The following figure shows the normal job state transitions. -- Other transitions are unlikely, but are not forbidden. -- -- +---> canceled(7) -- / -- pending(3) ------> processing(5) --+-----> aborted(8) -- ^ ^ \ -- | | +---> completed(9) -- v v -- pending-stopped(4) processing-stopped(5) -- -- <----------------- active -------------->|<-- in-active -->| -- Normally a job progresses only from left to right. We only have 15 minutes, so we may have to consider the following later: Remaining details of the agreement: Do we remove the MANDATORY printer-stopped job-state-reasons value from IPP? Do we remove the MANDATORY deviceStopped jmJobStateReaons1 value from JMP? My suggestion it yes. What about the OPTIONAL printer-stopped-partly job-state-reasons value from IPP? And the OPTIONAL deviceStoppedPartly jmJobStateReasons1 value from JMP? My suggestion is no. Its unlikely to be implemented, but can be. Finally, job-state-reasons is MANDATORY in IPP. Should it remain MANDATORY in JMP or become CONDITIONALLY MANDATORY? What about the remaining MANDATORY values: MAN jobIncoming OPT jobOutgoing CM jobHeld CM jobHoldSpecified, jobHeld CM jobHoldUntilSpecified, jobHeld CM jobHoldUntilResourcesAreReady,jobHeld CM jobProcessAfterSpecified, jobHeld OPT deviceStoppedPartly MAN deviceStopped OPT jobPrinting CM jobCanceledByUser CM jobCanceledByOperator OPT logfilePending OPT logfileTransferring MAN jobCompletedSuccessfully MAN jobCompletedWithWarnings MAN jobCompletedWithErrors MAN = MANDATORY - a conforming agent shall implement CM = CONDITIONALLY MANDATORY - a conforming agent shall implement only if the device has this behavior. OPT = OPTIONAL - a conforming agent need not implement even if the device has the behavior. If all of the values become CONDITIONALLY MANDATORY or OPTIONAL, then jmJobStateReasons1 can be changed from MANDATORY to CONDITIONALLY MANDATORY too (and be moved from the jmJobTable, back to the jmAttributeTable). Tom At 14:39 05/27/97 PDT, Robert Herriot wrote: > >There has been a lot of discussion on the JMP list about the held >and needs-attention state. > >Several people have stated that the primary reason for having 'held' >and 'needs-attention' as job-states rather than job-state-reason is >that the job-state should be all that most people need to look at. > >Keeping that in mind, here's is an slightly different view that we >should perhaps consider. I put this forth for discussion and can >see pro's and con's for keeping the simple 5 job-states of IPP versus >adding these two additional states. > >The Proposal: > >Change the name of "needs-attention" to "stopped-printing" and define >the "stopped-printing" state as an alternate view of the "processing" >state. A job is in the "stopped-printing" state when certain >job-state-reasons take it out of the "processing" state temporarily. >When those reasons clear, the job goes back to the "processing" state. > >Likewise, the "held" job-state is an alternate view of the "pending" >state. A job is in the "held" state when certain job-state-reasons >take it out of the "pending" state temporarily. When those reasons >clear, the job goes back to the "pending" state. Such reasons include >"held-until" (aka "job-hold-until-specified"), "held-for-resources" >(aka "required-resources-not-ready"), and "printer-stopped". > >Any reasons that keeps a job from making progress towards the printer >put it in the "held" state. Any reasons that keep a job from >processing put it in the "stopped-printing state. > >Note that the "printing-stopped" reason changes a "processing" job to >"stopped-printing" and a "pending" job to a "held" job. > >If we want more regular names, then we should call "held", "pending-stopped" >and we should call "stopped-printing", "processing-stopped". > >Note: I do not like the name "needs-attention" because it is the printer >that needs attention and not the job. Furthermore, the printer may need >attention even when a particular job is pending. > >Comments? > >Bob Herriot > > From bwagner at digprod.com Wed May 28 14:42:39 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> RE: Should 'pending' be a mandatory state or not? In-Reply-To: RE: Should 'pending' be a mandatory state or not?> Message-ID: <9705281701.AA00845@zazen.cp10.es.xerox.com> It might help if someone indicated what it meant for a state enum to be mandatory or conditionally mandatory. Does mandatory mean that: 1. each job must go though that state and be reported? 2. if the job goes through the state, it must be reported? Does conditionally mandatory mean that: 2. if the job goes through the state, it must be reported? 3. the unit report it if it is able to? I maintain that (1) is unreasonable, since as pointed out, depending upon the implementation, the state may be highly transitory and may not persist long enough to be observed. (2) is reasonable, how ever you wish to define it. I believe it is what Ron suggested. (3) means nothing in terms of consistency, and is useless. Bill Wagner Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: IPP> RE: Should 'pending' be a mandatory state or not? Author: Tom Hastings at Internet Date: 5/28/97 9:13 AM How about we keep pending as CONDITIONALLY MANDATORY, but state the condition: The pending state shall be implemented if jobs may not be able to be proessed for human noticable amount of time, such as a second or more, in certain circumstances. How about if the Job Monitoring spec states the condition: on all CONDITIONALLY MANDATORY attributes? On all CONDITIONALLY MANDATORY enum values? Tom From harryl at us.ibm.com Wed May 28 18:05:28 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> RE: Should 'pending' be a mandatory state or not? In-Reply-To: RE: Should 'pending' be a mandatory state or not?> Message-ID: <5030100002913609000002L092*@MHS> I'm really not sure it makes sense to talk about mandatory States (as opposed to mandatory Objects), but, I believe what Bill describes as >2. if the job goes through the state, it must be reported? is what we're striving for. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed May 28 19:54:09 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Should jobStateReasons1 be mandatory? In-Reply-To: Should jobStateReasons1 be mandatory?> Message-ID: <5030100002917610000002L002*@MHS> I'll repeat ... I don't see how we can make a particular state mandatory but for the sake of discussion... how can we possibly label "jobPrinting" as Optional but jobCompletedWithWarnings and jobCompletedWithErrors Mandatory? I can guarantee it will be easier for some printer job agents to be aware that the job is Printing then to know whether or not warnings or errors were encountered on the way to the stacker! > JMP jobStateReasons1 values > other > unknown >Man jobIncoming >OPT jobOutgoing > jobHeld > jobHoldSpecified, jobHeld > jobHoldUntilSpecified, jobHeld > jobHoldUntilResourcesAreReady,jobHeld > jobProcessAfterSpecified, jobHeld >OPT deviceStoppedPartly >MAN deviceStopped >OPT jobPrinting > jobCanceledByUser > jobCanceledByOperator >OPT logfilePending >OPT logfileTransferring >MAN jobCompletedSuccessfully >MAN jobCompletedWithWarnings >MAN jobCompletedWithErrors > jobPaused > jobInterrupted > jobRetained Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/28/97 05:35 PM --------------------------- jmp-owner@pwg.org 05/28/97 10:31 AM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> Should jobStateReasons1 be mandatory? At 17:16 05/27/97 PDT, Harry Lewis wrote: >So, let me understand... > >>Harry, > >>It was on this mail and Jay's that I concluded we had JMP agreement on >>making jobStateReasons1 attribute mandatory and I made the second >>step of moving it to the jmJobTable, as we agreed for all mandatory >>attributes in San Diego. Making it mandatory also agrees with IPP. > >>Tom > >You are proposing that jmJobTable contain a mandatory OID for >jobStateReasons1. But, if, of the 20 reasons specified, a printer >can only "detect" the 4 that I have marked with (*), below, that's acceptable, >right? Almost. Even though the jmJobStateReason1 object is mandatory because its in a Mandatory group, we get to decide on a enum by enum basis which ones are mandatory (agent shall implement whether printer has or not) which are conditionally mandatory (agent shall implement, but only if the printer has that behavior) and which ones are optional (agent doesn't have to imlement, even if the printer has that behavior) Most of the reasons are conditionally mandatory. The mandatory ones are indicate below with "Man": > >*other >*unknown >*no reason (all zeros) > documentsNeeded > jobHoldSet > jobProcessAfterSpecified > requiredResourceNotReady >*successfulCompletion > completedWithWarnings > completedWithErrors > canceledByUser > canceledByOperator > abortedBySystem > logfilePending > logfileTransferring > jobPreProcessing > jobPaused > jobInterrupted > jobRetained > jobHoldUntil > > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Thu May 29 10:10:28 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Instantiation Message-ID: <5030100002935296000002L062*@MHS> I had posted this topic earlier but I believe I only saw a response from one person (Jay) who agreed with me that it does not make sense to instantiate deviceAlertCode as soon as a job is "pending" because the device may never have an alert while producing that job. This may have become a mute point following our discussions about "printer-stopped" state etc. But, I still think we need to clarify the thread which was weaving during SanDiego which basically said... "mandatory attributes must be instantiated when the job enters pending state". One of the key attributes for which this is desired is jobOwner. This is due to the fact that "out of band" monitors will rely heavily on job owner for job identification. But, what should we do about multi-valued attributes like output bin? When the job is pending, there is no way to determine how many instances of output bin there will be! I think we should investigate what is behind the "instantiation" rule and ways to alleviate the problems it may cause. Basically, I think we are trying to define a list of objects or attributes that will never cause a GET (Varbind List) to fail. Correct? This would allow the monitoring application to "pick and choose" among these "mandatory, instantiated" attributes using an SNMP GET. For the Job Table, I agree that a GET on a row should reliably return a value for all objects in that row. I don't think it is necessary to achieve this level of instantiation, however, for the Attribute Table because, the monitoring application can use GET NEXT there, which will skip over any non-instantiated attributes. Based on this, I suggest we drop the "must be instantiated" rule as it relates to any attributes in the Attribute Table. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Thu May 29 12:01:04 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: A In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: A> Message-ID: <5030100002940251000002L012*@MHS> It would be quite interesting to sift through the archives and find the discussion leading to the decision to make 2 enum values "mandatory" for prtGeneralReset... >You are forgetting the prtGeneralReset object in the Printer MIB >which is an enum. >There are a few values that are mandatory and the Conformance >in the back explicitly lists which values are mandatory. >So we have the same situation for the JMP. ... but I would like to observe that, for prtGeneralReset, the set of "mandatory" supported values is *very* small, and (as I recall) agreed upon with the understanding that these are basically natural states of *every* printer. The two mandatory values are notResetting resettingToNVRAM Not resetting is a no-brainer. As defined, it has NO EFFECT on the printer. And, again, it would be interesting to re-live, but I recall discussion about printers that don't have NVRAM or can't reset to NVRAM in which case the behavior would be device specific (behavior is device specific anyway because there is no definition of what must be in NVRAM, if anything.). I think this is distinctly different than saying a printer or job agent MUST support a job state like "completedWithWarnings"! Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/29/97 09:43 AM --------------------------- jmp-owner@pwg.org 05/28/97 03:20 AM Please respond to jmp-owner@pwg.org @ internet To: bwagner@digprod.com @ internet cc: jmp@pwg.org @ internet, pgloger@cp10.es.xerox.com @ internet Subject: Re: Re[2]: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: A Bill, Tom At 11:47 05/27/97 PDT, Bill Wagner wrote: > I certainly can agree. I was rather wondering about all the > discussion. It was my understanding that objects can be mandatory, not > values of the object variable. > > Bill Wagner, Osicom/DPI > > >______________________________ Reply Separator _________________________________ >Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther >Author: JK Martin at Internet >Date: 5/27/97 2:16 PM > > >Ron, > >> The object jmJobState should be mandatory. All possible enums for this >> object must be reported if implemented and available to the agent. (I >> sent another email on this subject with more info earlier today.) >> >> Does this make more sense? > >Yes! I like your wording. Can everyone else agree to this? > > ...jay > > From harryl at us.ibm.com Thu May 29 12:03:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <5030100002940602000002L022*@MHS> I'd hate to think we might confuse the IETF... >Again, we will certainly confuse the IETF if we redefine what mandatory >means by using the defintion for conditionally mandatory as Ron has. Yes, I think I see the clarity already ;-) >We must, as we did for the Printer MIB jmGeneralReset, decide which >values an agent must implement whether the device does or not >and which values the agent need only implement if the device does. >We must label the former Mandatory and the latter Conditionally Mandatory. Harry Lewis - Individual From papowell at dickory.sdsu.edu Thu May 29 12:24:08 1997 From: papowell at dickory.sdsu.edu (Patrick Powell) Date: Wed May 6 14:00:06 2009 Subject: JMP> HELD vs NEEDS-ATTENTION Message-ID: <199705291624.JAA18554@dickory.sdsu.edu> Having thought about this, I realize that I really don't care WHICH form we use, as long as there is ONE form (format) that is common between the JMP and IPP protocols/standards. Note: while I want one set, I wouldn't be opposed to two sets of 'names' with a well defined (i.e. -cast into standard) mapping between the two sets. Patrick Powell From: "Caruso,Angelo" Subject: RE: JMP> HELD vs NEEDS-ATTENTION There seem to be two extremes on this whole issue. On the one side there are those who would like all their favorite states included in one easy to use job state object. On the other side are those who want to keep the job state object ultra simple and have lots of job state reasons. Both points of view have been backed up by many good arguments. Last week at the IPP teleconference it seemed that a reasonable COMPROMISE was reached. Unfortunately, several key JMP folks were not present for that discussion and now we're waffling on the whole issue again. Based on todays mail volume there does not appear to be any end in sight. For the record, here is my position. IPP and JMP should use EXACTLY the same set of job states and the same state reasons (the agreement reached at the last IPP/JMP teleconference seemed reasonable to me). How are we to expect the PWG to be taken seriously if we simultaneously create two specifications with different job models? The rest of the world expects and deserves a consistent set of standards from this working group! Please don't respond again how easy it is to map between the two different state models. I understand the mapping because I have been following the discussions. But the rest of the world will not find the mapping to be so obvious. If we learned anything from the Printer MIB interop testing it is that interpreting ONE model correctly is hard enough. Now, we are on the verge of generating two different models to represent the same thing. It's time to find a compromise. Thanks, Angelo From hastings at cp10.es.xerox.com Thu May 29 15:46:27 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: Charter Update Request (fwd) In-Reply-To: Message-ID: <9705291948.AA01348@zazen.cp10.es.xerox.com> Keith, What other lists do you suggest sending the Job Monitoring MIB to in order to get comments before LAST CALL? I'd be glad to do that. Also who determines "LAST CALL" for comments? How is that done and to whom? I'm not familiar with that step. Thanks, Tom At 10:17 05/23/97 PDT, Keith Moore wrote: snip... >> P.S. We have gotten no feed back from anyone outside the printmib WG >> on the first Internet-Draft Job Monitoring MIB that we submitted a few >> weeks ago as and was published >> as an I-D on 4/30/97. Should we be worried about this? > >I wouldn't consider it unusual, if that's what you mean. >Network management isn't exactly an attractive topic, even to most >IETFers, and so many Internet-Drafts are released that it's possible >that it escaped the notice of some people who might be interested. >People tend to pay more attention to Last Calls, which is unfortunate >because such feedback really needs to occur earlier. > >It doesn't hurt to actively solicit reviews from people or mailing lists >other than the working group mailing list. > >Keith > > From moore at cs.utk.edu Thu May 29 16:16:59 1997 From: moore at cs.utk.edu (Keith Moore) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: Charter Update Request (fwd) In-Reply-To: Message-ID: <199705292017.QAA02937@spot.cs.utk.edu> > What other lists do you suggest sending the Job Monitoring MIB to > in order to get comments before LAST CALL? > > I'd be glad to do that. > > Also who determines "LAST CALL" for comments? How is that done and to > whom? I'm not familiar with that step. Since JOB MIB isn't part of printmib's charter, this will be handled as an individual submission, and can be submitted at any time the authors feel that the document is ready. To submit the draft, follow the procedure listed in http://www.apps.ietf.org/apps/procedures.html under the heading "Standards without a WG" (which in turm references the section "Standards from a WG") Strictly speaking, the submission should come from the document authors. (IESG may refer the document to a working group -- say, the printmib working group -- for review, in which case the chair of that group should determine whether that group has any objections to the proposal... though if there's already a clear indication of concensus on the printmib mailing list, we won't bother with the actual referral...) As for where else to get comments, I'd certainly recommend having SNMP experts look it over for soundness (if it hasn't been done already), and you could send it to the APPS directorate at directorate@apps.ietf.org. You might also ask the O&M area directors, since they handle most SNMP-related stuff. Keith From jkm at underscore.com Thu May 29 16:48:36 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: Charter Update Request (fwd) In-Reply-To: Re: Charter Update Request (fwd)> Message-ID: <199705292048.QAA23356@uscore.underscore.com> Funny, but I thought the Job Monitoring MIB effort was officially sanctioned as part of the printmib WG as of the San Jose IETF meetings last December. (Or rather, shortly after those meetings, as a result of the Job MIB BOF.) Has something changed? Or do I (and others) misunderstand this situation? ...jay ----- Begin Included Message ----- X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , jmp@pwg.org, case@snmp.com, Chris Wellens , Lloyd Young , rbergma@dpc.com, don@lexmark.com, Harald Alvestrand Subject: JMP> Re: Charter Update Request (fwd) Date: Thu, 29 May 1997 16:16:59 -0400 > What other lists do you suggest sending the Job Monitoring MIB to > in order to get comments before LAST CALL? > > I'd be glad to do that. > > Also who determines "LAST CALL" for comments? How is that done and to > whom? I'm not familiar with that step. Since JOB MIB isn't part of printmib's charter, this will be handled as an individual submission, and can be submitted at any time the authors feel that the document is ready. To submit the draft, follow the procedure listed in http://www.apps.ietf.org/apps/procedures.html under the heading "Standards without a WG" (which in turm references the section "Standards from a WG") Strictly speaking, the submission should come from the document authors. (IESG may refer the document to a working group -- say, the printmib working group -- for review, in which case the chair of that group should determine whether that group has any objections to the proposal... though if there's already a clear indication of concensus on the printmib mailing list, we won't bother with the actual referral...) As for where else to get comments, I'd certainly recommend having SNMP experts look it over for soundness (if it hasn't been done already), and you could send it to the APPS directorate at directorate@apps.ietf.org. You might also ask the O&M area directors, since they handle most SNMP-related stuff. Keith ----- End Included Message ----- From moore at cs.utk.edu Thu May 29 17:45:46 1997 From: moore at cs.utk.edu (Keith Moore) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: Charter Update Request (fwd) In-Reply-To: Re: Charter Update Request (fwd)> Message-ID: <199705292145.RAA03206@spot.cs.utk.edu> > Funny, but I thought the Job Monitoring MIB effort was officially > sanctioned as part of the printmib WG as of the San Jose IETF meetings > last December. (Or rather, shortly after those meetings, as a result > of the Job MIB BOF.) > > Has something changed? Or do I (and others) misunderstand this situation? I don't have any record of that charter change being approved; for whatever reason, it never made it to the IETF web pages. Naturally, if the charter change really was formally approved by the area director, IETF should honor it. I'll ask the IETF secretariat to look through its records. However, I wouldn't let this hold up the job mib. If or when it's ready to go, go ahead and send it in. The approval process isn't that different, and once the document is approved there is no distinction between an individual submission and one produced by a working group. Keith From jkm at underscore.com Thu May 29 19:01:42 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> ISSUE: Putting jobOwner in the jmJobIDTable? In-Reply-To: ISSUE: Putting jobOwner in the jmJobIDTable?> Message-ID: <199705292301.TAA29221@uscore.underscore.com> Tom, Sorry for not responding sooner on your posting (and questions). > Jay, > > Does Harry's suggestion to put the jobOwner in the jmJobIDTable > as another form of job submission ID> Sorry, but this sentence is incomplete (no?). Restate the question? (This may not be necessary if the rest of this message addresses your thought.) > Presumably, the jobOwner would also go in the jmAttributeTable too, > where it would be for any jobsubmission id format, ok? > > The reason for duplicating the jobOwner in the jmJobIDTable is because > the persistence is longer (same as the jmJobTable) than in the > jmAttributeTable. This idea will work for those systems that don't > support the idea of a jobSubmissionID that is a unique ID generated by > the client or the server/printer. I don't think the jobOwner variable has to exist in two places. No data should be replicated in any other part of a MIB-based model (as recommended by the SNMP/MIB gurus), right? > So are there any applications that would need both the real job > submission id and the job owner, after the jmAttributeTable entry > as been deleted? If applications copy the jobOwner sometime while > the job is pending, processing, or completed, before the attributes > are deleted, there won't be a problem. But if applications are memoryless > and don't copy the attribute table, then the jobOwner would be lost, > except for systems that don't have a real job submission id and use > the job owner as the job submission id. Look, if certain informational components of a job can be "aged out" over time, then applications must have a way to uniquely identify jobs while the remaining info is available. It really has nothing to do with the infamous "memoryless" application design--if the app doesn't get to the agent before the data is aged out, then it doesn't matter how much state baggage the app carries around. In other words, jobOwner must be available for the life of the job in the agent. ...jay From jkm at underscore.com Thu May 29 20:37:59 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value Message-ID: <199705300037.UAA03417@uscore.underscore.com> Harry, Sorry for not responding to your question sooner... > So, what about my proposal to add a new jmJobSubmissionID format for LPR > JobOwner? The owner information would have to be truncated to 30 bytes and > someone, most likely the NIC, would have to prepend the assigned > jmJobSubmissionID format number to the attribute. Your proposal (as documented in the San Diego meeting minutes, page 4) suggested this encoding of the 30 available octets: Job owner: 6 Owner's host: 8 Server job ID: 16 This doesn't look like it will work, as the owner/host values are too severely truncated. To ensure the required uniqueness, the server job ID must be at least 12 bytes to cover the Unix case; many (but not all) Unix systems restrict queue names to 9 bytes, and when combined with the 3 bytes required for the job number (0-999), this makes a total of 12 bytes. This means we have 4 more bytes to use for either the owner and/or host components. This is still too restrictive, unfortunately. We need the jobOwner field. (Sorry!) However, I don't think we need to take Tom's suggestion of changing the JobID table to include jobOwner and make the table indexed by *both* the submission ID *and* the jobOwner values, as this makes life more complex for ALL other environments. If jobOwner is added to the jobID or jobState tables, then those monitoring apps that need to key off of jobOwner will simply have to do their own indexing on the jobOwner value in each job entry. Comments? ...jay From jkm at underscore.com Thu May 29 21:15:15 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <199705300115.VAA05070@uscore.underscore.com> In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay From Angelo_Caruso at wb.xerox.com Fri May 30 08:42:37 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:06 2009 Subject: JMP> Instantiation Message-ID: <199705300115.VAA05070@uscore.underscore.com> Harry, I agree completely. Good MIB design should not center around guaranteeing that GETs always succeed. This is why some SNMP protocol guru's (Jeff Case, for example) preach that GET is evil, but GET NEXT is good. Angelo ---------- From: jmp-owner@pwg.org To: jmp@pwg.org Subject: JMP> Instantiation Date: Thursday, May 29, 1997 12:00AM I had posted this topic earlier but I believe I only saw a response from one person (Jay) who agreed with me that it does not make sense to instantiate deviceAlertCode as soon as a job is "pending" because the device may never have an alert while producing that job. This may have become a mute point following our discussions about "printer-stopped" state etc. But, I still think we need to clarify the thread which was weaving during SanDiego which basically said... "mandatory attributes must be instantiated when the job enters pending state". One of the key attributes for which this is desired is jobOwner. This is due to the fact that "out of band" monitors will rely heavily on job owner for job identification. But, what should we do about multi-valued attributes like output bin? When the job is pending, there is no way to determine how many instances of output bin there will be! I think we should investigate what is behind the "instantiation" rule and ways to alleviate the problems it may cause. Basically, I think we are trying to define a list of objects or attributes that will never cause a GET (Varbind List) to fail. Correct? This would allow the monitoring application to "pick and choose" among these "mandatory, instantiated" attributes using an SNMP GET. For the Job Table, I agree that a GET on a row should reliably return a value for all objects in that row. I don't think it is necessary to achieve this level of instantiation, however, for the Attribute Table because, the monitoring application can use GET NEXT there, which will skip over any non-instantiated attributes. Based on this, I suggest we drop the "must be instantiated" rule as it relates to any attributes in the Attribute Table. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Fri May 30 11:16:01 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <5030100002977564000002L042*@MHS> Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay From jkm at underscore.com Fri May 30 13:55:03 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <199705301755.NAA20176@uscore.underscore.com> Harry, I'm a bit confused by your response. You suggest that the format identifier for LPR/LPD could be the "cfA" prefix string; however, don't we want to be completely consistent with the form for the format descriptor? That is, all the other format descriptors are two-digit numeric characters, and I would have thought that we'd want to define all format descriptors in that manner to simplify parsing/lookup, etc. Perhaps I'm missing something here? Thanks for being agreeable to moving from a two-digit descriptor to a single-digit descriptor. Let's see if the rest of the group can agree to that. ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Fri, 30 May 1997 11:16:01 -0400 Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay ----- End Included Message ----- From jkm at underscore.com Fri May 30 14:12:51 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <199705301812.OAA20945@uscore.underscore.com> I guess I can agree with Patrick's proposal for the LPR/LPD submission ID encoding. I'm still concerned about the length restrictions for this object (currently a max of 30, but could become 31 if we move from a 2-digit format field size to a single-digit field). The question now might be: can this format serve as a useful way to identify the job owner, thereby eliminating the need to have the jobOwner object in the jobState table? I still think the answer is No, due to the length restrictions for the jmJobSubmissionID object. If that object were to increase in size to, say, 63 bytes, then maybe this could work. (I can hear Harry cringing even as I write this... ;-) If the submission ID object were increased to 63 bytes (hey, or even more! ;-), then it might very well be that jobOwner can stay in the quickly-aged-out jobAttribute table. If we were to make this move, then I would definitely prefer Patrick's encoding form, and think that jobOwner can then stay in the jobAttribute table. Comments on such a change to increase the size of jmJobSubmissionID? ...jay ----- Begin Included Message ----- Date: Fri, 30 May 1997 09:08:46 -0700 (PDT) From: Patrick Powell To: jkm@underscore.com Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value # Date: Thu, 29 May 1997 21:15:15 -0400 (EDT) # From: JK Martin # To: jmp@pwg.org # Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value # In that previous message I forgot to state that I think it would be # a good idea to formally define a job submission ID specifically for # LPR/LPD, even though such an ID would not necessarily help the kinds # of monitoring apps we've been talking about recently (ie, "out-of-band" # job monitors). # The encoding of the ID for LPR/LPD is quite trivial and follows the # format defined in RFC 1179 for the encoding of the control/data files. # Control file names follow this form: # cfAnnn example: cfA027punky.underscore.com I would like to suggest: user@host+jobnumber For example: root@dickory+024 or root@dickory.sdsu.edu+024 The job ID embeds the user, originating host, and job number id into one 'string'. The job ID would fix up the problem of conflicts in job numbers which could occur from different hosts, if there was not a distinguisher. In addition, I like to see the user's name in the id. Patrick Powell ----- End Included Message ----- From bpenteco at boi.hp.com Fri May 30 16:31:03 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:06 2009 Subject: JMP> PJL command for jmJobSubmissionIDIndex Message-ID: <01BC6D06.1B37BBC0@hpb15767.boi.hp.com> At the San Diego meeting I agreed to provide some PJL job submission information that could be added to an appendix of the Job Monitoring MIB. Below is the suggested wording. Bob Pentecost HP ======================================== Hewlett-Packard's Printer Job Language provides job-level printer control and printer status information to applications. The PJL JOB command is used at the beginning of a print job and can include options applying only to that job. A PJL JOB command option has been defined to facilitate passing the JobSubmissionID with the print job, as required by the Job Monitoring MIB. The option is of the form: SUBMISSIONID = "id string" Where the "id string" is a string and must be enclosed in double quotes. The format is as described for the jmJobSubmissionIDIndex object. The entire PJL JOB command with the optional parameter would be of the form: @PJL JOB SUBMISSIONID = "id string" See "Printer Job Language Technical Reference Manual", part number 5021-0328, from Hewlett-Packard for complete information on the the PJL JOB command and the Printer Job Language. From jkm at underscore.com Fri May 30 16:56:57 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> PJL command for jmJobSubmissionIDIndex In-Reply-To: PJL command for jmJobSubmissionIDIndex> Message-ID: <199705302056.QAA28530@uscore.underscore.com> Outstanding, Bob. This would be very beneficial for Job MIB use. ...jay ----- Begin Included Message ----- From: Bob Pentecost To: "'PWG-jmp'" Subject: JMP> PJL command for jmJobSubmissionIDIndex Date: Fri, 30 May 1997 14:31:03 -0600 Encoding: 32 TEXT At the San Diego meeting I agreed to provide some PJL job submission information that could be added to an appendix of the Job Monitoring MIB. Below is the suggested wording. Bob Pentecost HP ======================================== Hewlett-Packard's Printer Job Language provides job-level printer control and printer status information to applications. The PJL JOB command is used at the beginning of a print job and can include options applying only to that job. A PJL JOB command option has been defined to facilitate passing the JobSubmissionID with the print job, as required by the Job Monitoring MIB. The option is of the form: SUBMISSIONID = "id string" Where the "id string" is a string and must be enclosed in double quotes. The format is as described for the jmJobSubmissionIDIndex object. The entire PJL JOB command with the optional parameter would be of the form: @PJL JOB SUBMISSIONID = "id string" See "Printer Job Language Technical Reference Manual", part number 5021-0328, from Hewlett-Packard for complete information on the the PJL JOB command and the Printer Job Language. ----- End Included Message ----- From harryl at us.ibm.com Mon Jun 2 12:36:04 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <5030100003037795000002L052*@MHS> Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it "violates" the 2 (or 1) byte format ID definition, to accommodate existing systems that utilize this convention. I have interpreting your concerns about compatibility as indications that it will be unlikely for system components to be created or modified to add the JobSubmissionID format ID byte(s). Am I misreading you? Yes, I would prefer to have an "architected" 1-byte format ID. Harry Lewis ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 10:12 AM --------------------------- jkm@underscore.com 05/30/97 04:41 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, I'm a bit confused by your response. You suggest that the format identifier for LPR/LPD could be the "cfA" prefix string; however, don't we want to be completely consistent with the form for the format descriptor? That is, all the other format descriptors are two-digit numeric characters, and I would have thought that we'd want to define all format descriptors in that manner to simplify parsing/lookup, etc. Perhaps I'm missing something here? Thanks for being agreeable to moving from a two-digit descriptor to a single-digit descriptor. Let's see if the rest of the group can agree to that. ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Fri, 30 May 1997 11:16:01 -0400 Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay ----- End Included Message ----- From jkm at underscore.com Mon Jun 2 12:37:59 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <199706021637.MAA16776@uscore.underscore.com> Harry, Your concern for integration is most appreciated, however I don't think it's a big deal to strip the leading "cfA" prefix off the LPR/LPD job submission string. Ron Bergman: It looks like we're going to need a "vote" (ie, in IETF terms, a "statement of consensus" ;-) regarding the change in the length of the format descriptor for the job submission ID string. (From the current 2 bytes to 1 byte.) ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Mon, 2 Jun 1997 12:36:04 -0400 Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it "violates" the 2 (or 1) byte format ID definition, to accommodate existing systems that utilize this convention. I have interpreting your concerns about compatibility as indications that it will be unlikely for system components to be created or modified to add the JobSubmissionID format ID byte(s). Am I misreading you? Yes, I would prefer to have an "architected" 1-byte format ID. Harry Lewis ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 10:12 AM --------------------------- jkm@underscore.com 05/30/97 04:41 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, I'm a bit confused by your response. You suggest that the format identifier for LPR/LPD could be the "cfA" prefix string; however, don't we want to be completely consistent with the form for the format descriptor? That is, all the other format descriptors are two-digit numeric characters, and I would have thought that we'd want to define all format descriptors in that manner to simplify parsing/lookup, etc. Perhaps I'm missing something here? Thanks for being agreeable to moving from a two-digit descriptor to a single-digit descriptor. Let's see if the rest of the group can agree to that. ...jay ----- Begin Included Message ----- >From harryl@us.ibm.com Fri May 30 11:14 EDT 1997 From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Fri, 30 May 1997 11:16:01 -0400 Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay ----- End Included Message ----- ----- End Included Message ----- From harryl at us.ibm.com Mon Jun 2 15:32:25 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <5030100003047566000002L062*@MHS> I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). I want to add that I believe the original proposal was 1 byte and I think we "up'd" it to 2 bytes in Austin based on some expectation that other (how shall I phrase this...) individuals were aware of (close your ears...) Companies... that may have a lot of additional formats to register. So, we should make sure we receive some input from Tom. He seemed like the individual most likely to know of such a company. Harry Lewis -------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 01:19 PM ------- jmp-owner@pwg.org 06/02/97 11:18 AM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, Your concern for integration is most appreciated, however I don't think it's a big deal to strip the leading "cfA" prefix off the LPR/LPD job submission string. Ron Bergman: It looks like we're going to need a "vote" (ie, in IETF terms, a "statement of consensus" ;-) regarding the change in the length of the format descriptor for the job submission ID string. (From the current 2 bytes to 1 byte.) ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Mon, 2 Jun 1997 12:36:04 -0400 Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it "violates" the 2 (or 1) byte format ID definition, to accommodate existing systems that utilize this convention. I have interpreting your concerns about compatibility as indications that it will be unlikely for system components to be created or modified to add the JobSubmissionID format ID byte(s). Am I misreading you? Yes, I would prefer to have an "architected" 1-byte format ID. Harry Lewis ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 10:12 AM --------------------------- jkm@underscore.com 05/30/97 04:41 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, I'm a bit confused by your response. You suggest that the format identifier for LPR/LPD could be the "cfA" prefix string; however, don't we want to be completely consistent with the form for the format descriptor? That is, all the other format descriptors are two-digit numeric characters, and I would have thought that we'd want to define all format descriptors in that manner to simplify parsing/lookup, etc. Perhaps I'm missing something here? Thanks for being agreeable to moving from a two-digit descriptor to a single-digit descriptor. Let's see if the rest of the group can agree to that. ...jay ----- Begin Included Message ----- >From harryl@us.ibm.com Fri May 30 11:14 EDT 1997 From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Fri, 30 May 1997 11:16:01 -0400 Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay ----- End Included Message ----- ----- End Included Message ----- From jkm at underscore.com Mon Jun 2 15:39:23 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <199706021939.PAA29121@uscore.underscore.com> If one or more persons have indicated the expectation of a *large* number of registered job ID formats, then great. (I had not heard that before.) If we think we need two bytes, then as long as someone can *really* justify it, then it should probably stay two bytes. (We just don't want to here a line like "somebody somehow for some reason just might want to register a lot of ID formats..." ;-) Ron: Would you mind asking for "Last Call" on this issue? Thanks. ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Mon, 2 Jun 1997 15:32:25 -0400 I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). I want to add that I believe the original proposal was 1 byte and I think we "up'd" it to 2 bytes in Austin based on some expectation that other (how shall I phrase this...) individuals were aware of (close your ears...) Companies... that may have a lot of additional formats to register. So, we should make sure we receive some input from Tom. He seemed like the individual most likely to know of such a company. Harry Lewis -------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 01:19 PM ------- jmp-owner@pwg.org 06/02/97 11:18 AM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, Your concern for integration is most appreciated, however I don't think it's a big deal to strip the leading "cfA" prefix off the LPR/LPD job submission string. Ron Bergman: It looks like we're going to need a "vote" (ie, in IETF terms, a "statement of consensus" ;-) regarding the change in the length of the format descriptor for the job submission ID string. (From the current 2 bytes to 1 byte.) ...jay ----- Begin Included Message ----- >From harryl@us.ibm.com Mon Jun 2 12:34 EDT 1997 From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Mon, 2 Jun 1997 12:36:04 -0400 Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it "violates" the 2 (or 1) byte format ID definition, to accommodate existing systems that utilize this convention. I have interpreting your concerns about compatibility as indications that it will be unlikely for system components to be created or modified to add the JobSubmissionID format ID byte(s). Am I misreading you? Yes, I would prefer to have an "architected" 1-byte format ID. Harry Lewis ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 10:12 AM --------------------------- jkm@underscore.com 05/30/97 04:41 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Harry, I'm a bit confused by your response. You suggest that the format identifier for LPR/LPD could be the "cfA" prefix string; however, don't we want to be completely consistent with the form for the format descriptor? That is, all the other format descriptors are two-digit numeric characters, and I would have thought that we'd want to define all format descriptors in that manner to simplify parsing/lookup, etc. Perhaps I'm missing something here? Thanks for being agreeable to moving from a two-digit descriptor to a single-digit descriptor. Let's see if the rest of the group can agree to that. ...jay ----- Begin Included Message ----- >From harryl@us.ibm.com Fri May 30 11:14 EDT 1997 From: Harry Lewis To: Cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value Date: Fri, 30 May 1997 11:16:01 -0400 Jay, thanks for your informative response on this topic. I agree that 2 bytes is over-kill. I have no problem moving back to one byte for the Format ID. Since LPR is already a defined standard, and cfA always precedes the control file naming string, why not just reserve cfA as the LPR format identifier? I know it uses more bytes, but this would alleviate the need for adding the Format ID somewhere in the process. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- jmp-owner@pwg.org 05/29/97 07:17 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value In that previous message I forgot to state that I think it would be a good idea to formally define a job submission ID specifically for LPR/LPD, even though such an ID would not necessarily help the kinds of monitoring apps we've been talking about recently (ie, "out-of-band" job monitors). The encoding of the ID for LPR/LPD is quite trivial and follows the format defined in RFC 1179 for the encoding of the control/data files. Control file names follow this form: cfAnnn example: cfA027punky.underscore.com That is, a fixed prefix of "cfA" followed by a three-digit job number (000-999) followed by the hostname (usually fully qualified). Data files are similar, except that the "cfA" prefix is replaced with "dfA". (Hence the common references to "cf/df" files when talking about LPD spooling.) The idea here is that the names of the control and data files are very similar, with the only exception being the first character (ie, "c" vs. "d"). Since this distinction in prefixes is relatively meaningless for job identification, we shouldn't need to include the first three characters in the Job MIB job submission ID string. This results in an encoding of: nnn example: 027punky.underscore.com Of course, the component would have to be truncated after the 27th character, but since hostnames are formed with a left-to-right hierarchy, this should be sufficient for most environments (right??). The LPD encoding would be tagged with "04" in the list of defined job submission ID formats. By the way, why in the world do we need TWO octets for the format descriptor? As it stands we have only 5 formats (including this new LPD definition)! If we reduce this to a single byte (and continue to use a decimal-digit encoding technique), then we have room for 5 additional formats. Even if we needed more, we could then use a hex-like technique and start using letters (a-z, etc). This is a classic case of over-engineering, IMHO. Here we are worrying about truncating valuable information when we're wasting it elsewhere. We should change this. Comments? ...jay ----- End Included Message ----- ----- End Included Message ----- ----- End Included Message ----- From harryl at us.ibm.com Mon Jun 2 18:07:54 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: MOD JobState suggestion> Message-ID: <5030100003054899000002L092*@MHS> I am confused by the notation used in this discussion: >The states are: > pending > pending-stopped > processing > processing-stopped > done-aborted > done-canceled > done-completed >I suggest changing the last three states to > completed > completed-canceled > completed-abort I understand PENDING, PROCESSING and COMPLETED states. I thought I was following a thread, somewhere, that PENDING-STOPPED was another way to say HELD and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is going on... just some renaming? Or do the "dashes" in these names indicate separation between a state and a reason? I agree with Bob's recommendations, above, to stick with Completed rather than Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? What are we gaining. I find these discussions frequently go down the "generic language" path until the labels we choose are so vague that, rather than risk misinterpretation, the names end up meaning very little at all. Harry Lewis From jkm at underscore.com Mon Jun 2 18:13:34 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <199706022213.SAA06514@uscore.underscore.com> We took a very simple 3-state queue mechanism (waiting,working,done), then artificially elevated a few well-known substates to "full state" values to make some folks happy. This was done during the last IPP telecon, last Wednesday. ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: Subject: JMP> Re: IPP> MOD JobState suggestion Date: Mon, 2 Jun 1997 18:07:54 -0400 I am confused by the notation used in this discussion: >The states are: > pending > pending-stopped > processing > processing-stopped > done-aborted > done-canceled > done-completed >I suggest changing the last three states to > completed > completed-canceled > completed-abort I understand PENDING, PROCESSING and COMPLETED states. I thought I was following a thread, somewhere, that PENDING-STOPPED was another way to say HELD and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is going on... just some renaming? Or do the "dashes" in these names indicate separation between a state and a reason? I agree with Bob's recommendations, above, to stick with Completed rather than Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? What are we gaining. I find these discussions frequently go down the "generic language" path until the labels we choose are so vague that, rather than risk misinterpretation, the names end up meaning very little at all. Harry Lewis ----- End Included Message ----- From Robert.Herriot at Eng.Sun.COM Mon Jun 2 18:23:22 1997 From: Robert.Herriot at Eng.Sun.COM (Robert Herriot) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <199706022223.PAA12980@woden.eng.sun.com> In one sense we have just renamed some states: held to pending-stopped and needs-attention to processing-stopped. But the renaming regularizes the names to give the impression that there are 3 high level states of pending, processing and completed and 4 additional variant of those states. These regularized states allow us to have other attributes that draw from these names, e.g. time-since-pending time-since-processing and time-since-completed. It also allows the addition of other states, such as completed-with-errors. Bob Herriot > From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 > > I am confused by the notation used in this discussion: > > >The states are: > > > pending > > pending-stopped > > processing > > processing-stopped > > done-aborted > > done-canceled > > done-completed > > >I suggest changing the last three states to > > > completed > > completed-canceled > > completed-abort > > I understand PENDING, PROCESSING and COMPLETED states. I thought I was > following a thread, somewhere, that PENDING-STOPPED was another way to say HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is > going on... just some renaming? Or do the "dashes" in these names indicate > separation between a state and a reason? > > I agree with Bob's recommendations, above, to stick with Completed rather than > Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we gaining. I find these discussions frequently go down the "generic > language" path until the labels we choose are so vague that, rather than risk > misinterpretation, the names end up meaning very little at all. > > Harry Lewis > From jkm at underscore.com Mon Jun 2 18:35:54 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <199706022235.SAA08058@uscore.underscore.com> I guess I'm a bit disappointed that we elected to not do the "elegant" thing and simply have 3 states (pending, processing, done), then use a set defined of substates to describe refinements of those states. A rare chance to do something that is both elegant *and* simple. (Sigh...) ...jay ----- Begin Included Message ----- Date: Mon, 2 Jun 1997 15:23:22 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org, harryl@us.ibm.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: jmp@pwg.org In one sense we have just renamed some states: held to pending-stopped and needs-attention to processing-stopped. But the renaming regularizes the names to give the impression that there are 3 high level states of pending, processing and completed and 4 additional variant of those states. These regularized states allow us to have other attributes that draw from these names, e.g. time-since-pending time-since-processing and time-since-completed. It also allows the addition of other states, such as completed-with-errors. Bob Herriot > From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 > > I am confused by the notation used in this discussion: > > >The states are: > > > pending > > pending-stopped > > processing > > processing-stopped > > done-aborted > > done-canceled > > done-completed > > >I suggest changing the last three states to > > > completed > > completed-canceled > > completed-abort > > I understand PENDING, PROCESSING and COMPLETED states. I thought I was > following a thread, somewhere, that PENDING-STOPPED was another way to say HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is > going on... just some renaming? Or do the "dashes" in these names indicate > separation between a state and a reason? > > I agree with Bob's recommendations, above, to stick with Completed rather than > Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we gaining. I find these discussions frequently go down the "generic > language" path until the labels we choose are so vague that, rather than risk > misinterpretation, the names end up meaning very little at all. > > Harry Lewis > ----- End Included Message ----- From hastings at cp10.es.xerox.com Mon Jun 2 20:20:07 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: "NEED NOT" is a better negative than "MAY NOT" - from In-Reply-To: <"NEED NOT" is a better negative than "MAY NOT" - from> Message-ID: <9706030022.AA01484@zazen.cp10.es.xerox.com> Scott Bradner replied to my query, but I missed it, on NEED NOT and capitalizing the conformance words. Tom >Return-Path: >Date: Thu, 22 May 1997 04:27:22 PDT >From: Scott Bradner >To: hastings@cp10.es.xerox.com >Subject: Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX > >Tom, > "need not" would be a good addition. If this rfc comes >up for revision I will add that. > >> Also, are you recommending that we capitalize the words? > >there was quite a bit of argument on that. I think it helps the reader >quite a bit but some other people felt that we did not even >need the rfc since the words should mean what they mean. The compromise >was to just say that the "may" be capitalized. > >Scott > > From hastings at cp10.es.xerox.com Mon Jun 2 21:09:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are there> Message-ID: <9706030111.AB01503@zazen.cp10.es.xerox.com> At 07:39 05/28/97 PDT, Ron Bergman wrote: snip.. > >RB> Tom, I still have a hard time justifying that enums for an object >RB> are "mandatory" or "conditionally-mandatory". It made some sense >RB> for the Attribute Table but for objects in the Job State Table this >RB> generating significant confusion. I still prefer that the *object* >RB> jmJobState be "mandatory" and the enums for the object are implied >RB> to be "conditionally mandatory". So some say make all the job state enums mandatory and some say make them all conditionally mandatory. As I've tried to reason before, the 'completed' state is one of the most important states to make mandatory, not conditionally mandatory. Most printers today do not have a 'completed' state, at least not one that lasts for a human perceptable time. So if JMP doesn't make the 'completed' state mandatory, no one need implement it. Doesn't that make sense to include 'completed' in the conformance ASN.1 at the back, like we did for Reset in the Printer MIB? Tom From hastings at cp10.es.xerox.com Mon Jun 2 21:09:21 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:> Message-ID: <9706030111.AA01503@zazen.cp10.es.xerox.com> At 04:57 05/28/97 PDT, Peter Zehler wrote: >Tom, >The amount of time a job would be in the pending state on a non-queueing > non-spooling printer could be noticable to humans. It is dependant on the >size of the print jobs on the other channels. Then such a printer shall implement the conditionally mandatory pending state. But an implementation that never waited a human perceptible time should not have to implement the 'pending' state. Imagine that you are building a product that is going to be tested against by a testing company. If 'pending' is mandatory and your product doesn't ever show 'pending', that testing company might say you didn't conform to the standard. >I think it would simplify things just to have the pending state mandatory. >Implementations could step through this state so quickly it would never be >noticable to humans. If we spend much more time discussing this issue, it may be wiser to take your suggestion and make 'pending' mandatory. >Pete > > >Peter, > >How long would a job be in the pending state in your non-queuing, non-spooling >IPP system? > >If the time is not noticable to humans, e.g., 100s of miliseconds, I would >think that there wan't much point in simplementin the IPP state of 'pending'. >If it was longer, so that end-users would see it for a while, while nothing >was happending on the printer, then it would be good to implemente the >IPP 'pending' state for your Printer object. > >So your point was not that 'pending' must be a Mandatory state, but >that in your implementation of a simple, non-queuing, non-spooling printer >you wanted to be able to implement 'pending'. So we just have to find >language that permits non-queuing, non-spooling printers to implement >'pending', but doesn't require it. > >On the other hand, it might be simpler to mandate the 'pending' state >and for implementations that don't queue or spool, the state would >never be visible or would be visible for a very short period of time. > >Tom > > > > From hastings at cp10.es.xerox.com Mon Jun 2 21:09:28 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: In-Reply-To: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:> Message-ID: <9706030111.AB01503@zazen.cp10.es.xerox.com> At 08:20 05/28/97 PDT, Harry Lewis wrote: >Regarding this statement... > >>I think it would simplify things just to have the pending state mandatory. > >I think we should all agree, as (I think it was) Ron Bergman who pointed out, >that it is jmJobState which is mandatory... *not* the underlying enums. What about my argument about the 'completed' state? As I've tried to reason before, the 'completed' state is one of the most important states to make mandatory, not conditionally mandatory. Most printers today do not have a 'completed' state, at least not one that lasts for a human perceptable time. So if JMP doesn't make the 'completed' state mandatory, no one need implement it. Doesn't that make sense to include 'completed' in the conformance ASN.1 at the back, like we did for Reset in the Printer MIB? > >I agree with the "spirit" of the concensus, however, that non-spooling >devices *can* have jobs pending for significant periods of time. I agree. And if 'pending' is conditionally mandatory, then such a printer that can take a signigicant period of time shall have to implement 'pending'. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon Jun 2 21:09:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Instantiation In-Reply-To: Instantiation> Message-ID: <9706030111.AB01503@zazen.cp10.es.xerox.com> At 07:10 05/29/97 PDT, Harry Lewis wrote: >I had posted this topic earlier but I believe I only saw a response from one >person (Jay) who agreed with me that it does not make sense to instantiate >deviceAlertCode as soon as a job is "pending" because the device may never have >an alert while producing that job. This may have become a mute point following >our discussions about "printer-stopped" state etc. > >But, I still think we need to clarify the thread which was weaving during >SanDiego which basically said... "mandatory attributes must be instantiated >when the job enters pending state". One of the key attributes for which this is >desired is jobOwner. This is due to the fact that "out of band" monitors will >rely heavily on job owner for job identification. > >But, what should we do about multi-valued attributes like output bin? When the >job is pending, there is no way to determine how many instances of output bin >there will be! Good point. However, output bin was agreed not to be mandatory. So if the rule is that only mandatory attributes shall be instantiated when the job is received, then it is only the jobOwner that need be instantiated at submit time. > >I think we should investigate what is behind the "instantiation" rule and ways >to alleviate the problems it may >cause. Basically, I think we are trying to define a list of objects or >attributes that will never cause a GET (Varbind List) to fail. Correct? This >would allow the monitoring application to "pick and choose" among these >"mandatory, instantiated" attributes using an SNMP GET. Good point. > >For the Job Table, I agree that a GET on a row should reliably return a value >for all objects in that row. I don't think it is necessary to achieve this >level of instantiation, however, for the Attribute Table because, the >monitoring application can use GET NEXT there, which will skip over any >non-instantiated attributes. I agree. So can we agree to say that only mandatory objects and attributes shall be instantiated when the job is received? > >Based on this, I suggest we drop the "must be instantiated" rule as it relates >to any attributes in the Attribute Table. Except the jobOwner which is mandatory? > > >Harry Lewis - IBM Printing Systems > > From bogus@does.not.exist.com Tue Jun 3 09:52:56 1997 From: bogus@does.not.exist.com () Date: Wed May 6 14:00:06 2009 Subject: No subject Message-ID: <> Hi Tom, Note that the POSIX.2 usage of 'need not' as the inverse of 'may' is now ubiquitous in new ISO and IEEE communications standards. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA24966; Mon, 2 Jun 97 20:30:45 EDT Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA07689; Mon, 2 Jun 97 20:27:57 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <14603(4)>; Mon, 2 Jun 1997 17:28:10 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18480 for ; Mon, 2 Jun 1997 20:24:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Jun 1997 20:22:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18363 for jmp-outgoing; Mon, 2 Jun 1997 20:22:16 -0400 (EDT) Message-Id: <9706030022.AA01484@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Jun 1997 17:20:07 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX [and capatalizing conformance words] Sender: jmp-owner@pwg.org Status: R Scott Bradner replied to my query, but I missed it, on NEED NOT and capitalizing the conformance words. Tom >Return-Path: >Date: Thu, 22 May 1997 04:27:22 PDT >From: Scott Bradner >To: hastings@cp10.es.xerox.com >Subject: Re: "NEED NOT" is a better negative than "MAY NOT" - from POSIX > >Tom, > "need not" would be a good addition. If this rfc comes >up for revision I will add that. > >> Also, are you recommending that we capitalize the words? > >there was quite a bit of argument on that. I think it helps the reader >quite a bit but some other people felt that we did not even >need the rfc since the words should mean what they mean. The compromise >was to just say that the "may" be capitalized. > >Scott > > From harryl at us.ibm.com Tue Jun 3 10:15:38 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are ther> Message-ID: <5030100003070447000002L072*@MHS> Combining from a couple previous notes... >As I've tried to reason before, the 'completed' state is one of the >most important states to make mandatory, not conditionally mandatory. >Most printers today do not have a 'completed' state, at least not one >that lasts for a human perceptable time. So if JMP doesn't make the >'completed' state mandatory, no one need implement it. >Tom These two statements are contradictory. If most printers don't have a completed state then how can we possibly make completed state mandatory? I am not in favor of describing job states as mandatory or conditionally mandatory but I agree that COMPLETED is probably the most "interesting" state and would go along with applying some architectural emphasis (like was done for prtGeneralReset). >Then such a printer shall implement the conditionally mandatory >pending state. But an implementation that never waited a human perceptible >time should not have to implement the 'pending' state. Imagine that you >are building a product that is going to be tested against by a testing >company. If 'pending' is mandatory and your product doesn't ever show >'pending', that testing company might say you didn't conform to the >standard. I agree with Tom's imagination. All the more reason NOT to specify job state enumerations as mandatory (except, possibly for Completed). Harry From harryl at us.ibm.com Tue Jun 3 10:24:55 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003070660000002L002*@MHS> Thank you Jay! I agree! Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 06/03/97 08:18 AM ------ jmp-owner@pwg.org 06/02/97 06:39 PM Please respond to jmp-owner@pwg.org @ internet To: Robert.Herriot@Eng.Sun.COM @ internet cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: Re: JMP> Re: IPP> MOD JobState suggestion I guess I'm a bit disappointed that we elected to not do the "elegant" thing and simply have 3 states (pending, processing, done), then use a set defined of substates to describe refinements of those states. A rare chance to do something that is both elegant *and* simple. (Sigh...) ...jay ----- Begin Included Message ----- Date: Mon, 2 Jun 1997 15:23:22 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) To: ipp@pwg.org, harryl@us.ibm.com Subject: Re: JMP> Re: IPP> MOD JobState suggestion Cc: jmp@pwg.org In one sense we have just renamed some states: held to pending-stopped and needs-attention to processing-stopped. But the renaming regularizes the names to give the impression that there are 3 high level states of pending, processing and completed and 4 additional variant of those states. These regularized states allow us to have other attributes that draw from these names, e.g. time-since-pending time-since-processing and time-since-completed. It also allows the addition of other states, such as completed-with-errors. Bob Herriot > From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 > > I am confused by the notation used in this discussion: > > >The states are: > > > pending > > pending-stopped > > processing > > processing-stopped > > done-aborted > > done-canceled > > done-completed > > >I suggest changing the last three states to > > > completed > > completed-canceled > > completed-abort > > I understand PENDING, PROCESSING and COMPLETED states. I thought I was > following a thread, somewhere, that PENDING-STOPPED was another way to say HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is > going on... just some renaming? Or do the "dashes" in these names indicate > separation between a state and a reason? > > I agree with Bob's recommendations, above, to stick with Completed rather than > Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we gaining. I find these discussions frequently go down the "generic > language" path until the labels we choose are so vague that, rather than risk > misinterpretation, the names end up meaning very little at all. > > Harry Lewis > ----- End Included Message ----- From bwagner at digprod.com Tue Jun 3 10:34:56 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are t Message-ID: <5030100003070660000002L002*@MHS> Tom, I guess I will try again. Why do we feel obligated to make the enums mandatory or conditionally mandatory? I do not think that the unfortunate fact that we made one object mandatory on the printer MIB, and a very particular set-only object at that, has set sufficient precedent. The question of which state values are mandatory and which are conditionally mandatory has been argued to death. One of the reasons is, I believe, that the reason/justification for making any state mandatory is not understood. What is the reason for making state values mandatory? Or conditionally mandatory? What does it mean to have state mandatory, or conditioanlly mandatory? 1. Does it mean that every job must go through every mandatory state? 2. Does it mean that the hardware be capable of putting a job in each the "mandatory" state? 3. Does it mean that, if a job is in a "mandatory" state, the equipment must report it? Calling on the IETF definitions for mandatory and conditioanlly mandatory doe not answer these questions. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther Author: Tom Hastings at Internet Date: 6/2/97 6:09 PM At 07:39 05/28/97 PDT, Ron Bergman wrote: snip.. > >RB> Tom, I still have a hard time justifying that enums for an object >RB> are "mandatory" or "conditionally-mandatory". It made some sense >RB> for the Attribute Table but for objects in the Job State Table this >RB> generating significant confusion. I still prefer that the *object* >RB> jmJobState be "mandatory" and the enums for the object are implied >RB> to be "conditionally mandatory". So some say make all the job state enums mandatory and some say make them all conditionally mandatory. As I've tried to reason before, the 'completed' state is one of the most important states to make mandatory, not conditionally mandatory. Most printers today do not have a 'completed' state, at least not one that lasts for a human perceptable time. So if JMP doesn't make the 'completed' state mandatory, no one need implement it. Doesn't that make sense to include 'completed' in the conformance ASN.1 at the back, like we did for Reset in the Printer MIB? Tom From jkm at underscore.com Tue Jun 3 11:11:32 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are t In-Reply-To: jmJobState and jmJobStateReasonsTC [ISSUE: Are t> Message-ID: <199706031511.LAA22000@uscore.underscore.com> After thinking about this long and hard, I agree with Bill (and others) that mandating the use of enum values seems pretty strange. Either the conforming agent/entity supports those enums or they don't. If they do, then the agent/entity supplies them as values at the appropriate time. ...jay ----- Begin Included Message ----- Date: Tue, 3 Jun 1997 10:34:56 -0400 From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are t To: jmp@pwg.org Content-Transfer-Encoding: 7bit Tom, I guess I will try again. Why do we feel obligated to make the enums mandatory or conditionally mandatory? I do not think that the unfortunate fact that we made one object mandatory on the printer MIB, and a very particular set-only object at that, has set sufficient precedent. The question of which state values are mandatory and which are conditionally mandatory has been argued to death. One of the reasons is, I believe, that the reason/justification for making any state mandatory is not understood. What is the reason for making state values mandatory? Or conditionally mandatory? What does it mean to have state mandatory, or conditioanlly mandatory? 1. Does it mean that every job must go through every mandatory state? 2. Does it mean that the hardware be capable of putting a job in each the "mandatory" state? 3. Does it mean that, if a job is in a "mandatory" state, the equipment must report it? Calling on the IETF definitions for mandatory and conditioanlly mandatory doe not answer these questions. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are ther Author: Tom Hastings at Internet Date: 6/2/97 6:09 PM At 07:39 05/28/97 PDT, Ron Bergman wrote: snip.. > >RB> Tom, I still have a hard time justifying that enums for an object >RB> are "mandatory" or "conditionally-mandatory". It made some sense >RB> for the Attribute Table but for objects in the Job State Table this >RB> generating significant confusion. I still prefer that the *object* >RB> jmJobState be "mandatory" and the enums for the object are implied >RB> to be "conditionally mandatory". So some say make all the job state enums mandatory and some say make them all conditionally mandatory. As I've tried to reason before, the 'completed' state is one of the most important states to make mandatory, not conditionally mandatory. Most printers today do not have a 'completed' state, at least not one that lasts for a human perceptable time. So if JMP doesn't make the 'completed' state mandatory, no one need implement it. Doesn't that make sense to include 'completed' in the conformance ASN.1 at the back, like we did for Reset in the Printer MIB? Tom ----- End Included Message ----- From harryl at us.ibm.com Tue Jun 3 11:47:46 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> LPR/LPD format for jmJobSubmissionID object value In-Reply-To: LPR/LPD format for jmJobSubmissionID object value> Message-ID: <5030100003072786000002L062*@MHS> I like Patricks proposal >I would like to suggest: > user@host+jobnumber >For example: > root@dickory+024 or root@dickory.sdsu.edu+024 >The job ID embeds the user, originating host, and job number id >into one 'string'. >The job ID would fix up the problem of conflicts in job numbers >which could occur from different hosts, if there was not a distinguisher. >In addition, I like to see the user's name in the id. I agree with Jay, that this does not fully satisfy the desire for a reliable attribute that indicates JobOwner. >The question now might be: can this format serve as a useful way to >identify the job owner, thereby eliminating the need to have the >jobOwner object in the jobState table? >I still think the answer is No, due to the length restrictions for the >jmJobSubmissionID object. If that object were to increase in size to, >say, 63 bytes, then maybe this could work. (I can hear Harry cringing >even as I write this... ;-) I would *strongly* object to making jmJobSubmissionID any larger (as Jay predicted). I believe we MUST keep in mind that we are moving job identification from the paradigm of an element in a (LPR/LPD) submission control file to an object in a job MIB. This implies database storage in the printer with some degree of persistence (to be useful). Yes, I am defending the "low-end" embedded controller, but I don't think any of us really want to design a job MIB that no printers take advantage of. >If the submission ID object were increased to 63 bytes (hey, or even >more! ;-), then it might very well be that jobOwner can stay in the >quickly-aged-out jobAttribute table. So I am in favor of an LPR/LPD jmJobSubmissionID format (along the lines of Patricks proposal) plus keeping JobOwner as a *mandatory* job Attribute. As Jay points out, the job MIB does allow separate persistence between the Job Table and the Attribute Table and does insist that Job Table will persist as long or longer than Attribute Table. But, no where, does the job MIB imply that the Attribute table should age "rapidly". The notion of JobOwner being a *mandatory* attribute, coupled with the idea that this attribute must be "instantiated" as soon as the job is Pending should allow the management or accounting application to make an association between the jmJobIndex (effectively the printer assigned job id) and the jobOwner during the Pending and Processing states. It is only *after* the job has reached the Completed state that the two persistence clocks start ticking. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Tue Jun 3 12:44:05 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Message-ID: <9706031646.AB01747@zazen.cp10.es.xerox.com> At 07:15 06/03/97 PDT, Harry Lewis wrote: >Combining from a couple previous notes... > >>As I've tried to reason before, the 'completed' state is one of the >>most important states to make mandatory, not conditionally mandatory. > >>Most printers today do not have a 'completed' state, at least not one >>that lasts for a human perceptable time. So if JMP doesn't make the >>'completed' state mandatory, no one need implement it. > >>Tom > >These two statements are contradictory. If most printers don't >have a completed state then how can we possibly make completed state >mandatory?\ I agree that the statements are contradictory. The problem is that when we say "printer", sometimes we are talking about the agent and printer combined, and sometimes we are talking about just the printer. To help out, lets be more clear when we are talking about the agent and when we are talking about the device that the agent is instrumenting with SNMP. My understanding of SNMP conformance is that there are two pieces to an implementation: 1. the agent 2. the device Of course the agent is usually implemented (embedded) in the device, so when we say the "device" (or printer), its ambigugous as to whether we are including the agent or not. I have the following picture in mind: management application <------SNMP----> agent <--> device The interface between the agent and the device is implementation dependent. The agent could even be elsewhere on the network. But usually, the agent will be in the device that the agent is instrumenting: a. in the printer (JMP config 1 and 3) or b. in the server (JMP config 2) So conformance requirements in a MIB specification are ONLY on the agent as measured through SNMP operations by a management application. For the completed state, its the agent, not the device that will usually retain the data for the row for each completed job. But if 'completed' were only conditionally mandatory, then the agent doesn't have to add anything extra to what the device already has. So if the device doesn't keep job information after the job finishes processing, the agent wouldn't have to either, IF the 'completed' state were conditionally mandatory. So lets be clear that conformance requirements are for the agent, not the device (printer or server). > >I am not in favor of describing job states as mandatory or conditionally >mandatory but I agree that COMPLETED is probably the most "interesting" >state and would go along with applying some architectural emphasis >(like was done for prtGeneralReset). > >>Then such a printer shall implement the conditionally mandatory >>pending state. But an implementation that never waited a human perceptible >>time should not have to implement the 'pending' state. Imagine that you >>are building a product that is going to be tested against by a testing >>company. If 'pending' is mandatory and your product doesn't ever show >>'pending', that testing company might say you didn't conform to the >>standard. > >I agree with Tom's imagination. All the more reason NOT to specify job >state enumerations as mandatory (except, possibly for Completed). I would hope that we could agree that all devices do 'processing', so that making 'processing' be mandatory too won't make any problems for an agent to be required to implement. I would also hope that we could agree that all devices also encounter problems, so that making 'processing-stopped' be mandatory won't make any problems for an agent to be required to implement. I also think that all devices abort jobs, so that making 'aborted' mandatory won't make any problems either. The remaining states should be conditionally mandatory: 'pending' need not be implemented by an agent that instruments a device that never has to wait before starting processing for a human perceptable time. 'pending-stopped' not needed by the above and by an agent that instruments a device that has no job submission attributes that 'hold' a job. 'canceled' is not needed by an agent that instruments a device that doesn't support a CancelJob operation, such as an IPP level 1 device. So how about the following conformance requirements for agents for our nine states: 'other(1)' conditionally mandatory 'unknown(2)' conditionally mandatory 'pending(3)' conditionally mandatory 'pending-stopped(4)' conditionally mandatory 'processing(5)' mandatory 'processing-stopped(6)' mandatory 'canceled(7)' conditionally mandatory 'aborted(8)' mandatory 'completed(9)' mandatory Tom > >Harry > > From rbergma at dpc.com Tue Jun 3 15:10:10 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:06 2009 Subject: JMP> Last Call for JobSubmissionID Format ID Length In-Reply-To: <199706021939.PAA29121@uscore.underscore.com> Message-ID: <9706031646.AB01747@zazen.cp10.es.xerox.com> There has been a significant discussion regarding the length of the JobSubmissionID Format ID length. I recall that it was changed to 2 bytes in Austin because no one believed that more than 30 bytes would ever be needed for the Submission ID. The proposal is: "Now that we have a valid reason for maximizing the Submission ID the size should be reduced to one byte." I have not seen any objections to this proposal. If anyone objects, please respond ASAP. The proposal will be accepted if there are no objections by Monday, June 9th. Ron Bergman On Mon, 2 Jun 1997, JK Martin wrote: > If one or more persons have indicated the expectation of a *large* > number of registered job ID formats, then great. (I had not heard > that before.) If we think we need two bytes, then as long as someone > can *really* justify it, then it should probably stay two bytes. > (We just don't want to here a line like "somebody somehow for some > reason just might want to register a lot of ID formats...." ;-) > > Ron: Would you mind asking for "Last Call" on this issue? Thanks. > > ...jay > > ----- Begin Included Message ----- > > From: Harry Lewis > To: > Cc: > Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value > Date: Mon, 2 Jun 1997 15:32:25 -0400 > > I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). > I want to add that I believe the original proposal was 1 byte and I think we > "up'd" it to 2 bytes in Austin based on some expectation that other (how shall > I phrase this...) individuals were aware of (close your ears...) Companies... > that may have a lot of additional formats to register. > > So, we should make sure we receive some input from Tom. He seemed like the > individual most likely to know of such a company. > > > Harry Lewis > > > > ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- > > jmp-owner@pwg.org > 05/29/97 07:17 PM > Please respond to jmp-owner@pwg.org @ internet > > > To: jmp@pwg.org @ internet > cc: > Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value > > In that previous message I forgot to state that I think it would be > a good idea to formally define a job submission ID specifically for > LPR/LPD, even though such an ID would not necessarily help the kinds > of monitoring apps we've been talking about recently (ie, "out-of-band" > job monitors). > > The encoding of the ID for LPR/LPD is quite trivial and follows the > format defined in RFC 1179 for the encoding of the control/data files. > Control file names follow this form: > > cfAnnn example: cfA027punky.underscore.com > > That is, a fixed prefix of "cfA" followed by a three-digit job number > (000-999) followed by the hostname (usually fully qualified). > > Data files are similar, except that the "cfA" prefix is replaced with > "dfA". (Hence the common references to "cf/df" files when talking > about LPD spooling.) > > The idea here is that the names of the control and data files are very > similar, with the only exception being the first character (ie, "c" > vs. "d"). Since this distinction in prefixes is relatively > meaningless for job identification, we shouldn't need to include the > first three characters in the Job MIB job submission ID string. > > This results in an encoding of: > > nnn example: 027punky.underscore.com > > Of course, the component would have to be truncated after > the 27th character, but since hostnames are formed with a left-to-right > hierarchy, this should be sufficient for most environments (right??). > > The LPD encoding would be tagged with "04" in the list of defined > job submission ID formats. > > By the way, why in the world do we need TWO octets for the format > descriptor? As it stands we have only 5 formats (including this > new LPD definition)! If we reduce this to a single byte (and continue > to use a decimal-digit encoding technique), then we have room for > 5 additional formats. Even if we needed more, we could then use > a hex-like technique and start using letters (a-z, etc). > > This is a classic case of over-engineering, IMHO. Here we are worrying > about truncating valuable information when we're wasting it elsewhere. > We should change this. > > Comments? > > ...jay > > ----- End Included Message ----- From hastings at cp10.es.xerox.com Tue Jun 3 17:26:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Last Call for JobSubmissionID Format ID Length In-Reply-To: Last Call for JobSubmissionID Format ID Length> Message-ID: <9706032129.AA01862@zazen.cp10.es.xerox.com> I agree that we can go with one byte. We need all the octets we can get. We probably need to agree how to extend after format "9". I suggest that we use single UPPER CASE letters, then single lower case letters. Tom P.S. Ron, I like this process for resolving issues too. At 12:10 06/03/97 PDT, Ron Bergman wrote: >There has been a significant discussion regarding the length of the >JobSubmissionID Format ID length. I recall that it was changed to >2 bytes in Austin because no one believed that more than 30 bytes >would ever be needed for the Submission ID. > >The proposal is: > >"Now that we have a valid reason for maximizing the Submission ID >the size should be reduced to one byte." > >I have not seen any objections to this proposal. If anyone objects, >please respond ASAP. The proposal will be accepted if there are no >objections by Monday, June 9th. > > > Ron Bergman > > >On Mon, 2 Jun 1997, JK Martin wrote: > >> If one or more persons have indicated the expectation of a *large* >> number of registered job ID formats, then great. (I had not heard >> that before.) If we think we need two bytes, then as long as someone >> can *really* justify it, then it should probably stay two bytes. >> (We just don't want to here a line like "somebody somehow for some >> reason just might want to register a lot of ID formats...." ;-) >> >> Ron: Would you mind asking for "Last Call" on this issue? Thanks. >> >> ...jay >> >> ----- Begin Included Message ----- >> >> From: Harry Lewis >> To: >> Cc: >> Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value >> Date: Mon, 2 Jun 1997 15:32:25 -0400 >> >> I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). >> I want to add that I believe the original proposal was 1 byte and I think we >> "up'd" it to 2 bytes in Austin based on some expectation that other (how shall >> I phrase this...) individuals were aware of (close your ears...) Companies... >> that may have a lot of additional formats to register. >> >> So, we should make sure we receive some input from Tom. He seemed like the >> individual most likely to know of such a company. >> >> >> Harry Lewis >> >> > >> >> ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- >> >> jmp-owner@pwg.org >> 05/29/97 07:17 PM >> Please respond to jmp-owner@pwg.org @ internet >> >> >> To: jmp@pwg.org @ internet >> cc: >> Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value >> >> In that previous message I forgot to state that I think it would be >> a good idea to formally define a job submission ID specifically for >> LPR/LPD, even though such an ID would not necessarily help the kinds >> of monitoring apps we've been talking about recently (ie, "out-of-band" >> job monitors). >> >> The encoding of the ID for LPR/LPD is quite trivial and follows the >> format defined in RFC 1179 for the encoding of the control/data files. >> Control file names follow this form: >> >> cfAnnn example: cfA027punky.underscore.com >> >> That is, a fixed prefix of "cfA" followed by a three-digit job number >> (000-999) followed by the hostname (usually fully qualified). >> >> Data files are similar, except that the "cfA" prefix is replaced with >> "dfA". (Hence the common references to "cf/df" files when talking >> about LPD spooling.) >> >> The idea here is that the names of the control and data files are very >> similar, with the only exception being the first character (ie, "c" >> vs. "d"). Since this distinction in prefixes is relatively >> meaningless for job identification, we shouldn't need to include the >> first three characters in the Job MIB job submission ID string. >> >> This results in an encoding of: >> >> nnn example: 027punky.underscore.com >> >> Of course, the component would have to be truncated after >> the 27th character, but since hostnames are formed with a left-to-right >> hierarchy, this should be sufficient for most environments (right??). >> >> The LPD encoding would be tagged with "04" in the list of defined >> job submission ID formats. >> >> By the way, why in the world do we need TWO octets for the format >> descriptor? As it stands we have only 5 formats (including this >> new LPD definition)! If we reduce this to a single byte (and continue >> to use a decimal-digit encoding technique), then we have room for >> 5 additional formats. Even if we needed more, we could then use >> a hex-like technique and start using letters (a-z, etc). >> >> This is a classic case of over-engineering, IMHO. Here we are worrying >> about truncating valuable information when we're wasting it elsewhere. >> We should change this. >> >> Comments? >> >> ...jay >> >> ----- End Included Message ----- > > > From jkm at underscore.com Tue Jun 3 17:48:12 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:06 2009 Subject: JMP> Last Call for JobSubmissionID Format ID Length In-Reply-To: Last Call for JobSubmissionID Format ID Length> Message-ID: <199706032148.RAA09733@uscore.underscore.com> Tom's suggestion for extending the format byte definitions looks ok to me. ...jay ----- Begin Included Message ----- Date: Tue, 3 Jun 1997 14:26:39 PDT To: Ron Bergman From: Tom Hastings Subject: Re: JMP> Last Call for JobSubmissionID Format ID Length Cc: jmp@pwg.org, Harry Lewis , jkm@underscore.com I agree that we can go with one byte. We need all the octets we can get. We probably need to agree how to extend after format "9". I suggest that we use single UPPER CASE letters, then single lower case letters. Tom P.S. Ron, I like this process for resolving issues too. At 12:10 06/03/97 PDT, Ron Bergman wrote: >There has been a significant discussion regarding the length of the >JobSubmissionID Format ID length. I recall that it was changed to >2 bytes in Austin because no one believed that more than 30 bytes >would ever be needed for the Submission ID. > >The proposal is: > >"Now that we have a valid reason for maximizing the Submission ID >the size should be reduced to one byte." > >I have not seen any objections to this proposal. If anyone objects, >please respond ASAP. The proposal will be accepted if there are no >objections by Monday, June 9th. > > > Ron Bergman > > >On Mon, 2 Jun 1997, JK Martin wrote: > >> If one or more persons have indicated the expectation of a *large* >> number of registered job ID formats, then great. (I had not heard >> that before.) If we think we need two bytes, then as long as someone >> can *really* justify it, then it should probably stay two bytes. >> (We just don't want to here a line like "somebody somehow for some >> reason just might want to register a lot of ID formats...." ;-) >> >> Ron: Would you mind asking for "Last Call" on this issue? Thanks. >> >> ...jay >> >> ----- Begin Included Message ----- >> >> From: Harry Lewis >> To: >> Cc: >> Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value >> Date: Mon, 2 Jun 1997 15:32:25 -0400 >> >> I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). >> I want to add that I believe the original proposal was 1 byte and I think we >> "up'd" it to 2 bytes in Austin based on some expectation that other (how shall >> I phrase this...) individuals were aware of (close your ears...) Companies... >> that may have a lot of additional formats to register. >> >> So, we should make sure we receive some input from Tom. He seemed like the >> individual most likely to know of such a company. >> >> >> Harry Lewis >> >> > >> >> ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- >> >> jmp-owner@pwg.org >> 05/29/97 07:17 PM >> Please respond to jmp-owner@pwg.org @ internet >> >> >> To: jmp@pwg.org @ internet >> cc: >> Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value >> >> In that previous message I forgot to state that I think it would be >> a good idea to formally define a job submission ID specifically for >> LPR/LPD, even though such an ID would not necessarily help the kinds >> of monitoring apps we've been talking about recently (ie, "out-of-band" >> job monitors). >> >> The encoding of the ID for LPR/LPD is quite trivial and follows the >> format defined in RFC 1179 for the encoding of the control/data files. >> Control file names follow this form: >> >> cfAnnn example: cfA027punky.underscore.com >> >> That is, a fixed prefix of "cfA" followed by a three-digit job number >> (000-999) followed by the hostname (usually fully qualified). >> >> Data files are similar, except that the "cfA" prefix is replaced with >> "dfA". (Hence the common references to "cf/df" files when talking >> about LPD spooling.) >> >> The idea here is that the names of the control and data files are very >> similar, with the only exception being the first character (ie, "c" >> vs. "d"). Since this distinction in prefixes is relatively >> meaningless for job identification, we shouldn't need to include the >> first three characters in the Job MIB job submission ID string. >> >> This results in an encoding of: >> >> nnn example: 027punky.underscore.com >> >> Of course, the component would have to be truncated after >> the 27th character, but since hostnames are formed with a left-to-right >> hierarchy, this should be sufficient for most environments (right??). >> >> The LPD encoding would be tagged with "04" in the list of defined >> job submission ID formats. >> >> By the way, why in the world do we need TWO octets for the format >> descriptor? As it stands we have only 5 formats (including this >> new LPD definition)! If we reduce this to a single byte (and continue >> to use a decimal-digit encoding technique), then we have room for >> 5 additional formats. Even if we needed more, we could then use >> a hex-like technique and start using letters (a-z, etc). >> >> This is a classic case of over-engineering, IMHO. Here we are worrying >> about truncating valuable information when we're wasting it elsewhere. >> We should change this. >> >> Comments? >> >> ...jay >> >> ----- End Included Message ----- > > > ----- End Included Message ----- From harryl at us.ibm.com Tue Jun 3 18:35:53 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Last Call for JobSubmissionID Format ID Length In-Reply-To: Last Call for JobSubmissionID Format ID Length> Message-ID: <5030100003098821000002L012*@MHS> I vote for a 1 byte Job Submission ID FORMAT ID. This will allow 31 bytes for the jmJobSubmissionID itself, as Ron points out. Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 06/03/97 04:27 PM ------ jmp-owner@pwg.org 06/03/97 03:15 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: jkm@underscore.com @ internet, Harry Lewis/Boulder/IBM@IBMUS Subject: Re: JMP> Last Call for JobSubmissionID Format ID Length There has been a significant discussion regarding the length of the JobSubmissionID Format ID length. I recall that it was changed to 2 bytes in Austin because no one believed that more than 30 bytes would ever be needed for the Submission ID. The proposal is: "Now that we have a valid reason for maximizing the Submission ID the size should be reduced to one byte." I have not seen any objections to this proposal. If anyone objects, please respond ASAP. The proposal will be accepted if there are no objections by Monday, June 9th. Ron Bergman On Mon, 2 Jun 1997, JK Martin wrote: > If one or more persons have indicated the expectation of a *large* > number of registered job ID formats, then great. (I had not heard > that before.) If we think we need two bytes, then as long as someone > can *really* justify it, then it should probably stay two bytes. > (We just don't want to here a line like "somebody somehow for some > reason just might want to register a lot of ID formats...." ;-) > > Ron: Would you mind asking for "Last Call" on this issue? Thanks. > > ...jay > > ----- Begin Included Message ----- > > From: Harry Lewis > To: > Cc: > Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value > Date: Mon, 2 Jun 1997 15:32:25 -0400 > > I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes). > I want to add that I believe the original proposal was 1 byte and I think we > "up'd" it to 2 bytes in Austin based on some expectation that other (how shall > I phrase this...) individuals were aware of (close your ears...) Companies... > that may have a lot of additional formats to register. > > So, we should make sure we receive some input from Tom. He seemed like the > individual most likely to know of such a company. > > > Harry Lewis > > > > ------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM ----- > > jmp-owner@pwg.org > 05/29/97 07:17 PM > Please respond to jmp-owner@pwg.org @ internet > > > To: jmp@pwg.org @ internet > cc: > Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value > > In that previous message I forgot to state that I think it would be > a good idea to formally define a job submission ID specifically for > LPR/LPD, even though such an ID would not necessarily help the kinds > of monitoring apps we've been talking about recently (ie, "out-of-band" > job monitors). > > The encoding of the ID for LPR/LPD is quite trivial and follows the > format defined in RFC 1179 for the encoding of the control/data files. > Control file names follow this form: > > cfAnnn example: cfA027punky.underscore.com > > That is, a fixed prefix of "cfA" followed by a three-digit job number > (000-999) followed by the hostname (usually fully qualified). > > Data files are similar, except that the "cfA" prefix is replaced with > "dfA". (Hence the common references to "cf/df" files when talking > about LPD spooling.) > > The idea here is that the names of the control and data files are very > similar, with the only exception being the first character (ie, "c" > vs. "d"). Since this distinction in prefixes is relatively > meaningless for job identification, we shouldn't need to include the > first three characters in the Job MIB job submission ID string. > > This results in an encoding of: > > nnn example: 027punky.underscore.com > > Of course, the component would have to be truncated after > the 27th character, but since hostnames are formed with a left-to-right > hierarchy, this should be sufficient for most environments (right??). > > The LPD encoding would be tagged with "04" in the list of defined > job submission ID formats. > > By the way, why in the world do we need TWO octets for the format > descriptor? As it stands we have only 5 formats (including this > new LPD definition)! If we reduce this to a single byte (and continue > to use a decimal-digit encoding technique), then we have room for > 5 additional formats. Even if we needed more, we could then use > a hex-like technique and start using letters (a-z, etc). > > This is a classic case of over-engineering, IMHO. Here we are worrying > about truncating valuable information when we're wasting it elsewhere. > We should change this. > > Comments? > > ...jay > > ----- End Included Message ----- From rbergma at dpc.com Tue Jun 3 20:56:03 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:06 2009 Subject: JMP> Last Call for JobSubmissionID Format ID Length In-Reply-To: <9706032129.AA01862@zazen.cp10.es.xerox.com> Message-ID: <5030100003098821000002L012*@MHS> Tom, Your suggested method of extension is exactly what I would have proposed. This allows a total of 62 (if zero is included?) formats. Seems like more than enough. Ron Bergman On Tue, 3 Jun 1997, Tom Hastings wrote: > I agree that we can go with one byte. We need all the octets we can get. > > We probably need to agree how to extend after format "9". > > I suggest that we use single UPPER CASE letters, then single > lower case letters. > > Tom > > P.S. Ron, > I like this process for resolving issues too. > > At 12:10 06/03/97 PDT, Ron Bergman wrote: > >There has been a significant discussion regarding the length of the > >JobSubmissionID Format ID length. I recall that it was changed to > >2 bytes in Austin because no one believed that more than 30 bytes > >would ever be needed for the Submission ID. > > > >The proposal is: > > > >"Now that we have a valid reason for maximizing the Submission ID > >the size should be reduced to one byte." > > > >I have not seen any objections to this proposal. If anyone objects, > >please respond ASAP. The proposal will be accepted if there are no > >objections by Monday, June 9th. > > > > > > Ron Bergman From hastings at cp10.es.xerox.com Wed Jun 4 08:53:28 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706041255.AA02021@zazen.cp10.es.xerox.com> Gee Jay, You want to add another attribute to IPP: job-sub-state and another object to the JMP jmJobTable: jmJobSubState? This doesn't sound like simplicity and elegance to me. Instead, we've shown the "refinement" of these substates, in the names of the states and not added any more attributes or objects. That seems like the best of both worlds, namely show the refinement but keep the attributes and object simple. Or did you mean to add the sub-states as job-state-reasons which wouldn't add anymore attributes to IPP and objects to JMP? Tom At 15:35 06/02/97 PDT, JK Martin wrote: >I guess I'm a bit disappointed that we elected to not do the "elegant" >thing and simply have 3 states (pending, processing, done), then use >a set defined of substates to describe refinements of those states. > >A rare chance to do something that is both elegant *and* simple. >(Sigh...) > > ...jay > >----- Begin Included Message ----- > >>From ipp-owner@pwg.org Mon Jun 2 18:28 EDT 1997 >Date: Mon, 2 Jun 1997 15:23:22 -0700 >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org, harryl@us.ibm.com >Subject: Re: JMP> Re: IPP> MOD JobState suggestion >Cc: jmp@pwg.org > >In one sense we have just renamed some states: held to pending-stopped >and needs-attention to processing-stopped. But the renaming regularizes >the names to give the impression that there are 3 high level states >of pending, processing and completed and 4 additional variant of those >states. These regularized states allow us to have other attributes >that draw from these names, e.g. time-since-pending time-since-processing >and time-since-completed. It also allows the addition of other states, >such as completed-with-errors. > > >Bob Herriot > > >> From harryl@us.ibm.com Mon Jun 2 15:09:05 1997 >> >> I am confused by the notation used in this discussion: >> >> >The states are: >> >> > pending >> > pending-stopped >> > processing >> > processing-stopped >> > done-aborted >> > done-canceled >> > done-completed >> >> >I suggest changing the last three states to >> >> > completed >> > completed-canceled >> > completed-abort >> >> I understand PENDING, PROCESSING and COMPLETED states. I thought I was >> following a thread, somewhere, that PENDING-STOPPED was another way to say HELD >> and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is >> going on... just some renaming? Or do the "dashes" in these names indicate >> separation between a state and a reason? >> >> I agree with Bob's recommendations, above, to stick with Completed rather than >> Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? >> What are we gaining. I find these discussions frequently go down the "generic >> language" path until the labels we choose are so vague that, rather than risk >> misinterpretation, the names end up meaning very little at all. >> >> Harry Lewis >> > > >----- End Included Message ----- > > > From hastings at cp10.es.xerox.com Wed Jun 4 08:53:35 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706041256.AB02021@zazen.cp10.es.xerox.com> At 15:07 06/02/97 PDT, Harry Lewis wrote: snip... >I understand PENDING, PROCESSING and COMPLETED states. I thought I was >following a thread, somewhere, that PENDING-STOPPED was another way to say HELD >and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is >going on... just some renaming? Or do the "dashes" in these names indicate >separation between a state and a reason? > >I agree with Bob's recommendations, above, to stick with Completed rather than >Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION? >What are we gaining. I find these discussions frequently go down the "generic >language" path until the labels we choose are so vague that, rather than risk >misinterpretation, the names end up meaning very little at all. > >Harry Lewis I agree with Harry that we should reconsider the name change from 'held' to 'pending-stopped' and go back to 'held'. In looking at the complete spec for job-state and job-state-reasons in IPP and the corresponding jmJobState and jmJobStateReason1 objects in JMP, I discovered a problem with our renaming of 'held' to 'pending-stopped': I've added the following joint IPP/JMP issue to the joint spec: JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. I think that 'processing-stopped' is fine and is clear that it is a sub-state of processing, so I'm not suggesting that we re-open the 'processing-stopped' name change. Comments? Tom From hastings at cp10.es.xerox.com Wed Jun 4 08:53:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for Message-ID: <9706041256.AB02021@zazen.cp10.es.xerox.com> JMP people, Pleae call-in today so we can finish the agreements on the IPP/JMP job-state and job-state-reasons attributes. June 4 ------ Call-in: 1-423-673-6712 Access: 190148 All calls are at 4PM EDT (1PM PDT) I've cross-posted (again) 5 files dealing with the agreements and updated text on the IPP "job-state" and "job-state-reasons" attributes and the corresonding JMP jmJobState and jmJobStateReason1 objects in: ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt -rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt -rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr The *.doc files are MS-WORD V6.0a The jobstate.* are with revisions accepted (i.e., no revisions marks). The jobstatr.* are with revisions marked from the current texts of IPP and JMP. The jobstatr.pdf has black revision marks and the jobstatr.pdr file has red revision marks. These results are from the joint IPP/JMP telecon last Wednesday, May 28. There is an IPP issue listed below and in the document which Carl-Uno said we could handle on the IPP telecon, tommorrow, Wed, June 4, if it takes a short time. If it takes longer, we will need to setup a separate IPP Model telecon, since the major discussion for the IPP telecon will be the new protocol document. There is also a JMP issue listed below that could be handled at this separate IPP Model telecon, if the JMP issue listed below need discussion. JMP people, Please read these files to make sure you agree with the agreements we reached last week on IPP and their impact on JMP. It would be good to see if we have agreement between IPP and JMP on these crucial job state and job state reasons attributes (which are JMP SNMP objects). If you have problems, please raise them on the IPP and JMP DLs so that we can decide how to process the issues at the IPP telecon tommorrow: Thanks, Tom In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions for each CONDITIONALLY MANDATORY job state and job state reason. Please read and see if this helps the discussion that JMP has been having around what MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. Tom Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 5/30/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) This document is the updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 states in common between IPP and JMP: pending, pending-stopped, processing, processing-stopped, canceled, aborted, and completed. The JMP values of the jmJobStateReasons1 object are a superset of the IPP values of the "job-state-reasons" attribute. I've applied revision marks to the specification of 5/25/97 to show the changes, both to the commentary and the specification. There are three joint IPP/JMP issues and one JMP-only issue listed below. I've included Ron's suggestions to eliminate duplication between the object and textual convention descriptions and to put more explanation in the objects and less in the textual conventions in the process. I've re-ordered the job-state-reasons to be in the order that jobs normally proceed by job states. This will help with understanding that Jay requested about "the day in the life of a job". I've also attempted to make each job state and job state reason more concise without changing the meaning. If any Job Monitoring MIB participants disagree with the agreements, please send e-mail ASAP, since I'm editing the agreements into the Job Monitoring MIB. Talking to Scott, I have taken the "job-state", "job-state-reasons", and "job-state-message" attribute sections from IPP and edited in the changes with revision marks. After each edited IPP section, I've edited corresponding Job Monitoring MIB TC and object or attribute section. I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP e-mail discussion indicated that it should be MANDATORY. The remaining jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as attributes in the jmAttributeTable. (No attributes in the attribute table are MANDATORY, except jobOwner, and we are discussing means to make jobOwner an object in a MANDATORY table, somehow, possibly using the jmJobIDTable.) JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the IPP Internet-Draft, there is a conflict between the semantics of the 'processing' state specified under the "job-state" attribute and the "job-state-reasons" values: 'job-sending-to-output-device' and 'job-queued-in-output-device' which we agreed to combine into: 'job-outgoing'. In the "job-state" definition, 'job-outgoing' is in the 'processing' state, while the "job-state-reasons" definition says that 'job-outgoing' shall be in the 'pending' state. Which do we want the IPP and JMP spec to say? Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and 'completed-with-errors' be mandatory job-state-reasons values or not? Currently both IPP and JMP specs say they are mandatory reasons. JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? If none are, the jmJobStateReasons1 object could go back to the jmAttributeTable. Summary of IPP and JMP job state and job state reasons agreements ------------------------------------------------------------------ Here is the summary of the job state and job state reasons agreements: 1. In JMP remove the 'printing' state. 2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state 'needsAttention' to 'processingStopped'. 3. In both IPP and JMP add the 'aborted' state and make it a final state. 4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 5. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' states and make 'canceled' and 'aborted' final states, like the JMP 'canceled' and 'completed' states. 6. Since the pending-stopped state has been added, JMP no longer needs a generic jobHeld job state reason. So the simplified state transition diagram for IPP and JMP was agreed to be: The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. +--> canceled / +----> pending --------> processing --+----> aborted | ^ ^ \ --->+ | | +--> completed | v v +----> pending-stopped processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right. From harryl at us.ibm.com Wed Jun 4 10:09:15 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003117793000002L032*@MHS> Tom, I support your proposal - >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >'pending-stopped'? Not only for the many good reasons you listed but simply due to the reduced brain-strain. HELD... I can relate to. But what exactly happens when pending stops? It's obvious, by most of my notes, that I'm not much of a comedian, but I can picture one having fun with some of these genericized brain teasers. >I think that 'processing-stopped' is fine and is clear that it is a >sub-state of processing, so I'm not suggesting that we re-open the >'processing-stopped' name change. I guess processing-stopped is about as clear as needs-attention (I think this was the old name in JMP). No big problem with the name. I'm not sure I really understand your use of the term "sub-state", however. Are you referring to a JobStateReason or are you thinking of a job transition diagram? I THINK you are talking about job transition flow and processing-stopped is really a STATE, not a REASON. I don't think stopped is a very good reason to be processing. Harry From hastings at cp10.es.xerox.com Wed Jun 4 12:20:56 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> URGENT: JMP/IPP job-state/job-state-reasons: 1:00-1:15 PDT Message-ID: <9706041623.AA02114@zazen.cp10.es.xerox.com> Carl-Uno said we could have 15 minutes on the joint IPP/JMP job-state and job-state-reasons issues (see attached). JMP people, please call in, so we can put these issues to bed for both IPP and JMP. (NOTE - the entire document is NOT included in the e-mail. You should fetch at least the .pdf file without revison marks (jobstate.pdf) from the ftp server). Thanks, Tom >Date: Wed, 04 Jun 1997 05:53:39 -0700 >To: jmp, ipp >From: Tom Hastings >Subject: Updated IPP/JMP joint job-state/job-state-reasons specs for IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues > >JMP people, > >Pleae call-in today so we can finish the agreements on the IPP/JMP >job-state and job-state-reasons attributes. > >June 4 >------ >Call-in: 1-423-673-6712 >Access: 190148 > >All calls are at 4PM EDT (1PM PDT) > >I've cross-posted (again) 5 files dealing with the agreements and updated text >on the IPP "job-state" and "job-state-reasons" attributes and the >corresonding JMP jmJobState and jmJobStateReason1 objects in: > >ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >The *.doc files are MS-WORD V6.0a >The jobstate.* are with revisions accepted (i.e., no revisions marks). >The jobstatr.* are with revisions marked from the current texts of IPP >and JMP. The jobstatr.pdf has black revision marks and the >jobstatr.pdr file has red revision marks. > >These results are from the joint IPP/JMP telecon last Wednesday, >May 28. There is an IPP issue listed below and in the document >which Carl-Uno said we could handle on the IPP telecon, tommorrow, >Wed, June 4, if it takes a short time. If it takes longer, we will >need to setup a separate IPP Model telecon, since the major discussion >for the IPP telecon will be the new protocol document. > >There is also a JMP issue listed below that could be handled at this >separate IPP Model telecon, if the JMP issue listed below need discussion. > >JMP people, >Please read these files to make sure you agree with the agreements we >reached last week on IPP and their impact on JMP. It would be good to >see if we have agreement between IPP and JMP on these crucial >job state and job state reasons attributes (which are JMP SNMP objects). >If you have problems, please raise them on the IPP and JMP DLs so that >we can decide how to process the issues at the IPP telecon tommorrow: > >Thanks, >Tom > > >In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions >for each CONDITIONALLY MANDATORY job state and job state reason. Please read >and see if this helps the discussion that JMP has been having around what >MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. > >Tom > > >Subject: IPP and JMP agreements on job-state and job-state-reasons >From: Tom Hastings >Date: 5/30/97 >File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) > >This document is the updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects >from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 states in common between IPP and JMP: pending, pending-stopped, processing, processing-stopped, canceled, aborted, and completed. The JMP values of the jmJobStateReasons1 object are a superset of the IPP values of the "job-state-reasons" attribute. > >I've applied revision marks to the specification of 5/25/97 to show the changes, both to the commentary and the specification. > >There are three joint IPP/JMP issues and one JMP-only issue listed below. > >I've included Ron's suggestions to >eliminate duplication between the object and textual convention descriptions >and to put more explanation in the objects and less in the textual conventions >in the process. > >I've re-ordered the job-state-reasons to be in the order that jobs normally >proceed by job states. This will help with understanding that Jay requested >about "the day in the life of a job". > >I've also attempted to make each job state and job state reason more concise >without changing the meaning. > >If any Job Monitoring MIB participants disagree with the agreements, >please send e-mail ASAP, since I'm editing the agreements into the >Job Monitoring MIB. > >Talking to Scott, I have taken the "job-state", "job-state-reasons", and >"job-state-message" attribute sections from IPP and edited in the >changes with revision marks. After each edited IPP section, I've edited >corresponding Job Monitoring MIB TC and object or attribute section. >I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP >e-mail discussion indicated that it should be MANDATORY. The remaining >jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as >attributes in the jmAttributeTable. (No attributes in the attribute >table are MANDATORY, except jobOwner, and we are discussing means to >make jobOwner an object in a MANDATORY table, somehow, possibly using the >jmJobIDTable.) > > > >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of 'pending-stopped'? > >The IPP protocol has a "job-hold-until", so having the name of the state be 'held' aligns with that name better making it clearer to the user the relationship between the attribute and the state. Also some current systems have a 'held' state, so that current practice for system that have such as state is to call that state 'held'. Also the ISO DPA has a 'held' state. >Finally, our sub-classing in the names doesn't work for 'completed', since we have 'aborted' and 'canceled', not 'completed-aborted' and 'completed-canceled', so why have it for pending-stopped, which may prove fairly startling to a user, while 'held' is readily understandable. > > > >Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or > 'processing' states? > >In the IPP Internet-Draft, there is a conflict between the semantics of the >'processing' state specified under the "job-state" attribute and the >"job-state-reasons" values: 'job-sending-to-output-device' and >'job-queued-in-output-device' which we agreed to combine into: 'job-outgoing'. >In the "job-state" definition, 'job-outgoing' is in the 'processing' state, >while the "job-state-reasons" definition says that 'job-outgoing' shall be in >the 'pending' state. Which do we want the IPP and JMP spec to say? > > > >Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and 'completed-with-errors' be mandatory job-state-reasons values or not? > >Currently both IPP and JMP specs say they are mandatory reasons. > > > > >JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? >If none are, the jmJobStateReasons1 object could go back to the jmAttributeTable. > > > > Summary of IPP and JMP job state and job state reasons agreements >------------------------------------------------------------------ > >Here is the summary of the job state and job state reasons agreements: > >1. In JMP remove the 'printing' state. > >2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state 'needsAttention' to 'processingStopped'. > >3. In both IPP and JMP add the 'aborted' state and make it a final state. > >4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, >since the new 'aborted' state says it all. > >5. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' >states and make 'canceled' and 'aborted' final states, like the >JMP 'canceled' and 'completed' states. > >6. Since the pending-stopped state has been added, JMP no longer needs a generic jobHeld job state reason. > > >So the simplified state transition diagram for IPP and JMP was agreed to be: > >The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. > > +--> canceled > / > +----> pending --------> processing --+----> aborted > | ^ ^ \ >--->+ | | +--> completed > | v v > +----> pending-stopped processing-stopped > >Figure 1 - Normal job state transitions > >Normally a job progresses only from left to right. > > From hastings at cp10.es.xerox.com Wed Jun 4 12:34:42 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:06 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706041637.AA02128@zazen.cp10.es.xerox.com> At 07:09 06/04/97 PDT, Harry Lewis wrote: >Tom, I support your proposal - > >>JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >>'pending-stopped'? > >Not only for the many good reasons you listed but simply due to the reduced >brain-strain. HELD... I can relate to. But what exactly happens when pending >stops? It's obvious, by most of my notes, that I'm not much of a comedian, but >I can picture one having fun with some of these genericized brain teasers. > >>I think that 'processing-stopped' is fine and is clear that it is a >>sub-state of processing, so I'm not suggesting that we re-open the >>'processing-stopped' name change. > >I guess processing-stopped is about as clear as needs-attention (I think >this was the old name in JMP). No big problem with the name. I'm not sure >I really understand your use of the term "sub-state", however. Are you >referring to a JobStateReason or are you thinking of a job transition >diagram? I THINK you are talking about job transition flow and >processing-stopped is really a STATE, not a REASON. I don't think stopped is >a very good reason to be processing. I definitely meant that the 'processing-stopped' state is a separate state that a job gets to from the 'processing' and returns to 'processing' state. Here's the picture in the joint IPP/JMP jobstate.pdf file that I posted for today's IPP telecon: The following JMP figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) -------> processing(5) --+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v v +---> pending-stopped(4) processing-stopped(6) <------------- active ------------>|<-- in-active -->| Figure 3 - Normal job state transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden." Changing the name from 'pending-stopped' to 'held' would yield: The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) -------> processing(5) --+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v v +---> held(4) processing-stopped(6) <-------------- active ------------>|<-- in-active -->| Figure 3 - Normal job state transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden." > >Harry > > From bwagner at digprod.com Wed Jun 4 13:56:06 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Re: jmJobState [which mandatory job states?]> Message-ID: <9706041637.AA02128@zazen.cp10.es.xerox.com> Tom, I would still very much apprecaite a statement of why you (and I don't see any one else) insist that the enums must be specified as being mandatory or conditionally mandatory. At this point I am not even being argumentative. But I see no more reason to make these values mandatory than to make certain emulations mandatory, or certain paper handling mandatory, or any number of other enums in the printer MIB mandatory. All it has done is produce vast discussion of what state should be at what compliance level, and concepts of the agent fabricating states that are inperceptable by the equipment or by a user. Please Tom, what is the reason for assigning compliance levels to the state values? Bill Wagner, Osicom/DPI So conformance requirements in a MIB specification are ONLY on the agent as measured through SNMP operations by a management application. For the completed state, its the agent, not the device that will usually retain the data for the row for each completed job. But if 'completed' were only conditionally mandatory, then the agent doesn't have to add anything extra to what the device already has. So if the device doesn't keep job information after the job finishes processing, the agent wouldn't have to either, IF the 'completed' state were conditionally mandatory. So lets be clear that conformance requirements are for the agent, not the device (printer or server). From jkm at underscore.com Wed Jun 4 14:09:04 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> URGENT: JMP/IPP job-state/job-state-reasons: 1:00-1:15 PDT In-Reply-To: URGENT: JMP/IPP job-state/job-state-reasons: 1:00-1:15 PDT> Message-ID: <199706041809.OAA05226@uscore.underscore.com> > Carl-Uno said we could have 15 minutes on the joint IPP/JMP job-state > and job-state-reasons issues (see attached). > > JMP people, please call in, so we can put these issues to bed for both > IPP and JMP. Yeah, 15 minutes ought to do it. Particularly when some folks have taken to time to post a big bunch of messages today on this topic. ;-) > (NOTE - the entire document is NOT included in the e-mail. You should > fetch at least the .pdf file without revison marks (jobstate.pdf) from the > ftp server). This document is faulty, as is jobstatr.pdf. Tom has been notified. ...jay From jkm at underscore.com Wed Jun 4 14:13:30 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <199706041813.OAA05423@uscore.underscore.com> [I hope this cross-posting ends soon... :-{ ] Tom, Regarding your latest-greatest state transition map: > The following figure shows the normal job state transitions: > > +--> canceled(7) > / > +---> pending(3) -------> processing(5) --+----> aborted(8) > | ^ ^ \ > --->+ | | +--> completed(9) > | v v > +---> held(4) processing-stopped(6) > > <-------------- active ------------>|<-- in-active -->| > > Figure 3 - Normal job state transitions > > Normally a job progresses only from left to right. Other state transitions > are unlikely, but are not forbidden." Are you really sure this diagram is accurate? Say, for example, a job is in the "held" state. An operator or user then cancels the job. According to your diagram, the job transits would then manner: held -> pending pending -> processing processing -> canceled The same kind of mess occurs with the "processing-stopped" state, etc. This certainly must not be what you intend, right? ...jay From hastings at cp10.es.xerox.com Wed Jun 4 14:35:58 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Updated IPP/JMP joint job-state/job-state-reasons In-Reply-To: Updated IPP/JMP joint job-state/job-state-reasons> Message-ID: <9706041838.AA02229@zazen.cp10.es.xerox.com> The .pdf files are now fixed in the jmp/contribution/ They had been truncated: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 89653 Jun 4 18:33 jobstate.pdf -rw-r--r-- 1 pwg pwg 42819 Jun 4 12:29 jobstate.txt -rw-r--r-- 1 pwg pwg 113132 Jun 4 12:30 jobstatr.doc -rw-r--r-- 1 pwg pwg 143298 Jun 4 18:33 jobstatr.pdf -rw-r--r-- 1 pwg pwg 148621 Jun 4 18:33 jobstatr.pdr The ones in ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ were ok as posted Sorry for the problems. Tom >Return-Path: >Date: Wed, 4 Jun 1997 11:04:50 PDT >From: JK Martin >To: hastings@cp10.es.xerox.com >Subject: Re: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for > IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues >X-Sun-Charset: US-ASCII > >Tom, > >You've got some problems with a couple of your uploaded files: > > jobstate.pdf -- Is empty > jobstatr.pdf -- Is either truncated or otherwise is bad for Acrobat > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Wed Jun 4 09:00 EDT 1997 >Date: Wed, 4 Jun 1997 05:53:39 PDT >To: jmp@pwg.org, ipp@pwg.org >From: Tom Hastings >Subject: JMP> Updated IPP/JMP joint job-state/job-state-reasons specs for > IPP telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues > >JMP people, > >Pleae call-in today so we can finish the agreements on the IPP/JMP >job-state and job-state-reasons attributes. > >June 4 >------ >Call-in: 1-423-673-6712 >Access: 190148 > >All calls are at 4PM EDT (1PM PDT) > >I've cross-posted (again) 5 files dealing with the agreements and updated text >on the IPP "job-state" and "job-state-reasons" attributes and the >corresonding JMP jmJobState and jmJobStateReason1 objects in: > >ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ >-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf >-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt >-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc >-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf >-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr > >The *.doc files are MS-WORD V6.0a >The jobstate.* are with revisions accepted (i.e., no revisions marks). >The jobstatr.* are with revisions marked from the current texts of IPP >and JMP. The jobstatr.pdf has black revision marks and the >jobstatr.pdr file has red revision marks. > >These results are from the joint IPP/JMP telecon last Wednesday, >May 28. There is an IPP issue listed below and in the document >which Carl-Uno said we could handle on the IPP telecon, tommorrow, >Wed, June 4, if it takes a short time. If it takes longer, we will >need to setup a separate IPP Model telecon, since the major discussion >for the IPP telecon will be the new protocol document. > >There is also a JMP issue listed below that could be handled at this >separate IPP Model telecon, if the JMP issue listed below need discussion. > >JMP people, >Please read these files to make sure you agree with the agreements we >reached last week on IPP and their impact on JMP. It would be good to >see if we have agreement between IPP and JMP on these crucial >job state and job state reasons attributes (which are JMP SNMP objects). >If you have problems, please raise them on the IPP and JMP DLs so that >we can decide how to process the issues at the IPP telecon tommorrow: > >Thanks, >Tom > > >In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions >for each CONDITIONALLY MANDATORY job state and job state reason. Please read >and see if this helps the discussion that JMP has been having around what >MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance. > >Tom > > >Subject: IPP and JMP agreements on job-state and job-state-reasons >From: Tom Hastings >Date: 5/30/97 >File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) > >This document is the updated IPP "job-state" and "job-state-reasons" >attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects >from the IPP telecon, of Wednesday, May 27. There we agreed to having 7 >states in common between IPP and JMP: pending, pending-stopped, processing, >processing-stopped, canceled, aborted, and completed. The JMP values of the >jmJobStateReasons1 object are a superset of the IPP values of the >"job-state-reasons" attribute. > >I've applied revision marks to the specification of 5/25/97 to show the >changes, both to the commentary and the specification. > >There are three joint IPP/JMP issues and one JMP-only issue listed below. > >I've included Ron's suggestions to >eliminate duplication between the object and textual convention descriptions >and to put more explanation in the objects and less in the textual conventions >in the process. > >I've re-ordered the job-state-reasons to be in the order that jobs normally >proceed by job states. This will help with understanding that Jay requested >about "the day in the life of a job". > >I've also attempted to make each job state and job state reason more concise >without changing the meaning. > >If any Job Monitoring MIB participants disagree with the agreements, >please send e-mail ASAP, since I'm editing the agreements into the >Job Monitoring MIB. > >Talking to Scott, I have taken the "job-state", "job-state-reasons", and >"job-state-message" attribute sections from IPP and edited in the >changes with revision marks. After each edited IPP section, I've edited >corresponding Job Monitoring MIB TC and object or attribute section. >I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP >e-mail discussion indicated that it should be MANDATORY. The remaining >jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as >attributes in the jmAttributeTable. (No attributes in the attribute >table are MANDATORY, except jobOwner, and we are discussing means to >make jobOwner an object in a MANDATORY table, somehow, possibly using the >jmJobIDTable.) > > > >JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of >'pending-stopped'? > >The IPP protocol has a "job-hold-until", so having the name of the state be >'held' aligns with that name better making it clearer to the user the >relationship between the attribute and the state. Also some current systems >have a 'held' state, so that current practice for system that have such as >state is to call that state 'held'. Also the ISO DPA has a 'held' state. >Finally, our sub-classing in the names doesn't work for 'completed', since >we have 'aborted' and 'canceled', not 'completed-aborted' and >'completed-canceled', so why have it for pending-stopped, which may prove >fairly startling to a user, while 'held' is readily understandable. > > > >Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or > 'processing' states? > >In the IPP Internet-Draft, there is a conflict between the semantics of the >'processing' state specified under the "job-state" attribute and the >"job-state-reasons" values: 'job-sending-to-output-device' and >'job-queued-in-output-device' which we agreed to combine into: 'job-outgoing'. >In the "job-state" definition, 'job-outgoing' is in the 'processing' state, >while the "job-state-reasons" definition says that 'job-outgoing' shall be in >the 'pending' state. Which do we want the IPP and JMP spec to say? > > > >Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and >'completed-with-errors' be mandatory job-state-reasons values or not? > >Currently both IPP and JMP specs say they are mandatory reasons. > > > > >JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY? >If none are, the jmJobStateReasons1 object could go back to the >jmAttributeTable. > > > > Summary of IPP and JMP job state and job state reasons agreements >------------------------------------------------------------------ > >Here is the summary of the job state and job state reasons agreements: > >1. In JMP remove the 'printing' state. > >2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state >'needsAttention' to 'processingStopped'. > >3. In both IPP and JMP add the 'aborted' state and make it a final state. > >4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, >since the new 'aborted' state says it all. > >5. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' >states and make 'canceled' and 'aborted' final states, like the >JMP 'canceled' and 'completed' states. > >6. Since the pending-stopped state has been added, JMP no longer needs a >generic jobHeld job state reason. > > >So the simplified state transition diagram for IPP and JMP was agreed to be: > >The following figure shows the normal job state transitions. Other >transitions are unlikely, but are not forbidden. > > +--> canceled > / > +----> pending --------> processing --+----> aborted > | ^ ^ \ >--->+ | | +--> completed > | v v > +----> pending-stopped processing-stopped > >Figure 1 - Normal job state transitions > >Normally a job progresses only from left to right. > > > > >----- End Included Message ----- > > > > From jkm at underscore.com Wed Jun 4 15:12:40 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <199706041912.PAA08117@uscore.underscore.com> Tom, > Gee Jay, > > You want to add another attribute to IPP: job-sub-state > and another object to the JMP jmJobTable: jmJobSubState? > > This doesn't sound like simplicity and elegance to me. > > Instead, we've shown the "refinement" of these substates, in the > names of the states and not added any more attributes or objects. > > That seems like the best of both worlds, namely show the refinement > but keep the attributes and object simple. Someday, once the dust finally settles on the JMP and IPP projects, I'd be really interested in hearing your definitions and metrics relating to "simplicity" and "elegance". Unfortunately, the combined JMP/IPP dust is now swirling around at around 50,000 feet...and is unlikely to settle soon. ;-) > Or did you mean to add the sub-states as job-state-reasons which > wouldn't add anymore attributes to IPP and objects to JMP? Yes, Tom, this is the only natural conclusion here. Better yet, no need to wait until the dust settles to do this. ;-) The really sad situation here is that some folks want to model the job problem/solution to achieve an extremely teenie-weenie minor performance boost. That is, to only get a single MIB object instead of two (either of which can be done by a single SNMP Get message). Sorry, but perhaps the "puritan" nature of my engineering side has surfaced on this topic, and hence my resistance to this kind of bastardization of the IPP/JMP job model in general. A job can be in many, many kinds of "states", depending on the features (and attendant complexities) of the underlying printing system. However, no matter what printing system is involved, all jobs will be in exactly one of the three top-level "meta" states of pending, processing, done. Below these three states, the mgmt application in question will decide on the exact semantics of the job based on some *consistent* refinement of the top-level state. Hence, the simple two-level model I have been suggesting this past week or so. ...jay From jkm at underscore.com Wed Jun 4 15:35:08 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Re: jmJobState [which mandatory job states?]> Message-ID: <199706041935.PAA09108@uscore.underscore.com> I completely agree with Bill here. This whole issue seems quite insane to me. What is it about the Job MIB regarding enums that is any different than any other MIB-related effort we've done??? Tom: You posted a message to the IPP/JMP lists encouraging folks to read your documents relating to the IPP telecon later today. With regard to your pushing the definitions of MANDATORY and CONDITIONALLY MANDATORY for job enums...well, give it up. As Bill points out, not one single person has stood up in defense of a need for such definitions, so why are we still discussing this? (Much less, taking up valuable telecon time) ...jay ----- Begin Included Message ----- Date: Wed, 4 Jun 1997 13:56:06 -0400 From: bwagner@digprod.com (Bill Wagner) Subject: Re: JMP> Re: jmJobState [which mandatory job states?] To: jmp@pwg.org Cc: case@snmp.com Content-Transfer-Encoding: 7bit Tom, I would still very much apprecaite a statement of why you (and I don't see any one else) insist that the enums must be specified as being mandatory or conditionally mandatory. At this point I am not even being argumentative. But I see no more reason to make these values mandatory than to make certain emulations mandatory, or certain paper handling mandatory, or any number of other enums in the printer MIB mandatory. All it has done is produce vast discussion of what state should be at what compliance level, and concepts of the agent fabricating states that are inperceptable by the equipment or by a user. Please Tom, what is the reason for assigning compliance levels to the state values? Bill Wagner, Osicom/DPI So conformance requirements in a MIB specification are ONLY on the agent as measured through SNMP operations by a management application. For the completed state, its the agent, not the device that will usually retain the data for the row for each completed job. But if 'completed' were only conditionally mandatory, then the agent doesn't have to add anything extra to what the device already has. So if the device doesn't keep job information after the job finishes processing, the agent wouldn't have to either, IF the 'completed' state were conditionally mandatory. So lets be clear that conformance requirements are for the agent, not the device (printer or server). ----- End Included Message ----- From harryl at us.ibm.com Wed Jun 4 15:49:20 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003135910000002L002*@MHS> I think there is a problem with the state diagram +--> canceled(7) / +---> pending(3) ----> processing(5) -----+----> aborted(8) | ^ ^ \ --->+ | | +--> completed(9) | v | +---> held(4) processing-stopped(6) In that it does not show the ability to cancel a job from Held or Needs-Attention (processing-stopped) states. It is also quite possible that a job in Needs-Attention state would ultimately abort. I recommend the following changes to the diagram... +--> canceled(7) / +---> pending(3) ----> processing(5) ---+-+----> aborted(8) | ^ ^ | \ --->+ | | | +--> completed(9) | v v | +---> held(4) processing-stopped(6) | | | | +--------------------+---------+ Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed Jun 4 17:05:15 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003139571000002L012*@MHS> I also want a small set of meaningful job states. >A job can be in many, many kinds of "states", depending on the features >(and attendant complexities) of the underlying printing system. However, >no matter what printing system is involved, all jobs will be in exactly >one of the three top-level "meta" states of pending, processing, done. >Below these three states, the mgmt application in question will decide >on the exact semantics of the job based on some *consistent* refinement >of the top-level state. Hence, the simple two-level model I have been >suggesting this past week or so. > ...jay I tend to get very confused by the 3 separate terminology's however, those being JobState, JobSubState and JobStateReason. I believe there are actually 7 job states that deserve to be called STATES. We should be welcome to embellish any state with as many (or as FEW) REASONS as seen fit. Listed in my preferred terminology along with the current IPP/JMP name-for-a-day in parenthesis, the 7 are: Pending Held (Pending-Held) Printing (Processing) Needs_Attention (Processing-Stopped) Completed Canceled (Completed-Canceled) Aborted (Completed-Aborted) Yes, the STRAIGHT LINE PATH from submission to marks on paper is Pending-Printing-Complete, but other significant states are Held, Needs_Attention, Canceled and Aborted. There are all kinds of reasons (my favorite being printer-partly-stopped). I would like to suggest, however, that if we adopt these 7 as the "high level" states then we can eliminate the idea of "sub-state". Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Thu Jun 5 11:38:44 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Re: jmJobState [which mandatory job states?]> Message-ID: <9706051541.AA02600@zazen.cp10.es.xerox.com> Bill, Here goes some thoughts on why having MANDATORY enums be specified for mandatory objects, so that all conforming agents shall implement them. [However, on the telecon yesterday, I was the only person advocating conformance on the enum values. So I won't keep bringing up this subject anymore. The e-mail discussion this past week has prevented me from getting the MIB I need to consult with some SNMP experts in this, because my understanding of SNMP conformance (see the back of the Printer MIB, is that conformance of enum values is an important part of SNMP to help interworking between implementations from different vendors).] The major reason for having conformance on enum values is to increase the chances that an application program can interoperate with more than one implementation. If an application program can count on certain enums as being present, because they are mandatory, then the application designer/implementor can make plans that will work with evey agent implementation (at least with the conformant agents). For those enums that are conditionally mandatory, the application program designer/implementor knows that he can't count on those enums being present in all implementations, so the application program has to take account of the variability that it might encounter. On the other hand, the conformance requirements for a conforming monitoring application are that it be able to handle all job states that an agent might return. So the completed and aborted states are mandatory enums, so the application can count on jobs being in those states after a while and those are the last states that the jobs wind up in. We as printer vendors can decide that all implementations have some cases that they detect that causes an abort of the current job, so we make that state mandatory, so that applications can count on that. It would be extremely misleading if an application reports to a user that his job completed, when in fact it really aborted. If the application was from one vendor and the printer/agent from another there could be some ugly finger pointing by a customer who was mislead by thinking that his job printed ok (and he got into the meeting with his handouts or slides, only to discover that the job was only partially done, because of an abort). I can even see law suits down the road where a job was not printed completely, but the customer didn't know that. On some implementations there may not be the canceled state, such as an agent instrumenting an IPP level 1 conformant device (which doesn't have the canceljob operation). However, the monitoring application designer can probably design around a system that never shows jobs in the canceled state. However, an application that also submits a cancel request via some job protocol that the printer supports that has a CancelJob operation, say, IPP level 2, and expects to see the result of the cancel through the Job Monitoring MIB, has every right to expect to see the job end up in the canceled state, not the completed (or aborted) state. By making the canceled state CONDITIONALLY MANDATORY we force the IPP level 2 Job Monitoring MIB agent to support the caneled state. This is because a state that is labeled CONDITIONALL MANDATORY means that a conforming agent shall report jobs in the 'canceled' state, if the device has a canceljob operation (which level 2 IPP says is MANDATORY). If the canceled state were labeled OPTIONAL in JMP, instead of CONDITIONALLY MANDATORY, then an application designer would have no right to expect to see canceled jobs on an IPP level 2 JM MIB. But since our requirements were to support accounting, we know that we must make the 'canceled' state CONDITIONALLY MANDATORY in order to have meaningful accounting applications use our MIB. Remember some of these monitoring applications may be third party accounting programs. They want accurate reporting on canceling versus aborting, vs completed. Also a Kinkos customer wants to know what he/she is getting charged for. If our MIB leaves out this crucial conformance stuff, the third parties are much less likely to invest in an accounting package product, because they don't know what they can count on in the Job Monitoring MIB agents. As another example, the job-state-reasons of canceled-by-user vs canceled-by-operator, is very crucial when accounting comes in. Users may have to pay for canceling their jobs, but not if the operator does. Kinkos might not be interested using our MIB from various printer vendors, if these basic accounting requirements are not MANDATORY (or at least CONDITIONALLY MANDATORY with the condition being that the device supports a canceljob operation) and so are not present in enough printers to make it worth Kinko's investment in applications, such as accounting programs, that use the Job Monitoring MIB. Most systems that implement canceljob also have some sort of security so that ordinary users can only cancel their own jobs, but the operator can cancel any user's job. For any CONDITIONALLY MANDATORY enum, the condition that makes the enum MANDATORY should be included with the definition of the enum. So the condition for the canceled-by-user and canceled-by-operator could be simply: that the device supports a canceljob operation and we know that any viable implementation has to include the security necessary to distinguish between the user and the operator. On the other hand, if there were sufficient systems that did support canceljob, but didn't support the distinction between a user and an operator, we could add a second condition that the implementation distinguishes between users and operators. At 10:56 06/04/97 PDT, Bill Wagner wrote: > Tom, > > I would still very much apprecaite a statement of why you (and I > don't see any one else) insist that the enums must be specified as > being mandatory or conditionally mandatory. At this point I am not > even being argumentative. But I see no more reason to make these > values mandatory than to make certain emulations mandatory, or > certain paper handling mandatory, or any number of other enums in the > printer MIB mandatory. All it has done is produce vast discussion of > what state should be at what compliance level, and concepts of the > agent fabricating states that are inperceptable by the equipment or > by a user. Please Tom, what is the reason for assigning compliance > levels to the state values? > > Bill Wagner, Osicom/DPI > >So conformance requirements in a MIB specification are ONLY on the agent as >measured through SNMP operations by a management application. > >For the completed state, its the agent, not the device that will usually >retain the data for the row for each completed job. But if 'completed' >were only conditionally mandatory, then the agent doesn't have to add >anything extra to what the device already has. So if the device doesn't keep >job information after the job finishes processing, the agent wouldn't >have to either, IF the 'completed' state were conditionally mandatory. > >So lets be clear that conformance requirements are for the agent, not >the device (printer or server). > > > > > From hastings at cp10.es.xerox.com Thu Jun 5 11:39:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Re: jmJobState [which mandatory job states?]> Message-ID: <9706051541.AB02600@zazen.cp10.es.xerox.com> At 12:35 06/04/97 PDT, JK Martin wrote: >I completely agree with Bill here. This whole issue seems quite >insane to me. What is it about the Job MIB regarding enums that >is any different than any other MIB-related effort we've done??? The Printer MIB is the only other MIB "we've" done and it has some mandatory enums in it, so I'm very confused by your statement. Here is the relevant lines from pages 91-92 of RFC 1759 which lists mandatory enums in the prtGeneralReset object. -- compliance statements prtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the printer MIB." MODULE -- this module MANDATORY-GROUPS { prtGeneralGroup, prtInputGroup, prtOutputGroup, prtMarkerGroup, prtMediaPathGroup, prtChannelGroup, prtInterpreterGroup, prtConsoleGroup, prtAlertTableGroup } OBJECT prtGeneralReset SYNTAX INTEGER { notResetting(3), resetToNVRAM(5) } DESCRIPTION "It is conformant to implement just these two states in this object. Any additional states are optional." OBJECT prtConsoleOnTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT prtConsoleOffTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." -- the prtResponsiblePartyGroup, prtExtendedInputGroup, -- prtInputMediaGroup, prtExtendedOutputGroup, -- prtOutputDimensionsGroup, prtOutputFeaturesGroup, -- prtMarkerSuppliesGroup, prtMarkerColorantGroup, -- and the prtAlertTimeGroup are completely optional. ::= { prtMIBConformance 1 } Part of the problem is that many of us are new to SNMP (me included), so that these conformance issues are not well appreciated. > >Tom: You posted a message to the IPP/JMP lists encouraging folks > to read your documents relating to the IPP telecon later today. > With regard to your pushing the definitions of MANDATORY and > CONDITIONALLY MANDATORY for job enums...well, give it up. > >As Bill points out, not one single person has stood up in defense >of a need for such definitions, so why are we still discussing this? >(Much less, taking up valuable telecon time) Ok, I'll desist for now and get the next version of the MIB out. These discussions have been keeping me from updating the document as quickly as I had hoped with the good agreements we have reached in other areas. However, I want to check with some real SNMP experts here. My experience with any standard that has significant implementations and significant testing groups and significant producer implementations interworking with consumer implementations from different implementation organizations, is that conforance requirements is the only way to get interoperability. At Digital we had the PDP-11 whose implementations were all over the map. Our answer was the VAX with specific conformance requirements that the processors had to meet and that the software could count on. The compatibility was very high on the VAX, and not so good on the PDP-11. (I was one of the five authors of the VAX architectural spec, so I've been through this interworking thing on a spec for an iterface). The simplest example of a conformance requirement which shows that such a requirement is more than the nonimal dimension is the tolerance dimensions on an interchangable part in manufacturing. The size of something isn't, say, just a nominal 5 inches, but 5 inches plus or minus a specified tolerance, say .01 inches. A conforming implementation is one that measures within the tolerance and will fit into something that is expecting something in the range of 4.99 to 5.01 inches. Without the conformance requirement specified in the interface spec, some implementor might have thought that 4.9 was close enough. But his implementation would not interwork with (plug into) something that expected 4.99 to 5.01 inches. > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Wed Jun 4 13:53 EDT 1997 >Date: Wed, 4 Jun 1997 13:56:06 -0400 >From: bwagner@digprod.com (Bill Wagner) >Subject: Re: JMP> Re: jmJobState [which mandatory job states?] >To: jmp@pwg.org >Cc: case@snmp.com >Content-Transfer-Encoding: 7bit > > Tom, > > I would still very much apprecaite a statement of why you (and I > don't see any one else) insist that the enums must be specified as > being mandatory or conditionally mandatory. At this point I am not > even being argumentative. But I see no more reason to make these > values mandatory than to make certain emulations mandatory, or > certain paper handling mandatory, or any number of other enums in the > printer MIB mandatory. All it has done is produce vast discussion of > what state should be at what compliance level, and concepts of the > agent fabricating states that are inperceptable by the equipment or > by a user. Please Tom, what is the reason for assigning compliance > levels to the state values? > > Bill Wagner, Osicom/DPI > >So conformance requirements in a MIB specification are ONLY on the agent as >measured through SNMP operations by a management application. > >For the completed state, its the agent, not the device that will usually >retain the data for the row for each completed job. But if 'completed' >were only conditionally mandatory, then the agent doesn't have to add >anything extra to what the device already has. So if the device doesn't keep >job information after the job finishes processing, the agent wouldn't >have to either, IF the 'completed' state were conditionally mandatory. > >So lets be clear that conformance requirements are for the agent, not >So lets be clear that conformance requirements are for the agent, not >the device (printer or server). > > > > > >----- End Included Message ----- > > > From hastings at cp10.es.xerox.com Thu Jun 5 11:39:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706051541.AB02600@zazen.cp10.es.xerox.com> I agree completely with Harry that we should have seven job states for IPP and JMP. I also happen to like the simpler single word names for the 7 states: pending held processing stopped canceled aborted completed My understanding from the 6/4 telecon is that the JMP jmJobState object will remain in the MANDATORY jmJobTable and that we will use Ron's suggestion for the conformance of the enums as: "All possible enums for this object must be reported if implemented and available to the agent." And then I agree with Harry that JMP implementations can use as many or as few job-state-reasons to embellish these states. My understanding of our agreement yesterday (6/4 telecon) is that JMP will keep jmJobStateReasons1 object MANDATORY, but not say anything about which enums are MANDATORY, which are CONDITIONALLY MANDATORY and which are OPTIONAL. Correct? Or should we include Ron's statement for JMP jmJobStateReasons1 object as well? IPP has job-state-reasons attribute as MANDATORY and has the following job-state-reason values MANDATORY, CONDITIONALLY MANDATORY, and OPTIONAL: MAN none MAN job-incoming OPT outgoing COND job-hold-until-specified OPT job-hold-until-resources-are-ready OPT printer-stopped-partly MAN printer-stopped OPT job-printing MAN-L2 job-canceled-by-user MAN-L2 job-canceled-by-operator OPT logfile-pending OPT logfile-transferring MAN job-completed-successfully MAN job-completed-with-warnings MAN job-completed-with-errors Tom At 14:05 06/04/97 PDT, Harry Lewis wrote: >I also want a small set of meaningful job states. > >>A job can be in many, many kinds of "states", depending on the features >>(and attendant complexities) of the underlying printing system. However, >>no matter what printing system is involved, all jobs will be in exactly >>one of the three top-level "meta" states of pending, processing, done. > >>Below these three states, the mgmt application in question will decide >>on the exact semantics of the job based on some *consistent* refinement >>of the top-level state. Hence, the simple two-level model I have been >>suggesting this past week or so. > >> ...jay > >I tend to get very confused by the 3 separate terminology's however, >those being JobState, JobSubState and JobStateReason. > >I believe there are actually 7 job states that deserve to be called >STATES. We should be welcome to embellish any state with as many (or as >FEW) REASONS as seen fit. Listed in my preferred terminology along with >the current IPP/JMP name-for-a-day in parenthesis, the 7 are: > >Pending >Held (Pending-Held) >Printing (Processing) >Needs_Attention (Processing-Stopped) >Completed >Canceled (Completed-Canceled) >Aborted (Completed-Aborted) > >Yes, the STRAIGHT LINE PATH from submission to marks on paper is >Pending-Printing-Complete, but other significant states are Held, >Needs_Attention, Canceled and Aborted. There are all kinds of reasons >(my favorite being printer-partly-stopped). I would like to suggest, however, >that if we adopt these 7 as the "high level" states then we can eliminate the >idea of "sub-state". > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Thu Jun 5 12:57:33 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003197841000002L012*@MHS> I don't want to begin making the diagram too complex. >> +--------->----------+------>------+--> canceled(7) >> | | | >> +---> pending(3) -------> processing(5) -------> completed(9) >> | ^ ^ \ | >> --->+ | | +------------> aborted(8) >> | v v / | >> +---> held(4) stopped(6) | | | | +--------->----------+------>------+ I only want to assure that the state diagram does not give the impression that, to cancel or abort a job, the flow has to be back through processing. > +--> canceled(7) > / > +---> pending(3) ----> processing(5) -----+----> aborted(8) > | ^ ^ \ >--->+ | | +--> completed(9) > | v | > +---> held(4) processing-stopped(6) What was wrong with my proposal? > +--> canceled(7) > / > +---> pending(3) ----> processing(5) ---+-+----> aborted(8) > | ^ ^ | \ >--->+ | | | +--> completed(9) > | v v | > +---> held(4) processing-stopped(6) | > | | | > +--------------------+---------+ > >>> Harry <<< From rbergma at dpc.com Thu Jun 5 13:05:35 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: <9706051541.AB02600@zazen.cp10.es.xerox.com> Message-ID: <5030100003197841000002L012*@MHS> Tom, I agree that you new revised figure is correct. But it has so many lines and lines crossing that I doubt it is useful. I propose that we keep the original figure, but show the two paths to "Aborted", with the added text: "The Canceled state can be entered from the Pending, Pending-Held, Processing, or Processing-Stopped states." Ron Bergman Dataproducts Corp. On Thu, 5 Jun 1997, Tom Hastings wrote: > I agree that canceled can be entered from any state and that a system > might (but need not) abort a stopped job. > > The definition of the aborted state for IPP and JMP supports your > idea with the weasil word "usually" in the definition: > > aborted: > The job has been aborted by the system, usually while the job was in the > processing state. > > So how does this picture look to you for IPP and JMP (IPP wouldn't > have the enums and wouldn't have the "active/in-active" line, since > it is a JMP-only term). > > Running arrows from every state to canceled and from stopped to > aborted would look like this: > > >> +--------->----------+------>------+--> canceled(7) > >> | | | > >> +---> pending(3) -------> processing(5) -------> completed(9) > >> | ^ ^ \ | > >> --->+ | | +------------> aborted(8) > >> | v v / | > >> +---> held(4) stopped(6) | > | | | > +--------->----------+------>------+ > >> > >> <-------------- active ------------>|<-- in-active -->| > >> > > Is this figure ok? From harryl at us.ibm.com Thu Jun 5 13:16:08 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> "Held" is not Active Message-ID: <5030100003199363000002L032*@MHS> Tom, >So how does this picture look to you for IPP and JMP (IPP wouldn't >have the enums and wouldn't have the "active/in-active" line, since >it is a JMP-only term). I thought we agreed, in Austin, that Held was not Active. Harry Lewis - IBM Printing Systems From bwagner at digprod.com Thu Jun 5 13:30:08 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: jmJobState [which mandatory job states?] In-Reply-To: Re: jmJobState [which mandatory job states?]> Message-ID: <5030100003199363000002L032*@MHS> Tom, Many thanks for the response. I think the point is moot now, but I guess I would argue that: 1. since the MIB is dealing with states of a short-lived entity,the states are all transitory. The management applications have no guarantee that they will see each state that the job goes through,whether that state is mandatory or not. 2. the MIB documents the desired implementation; the market pressures and desire to add value to the product will ultimately be the major driving force to follow this implementation as closely as feasible. Getting into squabbles about what is compliant or not, when it does not significantly aid utilization, is fruitless. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Re: jmJobState [which mandatory job states?] Author: Tom Hastings at Internet Date: 6/5/97 8:38 AM Bill, Here goes some thoughts on why having MANDATORY enums be specified for mandatory objects, so that all conforming agents shall implement them. [However, on the telecon yesterday, I was the only person advocating conformance on the enum values. So I won't keep bringing up this subject anymore. The e-mail discussion this past week has prevented me from getting the MIB I need to consult with some SNMP experts in this, because my understanding of SNMP conformance (see the back of the Printer MIB, is that conformance of enum values is an important part of SNMP to help interworking between implementations from different vendors).] ... From hastings at cp10.es.xerox.com Thu Jun 5 18:02:32 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706052204.AA02916@zazen.cp10.es.xerox.com> At 09:57 06/05/97 PDT, Harry Lewis wrote: >I don't want to begin making the diagram too complex. > >>> +--------->----------+------>------+--> canceled(7) >>> | | | >>> +---> pending(3) -------> processing(5) -------> completed(9) >>> | ^ ^ \ | >>> --->+ | | +------------> aborted(8) >>> | v v / | >>> +---> held(4) stopped(6) | > | | | > +--------->----------+------>------+ > >I only want to assure that the state diagram does not give the impression that, >to cancel or abort a job, the flow has to be back through processing. > >> +--> canceled(7) >> / >> +---> pending(3) ----> processing(5) -----+----> aborted(8) >> | ^ ^ \ >>--->+ | | +--> completed(9) >> | v | >> +---> held(4) processing-stopped(6) > > >What was wrong with my proposal? > >> +--> canceled(7) >> / >> +---> pending(3) ----> processing(5) ---+-+----> aborted(8) >> | ^ ^ | \ >>--->+ | | | +--> completed(9) >> | v v | >> +---> held(4) processing-stopped(6) | >> | | | >> +--------------------+---------+ >> > >>>> Harry <<< > > It shows state transitions that are very unlikely: held -> aborted held -> completed processing-stopped -> completed and it doesn't show pending -> canceled From hastings at cp10.es.xerox.com Thu Jun 5 18:20:44 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: "Held" is not Active In-Reply-To: <"Held" is not Active> Message-ID: <9706052223.AA02933@zazen.cp10.es.xerox.com> I don't remember the discussion. The definition of which job states include "active" has affect on the following objects: jmGeneralNumberOfActiveJobs Integer32(0..2147483647), jmGeneralOldestActiveJobIndex Integer32(0..2147483647), jmGeneralNewestActiveJobIndex Integer32(0..2147483647), I had assumed that the fact that a job was in the 'held' state still meant that it would be included in the jmGeneralNumberOfActiveJobs, since 'held' is just a variant of the 'pending' state (though you could make an argument that a held job isn't as likely to be processed as other jobs that are pending and so shouldn't be included in the count of active jobs which is an indication of the business of the printer). On the other hand, an application that is using the OldestActiveJobIndex might not want to miss jobs that are in the 'held' state. Similarly, when an idle printer accepts a job that is in the 'held' state, I don't think we want the agent to keep the NewestActiveJobIndex at 0. So I thought it was simpler to include 'held' jobs as active. So all the states on the left of the picture are the "active" states, and the three terminal states on the right of the picture are in-active states. Ok? Tom At 10:16 06/05/97 PDT, Harry Lewis wrote: >Tom, > >>So how does this picture look to you for IPP and JMP (IPP wouldn't >>have the enums and wouldn't have the "active/in-active" line, since >>it is a JMP-only term). > >I thought we agreed, in Austin, that Held was not Active. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Thu Jun 5 19:52:37 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706052355.AA03022@zazen.cp10.es.xerox.com> Sounds simpler. So how is this for JMP: JmJobStateTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) --------> processing(5) -----+----> completed(9) | ^ ^ \ --->+ | | +--> aborted(8) | v v / +---> pendingHeld(4) processingStopped(6) --+ <--------------- active -----------------> <--- in-active ---> Figure 4 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states." -- This is a type 2 enumeration. See Section 7.1 on page 25. SYNTAX INTEGER { other(1), At 10:05 06/05/97 PDT, Ron Bergman wrote: >Tom, > >I agree that you new revised figure is correct. But it has so >many lines and lines crossing that I doubt it is useful. > >I propose that we keep the original figure, but show the two paths >to "Aborted", with the added text: > >"The Canceled state can be entered from the Pending, Pending-Held, >Processing, or Processing-Stopped states." > > > Ron Bergman > Dataproducts Corp. > > >On Thu, 5 Jun 1997, Tom Hastings wrote: > >> I agree that canceled can be entered from any state and that a system >> might (but need not) abort a stopped job. >> >> The definition of the aborted state for IPP and JMP supports your >> idea with the weasil word "usually" in the definition: >> >> aborted: >> The job has been aborted by the system, usually while the job was in the >> processing state. >> >> So how does this picture look to you for IPP and JMP (IPP wouldn't >> have the enums and wouldn't have the "active/in-active" line, since >> it is a JMP-only term). >> >> Running arrows from every state to canceled and from stopped to >> aborted would look like this: >> >> >> +--------->----------+------>------+--> canceled(7) >> >> | | | >> >> +---> pending(3) -------> processing(5) -------> completed(9) >> >> | ^ ^ \ | >> >> --->+ | | +------------> aborted(8) >> >> | v v / | >> >> +---> held(4) stopped(6) | >> | | | >> +--------->----------+------>------+ >> >> >> >> <-------------- active ------------>|<-- in-active -->| >> >> >> >> Is this figure ok? > > > From rbergma at dpc.com Thu Jun 5 21:12:12 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: <9706052355.AA03022@zazen.cp10.es.xerox.com> Message-ID: <9706052355.AA03022@zazen.cp10.es.xerox.com> Tom, Looks good. Any objections from anyone else? Ron Bergman On Thu, 5 Jun 1997, Tom Hastings wrote: > Sounds simpler. So how is this for JMP: > > JmJobStateTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The current state of the job (pending, processing, completed, etc.). > > The following figure shows the normal job state transitions: > > +--> canceled(7) > / > +---> pending(3) --------> processing(5) -----+----> completed(9) > | ^ ^ \ > --->+ | | +--> aborted(8) > | v v / > +---> pendingHeld(4) processingStopped(6) --+ > > <--------------- active -----------------> <--- in-active ---> > Figure 4 - Normal Job State Transitions > > Normally a job progresses only from left to right. Other state transitions > are unlikely, but are not forbidden. The canceled state can be entered from > the pending, pendingHeld, processing, or processingStopped states." > > -- This is a type 2 enumeration. See Section 7.1 on page 25. > SYNTAX INTEGER { > other(1), > > > At 10:05 06/05/97 PDT, Ron Bergman wrote: > >Tom, > > > >I agree that you new revised figure is correct. But it has so > >many lines and lines crossing that I doubt it is useful. > > > >I propose that we keep the original figure, but show the two paths > >to "Aborted", with the added text: > > > >"The Canceled state can be entered from the Pending, Pending-Held, > >Processing, or Processing-Stopped states." > > > > > > Ron Bergman > > Dataproducts Corp. > > > > From Angelo_Caruso at wb.xerox.com Fri Jun 6 14:14:34 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <9706052355.AA03022@zazen.cp10.es.xerox.com> Given the recent argument that HELD is more intuitive to the average user than PENDING-STOPPED, isn't the original name NEEDS-ATTENTION also more intuitive than STOPPED or PROCESSING-STOPPED? It certainly is to me. I propose we go back to the original name NEEDS-ATTENTION. So, the seven states would be: pending held processing needs-attention canceled aborted completed Thanks, Angelo ---------- From: jmp-owner@pwg.org To: ipp@pwg.org; jmp@pwg.org; Harry Lewis Subject: Re: JMP> Re: IPP> MOD JobState suggestion Date: Thursday, June 05, 1997 12:00AM I agree completely with Harry that we should have seven job states for IPP and JMP. I also happen to like the simpler single word names for the 7 states: pending held processing stopped canceled aborted completed My understanding from the 6/4 telecon is that the JMP jmJobState object will remain in the MANDATORY jmJobTable and that we will use Ron's suggestion for the conformance of the enums as: "All possible enums for this object must be reported if implemented and available to the agent." And then I agree with Harry that JMP implementations can use as many or as few job-state-reasons to embellish these states. My understanding of our agreement yesterday (6/4 telecon) is that JMP will keep jmJobStateReasons1 object MANDATORY, but not say anything about which enums are MANDATORY, which are CONDITIONALLY MANDATORY and which are OPTIONAL. Correct? Or should we include Ron's statement for JMP jmJobStateReasons1 object as well? IPP has job-state-reasons attribute as MANDATORY and has the following job-state-reason values MANDATORY, CONDITIONALLY MANDATORY, and OPTIONAL: MAN none MAN job-incoming OPT outgoing COND job-hold-until-specified OPT job-hold-until-resources-are-ready OPT printer-stopped-partly MAN printer-stopped OPT job-printing MAN-L2 job-canceled-by-user MAN-L2 job-canceled-by-operator OPT logfile-pending OPT logfile-transferring MAN job-completed-successfully MAN job-completed-with-warnings MAN job-completed-with-errors Tom At 14:05 06/04/97 PDT, Harry Lewis wrote: >I also want a small set of meaningful job states. > >>A job can be in many, many kinds of "states", depending on the features >>(and attendant complexities) of the underlying printing system. However, >>no matter what printing system is involved, all jobs will be in exactly >>one of the three top-level "meta" states of pending, processing, done. > >>Below these three states, the mgmt application in question will decide >>on the exact semantics of the job based on some *consistent* refinement >>of the top-level state. Hence, the simple two-level model I have been >>suggesting this past week or so. > >> ...jay > >I tend to get very confused by the 3 separate terminology's however, >those being JobState, JobSubState and JobStateReason. > >I believe there are actually 7 job states that deserve to be called >STATES. We should be welcome to embellish any state with as many (or as >FEW) REASONS as seen fit. Listed in my preferred terminology along with >the current IPP/JMP name-for-a-day in parenthesis, the 7 are: > >Pending >Held (Pending-Held) >Printing (Processing) >Needs_Attention (Processing-Stopped) >Completed >Canceled (Completed-Canceled) >Aborted (Completed-Aborted) > >Yes, the STRAIGHT LINE PATH from submission to marks on paper is >Pending-Printing-Complete, but other significant states are Held, >Needs_Attention, Canceled and Aborted. There are all kinds of reasons >(my favorite being printer-partly-stopped). I would like to suggest, however, >that if we adopt these 7 as the "high level" states then we can eliminate the >idea of "sub-state". > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Fri Jun 6 15:28:45 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Issues and agenda for job-state and job-state-reasons for Message-ID: <9706061931.AA03384@zazen.cp10.es.xerox.com> Agenda for job-state and job-state-reasons part of today's telecon. 1. Is the updated text for IPP and JMP ok? 2. Names of the state agreed? (not exactly as in the minutes)? (can we just simplify the names to the last word in the hyphendated names?) 3. in-coming and out-going issue 4. any other problems with the rest of the specification sent out for the 6/4 telecon: jobstate.pdf. Here is Scott's complete agenda: Friday June 6 2:00 pm - 4:00 pm Mountain 800-600-5302 code: 346463 Agenda: 1. Job State and Job State Reasons 2. Presentation of attributes in the Model document - separate doc? - lists of keyword values 3. Run through the remaining issues in the document Scott Isaacson Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or 'processing' states? In the IPP Internet-Draft, there is a conflict between the semantics of the 'processing' state specified under the "job-state" attribute and the "job-state-reasons" values: 'job-sending-to-output-device' and 'job-queued-in-output-device' which we agreed to combine into: 'job-outgoing'. In the "job-state" definition, 'job-outgoing' is in the 'processing' state, while the "job-state-reasons" definition says that 'job-outgoing' shall be in the 'pending' state. Which do we want the IPP and JMP spec to say? Do we agree on the following state transition diagrams: The corresponding IPP text will be: 6.3.2.5 job-state (type1 keyword) This attribute identifies the current state of the job. The Printer may provide additional information about each state value by supplying one or more values of the job's companion "job-state-reasons" attribute depending on implementation. While the job states cannot be added to without impacting deployed clients that take actions upon receiving job state values, it is the intent that additional "job-state-reasons" values can be defined without impacting such deployed clients. In other words, the "job-state-reasons" attribute is intended to be extensible. Standard values are: unknown The job state is not known, or its state is indeterminate. pending The job is a candidate to start processing, but is not yet processing. pending-held The job is not a candidate for processing for any number of reasons and will resume pending as soon as the reasons are no longer present. The job's "job-state-reason" attribute shall indicate why the job is no longer a candidate for processing. processing Either:1. the job is using, or is attempting to use, one or more document transforms which include (1) purely software processes that are interpreting a PDL, and (2) hardware devices that are interpreting a PDL, making marks on a medium, and/or performing finishing, such as stapling OR 2. the server has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. ISSUE: The "job-state-reasons" specification is that the job is in 'pending' state not 'processing' state.When the job is in the 'processing' state, the entire job state includes the detailed status represented in the printer's "printer-state", "printer-state-reasons", and "printer-state-message attributes.Implementations may include additional values in the job's "job-state-reasons" attribute to indicate the progress of the job, such as adding the 'job-printing' value to indicate when the output device is actually making marks on paper. Most implementations won't bother with this nuance. processing-stopped The job has stopped while processing for any number of reasons and will continue processing as soon as the reasons are no longer present. The job's "job-state-reason" attribute shall indicate why the job has stopped processing.If the output device is stopped, the 'printer-stopped' value shall be included in the job's "job-state-reasons" attribute. When the output device is stopped, the device usually indicates its condition in human readable form locally at the device. A client can obtain more complete device status remotely by querying the printer's "printer-state-reasons" attribute. canceled The job has been canceled by a Cancel-Job operation and is either (1) in the process of terminating or (2) has completed terminating. The job's "job-state-reasons" attribute shall contain either the 'canceled-by-user' or 'canceled-by-operator' value. aborted The job has been aborted by the system, usually while the job was in the 'processing' state. completed The job has completed successfully or with warnings or errors and all of the job media sheets have been properly stacked in the appropriate output tray or bin. The job's "job-state-reasons" attribute shall contain one of: 'completed-successfully', 'completed-with-warnings', or 'completed-with-errors'. The length of time that jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation. The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. +--> canceled / +----> pending --------> processing --+----> aborted | ^ ^ \ ----+ | | +--> completed | v v +----> pending-stopped processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right through three states. Even though the IPP protocol defines seven values for job states, Printers SHALL only implement those states which are appropriate for the particular implementation. For JMP: JmJobStateTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). The following figure shows the normal job state transitions: +--> canceled(7) / +---> pending(3) --------> processing(5) -----+----> completed(9) | ^ ^ \ --->+ | | +--> aborted(8) | v v / +---> pendingHeld(4) processingStopped(6) --+ <-------------- active -----------------> <-- in-active --> Figure 4 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states." -- This is a type 2 enumeration. See Section 7.1 on page 25. SYNTAX INTEGER { other(1), -- The job state is not one of the defined states. unknown(2), ---- The job state is not known, or its state is indeterminate. pending(3), ---- The job is waiting to start processing, but is not yet processing. pendingHeld(4), ---------------------- The job is not yet a candidate for processing for any number of reasons and will resume pending as soon as the reasons are no longer present. The reasons are represented as bits in the jobStateReasons1 object and/or jobStateReasonsn (n=2..4) attribute. Some reasons are used in other states to give added information about the job state. See the JmJobStateReasonsnTC (n=1..4) textual convention for the specification of each reason and in which states the reasons are intended to be used. processing(4), -- -------------------------------------------------------------------- Either: 1. The job is using, or is attempting to use, one or more document transforms which include (1) purely software processes that are interpreting a PDL, and (2) hardware devices that are interpreting a PDL, making marks on a medium, and/or performing finishing, such as stapling OR2. (configuration 2) the server has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. ISSUE: The definitions of job-outgoing say that the job state is 'pending', not 'processing'. Can we remove paragraph 2 about from the definition of the 'processing' state?When the job is in the processing state, the entire job state includes the detailed status represented in the device MIB indicated by the hrDeviceIndex value of the job's physicalDevice attribute.Implementations MAY, though they NEED NOT, include additional values in the job's jmJobStateReasons1 object to indicate the progress of the job, such as adding the jobPrinting value to indicate when the device is actually making marks on paper. processingStopped(7), -- ------------------------------------ The job has stopped while processing for any number of reasons and will continue processing as soon as the reasons are no longer present. The job's jmJobStateReasons1 object and/or the job's jobStateReasonsn (n=2..4) attributes SHOULD indicate why the job has stopped processing. For example, if the output device is stopped, the deviceStopped value SHOULD be included in the job's jmJobStateReasons1 object. NOTE - When an output device is stopped, the device usually indicate its condition in human readable form locally at the device. The management application can obtain more complete device status remotely by querying the appropriate device MIB using the job's deviceIndex attribute(s). canceled(5), -- ------------ The job is in the process of being terminated by the server or device or has completed terminating the job, because a client canceled the job. The job's jobStateReasons1 attribute SHOULD contain either the canceledByUser or canceledByOperator value. aborted(6) -- ---- The job has been aborted by the system, usually while the job was in the processing state. completed(7) -- ------------ The job has completed successfully or with warnings or errors after processing and all of the media have been successfully stacked in the output bin(s). The job's jobStateReasons1 attribute SHOULD contain one of: completedSuccessfully, completedWithWarnings, or completedWithErrors. } From hastings at cp10.es.xerox.com Fri Jun 6 15:35:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Updated IPP state transition diagram Message-ID: <9706061937.AA03396@zazen.cp10.es.xerox.com> I forgot to update the IPP part in my previous message. It should be: The following figure shows the normal job state transitions. Other transitions are unlikely, but are not forbidden. +--> canceled / +----> pending --------> processing --+----> aborted | ^ ^ \ ----+ | | +--> completed | v v +----> pending-held processing-stopped Figure 1 - Normal job state transitions Normally a job progresses only from left to right through three states. The canceled state can be entered from the pending, pendingHeld, processing, or processingStopped states. Even though the IPP protocol defines seven values for job states, Printers SHALL only implement those states which are appropriate for the particular implementation. Tom From harryl at us.ibm.com Fri Jun 6 15:43:04 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: IPP> MOD JobState suggestion In-Reply-To: Re: IPP> MOD JobState suggestion> Message-ID: <5030100003257806000002L062*@MHS> Taking your revised diagram: > The following figure shows the normal job state transitions: > > +--> canceled(7) > / > +---> pending(3) --------> processing(5) -----+----> completed(9) > | ^ ^ \ > --->+ | | +--> aborted(8) > | v v / > +---> pendingHeld(4) processingStopped(6) --+ > > <--------------- active -----------------> <--- in-active ---> > Figure 4 - Normal Job State Transitions > *and* the associated wording: > Normally a job progresses only from left to right. Other state transitions > are unlikely, but are not forbidden. The canceled state can be entered from > the pending, pendingHeld, processing, or processingStopped states." together, I think they tell the story we're looking for. I agree. >>> Harry Lewis <<< From harryl at us.ibm.com Fri Jun 6 17:02:02 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: "Held" is not Active In-Reply-To: <"Held" is not Active> Message-ID: <5030100003262155000002L052*@MHS> The problem I have with held meaning active is that is messes up the concept of "number of intervening jobs". If I'm testing the waters at 9am for a printer with least number of intervening jobs, I will get a false impression if the printer tells me about all the jobs which are held until midnight. I think held jobs are, indeed, inactive. >>> Harry Lewis <<< ------ Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 02:43 PM ------ jmp-owner@pwg.org 06/05/97 07:00 PM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: JMP> Re: "Held" is not Active I don't remember the discussion. The definition of which job states include "active" has affect on the following objects: jmGeneralNumberOfActiveJobs Integer32(0..2147483647), jmGeneralOldestActiveJobIndex Integer32(0..2147483647), jmGeneralNewestActiveJobIndex Integer32(0..2147483647), I had assumed that the fact that a job was in the 'held' state still meant that it would be included in the jmGeneralNumberOfActiveJobs, since 'held' is just a variant of the 'pending' state (though you could make an argument that a held job isn't as likely to be processed as other jobs that are pending and so shouldn't be included in the count of active jobs which is an indication of the business of the printer). On the other hand, an application that is using the OldestActiveJobIndex might not want to miss jobs that are in the 'held' state. Similarly, when an idle printer accepts a job that is in the 'held' state, I don't think we want the agent to keep the NewestActiveJobIndex at 0. So I thought it was simpler to include 'held' jobs as active. So all the states on the left of the picture are the "active" states, and the three terminal states on the right of the picture are in-active states. Ok? Tom At 10:16 06/05/97 PDT, Harry Lewis wrote: >Tom, > >>So how does this picture look to you for IPP and JMP (IPP wouldn't >>have the enums and wouldn't have the "active/in-active" line, since >>it is a JMP-only term). > >I thought we agreed, in Austin, that Held was not Active. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon Jun 9 11:07:15 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: "Held" is not Active [Ok if I don't include In-Reply-To: Re: "Held" is not Active [Ok if I don't include> Message-ID: <9706091509.AA03757@zazen.cp10.es.xerox.com> I agree that the jmGeneralNumberOfActiveJobs shouldn't count jobs in the pendingHeld state so that the user gets a better idea of how busy the printer is from the value of jmGeneralNumberOfActiveJobs. However, what about our two indexes which also include the active jobs. Here is isn't so clear whether the jmGeneralOldestActiveJobIndex should or should not include the pendingHeld jobs. The advantage of not including them, is that they tend to get "stuck" amongst a lot of completed jobs in the table, so that an application would have to skip over a growing number of completed jobs. >jmGeneralNumberOfActiveJobs Integer32(0..2147483647), >jmGeneralOldestActiveJobIndex Integer32(0..2147483647), >jmGeneralNewestActiveJobIndex Integer32(0..2147483647), For example, at 10:00Am when I submit the job that is held until 5:00 pm the table might look like: jmJobIndex State 200 completed 201 completed 202 completed ... 330 completed 331 processing <-- jmGeneralOldestActiveJobIndex 332 pending 333 pending 334 pendingHeld - my job <-- jmGeneralNewestActiveJobIndex At 12:00 AM the table might look like: 334 pendingHeld <-- jmGeneralOldestActiveJobIndex 450 completed 451 completed 452 completed ... 597 completed 598 processing 599 pending 600 pending 601 pending <-- jmGeneralNewestActiveJobIndex So the applications would have to skip over the 150 or so completed jobs. If we define active as no including pendingHeld, then we get: At 12:00 AM the table might look like: 334 pendingHeld 450 completed 451 completed 452 completed ... 597 completed 598 processing <-- jmGeneralOldestActiveJobIndex 599 pending 600 pending 601 pending <-- jmGeneralNewestActiveJobIndex This is better for most applications. An application that wants to show the entire queue to an operator will have to search through all the jobs looking for pendingHeld jobs. But maybe that is a good tradeoff. Such an application is likely to be keeping a copy of the table anyway. Note that at 5:00 pm, the agent has to cause the jmGeneralOldestActiveJobIndex to be set back to 334, when my job changes from pendingHeld to pending. Also note that an implementation that moves pending jobs to pendingHeld when the resources are changed on the device will have to fiddle with jmGeneralOldestActiveJobIndex as well, to keep it pointing at the oldest active job. So I'll change the definition of active to not include pendingHeld. (and remove the active in-active from the picture, since it doesn't cleanly divide. At 14:02 06/06/97 PDT, Harry Lewis wrote: >The problem I have with held meaning active is that is messes up the concept of >"number of intervening jobs". If I'm testing the waters at 9am for a printer >with least number of intervening jobs, I will get a false impression if the >printer tells me about all the jobs which are held until midnight. > >I think held jobs are, indeed, inactive. > >>>> Harry Lewis <<< > > >------ Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 02:43 PM ------ > > jmp-owner@pwg.org > 06/05/97 07:00 PM >Please respond to jmp-owner@pwg.org @ internet > > >To: Harry Lewis/Boulder/IBM@IBMUS >cc: jmp@pwg.org @ internet >Subject: JMP> Re: "Held" is not Active > >I don't remember the discussion. > >The definition of which job states include "active" has affect on the >following objects: > >jmGeneralNumberOfActiveJobs Integer32(0..2147483647), >jmGeneralOldestActiveJobIndex Integer32(0..2147483647), >jmGeneralNewestActiveJobIndex Integer32(0..2147483647), > >I had assumed that the fact that a job was in the 'held' state still >meant that it would be included in the jmGeneralNumberOfActiveJobs, >since 'held' is just a variant of the 'pending' state >(though you could make an argument that a held job isn't as likely >to be processed as other jobs that are pending and so shouldn't be included >in the count of active jobs which is an indication of the business of the >printer). > >On the other hand, an application that is using the OldestActiveJobIndex >might not want to miss jobs that are in the 'held' state. Similarly, >when an idle printer accepts a job that is in the 'held' state, I don't think >we want the agent to keep the NewestActiveJobIndex at 0. > >So I thought it was simpler to include 'held' jobs as active. So all the >states on the left of the picture are the "active" states, and the >three terminal states on the right of the picture are in-active states. > >Ok? > >Tom > >At 10:16 06/05/97 PDT, Harry Lewis wrote: >>Tom, >> >>>So how does this picture look to you for IPP and JMP (IPP wouldn't >>>have the enums and wouldn't have the "active/in-active" line, since >>>it is a JMP-only term). >> >>I thought we agreed, in Austin, that Held was not Active. >> >>Harry Lewis - IBM Printing Systems >> >> > > > > > > From hastings at cp10.es.xerox.com Mon Jun 9 11:32:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Problem with IMPLICIT for jmJobSubmissionID Message-ID: <9706091534.AA03782@zazen.cp10.es.xerox.com> Harry asked that I add IMPLICIT to the INDEX statement for the jmJobSubissionID. If we include IMPLICIT then it won't work with V1 SNMP. V1 doesn't have IMPLICIT. So instead I'll add a note that we are NOT using IMPLICIT in order to work with SNMP V1 as well as SNMP V2. That should make it clear that the extra octet is needed in the OID. Ok? Tom From harryl at us.ibm.com Mon Jun 9 13:07:28 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> documentFormatIndex Message-ID: <5030100003327735000002L052*@MHS> We have documentFormat as one of our Job Attributes. It points to prtInterpreterLanguageFamily TC in the printer MIB. I want to clarify that this job MIB Attribute may relate to a job control language as well as a page description language. Do you agree, Tom? Does anyone disagree? >>> Harry Lewis <<< From imcdonal at eso.mc.xerox.com Mon Jun 9 13:43:23 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> Fwd: MIB compiler sources (used by Tom Hastings) Message-ID: <9706091743.AA26864@snorkel.eso.mc.xerox.com> Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA26786; Mon, 9 Jun 97 12:40:35 EDT Received: from zazen.cp10.es.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA14877; Mon, 9 Jun 97 12:37:36 EDT Received: from cmqlite-6.cp10.es.xerox.com by zazen.cp10.es.xerox.com (4.1/SMI-4.1) id AA03824; Mon, 9 Jun 97 09:37:50 PDT Message-Id: <9706091637.AA03824@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Jun 1997 09:35:27 -0700 To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) From: Tom Hastings Subject: Re: MIB Compiler sources Status: R Ira, Thanks for all the good info. Ok if I forward to PMP and JMP lists? Or do you want to? Thanks, Tom At 17:06 06/06/97 EDT, you wrote: >Copies To: hastings@cp10.es.xerox.com, (Tom Hastings at Xerox) > bpenteco@boi.hp.com, (Bob Pentecost at HP) > xcmieditors@cp10.es.xerox.com > >Hi Tom and Bob, Friday (6 June 1997) > >Short answers on our MIB compiler sources: > >MOSY (from ISODE Consortium) >- comes with ISODE (ISO Development Environment) product distribution >- portable C source code >- free to academic users >- under license from ISODE Consortium to commercial users >- MOSY has been used for development by Fuji Xerox product teams > >Emissary (from Epilogue) >- comes with Epilogue's Envoy SNMP product distribution >- supports SNMPv2 Historic (RFC 144x) and SNMPv2 Community (RFC 190x) > in separate executables (Emissary 5.0 and Emissary 6.0) >- portable C source code (and some executables) >- under license from Epilogue to commercial users (usually royalties) >- Emissary has been used for development by Xerox product teams > >SMICng (by David Perkins) >- supports SNMPv2 Historic (RFC 144x) and SNMPv2 Community (RFC 190x) > in the same executable >- ported executables for all DOS, Windows, OS/2, and Unix systems >- Book Version (10/96) is free (on CD-ROM) w/ 'Understanding SNMP MIBs' > by David Perkins and Evan McGinnis, Prentice Hall (1996) >- Book Version update (02/97) is free to owners of 'Understanding...' > from SNMPinfo's home page >- Professional Version - under license from SNMPinfo to commercial users > >I use the updated SMICng Book Version (from the SNMPinfo Web page) and >and Emissary 5.0/6.0 (from Envoy 6.0/7.0 releases) MIB compilers daily >and thoroughly trust their combined error checking. > >Cheers, >- Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > >PS - The professional version of the SMICng distribution includes a >dandy MIB to HTML compiler which makes me want to talk Xerox into buying >a site license for this one, too. Epilogue also now has a MIB to HTML >compiler and Web Server product. The Emissary and SMICng compilers both >come with 'hand-edited' versions of ALL the 'standard' IETF MIBs (to >correct usage errors). Use with caution... > >PPS - The ubiquitous MIB-stripping utility for peeling MIBs loose from >the headers and footers of RFCs is 'mstrip' - part of SMICng stuff. > >>----------------------- Included Messages ----------------------------< > >>Date: Fri, 06 Jun 1997 08:41:04 -0700 >>To: xcmieditors@cp10.es.xerox.com >>From: Tom Hastings >>Subject: MIB Compilers >> >>I use SNICng, Epilogue, and MOSY, but I don't know where we got them. >> >>Can anyone help? >> >>This is a query from the HP representative on the PWG. Kind of scary >>that he is asking me. >> >>I'd like to help him out. >> >>The SNICng is availale with a book on SNMP, but I've forgotten the >>title and author. >> >>Tom >> >>Return-Path: >>From: Bob Pentecost >>To: "'Hastings, Tom (PWG)'" >>Subject: MIB Compilers >>Date: Thu, 5 Jun 1997 15:25:41 PDT >> >>Tom, >> >>You have made references to "compiling the MIB" and I'm wondering >which compiler(s) you use. Also, where do you get the compilers (buy >them or are they available off the web). >> >>Thanks. >> >>Bob > > From imcdonal at eso.mc.xerox.com Mon Jun 9 13:39:46 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> documentFormatIndex In-Reply-To: documentFormatIndex> Message-ID: <9706091739.AA26856@snorkel.eso.mc.xerox.com> Hi Harry and Tom, In describing its 'document-format' attribute, ISO DPA says, "This attribute identifies the overall print document format used for the document..." Although later examples all look like PDLs (Adobe Postscript, HP PCL, and Xerox Interpress), it never says this is JUST a PDL and not a JCL format. So, I agree with your clarification. Cheers, - Ira McDonald High North Inc From hastings at cp10.es.xerox.com Mon Jun 9 14:38:59 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> documentFormatIndex In-Reply-To: documentFormatIndex> Message-ID: <9706091841.AA03929@zazen.cp10.es.xerox.com> I would agree. The JMP documentFormatIndex is whatever the Printer MIB Index is, which includes control languages, as well as page description languages. The JMP value is the index into the Printer MIB. BTW, IPP is using the MIME type name as the value of its document-format attribute, not the PWG enums symbol names with the "lang" prefix removed. (At least the Model document says that the protocol is using the MIME types to identify document formats.). So I added the OCTETS form to the documentFormatType attribute (and removed the Type suffix) as we agreed for other attributes in San Diego that an agent can represent as an integer or a string or both. So an agent has a number of choices for representing the document format: 1. If implementing the Printer MIB, the agent can use the documentFormatIndex attribute with the same value as the Printer MIB. 2. Any agent can use the documentFormat attribute with either: the Printer MIB enum the MIME type name or both Ok? Tom At 10:07 06/09/97 PDT, Harry Lewis wrote: >We have documentFormat as one of our Job Attributes. It points to >prtInterpreterLanguageFamily TC in the printer MIB. I want to clarify that this >job MIB Attribute may relate to a job control language as well as a page >description language. Do you agree, Tom? Does anyone disagree? > >>>> Harry Lewis <<< > > From hastings at cp10.es.xerox.com Wed Jun 11 04:09:59 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Final IPP/JMP job-state and job-state-reasons Message-ID: <9706110812.AA04474@zazen.cp10.es.xerox.com> I've cross posted the final updates IPP and JMP job-state and job-state-reasons specifications with the final agreements reached on the June 6 telecon. I've incorporated the JMP specifications into the MIB. Scott will integrate the IPP specifications into the Model document. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 57826 Jun 11 07:45 jobstate.pdf -rw-r--r-- 1 pwg pwg 41694 Jun 11 07:45 jobstate.txt -rw-r--r-- 1 pwg pwg 92160 Jun 11 07:46 jobstatr.doc -rw-r--r-- 1 pwg pwg 109555 Jun 11 07:48 jobstatr.pdf -rw-r--r-- 1 pwg pwg 114072 Jun 11 07:49 jobstatr.pdr ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 57856 Jun 11 07:55 jobstate.doc -rw-r--r-- 1 pwg pwg 57826 Jun 11 07:55 jobstate.pdf -rw-r--r-- 1 pwg pwg 41694 Jun 11 07:56 jobstate.txt -rw-r--r-- 1 pwg pwg 92160 Jun 11 07:57 jobstatr.doc -rw-r--r-- 1 pwg pwg 109555 Jun 11 07:58 jobstatr.pdf -rw-r--r-- 1 pwg pwg 114072 Jun 11 07:59 jobstatr.pdr jobstatr.doc is the revision marks from the last Internet-Drafts of each. jobstatr.pdr is red revision marks jobstatr.pdf is black revision marks jobstate.doc is without revision marks jobstate.pdf is without revision marks Here is the beginning of the jobstate.doc file that list the changes: Subject: IPP and JMP agreements on job-state and job-state-reasons From: Tom Hastings Date: 6/6/97 File: jobstatr.doc (with revision marks) jobstate.doc (without revisions) This document is the final updated IPP "job-state" and "job-state-reasons" attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects from the IPP telecon, of Friday, June 6. 1. We agreed to the following states for IPP and JMP: IPP JMP other(1) 'unknown' unknown(2) 'pending' pending(3) 'pending-held' pendingHeld(4) 'processing' processing(5) 'processing-stopped' proessingStopped(6) 'canceled' canceled(7) 'aborted' aborted(8) 'completed' completed(9) 2. We agreed on the simplified job state transition diagram sentence at the end explaining the transitions into the canceled state that are not shown: For JMP: The following figure shows the normal job state transitions: +----> canceled(7) / +----> pending(3) ---------> processing(5) -------+------> completed(9) | ^ ^ \ --->+ | | +----> aborted(8) | v v / +----> pendingHeld(4) processingStopped(6) ----+ Figure 1 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the canceled state from the pending, pendingHeld, processing, and processingStopped states. Jobs in the pending, processing, and processingStopped states are called 'active', while jobs in the pendingHeld, canceled, aborted, and completed states are called 'in-active'." For IPP: The following figure shows the normal job state transitions: +--> canceled / +---> pending --------> processing ---------+-----> completed | ^ ^ \ --->+ | | +---> aborted | v v / +---> pending-held processing-stopped ----+ Figure 2 - Normal Job State Transitions Normally a job progresses only from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the 'canceled' state from the 'pending', 'pending-held', 'processing', and 'processing-stopped' states." 3. Conformance: we agreed that no job states are MANDATORY. For JMP the sentence proposed by Ron will be added: All possible enums for this object SHALL be reported if implemented by the device and available to the agent. The corresponding sentence for IPP will be: All possible job states SHALL be returned by the Printer object if implemented by the output device and available to the Printer object implementation. 4. We agreed to not specify which job state reasons go with which states. An implementation can use the reasons with any state for which the reason makes sense. The following JMP sentence will be included in the JmJobStateReasons1TC textual-convention: The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time. These values MAY be used with any job state for which the reason makes sense. The corresponding IPP "job-state-reasons" attribute sentence is: The following standard values are defined and MAY be used with any job state for which the reason makes sense. 5. We agreed that job-state-reasons are all OPTIONAL. The following JMP sentence will be included in the JmJobStateReasons1TC textual-convention: Implementation of these values is OPTIONAL, i.e., an agent NEED NOT implement them, even if the device supports the functionality represented by the reason and is available to the agent. The corresponding IPP "job-state-reasons" attribute sentence is: Implementation of these values is OPTIONAL, i.e., the Printer object NEED NOT return them, even if the output device supports the functionality represented by the reason and is available to the Printer object software. The following are the changes from the previous IPP and JMP published Internet-Draft specifications: 1. In JMP remove the 'printing' state. 2. Add the 'pending-held' and 'processing-stopped' states to IPP. 3. Rename the JMP 'held' state to 'pendingHeld' and rename the JMP state 'needsAttention' to 'processingStopped'. 4. In both IPP and JMP add the 'aborted' state and make it a final state. 5. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, since the new 'aborted' state says it all. 6. In IPP replace the 'terminating' state with the 'canceled' and 'aborted' states and make 'canceled' and 'aborted' final states, like the JMP 'canceled' and 'completed' states. 7. Since the pendingHeld state has been added, JMP no longer needs a generic jobHeld job state reason. 8. No job states are MANDATORY in IPP and JMP. However, those that are implemented in the device and are available to the Printer/agent shall be returned. 9. Job state reasons are OPTIONAL in IPP and JMP. From hastings at cp10.es.xerox.com Wed Jun 11 04:28:27 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Job Monitoring MIB V0.82 posted and sent as an I-D Message-ID: <9706110830.AA04487@zazen.cp10.es.xerox.com> I've posted an updated Job Monitoring MIB V0.82 with the agreements from San Diego and the recent telecons on jmJobState and jmJobStateReasons1. I've also sent it as our second Internet-Draft: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 117479 Jun 11 08:21 jmp-mib.mib -rw-r--r-- 1 pwg pwg 190215 Jun 11 08:23 jmp-mib.txt -rw-r--r-- 1 pwg pwg 424960 Jun 11 02:27 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 372625 Jun 11 02:28 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 374018 Jun 11 02:28 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 245741 Jun 11 02:28 jmp-mibv.pdf -rw-r--r-- 1 pwg pwg 7835 Jun 11 02:28 jmp.dic The jmp-mib.mib is the MIB that compiles (just BEGIN to END and no page numbers) The jmp-mib.txt is the Internet-Draft The jmp-mibr.doc is with revision marks. The jmp-mibr.pdf is with black revision marks The jmp-mibr.pdr is with red revision marks The jmp-mibv.pdf is variable pitch font without revision marks. Please make comments on the jmp-mibv.pdf using its line numbers. I'll update the change history tommorrow and post it separately. Here is the table of contents for the MIB specification part: 11. MIB SPECIFICATION 24 Textual conventions for this MIB module 26 JmTimeStampTC - simple time in seconds 26 JmJobSourcePlatformTypeTC - operating system platform definitions 26 JmFinishingTC - device finishing definitions 27 JmPrintQualityTC - print quality 28 JmPrinterResolutionTC - printer resolution 29 JmTonerEconomyTC - toner economy setting 30 JmMediumTypeTC - medium type definitions 30 JmJobStateTC - job state definitions 31 JmAttributeTypeTC - attribute type definitions 35 other 39 unknown 39 Job State attributes 39 jobStateReasons2 41 jobStateReasons3 41 jobStateReasons4 41 deviceAlertCode 41 processingMessage 42 Job Identification attributes 42 serverAssignedJobName 43 jobName 43 jobServiceTypes 43 jobOwner (MANDATORY) 42 jobAccountName 42 jobSourceChannelIndex 44 jobSourcePlatformType 44 submittingServerName 44 submittingApplicationName 45 jobOriginatingHost 45 deviceNameRequested 45 queueNameRequested 45 physicalDevice 45 numberOfDocuments 46 fileName 46 documentName 46 jobComment 46 documentFormatIndex 46 documentFormat 47 Job Parameter attributes 47 jobPriority 47 jobProcessAfterDateAndTime 48 jobHoldUntil 48 outputBin 48 sides 49 finishing 49 Image Quality attributes (requested and used) 49 printQualityRequested 49 printQualityUsed 49 printerResolutionRequested 49 printerResolutionUsed 49 tonerEcomonyRequested 49 tonerEcomonyUsed 49 tonerDensityRequested 50 tonerDensityUsed 50 Job Progress attributes (requested and consumed) 50 jobCopiesRequested 50 jobCopiesCompleted 50 documentCopiesRequested 50 documentCopiesCompleted 50 jobKOctetsTransferred 51 Impression attributes (requested and consumed) 53 impressionsSpooled 53 impressionsSentToDevice 53 impressionsInterpreted 53 impressionsCompletedCurrentCopy 53 fullColorImpressionsCompleted 54 highlightColorImpressionsCompleted 54 Page attributes (requested and consumed) 54 pagesRequested 54 pagesCompleted 54 pagesCompletedCurrentCopy 54 Sheet attributes (requested and consumed) 55 sheetsRequested 55 sheetsCompleted 55 sheetsCompletedCurrentCopy 55 Resource attributes (requested and consumed) 55 mediumRequested 55 mediumConsumedName 56 colorantRequested 56 colorantConsumed 56 Time attributes (set by server or device) 56 jobSubmissionToServerTime 57 jobSubmissionToDeviceTime 57 timeSinceJobWasSubmittedToDevice 57 jobStartedBeingHeldTimeStamp 57 jobStartedProcessingTime 57 timeSinceStartedProcessing 57 jobCompletedTime 58 timeSinceCompleted 58 jobProcessingCPUTime 58 JmJobServiceTypesTC - bit encoded job service type definitions 58 JmJobStateReasons1TC - additional information about job states 60 JmJobStateReasons2TC - More additional information about job states 64 JmJobStateReasons3TC - More additional information about job states 69 JmJobStateReasons4TC - More additional information about job states 70 The General Group (Mandatory) 73 jmGeneralNumberOfActiveJobs 73 jmGeneralOldestActiveJobIndex 74 jmGeneralNewestActiveJobIndex 74 jmGeneralJobPersistence 76 jmGeneralAttributePersistence 76 jmGeneralJobSetName 76 The Job ID Group (Mandatory) 77 jmJobSubmissionID 78 jmJobSetIndex 79 jmJobIndex 80 The Job Group (Mandatory) 80 jmJobState 81 jmJobStateReasons1 82 jmNumberOfInterveningJobs 83 jmJobKOctetsRequested 83 jmJobKOctetsProcessed 84 jmJobImpressionsRequested 85 jmJobImpressionsCompleted 85 The Attribute Group (Mandatory) 85 jmAttributeTypeIndex 87 jmAttributeInstanceIndex 88 jmAttributeValueAsInteger 88 jmAttributeValueAsOctets 89 From harryl at us.ibm.com Wed Jun 11 10:41:33 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Job Monitoring MIB V0.82 posted and sent as an I-D Message-ID: <5030100003414830000002L002*@MHS> Tom - thanks! This has been anxiously awaited. I will initiate a review immediately. >I've posted an updated Job Monitoring MIB V0.82 with the agreements >from San Diego and the recent telecons on jmJobState and jmJobStateReasons1. >>> Harry Lewis <<< From Angelo_Caruso at wb.xerox.com Wed Jun 11 12:00:07 1997 From: Angelo_Caruso at wb.xerox.com (Caruso,Angelo) Date: Wed May 6 14:00:07 2009 Subject: JMP> Final IPP/JMP job-state and job-state-reasons Message-ID: <5030100003414830000002L002*@MHS> Tom wrote: > 5. We agreed that job-state-reasons are all OPTIONAL. > > The following JMP sentence will be included in the JmJobStateReasons1TC > textual-convention: > > Implementation of these values is OPTIONAL, i.e., an agent NEED NOT > implement them, even if the device supports the functionality represented by > the reason and is available to the agent. The last part of the last sentence here, "i.e., an agent NEED NOT implement them, even if the device supports the functionality represented by the reason and is available to the agent", is pratically encouraging implementors NOT to implement the job state reasons. Why not just say "they're optional", PERIOD? I suggest the wording be shortened to, "Implementation of these values is OPTIONAL." for both JMP and IPP. Thanks, Angelo From don at lexmark.com Wed Jun 11 20:43:15 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:07 2009 Subject: JMP> August Printer Working Group Meetings Message-ID: <199706121548.AA27330@interlock2.lexmark.com> The August Printer Working Group meeting will be held at Microsoft in Redmond. The current schedule is as follows: August 4th, 5th 9AM - 6PM 1394 Printing Working Group August 6th, 7th 8:30 AM - 6PM IPP Work Group August 8th 8:30 AM - 6PM JMP, etc. as required Each of you is on your own for hotel reservations. Recommendations for hotels are as follows: Double Tree (was Red Lion) Bellvue 425-455-1300 Hyatt Bellvue 425-462-1234 Hilton Bellvue 425-455-3330 Ask for the Microsoft rate at these hotels. Maps, directions, buildings and rooms will be distributed in a later note. If you have any concerns about the above schedule (other than the times which are fixed by room availability at Microsoft) please let me know ASAP so people can make their travel plans. Thanks, Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From hastings at cp10.es.xerox.com Thu Jun 12 12:08:37 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: PWG> Proposed change to the June meeting schedule [JMP ALL In-Reply-To: Proposed change to the June meeting schedule [JMP ALL> Message-ID: <9706121611.AA05133@zazen.cp10.es.xerox.com> Jay, I talked with Ron Bergman and we agreed that JMP could use all of Friday, up to the usual closing time of 3:00pm EDT. Ron is travelling, so he wanted me to convey this message ASAP, since JMP participants may need to change their plane reservations. We see from Lloyd's response that PMP doesn't need any time Friday. We'd also like to keep Thursday evening as scheduled as well. The high level JMP agenda is: 1. Answer any issues that arise between now and the meeting. 2. Review the current draft (V0.82 = Internet-Draft 01) and resolve any issues. 3. Review mappings from each job submission protocol to the Job Monitoring MIB for that separate document that we'll produce as an informational RFC. The review of the mapping will also be helping us with the review of the MIB itself. I'm sure we'll get lots of "Oh, it that what that attribute means, we need to clarify ...". In effect, producing and reviewing the mappings from job submission protocols to the Job MIB will be like a "paper backoff". And I sure would like to clear up ambiguities BEFORE we publish the proposed standard, rather than AFTER. So we can sure use all the time. Thanks for your generosity in making it available, Tom and Ron At 13:04 06/09/97 PDT, JK Martin wrote: >Given the fact that both the Printer MIB (PMP) and Job Monitoring MIB >(JMP) projects are in the eleventh hour and are about to "finish", it >is probably in the best interests of the PWG to let those groups have >priority scheduling at the upcoming June meetings. > >Therefore (once again), I am willing to give up the Friday meeting >slot time for SENSE so that these groups have a chance to actually >complete their work at these meetings. > >Given the large amount of finalization needed for the Job MIB, it >could be that the JMP group needs BOTH the Thursday nite meeting >slot IN ADDITION TO a Friday slot. > >As I recall, the PMP group is in much better shape, but it could be >that at least 2 hours are needed for this group's final effort. > >Ron Bergman (JMP chair) and Lloyd Young (PMP chair): would you two >please comment on this rescheduling opportunity, stating what your >requirements are? Please respond as soon as possible, as a change >in scheduling (either duration or start-time) may affect some >participants' travel plans. > >If we can squeeze an evening discussion about SENSE into the mix, >then great. But the JMP and PMP groups really need focus right >now, so let's give it to them. (pun intended... ;-) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > At 14:57 06/09/97 PDT, lpyoung@lexmark.com wrote: > >Jay, >Thanks for thinking of us but the Printer MIB does not need any time >on the agenda for the June meeting. Everything that is left to be >resolved can be resolved via the mailing list. >Lloyd Young > > > > From hastings at cp10.es.xerox.com Thu Jun 12 14:27:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> PWG> I-D ACTION:draft-ietf-printmib-job-monitor-01.txt Message-ID: <9706121829.AA05192@zazen.cp10.es.xerox.com> >Return-Path: >To: IETF-Announce@ietf.org >Cc: pwg@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-01.txt >Date: Thu, 12 Jun 1997 06:33:43 PDT >Sender: owner-pwg@pwg.org > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Printer MIB Working Group of > the IETF. > > Title : Job Monitoring MIB - V0.82 > Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis > Filename : draft-ietf-printmib-job-monitor-01.txt > Pages : 92 > Date : 06/11/1997 > >This Internet-Draft specifies a set of 17 SNMP MIB objects for (1) >monitoring the status and progress of print jobs (2) obtaining resource >requirements before a job is processed, (3) monitoring resource consumption >while a job is being processed and (4) collecting resource accounting data >after the completion of a job. This MIB is intended to be implemented (1) >in a printer or (2) in a server that supports one or more printers. Use of >the object set is not limited to printing. However, support for services >other than printing is outside the scope of this Job Monitoring MIB. >Future extensions to this MIB may include, but are not limited to, fax >machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-01.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-01.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. >Content-Type: text/plain >Content-ID: <19970611105831.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-01.txt >Content-Type: text/plain >Content-ID: <19970611105831.I-D@ietf.org> > From hastings at cp10.es.xerox.com Fri Jun 13 13:04:20 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> ACTION: Please do protocol mapping as part of your JMP review Message-ID: <9706131706.AA05755@zazen.cp10.es.xerox.com> Its time to do the job submission protocol mapping to the JMP Job Monitoring MIB spec as part of the review of the MIB. Please do this before the upcoming meeting, so that we can review the mappings as part of the JMP review. This is a "paper bake off". I've put a new template into: ftp::/ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 46592 Jun 13 16:43 jmtmplt2.doc The following people have been assigned to do the mappings. If you cannot do your assignment, please respond to me with a substitute name. Job Submission file name Responsible person Protocol AppleTalk PAP applepap.doc Ron Bergman IPDS ipds.doc Harry Lewis ISO DPA iso-dpa.doc Tom Hastings LPR/LPD lpr-lpd.doc Ron Bergman NDPS ndps.doc Scott Isaacson PJL pjl.doc Bob Pennacost PostScript ps.doc Bob Setterbo PSERVER pserver.doc Scott Isaacson RPRINTER rprinter.doc Scott Isaacson SMB smb.doc Bob Setterbo TIPSI/NPAP tipsi.doc Don Wright I've put each object and attribute from the Table of contents into the template, along with the page number from the jmp-mibv.pdf version (0.82 that corresonds to the Internet-Draft 01) which is the file you should be using. So get out the template, look at the page number and read the MIB spec to see if that attribute or object is settable or queriable in your job submission protocol. Put the name of the attribute in your protocol next to the JMP object or attribute. Put any comments, questions, data conversion, issues in the Notes column. I've listed each of the jobState and jobStateReasons1 values as well. Thanks, Tom Here are the detaile instructions from the template: 1. Copy jmtmplt2.doc from ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmtmplt1.doc. 2. Fill in the first five lines of information about your job submission protocol immediately after the "cut here" line. 3. Delete the template before and including the "cut here". 4. Please go read each attribute, so that you are sure that the mapping is correct and to be part of the review process on the MIB itself. The page numbers correspond to the line numbered version with variable pitch font (jmp-mibv.pdf, V0.82), which is the one we should be using for review. If you find a description that is unclear or ambiguous, please make a note and send as e-mail or enter it in the Notes column here. We need to fix ambiguities now, not after we are a proposed standard. 5. Edit in the name of each of the job submission protocol attributes that corresponds to each of the object/attribute in the table below. For the attributes that are read-only in your job submission protocol, such as jmGeneralNumberOfActiveJobs, jobState, and pagesConsumed, enter the name of the attribute in your job submission protocol, if it is querable with your job submission protocol, otherwise leave blank. 6. For objects/attributes that do not have a corresponding attribute in your job submission protocol, please leave blank. 7. If you aren't sure whether the job attribute you found is correct, put a question mark after the name of your job submission protocol attribute. 8. Add any notes to the last column labeled NOTES. 9. Rename your file to the xxx.doc file name indicated below for your job submission protocol. 10. Post your file in: ftp://ftp.external.hp.com/snmpmib/jobs-mib/protomap/xxx.doc 11. Send mail to the jmp list indicating that you have posted your mapping. From jkm at underscore.com Mon Jun 16 13:36:19 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Please RSVP to the June Meetings if you have not already done so Message-ID: <199706161736.NAA04481@uscore.underscore.com> [Sorry for the cross-posting, but this message must get out to *everyone* as soon as possible...] The hotel is asking that we have a firm attendance count by Wednesday, June 18 (that is, the day after tomorrow) for the series of PWG meetings to be held Monday thru Friday, June 23-27 (ie, NEXT WEEK). If you have not already sent me a message with the dates of the meetings you plan to attend--OR IF YOU HAVE CHANGED YOUR PLANS since sending me a message--then please send me (jkm@underscore.com) a message BEFORE NOON EDT on Wednesday, June 18. Following are the lists of people who claim to be attending the various PWG meetings scheduled for next week. If you have already sent an RSVP (aka "ping") message, then please be sure your name is listed under the appropriate meeting(s): P1394 (Monday-Tuesday, June 23-24) Alan Berkema Brian Batchelder Danny Mitchell Don Wright Frank Zhao Fumio Nagasaka Greg LeClair Hamid Shenavai Jeff Rackowitz Larry Stein Richard Andrade Shigeru Ueda IPP (Wednesday-Thursday, June 25-26) Angelo Caruso Bob Pentecost Carl-Uno Manros Charles Gordon Chuck Adams Don Wright Frank Zhao Greg LeClair (Wed only) Jasper Wong Jay Martin Jeff Copeland Jeff Rackowitz Lloyd Young (Thurs only) Richard Landau Richard Schneider Robert Herriot Scott Isaacson Shigeru Ueda Stuart Rowley Tom Hastings JMP (Thursday nite, Friday, June 26-27) Angelo Caruso Bob Pentecost Chuck Adams Don Wright Jeff Rackowitz Lloyd Young Richard Landau Stuart Rowley Tom Hastings Folks, we really need to have ACCURATE counts of attendees, so if you're planning to attend one or more of next week's meetings, then by all means please send me a message NOW if you haven't already done so. Similarly, if your plans have changed such that you will not be attending one or more meetings (or if I have you down for the wrong meetings), please let me know ASAP. Thanks for your cooperation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From hastings at cp10.es.xerox.com Mon Jun 16 19:30:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comparison of JMP and IPP and some issues for each Message-ID: <9706162332.AA06344@zazen.cp10.es.xerox.com> I added the mapping of the IPP subsubmissionn protocol to the JMP Job Monitoring MIB as an assignment and did that one first. I've posted the comparison of the JMP Job Monitoring MIB (6/9/97, V0.82) with IPP 6/3/97 at: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 28160 Jun 16 23:28 ietf-ipp.doc -rw-r--r-- 1 pwg pwg 37229 Jun 16 23:24 ietf-ipp.pdf There are several issues, some for IPP and some for JMP. They are indicated in the NOTES column of the comparison. I've also included them in the e-mail message. The first column in the JMP object or attribute, the second column in the page number in the JMP V0.82 jmp-mibv.pdf, the third column is the IPP attribute and the fourth column is the issue. 1. jmGeneralNumberOfActiveJobs 57 queued-job-count IPP ISSUE: Should/does "queued-job-count" include pendingHeld or not? I suggest that, like JMP, the attribute NOT include jobs in the 'pending-held' state, since they are unlikely to be processed soon. The purpose of the attribute should be to show how busy the Printer is, not how may jobs are queued. In fact a Printer that is processing a job should have a different count than a Printer that is idle. So lets rename the IPP attribute to agree with JMP: "number-of-active-jobs" and define it to include jobs in the 'pending', 'processing', and 'processing-stopped' states (but not in the 'pending-held', 'canceled', 'aborted', and 'completed' states). 2. jmJobSetIndex 61 job-URI? The JMP agent MAY need to convert from a URI to a jmJobSetIndex. JMP ISSUE: should we add a jobIdentifier attribute to the attribute table that is the job submissio procotol format for a job identifer assigned by the server or device that accepts jobs? I suggest yes. 3. numberOfDocuments 39 IPP ISSUE: should have read-only "number-of-documents" set by Printer. 4. fileName 39 document-URI JMP ISSUE: clarify that the fileName attribute could be a URI 5. There are three JMP attributes that have enums for which IPP has keywords. While the mapping is one-to-one, should we also allow the JMP agent to return the Octets text representation? The three attributes are: finishing 41 finishings same values, but map IPP keywords to JMP enums. Both can be MULTI-VALUED JMP ISSUE: also allow Octets as supplement? printQualityRequested 42 print-quality same values, but map IPP keywords to JMP enums JMP ISSUE: also allow Octets as supplement? printerResolutionRequested 42 printer-resolution same values, but map IPP keywords to JMP enums JMP ISSUE: also allow Octets as supplement? I suggest yes. Also allow just the octets when the enum isn't known to the agent. 6. timeSinceJobWasSubmittedToDevice 47 time-since-submission JMP ISSUE: Should timeSinceJobWasSubmittedToDevice be seconds or like IPP milliseconds? I suggest we use milliseconds, like IPP From hastings at cp10.es.xerox.com Wed Jun 18 03:43:08 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Any comments on: Job Monitoring MIB V0.82 posted and sent as Message-ID: <9706180745.AA06666@zazen.cp10.es.xerox.com> Its awful quiet out there. Any comments on the MIB? Thanks, Tom >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Wed, 11 Jun 1997 01:28:27 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> Job Monitoring MIB V0.82 posted and sent as an I-D >Sender: jmp-owner@pwg.org > > >I've posted an updated Job Monitoring MIB V0.82 with the agreements >from San Diego and the recent telecons on jmJobState and jmJobStateReasons1. > >I've also sent it as our second Internet-Draft: > > >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ >-rw-r--r-- 1 pwg pwg 117479 Jun 11 08:21 jmp-mib.mib >-rw-r--r-- 1 pwg pwg 190215 Jun 11 08:23 jmp-mib.txt >-rw-r--r-- 1 pwg pwg 424960 Jun 11 02:27 jmp-mibr.doc >-rw-r--r-- 1 pwg pwg 372625 Jun 11 02:28 jmp-mibr.pdf >-rw-r--r-- 1 pwg pwg 374018 Jun 11 02:28 jmp-mibr.pdr >-rw-r--r-- 1 pwg pwg 245741 Jun 11 02:28 jmp-mibv.pdf >-rw-r--r-- 1 pwg pwg 7835 Jun 11 02:28 jmp.dic > >The jmp-mib.mib is the MIB that compiles (just BEGIN to END and no page numbers) >The jmp-mib.txt is the Internet-Draft >The jmp-mibr.doc is with revision marks. >The jmp-mibr.pdf is with black revision marks >The jmp-mibr.pdr is with red revision marks >The jmp-mibv.pdf is variable pitch font without revision marks. > >Please make comments on the jmp-mibv.pdf using its line numbers. > >I'll update the change history tommorrow and post it separately. > >Here is the table of contents for the MIB specification part: > >11. MIB SPECIFICATION 24 >Textual conventions for this MIB module 26 >JmTimeStampTC - simple time in seconds 26 >JmJobSourcePlatformTypeTC - operating system platform definitions 26 >JmFinishingTC - device finishing definitions 27 >JmPrintQualityTC - print quality 28 >JmPrinterResolutionTC - printer resolution 29 >JmTonerEconomyTC - toner economy setting 30 >JmMediumTypeTC - medium type definitions 30 >JmJobStateTC - job state definitions 31 > >JmAttributeTypeTC - attribute type definitions 35 >other 39 >unknown 39 >Job State attributes 39 >jobStateReasons2 41 >jobStateReasons3 41 >jobStateReasons4 41 >deviceAlertCode 41 >processingMessage 42 >Job Identification attributes 42 >serverAssignedJobName 43 >jobName 43 >jobServiceTypes 43 >jobOwner (MANDATORY) 42 >jobAccountName 42 >jobSourceChannelIndex 44 >jobSourcePlatformType 44 >submittingServerName 44 >submittingApplicationName 45 >jobOriginatingHost 45 >deviceNameRequested 45 >queueNameRequested 45 >physicalDevice 45 >numberOfDocuments 46 >fileName 46 >documentName 46 >jobComment 46 >documentFormatIndex 46 >documentFormat 47 >Job Parameter attributes 47 >jobPriority 47 >jobProcessAfterDateAndTime 48 >jobHoldUntil 48 >outputBin 48 >sides 49 >finishing 49 >Image Quality attributes (requested and used) 49 >printQualityRequested 49 >printQualityUsed 49 >printerResolutionRequested 49 >printerResolutionUsed 49 >tonerEcomonyRequested 49 >tonerEcomonyUsed 49 >tonerDensityRequested 50 >tonerDensityUsed 50 >Job Progress attributes (requested and consumed) 50 >jobCopiesRequested 50 >jobCopiesCompleted 50 >documentCopiesRequested 50 >documentCopiesCompleted 50 >jobKOctetsTransferred 51 >Impression attributes (requested and consumed) 53 >impressionsSpooled 53 >impressionsSentToDevice 53 >impressionsInterpreted 53 >impressionsCompletedCurrentCopy 53 >fullColorImpressionsCompleted 54 >highlightColorImpressionsCompleted 54 >Page attributes (requested and consumed) 54 >pagesRequested 54 >pagesCompleted 54 >pagesCompletedCurrentCopy 54 >Sheet attributes (requested and consumed) 55 >sheetsRequested 55 >sheetsCompleted 55 >sheetsCompletedCurrentCopy 55 >Resource attributes (requested and consumed) 55 >mediumRequested 55 >mediumConsumedName 56 >colorantRequested 56 >colorantConsumed 56 >Time attributes (set by server or device) 56 >jobSubmissionToServerTime 57 >jobSubmissionToDeviceTime 57 >timeSinceJobWasSubmittedToDevice 57 >jobStartedBeingHeldTimeStamp 57 >jobStartedProcessingTime 57 >timeSinceStartedProcessing 57 >jobCompletedTime 58 >timeSinceCompleted 58 >jobProcessingCPUTime 58 > >JmJobServiceTypesTC - bit encoded job service type definitions 58 >JmJobStateReasons1TC - additional information about job states 60 >JmJobStateReasons2TC - More additional information about job states 64 >JmJobStateReasons3TC - More additional information about job states 69 >JmJobStateReasons4TC - More additional information about job states 70 > >The General Group (Mandatory) 73 >jmGeneralNumberOfActiveJobs 73 >jmGeneralOldestActiveJobIndex 74 >jmGeneralNewestActiveJobIndex 74 >jmGeneralJobPersistence 76 >jmGeneralAttributePersistence 76 >jmGeneralJobSetName 76 > >The Job ID Group (Mandatory) 77 >jmJobSubmissionID 78 >jmJobSetIndex 79 >jmJobIndex 80 > >The Job Group (Mandatory) 80 >jmJobState 81 >jmJobStateReasons1 82 >jmNumberOfInterveningJobs 83 >jmJobKOctetsRequested 83 >jmJobKOctetsProcessed 84 >jmJobImpressionsRequested 85 >jmJobImpressionsCompleted 85 > >The Attribute Group (Mandatory) 85 >jmAttributeTypeIndex 87 >jmAttributeInstanceIndex 88 >jmAttributeValueAsInteger 88 >jmAttributeValueAsOctets 89 > > > From hastings at cp10.es.xerox.com Thu Jun 19 03:40:57 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Re: Any comments on: Job Monitoring MIB V0.82 posted and sent In-Reply-To: Message-ID: <9706190743.AA07084@zazen.cp10.es.xerox.com> By the way, a really good way to review the Job Monitoring MIB is to do the mapping from each Job Monitoring MIB object/attribute to your favorite (or assigned) job submission protocol. In other words, pretend you are an agent and need to respond to a Get for each of the Job Mononitoring MIB objects and attributes and compare the MIB description with your job submission protocol attribute. I've put the page numbers of each attribute and object in the template file, and they are in order of the document: ftp::/ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 46592 Jun 13 16:43 jmtmplt2.doc Thanks, Tom At 00:43 06/18/97 PDT, you wrote: >Its awful quiet out there. Any comments on the MIB? > >Thanks, >Tom > >>Return-Path: >>X-Sender: hastings@zazen (Unverified) >>Date: Wed, 11 Jun 1997 01:28:27 PDT >>To: jmp@pwg.org >>From: Tom Hastings >>Subject: JMP> Job Monitoring MIB V0.82 posted and sent as an I-D >>Sender: jmp-owner@pwg.org >> >> >>I've posted an updated Job Monitoring MIB V0.82 with the agreements >>from San Diego and the recent telecons on jmJobState and jmJobStateReasons1. >> >>I've also sent it as our second Internet-Draft: >> >> >>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ >>-rw-r--r-- 1 pwg pwg 117479 Jun 11 08:21 jmp-mib.mib >>-rw-r--r-- 1 pwg pwg 190215 Jun 11 08:23 jmp-mib.txt >>-rw-r--r-- 1 pwg pwg 424960 Jun 11 02:27 jmp-mibr.doc >>-rw-r--r-- 1 pwg pwg 372625 Jun 11 02:28 jmp-mibr.pdf >>-rw-r--r-- 1 pwg pwg 374018 Jun 11 02:28 jmp-mibr.pdr >>-rw-r--r-- 1 pwg pwg 245741 Jun 11 02:28 jmp-mibv.pdf >>-rw-r--r-- 1 pwg pwg 7835 Jun 11 02:28 jmp.dic >> >>The jmp-mib.mib is the MIB that compiles (just BEGIN to END and no page >numbers) >>The jmp-mib.txt is the Internet-Draft >>The jmp-mibr.doc is with revision marks. >>The jmp-mibr.pdf is with black revision marks >>The jmp-mibr.pdr is with red revision marks >>The jmp-mibv.pdf is variable pitch font without revision marks. >> >>Please make comments on the jmp-mibv.pdf using its line numbers. >> >>I'll update the change history tommorrow and post it separately. >> snip... From hastings at cp10.es.xerox.com Thu Jun 19 17:57:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers Message-ID: <9706192159.AA00527@zazen.cp10.es.xerox.com> The following comments are from an internal review at Xerox of the Job Monitoring MIB, V0.82. I started numbering these issues starting with the next free issue in issues.doc. ISSUE 88 - Add jmGeneralNumberOfJobsProcessed object since server or printer was booted? Most MIBs have some sort of utlization counter. The Job Monitoring MIB should have one also. Add the object to the jmGeneralTable. We assume that this object SHALL NOT be persistent across power cycles. The DESCRIPTION is proposed to be: jmGeneralNumberOfJobsProcessed OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of jobs that have completed processing for this job set since the server or device was powered on." ::= { jmGeneralEntry 7 } ISSUE 89 - Add jmGeneralAttributesImplemented object with bits for each attribute implemented? Instead of an application not knowing which attributes an implementation implements and trying to discover by getting errors, or by always using Get Next, instead of Get, how about adding a jmGeneralAttributesImplemented object to the jmGeneralTable that has a bit for each attribute implemented. jmGeneralAttributesImplemented OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit string indicating which JmAttributeTypeTC enum values are implemented. The value is a constant independent of which bits are currenly in entries in the jmAttributeTable. The most significant bit of the first octet is assigned the value 0 to correspond to enum 0 (not used), the next most significant bit of the first octet is assigned the value 1 to correspond to enum 1 (other), the next bit is assigned the value 2 (unknown), 3 (jobStateReasons2) etc. up to 32*8 - 1 = 255" ::= { jmGeneralEntry 8 } ISSUE 90 - The (MANDATORY) OCTET STRING objects should have a minimum MAX size required Otherwise, trivial implementations can implement too short sizes and be conforming. The SNMP conformance syntax as the end of the MIB has provision for specifying the minimum maximum that SHALL be implemented. The 63 in OCTET STRING(SIZE(0..63)) is the maximum size and the 0 is the minimum size for an instance returned on a Get operation. The (MANDATORY) OCTET STRING objects are with suggested MAX size required: jmGeneralJobSetName 8 octets required to be implemented jmJobSubmissionID 32 octets required to be implemented ISSUE 91 - The MANDATORY jobOwner attribute should have a minimum MAX size required Otherwise, trivial implementations can implement too short sizes and be conforming. We suggest that 16 octets of the maximum 63 be required to be implemented. Such a maximum will also help with the next issue. ISSUE 92 - The MANDATORY jobOwner attribute needs to persist as long as there is job data 92a: The MANDATORY jobOwner attribute needs to persist as long as there is job data. Otherwise, a client that does not have access to the jobSubmissionID or a system that does not have a jobSubmissionID cannot identify the jobs in the jmJobTable, after the agent removes the job's attributes from the jmAttributeTable. 92b: If it is agreed that the MANDATORY jobOwner SHALL persist for the longer period of time, then it should be moved to the jmJobTable, where all the other MANDATORY attributes have been made objects. 92c: Then the jmAttributeTable could be made OPTIONAL, so that really low end printers would not need to implement the jmAttributeTable at all. Experience at Xerox with low end non-queuing printers suggests that not requiring the jmAttributeTable is a win. With a required maximum of only 20 octets (see previous issue), it is reasonable to move the jobOwner to the MANDATORY jmJobTable. ISSUE 93 - The jobName and jobSubmission[ToDevice]Time should be MANDATORY 93a: The windows queue monitoring show three attributes: jobOwner, jobName, and start time. In IPP, jobName is a MANDATORY attribute. In order to work for all configurations, the jobSubmissionToDeviceTime should be changed to jobSubmissionTime and be used for all three configurations: configuration 1: device, configuration 2: server, and configuration 3: device. The jobSubmissionToServerTime shall only be used in configuration 3, where jobSubmissionTime is also used (for the device). Then jobSubmissionTime can be made MANDATORY (since it can be used in all three configurations). 93b: If the jobName attribute is made MANDATORY then it should have a minimum maximum value specified for conformance. We suggest that 12 octets is sufficient. 93c: If jobName and jobSubmissionTime are made MANDATORY, then they should be moved to the jmJobTable as well, so that the jmAttributeTable can remain OPTIONAL (see previous issue). ISSUE 94 - Are the 8 octet fields in the jobSubmisionID printable or binary? The text says "8-decimal-digits". Could it be allowed to be a binary sequence number or random number? Then the chances of collision are even lower. ISSUE 95 - When reducing the size of the jobSubmissionID field from 2 to 1, the other fields weren't increased by 1. ISSUE 96 - Add a jobSubmissionID format for jobOwner The first octet would be an ASCII '4'. The next 8 would be a sequential number, and the remaining 23 octets would be the low order 23 octets of the jobOwner. ISSUE 97 - Add some jobSubmissionID formats for numeric identifiers 97a - Add one for POSIX user numbers 97b - Add one for user account numbers 97c - Add one for DTMF incoming FAX routing number ISSUE 98 - The sequence number and random number in the jmJobSubmissionID should be the least significant field, not the most significant field Then a requester can leave off the sequential number or random number in a GetNext and find all of the jobs from a particular MAC address or client URL (or for a particular jobOwner). In order to make this switch, we need to specify that when the MAC address, client URL, (jobOwner, or numberic id) is shorter than 23 octets, that the field is shortened, rather than being padded out to 23 octets. The least significant field is always 8 octets with leading zeroes, so that we don't need any delimiters between the two fields. So the spec would become: Format Number Description ------ ------------ 1 octets 2 to n: upto last 23 bytes of the jobName attribute; n < 26 octets n to n+7: 8-decimal-digit random number 2 octets 2 to n: Client MAC address; n < 26 octets n to n+7: 8-decimal-digit sequential number 3 octets 2 to n: last 23 bytes of the client URL; n < 26 octets n to n+7: 8-decimal-digit sequential number .. to be registered according to procedures of a type 2 enum. See section 7.3 on page 22. ISSUE 99 - The jobSubmisionID format '0' makes no sense 98a: There are two interpretations of the text there: 1. The agent only puts a single digit of '0' for the entire jobSubmissionID index - but each subsequent submission would replace the entry. 2. The agent tacks on whatever it wants after the '0' to make a unique jobSubmissionID index for each job. 98b: If interpretation 2 is correct, then could we require the agent to use the jobOwner instead, rather than leaving it unspecified how the agent fills in the entry if interpretation is correct? ISSUE 100 - The jobSubmissionIDTable should have jmJobSet and jmJobIndex as indexes The current formats will have collisions of jobSubmissionIDs occasionally. The statement on lines 1695-1697: "None-the-less, collisions could occur, but without bas consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them." is incorrect, since future IETF and priviate MIBs are likely to have 'missles', not 'cameras'. We've had experience with a table like this (jobClientIdTable) for a year and a half and we added the jmJobIndex equivalent to the row entry that the agent adds to make sure that no entry ever gets overwritten. So we propose that the jmJobSet object and the jmJobIndex objects be added as the least significant indexes to the jmJobSubmissionIDTable. They are only simple integers and jmJobSet is likely to be 1 in most implementations. ISSUE 101 - add jobSubmissionID as an attribute, so can find the ID when scanning a job or attribute table. An accounting program that wants to find the jobSubmissionID would have to scan the entire jmJobSubmissionIDTable ISSUE 102 - Make a TC out of the jobSubmissionID formats, so can publish new ones more easily? ISSUE 103 - Specify a minimum required persistence time for jmGeneralAttributePersistence Put the lower bound right in the ASN.1. We suggest 60 seconds as a minimum with a recommendation of 300 (5 minutes). Even add a DEFVAL of 300 as the default. The real low cost device that doesn't want to keep job information around will have a small number of jobs anyway, since how many jobs can just a device process in a minute anyway? The spec would become: SYNTAX Integer32(60..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time in seconds for this instance of the Job Set that an entry will remain in the jmAttributeTable after processing has completed , i.e., the time in seconds starting when the job enters the completed, canceled, or aborted state. The value of this object MAY be either (1) set by the system administrator by means outside this specification or MAY be (2) fixed by the implementation, depending on implementation. This value SHALL be equal to or less than the value of jmGeneralJobPersistence. This value SHOULD be at least 300 which gives a monitoring application five minutes in which to poll for job data." DEFVAL { 300 } -- 5 minutes ::= { jmGeneralEntry 5 } From harryl at us.ibm.com Thu Jun 19 19:50:49 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Job MIB comments Message-ID: <5030100003751163000002L032*@MHS> Tom, thanks for getting the v0.82 draft out. Here are my comments on the PDF version. 1. deviceAlertCode (6) needs pointer to SNMP alert table - See pg. 36. When the device is a printer, the alert code SHALL be the printer alert code. This is the current definition. But, this is not very effective when genericAlertCodes are used. An index into the alert table would provide more information (rather than just JAM, you'd know jam in Input 3, for example). Maybe this is too much info for job monitoring? But it's just as easy for the agent. 2. deviceAlertCode (6) is may be multivalued - See pg. 36. More than one alert may be in effect. Do we need to clarify that this attribute can be multi row? 3. What happened to serverAssignedJobNumber (2x) - See pg. 37 We used to have serverAssignedJobNumber, with syntax integer. I think we combined this with serverAssignedJobName (22) and dropped it, but in so doing, it is not listed as Octets (only). What about the original concern that (OS/2 and perhaps other) some os's use an integer not a text string. Are we saying the integer must be converted to text? 4. Persistence of serverAssignedJobName - See pgs. 36, 37 Two other attributes (jobOwner and jobName) mandate "long" persistence. If you read the note under serverAssignedJobName, it leads in with the same reasoning, but stops short of requiring "long" persistence. Which persistence value is serverAssignedJobName intended to follow? (Aside... this leads to another whole question about persistence of tables vs. persistence of specific attributes or objects and whether or not the 3 objects above should just be added to the job state table. Separate topic but probably needs further discussion). 5. jobProcessAfterDateAndTime (51) - Octets vs Integer - See pg. 40-41 Shouldn't this be Octets, not Integer? 6. Eliminate "timeSince" Attributes - See pg. 47 This is too much work for the agent and is contrary to SNMP in that sysUpTime should do the trick. I don't mind using a JmTimeStampTC rather than sysUpTime so much, but the NMS, not the agent, should calculate the times since. I believe time can be synchronized by allowing jobSubmissionToDeviceTime to be multivalued - one DateAndTime passed in on submission and one jmTimeStampTC stamped by the printer. 7. IMPLIED/IMPLICIT - See pg. 61 The note reads "an IMPLICIT statement is NOT provided in the following INDEX clause, since it was not an SMIv2 feature. Therefore, the extra ASN.1 tag SHALL be included in the varbind in the SNMP request and the response." First, we think the terminology is IMPLIED, not IMPLICIT. Also, we think the IMPLIED statement SHOULD (SHALL?;-) be included because it saves a byte on each varbind. If you left this out because it is not part of v1 (as stated) I think there are other examples (like DateAndTime) where you are using v2 constructs. 8. "Requested Attribute" defaults For requested attributes like copies, toner, quality etc. what if the requested value is not passed in? Should the agent use the device default? 9. Misc editorial We noticed, in the text version, jobHoldUnitl is in the TOC twice. In the text and PDF versions jobHold is missing. >>> Harry Lewis <<< From imcdonal at eso.mc.xerox.com Thu Jun 19 21:40:38 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> Job MIB comments [from Harry Lewis] In-Reply-To: Job MIB comments [from Harry Lewis]> Message-ID: <9706200140.AA03417@snorkel.eso.mc.xerox.com> Hi Harry and Tom, Thursday (19 June 1997) Per Tom's request (below), I am replying to Harry's remarks about 'IMPLIED' and 'DateAndTime'. Harry's argument is flawed for several reasons. 'DateAndTime' is NOT an SMIv2 construct - it was borrowed in SNMPv2-TC (RFC 1903) from the SMIv1-based HR MIB (RFC 1514) - it is used in other existing SMIv1 MIBs. I believe that it is CRITICAL to keep the IETF Job Mon and Printer MIBs free from SMIv2 types or constructs which CANNOT be translated to SMIv1 (and thus cannot be supported via an SNMPv2/SNMPv1 Proxy agent or a native SNMPv1 device). The IMPLIED keyword CANNOT be translated to SMIv1 (you can't write SMIv1 ASN.1 that will translate to the same over-the-wire encoding). Why are we even considering such a construct to save ONE byte on each LONG object instance identifier. This is misguided. Sorry for the fuss, Harry, but I think you're missing something pretty important here. Specifically, we chose NOT to use the SMIv2 'BITS' type (for the state reasons flags) because it CANNOT be translated to SMIv1. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc >--------------- Tom's and Harry's notes -------------------------------< >Date: Thu, 19 Jun 1997 17:43:08 -0700 >From: Tom Hastings >Subject: JMP> Job MIB comments [from Harry Lewis] > >Here are Harry Lewis's comments. > >Ira, > >Could you respond to Harry and JMP about his issue over IMPLIED >and DateAndTime? > >>7. IMPLIED/IMPLICIT - See pg. 61 >> >>The note reads "an IMPLICIT statement is NOT provided in the following INDEX >>clause, since it >>was not an SMIv2 feature. Therefore, the extra ASN.1 tag SHALL be included in >>the varbind >>in the SNMP request and the response." >> >>First, we think the terminology is IMPLIED, not IMPLICIT. > >Agreed. The NOTE should say IMPLIED, not IMPLICIT. (IMPLICIT is what >ASN.1 uses for the same concept. SNMP uses IMPLIED). > >>Also, we think the IMPLIED statement >>SHOULD (SHALL?;-) be included because it saves a byte on each varbind. If you >>left this >>out because it is not part of v1 (as stated) I think there are other examples >>(like DateAndTime) >>where you are using v2 constructs. >> >>>>> Harry Lewis <<< > >Thanks, >Tom From hastings at cp10.es.xerox.com Thu Jun 19 21:41:58 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Job MIB comments In-Reply-To: Job MIB comments> Message-ID: <9706200144.AA00679@zazen.cp10.es.xerox.com> Harry, Thanks for your comments. I've listed the ones that should be issues to be covered at the meeting next week. Thanks, Tom At 16:50 06/19/97 PDT, Harry Lewis wrote: >Tom, thanks for getting the v0.82 draft out. Here are my comments on the PDF >version. > >1. deviceAlertCode (6) needs pointer to SNMP alert table - See pg. 36. > >When the device is a printer, the alert code SHALL be the printer alert code. >This is the current definition. But, this is not very effective when >genericAlertCodes are used. An index into the >alert table would provide more information (rather than just JAM, you'd know >jam in Input 3, for >example). Maybe this is too much info for job monitoring? But it's just as >easy for the agent. I agree we should add an attribute which is an index into the Printer MIB alert table. Leaving the deviceAlertCode(6) provides for a server (configuration 2) to put something about the printer, ok? ISSUE 104: Add deviceAlertIndex attribute which is index into alert table? Proposed new attribute: deviceAlertIndex(8) -- Integer32(0..2147483647) -- INTEGER: MULTI-ROW: The device alert table index for the device that -- the job is using. When the device is a printer, this index SHALL be the -- index into the prtAlertTable defined by the Printer MIB[1]. Whether -- this attribute is instantiated for this job when another job is -- using the device depends on implementation. > >2. deviceAlertCode (6) is may be multivalued - See pg. 36. > >More than one alert may be in effect. Do we need to clarify that this attribute >can be multi row? Yes, for both deviceAlertCode(6) and deviceAlertIndex(8). Done. > >3. What happened to serverAssignedJobNumber (2x) - See pg. 37 > >We used to have serverAssignedJobNumber, with syntax integer. I think we >combined >this with serverAssignedJobName (22) and dropped it, but in so doing, it is not >listed as >Octets (only). What about the original concern that (OS/2 and perhaps other) >some os's >use an integer not a text string. Are we saying the integer must be converted >to text? I think you are referring to the jmJobIdNumber attribute that Ron proposed along with jmJobIdName. We deleted both when switching over to your jmJobSubmissionID table scheme. Ron is in agreement I believe with not needing either jmJobIdName or jmJobIdNumber. So for servers that assign numbers to jobs before submitting them to devices (configuration 3), rather than names, I would suggest that having the agent converting a number that it received in the job submission protocol to a text string would mean that we could use the same attribute and that an application would not need to deal with two attributes when querying. However, we should add a sentence clarifying that the text string may be a name or a number. ISSUE 105: Ok to clarify that serverAssignedJobName(22) can be all digits? > >4. Persistence of serverAssignedJobName - See pgs. 36, 37 > >Two other attributes (jobOwner and jobName) mandate "long" persistence. If you >read the >note under serverAssignedJobName, it leads in with the same reasoning, but >stops short of >requiring "long" persistence. Which persistence value is serverAssignedJobName >intended >to follow? ISSUE 106: Should serverAssignedJobName persist longer too? > >(Aside... this leads to another whole question about persistence of tables vs. >persistence >of specific attributes or objects and whether or not the 3 objects above should >just be added >to the job state table. Separate topic but probably needs further discussion). Agreed. See ISSUE 93 in what I submitted as comments from Xerox developers. > >5. jobProcessAfterDateAndTime (51) - Octets vs Integer - See pg. 40-41 > >Shouldn't this be Octets, not Integer? Yes. Done. > >6. Eliminate "timeSince" Attributes - See pg. 47 > >This is too much work for the agent and is contrary to SNMP in that sysUpTime >should do >the trick. I don't mind using a JmTimeStampTC rather than sysUpTime so much, >but the >NMS, not the agent, should calculate the times since. Good issue. The three timeSinceJobWasSubmitted(192), timeSinceStartedProcessing(195), and timeSinceCompleted(197) were added becaue this is the way IPP does these time attributes. On the other hand, is easier as you point out for the agent to use the JmTimeStampTC jobSubmissionToDeviceTime(191), jobStartedProcessingTime(194), and jobCompletedTime(196) and the NMS can do the work. Also having fewer time attributes to choose from does make the NMS's job easier. I'm in favor of removing the three timeSinceXXX attributes. An agent instrumenting an IPP system will have to do a little more computation. ISSUE 107: Ok to remove the three IPP timeSinceXxx attributes? An agent instrumenting an IPP implemenation will either have access to the time that the job's state change happened and can convert to JmTimeStampTC or only has the time-since-xxx value and will have to substract that from the time of day and substract sysUpTime from the result to return the jmTimeStampTC value. > I believe time can be >synchronized >by allowing jobSubmissionToDeviceTime to be multivalued - one DateAndTime >passed >in on submission and one jmTimeStampTC stamped by the printer. Rather than making jobSubmissionToDeviceTime MULTI-ROW, in which an NMS wouldn't know whether the first value was a submission time to a server or a submission time to a device, see ISSUE 93a in the Xerox comments to keep two attributes, but call one jobSubmissionTime and the other jobSubmissionToServerTime for use in configuration 3 only when both times are needed. > >7. IMPLIED/IMPLICIT - See pg. 61 > >The note reads "an IMPLICIT statement is NOT provided in the following INDEX >clause, since it >was not an SMIv2 feature. Therefore, the extra ASN.1 tag SHALL be included in >the varbind >in the SNMP request and the response." > >First, we think the terminology is IMPLIED, not IMPLICIT. Agreed. SNMP uses IMPLIED, ASN.1 uses IMPLICIT. So I'll change the note if it stays. Done. Also, we think the >IMPLIED statement >SHOULD (SHALL?;-) be included because it saves a byte on each varbind. If you >left this >out because it is not part of v1 (as stated) I think there are other examples >(like DateAndTime) >where you are using v2 constructs. ISSUE 108: Add IMPLIED to jmJobIDEntry INDEX statement on page 61? > >8. "Requested Attribute" defaults > >For requested attributes like copies, toner, quality etc. what if the requested >value is not passed >in? Should the agent use the device default? Interesting question? In any case that would be implementation dependent. This is a difference between ISO DPA and IPP. In DPA, the server does populate the job object with the defaults. In IPP, the server doesn't, so that the defaults are only applied if neiter the requester nor the document PDL supplies the attribute. ISSUE 109: Ok for agent to supply defaults for the job attributes depending on implmentation? > >9. Misc editorial > >We noticed, in the text version, jobHoldUnitl is in the TOC twice. >In the text and PDF versions jobHold is missing. Oops! Looks like I didn't update the TOC after adding jobHold attribute. It will be in the TOC next version. > > >>>> Harry Lewis <<< > > From jkm at underscore.com Fri Jun 20 12:54:52 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers In-Reply-To: Comments on JMP V0.82 from Xerox developers> Message-ID: <199706201654.MAA15346@uscore.underscore.com> Tom, So, one day before the PWG meetings you present a list of 16 new issues (disregarding, for a second, the many "sub-issues" you've presented). This is the same old stuff that has kept the Job MIB from making significant progress these last two years. This is Not Good. No matter what, the Job Monitoring MIB is going to CLOSE its effort on Friday, June 27, right??? ...jay ----- Begin Included Message ----- Date: Thu, 19 Jun 1997 14:57:02 PDT To: jmp@pwg.org From: Tom Hastings Subject: JMP> Comments on JMP V0.82 from Xerox developers The following comments are from an internal review at Xerox of the Job Monitoring MIB, V0.82. I started numbering these issues starting with the next free issue in issues.doc. ISSUE 88 - Add jmGeneralNumberOfJobsProcessed object since server or printer was booted? Most MIBs have some sort of utlization counter. The Job Monitoring MIB should have one also. Add the object to the jmGeneralTable. We assume that this object SHALL NOT be persistent across power cycles. The DESCRIPTION is proposed to be: jmGeneralNumberOfJobsProcessed OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of jobs that have completed processing for this job set since the server or device was powered on." ::= { jmGeneralEntry 7 } ISSUE 89 - Add jmGeneralAttributesImplemented object with bits for each attribute implemented? Instead of an application not knowing which attributes an implementation implements and trying to discover by getting errors, or by always using Get Next, instead of Get, how about adding a jmGeneralAttributesImplemented object to the jmGeneralTable that has a bit for each attribute implemented. jmGeneralAttributesImplemented OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit string indicating which JmAttributeTypeTC enum values are implemented. The value is a constant independent of which bits are currenly in entries in the jmAttributeTable. The most significant bit of the first octet is assigned the value 0 to correspond to enum 0 (not used), the next most significant bit of the first octet is assigned the value 1 to correspond to enum 1 (other), the next bit is assigned the value 2 (unknown), 3 (jobStateReasons2) etc. up to 32*8 - 1 = 255" ::= { jmGeneralEntry 8 } ISSUE 90 - The (MANDATORY) OCTET STRING objects should have a minimum MAX size required Otherwise, trivial implementations can implement too short sizes and be conforming. The SNMP conformance syntax as the end of the MIB has provision for specifying the minimum maximum that SHALL be implemented. The 63 in OCTET STRING(SIZE(0..63)) is the maximum size and the 0 is the minimum size for an instance returned on a Get operation. The (MANDATORY) OCTET STRING objects are with suggested MAX size required: jmGeneralJobSetName 8 octets required to be implemented jmJobSubmissionID 32 octets required to be implemented ISSUE 91 - The MANDATORY jobOwner attribute should have a minimum MAX size required Otherwise, trivial implementations can implement too short sizes and be conforming. We suggest that 16 octets of the maximum 63 be required to be implemented. Such a maximum will also help with the next issue. ISSUE 92 - The MANDATORY jobOwner attribute needs to persist as long as there is job data 92a: The MANDATORY jobOwner attribute needs to persist as long as there is job data. Otherwise, a client that does not have access to the jobSubmissionID or a system that does not have a jobSubmissionID cannot identify the jobs in the jmJobTable, after the agent removes the job's attributes from the jmAttributeTable. 92b: If it is agreed that the MANDATORY jobOwner SHALL persist for the longer period of time, then it should be moved to the jmJobTable, where all the other MANDATORY attributes have been made objects. 92c: Then the jmAttributeTable could be made OPTIONAL, so that really low end printers would not need to implement the jmAttributeTable at all. Experience at Xerox with low end non-queuing printers suggests that not requiring the jmAttributeTable is a win. With a required maximum of only 20 octets (see previous issue), it is reasonable to move the jobOwner to the MANDATORY jmJobTable. ISSUE 93 - The jobName and jobSubmission[ToDevice]Time should be MANDATORY 93a: The windows queue monitoring show three attributes: jobOwner, jobName, and start time. In IPP, jobName is a MANDATORY attribute. In order to work for all configurations, the jobSubmissionToDeviceTime should be changed to jobSubmissionTime and be used for all three configurations: configuration 1: device, configuration 2: server, and configuration 3: device. The jobSubmissionToServerTime shall only be used in configuration 3, where jobSubmissionTime is also used (for the device). Then jobSubmissionTime can be made MANDATORY (since it can be used in all three configurations). 93b: If the jobName attribute is made MANDATORY then it should have a minimum maximum value specified for conformance. We suggest that 12 octets is sufficient. 93c: If jobName and jobSubmissionTime are made MANDATORY, then they should be moved to the jmJobTable as well, so that the jmAttributeTable can remain OPTIONAL (see previous issue). ISSUE 94 - Are the 8 octet fields in the jobSubmisionID printable or binary? The text says "8-decimal-digits". Could it be allowed to be a binary sequence number or random number? Then the chances of collision are even lower. ISSUE 95 - When reducing the size of the jobSubmissionID field from 2 to 1, the other fields weren't increased by 1. ISSUE 96 - Add a jobSubmissionID format for jobOwner The first octet would be an ASCII '4'. The next 8 would be a sequential number, and the remaining 23 octets would be the low order 23 octets of the jobOwner. ISSUE 97 - Add some jobSubmissionID formats for numeric identifiers 97a - Add one for POSIX user numbers 97b - Add one for user account numbers 97c - Add one for DTMF incoming FAX routing number ISSUE 98 - The sequence number and random number in the jmJobSubmissionID should be the least significant field, not the most significant field Then a requester can leave off the sequential number or random number in a GetNext and find all of the jobs from a particular MAC address or client URL (or for a particular jobOwner). In order to make this switch, we need to specify that when the MAC address, client URL, (jobOwner, or numberic id) is shorter than 23 octets, that the field is shortened, rather than being padded out to 23 octets. The least significant field is always 8 octets with leading zeroes, so that we don't need any delimiters between the two fields. So the spec would become: Format Number Description ------ ------------ 1 octets 2 to n: upto last 23 bytes of the jobName attribute; n < 26 octets n to n+7: 8-decimal-digit random number 2 octets 2 to n: Client MAC address; n < 26 octets n to n+7: 8-decimal-digit sequential number 3 octets 2 to n: last 23 bytes of the client URL; n < 26 octets n to n+7: 8-decimal-digit sequential number .. to be registered according to procedures of a type 2 enum. See section 7.3 on page 22. ISSUE 99 - The jobSubmisionID format '0' makes no sense 98a: There are two interpretations of the text there: 1. The agent only puts a single digit of '0' for the entire jobSubmissionID index - but each subsequent submission would replace the entry. 2. The agent tacks on whatever it wants after the '0' to make a unique jobSubmissionID index for each job. 98b: If interpretation 2 is correct, then could we require the agent to use the jobOwner instead, rather than leaving it unspecified how the agent fills in the entry if interpretation is correct? ISSUE 100 - The jobSubmissionIDTable should have jmJobSet and jmJobIndex as indexes The current formats will have collisions of jobSubmissionIDs occasionally. The statement on lines 1695-1697: "None-the-less, collisions could occur, but without bas consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them." is incorrect, since future IETF and priviate MIBs are likely to have 'missles', not 'cameras'. We've had experience with a table like this (jobClientIdTable) for a year and a half and we added the jmJobIndex equivalent to the row entry that the agent adds to make sure that no entry ever gets overwritten. So we propose that the jmJobSet object and the jmJobIndex objects be added as the least significant indexes to the jmJobSubmissionIDTable. They are only simple integers and jmJobSet is likely to be 1 in most implementations. ISSUE 101 - add jobSubmissionID as an attribute, so can find the ID when scanning a job or attribute table. An accounting program that wants to find the jobSubmissionID would have to scan the entire jmJobSubmissionIDTable ISSUE 102 - Make a TC out of the jobSubmissionID formats, so can publish new ones more easily? ISSUE 103 - Specify a minimum required persistence time for jmGeneralAttributePersistence Put the lower bound right in the ASN.1. We suggest 60 seconds as a minimum with a recommendation of 300 (5 minutes). Even add a DEFVAL of 300 as the default. The real low cost device that doesn't want to keep job information around will have a small number of jobs anyway, since how many jobs can just a device process in a minute anyway? The spec would become: SYNTAX Integer32(60..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time in seconds for this instance of the Job Set that an entry will remain in the jmAttributeTable after processing has completed , i.e., the time in seconds starting when the job enters the completed, canceled, or aborted state. The value of this object MAY be either (1) set by the system administrator by means outside this specification or MAY be (2) fixed by the implementation, depending on implementation. This value SHALL be equal to or less than the value of jmGeneralJobPersistence. This value SHOULD be at least 300 which gives a monitoring application five minutes in which to poll for job data." DEFVAL { 300 } -- 5 minutes ::= { jmGeneralEntry 5 } ----- End Included Message ----- From hastings at cp10.es.xerox.com Fri Jun 20 14:15:38 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers In-Reply-To: Comments on JMP V0.82 from Xerox developers> Message-ID: <9706201818.AA00982@zazen.cp10.es.xerox.com> At 09:54 06/20/97 PDT, JK Martin wrote: >Tom, > >So, one day before the PWG meetings you present a list of 16 new >issues (disregarding, for a second, the many "sub-issues" you've >presented). > >This is the same old stuff that has kept the Job MIB from making >significant progress these last two years. This is Not Good. > >No matter what, the Job Monitoring MIB is going to CLOSE its >effort on Friday, June 27, right??? Absolutely right! Harry refers to some of the same issues. Tom > > ...jay From hastings at cp10.es.xerox.com Fri Jun 20 17:02:48 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Some Editorial Comments on the Job Monitoring MIB Message-ID: <9706202105.AA01314@zazen.cp10.es.xerox.com> I've posted the attached file as a .doc, .txt, and .pdf file as well. They show the changes using revision marks. I'll bring copies of this to the meeting. ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 37888 Jun 20 20:56 edtcomth.doc -rw-r--r-- 1 pwg pwg 19901 Jun 20 20:56 edtcomth.pdf -rw-r--r-- 1 pwg pwg 8669 Jun 20 20:56 edtcomth.txt Tom Subj: Some Editorial Comments on the Job Monitoring MIB From: Tom Hastings Date: 6/20/97 File: edtcomth.doc 1. Page 39, fileName(34) - Clarify that the file name could be a URI. Need a reference to a URI. So change the description to: fileName(34), -- OCTET STRING(SIZE(0..63)) -- OCTETS: MULTI-ROW: The coded character set file name or -- URI[9] of the document. -- -- There is no restriction on the same file name in multiple -- rows. 2. Page 40, documentFormat(38), change "MIME type" to "media types", since that is what IANA registers, but IANA also calls them MIME content-type/subtype names and add a reference to the IANA registry. documentFormat(38), -- PrtInterpreterLangFamilyTC -- AND/OR -- OCTET STRING(SIZE(0..63)) -- INTEGER: MULTI-ROW: The interpreter language family -- corresponding to the Printer MIB[1] -- prtInterpreterLangFamily object, that this job -- requires/uses. A document or a job MAY use more than one -- PDL or control language. -- -- NOTE - This attribute is represented by a type 2 enum -- defined in the draft Printer MIB[1], but is not in RFC -- 1759. -- -- AND/OR -- -- OCTETS: MULTI-ROW: The document format registered as a -- mediaMIME type[8], i.e., the name of the MIME content- -- type/subtype. Examples: 'application/postscript', -- 'application/vnd.hp-PCL', and 'application/pdf' -- -- NOTE - IPP[3] uses MIME content-type/subtype -- nameskeywords to identify document formats. 3. Add a reference to the documentFormat attribute in the IANA Considerations section. 4. Clarify that the CPU time reproducibility is for the same device: jobProcessingCPUTime(198) -- Integer32(-2..2147483647) -- INTEGER: The amount of CPU time that the job has been -- processing in seconds, i.e., in the processing job state. -- If the device stops and/or the job enters the -- processingStopped state, that elapsed time SHALL not be -- included. In other words, the jobProcessingCPUTime value -- SHOULD be relatively repeatable when the same job is -- submitted again to the same device. 5. Page 47, timeSinceJobWasSubmittedToDevice(192) - units should be the changed from seconds to milliseconds so at to be the same as the other two timeSinceXxx attributes and as IPP, if we keep these three attributes at all (see Harry's issue 107). 6. If IPP changes the "printer-resolution" attribute from a keyword to two integers, the Job Monitoring MIB should do the same. I suggest that we just make printerResolution attribute be MULTI-ROW with integer data type. If there is only one value, it is the same for both x and y directions. If the values are different then there are two entries, with the first being the x (short edge direction) resolution. 7. I added the data type and range to the table of contents which showed some inconsistencies on the lower bound. Sometimes we have -2 and sometimes 0. 0 should remain for copies of indexes meaning no index (or do we want -2 to indicate unknown index?) and 1 should remain for actual indexes. However, I think that other 0 lower limits should be changes to -2 for consistency and to get the unknown value possible for them. The ones to change from 0 to -2 lower bound are: numberOfDocuments (Int32(0..)) outputBin (Int32(0..) and/or Octets63) timeSinceJobWasSubmittedToDevice (Int32(0..)) Here is the full table of contents: JmAttributeTypeTC - attribute type definitions other (Int32(-2..) and/or Octets63) unknown (Int32(-2..) or Octets63) Job State attributes jobStateReasons2 (JmJobStateReasons2TC) jobStateReasons3 (JmJobStateReasons3TC) jobStateReasons4 (JmJobStateReasons4TC) deviceAlertCode (PrtAlertCodeTC) processingMessage (Octets63) Job Identification attributes jobOwner (Octets63) (MANDATORY) jobAccountName (Octets63) serverAssignedJobName (Octets63) jobName (Octets63) jobServiceTypes (JmJobServiceTypesTC) jobSourceChannelIndex (Int32(0..)) jobSourcePlatformType (JmJobSourcePlatformTypeTC) submittingServerName (Octets63) submittingApplicationName (Octets63) jobOriginatingHost (Octets63) deviceNameRequested (Octets63) queueNameRequested (Octets63) physicalDevice (hrDeviceIndex and/or Octets63) numberOfDocuments (Int32(0..)) fileName (Octets63) documentName (Octets63) jobComment (Octets63) documentFormatIndex (Int32(0..)) documentFormat (PrtInterpreterLangFamilyTC and/or Octets63) Job Parameter attributes jobPriority (Int32(1..100)) jobProcessAfterDateAndTime (DateAndTime) jobHoldUntil (Int32(0..1)) jobHoldUntil (Octets63) outputBin (Int32(0..) and/or Octets63) sides (Int32(-2..1)) finishing (JmFinishingTC) Image Quality attributes (requested and used) printQualityRequested (JmPrintQualityTC) printQualityUsed (JmPrintQualityTC) printerResolutionRequested (JmPrinterResolutionTC) printerResolutionUsed (JmPrinterResolutionTC) tonerEcomonyRequested (JmTonerEconomyTC) tonerEcomonyUsed (JmTonerEconomyTC) tonerDensityRequested (Int32(1..20)) tonerDensityUsed (Int32(1..20)) Job Progress attributes (requested and consumed) jobCopiesRequested (Int32(-2..)) jobCopiesCompleted (Int32(-2..)) documentCopiesRequested (Int32(-2..)) documentCopiesCompleted (Int32(-2..)) jobKOctetsTransferred (Int32(-2..)) Impression attributes (requested and consumed) impressionsSpooled (Int32(-2..)) impressionsSentToDevice (Int32(-2..)) impressionsInterpreted (Int32(-2..)) impressionsCompletedCurrentCopy (Int32(-2..)) fullColorImpressionsCompleted (Int32(-2..)) highlightColorImpressionsCompleted (Int32(-2..)) Page attributes (requested and consumed) pagesRequested (Int32(-2..)) pagesCompleted (Int32(-2..)) pagesCompletedCurrentCopy (Int32(-2..)) Sheet attributes (requested and consumed) sheetsRequested (Int32(-2..)) sheetsCompleted (Int32(-2..)) sheetsCompletedCurrentCopy (Int32(-2..)) Resource attributes (requested and consumed) mediumRequested (JmMediumTypeTC and/or Octets63) mediumConsumedName (Octets63) colorantRequested (Int32(0..) and/or Octets63) colorantConsumed (Int32(0..) amd/or Octets63) Time attributes (set by server or device) jobSubmissionToServerTime (JmTimeStampTC and/or DateAndTime) jobSubmissionToDeviceTime (JmTimeStampTC and/or DateAndTime) timeSinceJobWasSubmittedToDevice (Int32(0..)) jobStartedBeingHeldTimeStamp (JmTimeStampTC) jobStartedProcessingTime (JmTimeStampTC and/or DateAndTime) timeSinceStartedProcessing (Int32(-2..)) jobCompletedTime (JmTimeStampTC and/or DateAndTime) timeSinceCompleted (Int32(-2..)) jobProcessingCPUTime (Int32(-2..)) The General Group (Mandatory) jmGeneralNumberOfActiveJobs (Int32(0..)) jmGeneralOldestActiveJobIndex (Int32(0..)) jmGeneralNewestActiveJobIndex (Int32(0..)) jmGeneralJobPersistence (Int32(0..)) jmGeneralAttributePersistence (Int32(0..)) jmGeneralJobSetName (Octets63) The Job ID Group (Mandatory) jmJobSubmissionID (OCTET STRING(SIZE(1..32))) jmJobSetIndex (Int32(1..32767)) jmJobIndex (Int32(1..)) The Job Group (Mandatory) jmJobState (JmJobStateTC) jmJobStateReasons1(JmJobStateReasons1TC) jmNumberOfInterveningJobs (Int32(-2..)) jmJobKOctetsRequested (Int32(-2..)) jmJobKOctetsProcessed (Int32(-2..)) jmJobImpressionsRequested (Int32(-2..)) jmJobImpressionsCompleted (Int32(-2..)) The Attribute Group (Mandatory) jmAttributeTypeIndex (JmAttributeTypeTC) jmAttributeInstanceIndex (Int32(1..32767)) jmAttributeValueAsInteger (Int32(-2..)) jmAttributeValueAsOctets (Octets63) From imcdonal at eso.mc.xerox.com Fri Jun 20 18:12:58 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers In-Reply-To: Comments on JMP V0.82 from Xerox developers> Message-ID: <9706202212.AA03764@snorkel.eso.mc.xerox.com> Hi Jay, Would you prefer half a viable standard now to an actually usable one a little later. You certainly managed to offend the Xerox SNMP implementors who took the time to review the latest draft in detail and post their comments (thanks to Tom's editorial cleanups) BEFORE the PWG meeting. The IETF strongly urges all sanctioned working groups to make ALL substantial decisions solely via mailing list. Face to face meetings may suit some of the PWG members, but they certainly penalize the distant folks (in other countries) and those who speak English as a second language. How about constructive comment on the input from Xerox implementors? Disgruntled, - Ira McDonald (outside consultant at Xerox) High North Inc From jkm at underscore.com Fri Jun 20 19:12:02 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers In-Reply-To: Comments on JMP V0.82 from Xerox developers> Message-ID: <199706202312.TAA15748@uscore.underscore.com> Ira, First off, it would have been nice to toss each of the 16 issues on the mailing list as they were identified, rather than waiting until the very last minute and throwing the whole lot onto the list as people are getting ready to fly to the PWG meetings next week. I don't think that's too much to ask, do you? Moreover, I *expressly* made such a comment to Tom during the JMP meeting in San Diego last month, strongly encouraging him to not repeat this same scenario as has been done so often in the past. And, by posting issues as they arise to the mailing list, you not only allow for interleaving of human effort, but you also satisfy the IETF working group rules you have referenced. Second, I would have preferred a MINIMALLY USEFUL IMPLEMENTATION out in the marketplace over a year ago. This certainly would have been possible if some folks didn't constantly insist on tossing in the kitchen sink into the effort. (Believe me, I'm not the only one who has made this statement over the last two years.) Of course I didn't mean to offend the Xerox implementors. However, I think it's high time Xerox takes a few moments and considers the rest of the JMP group's desire to FINALIZE the FIRST IMPLEMENTATION of this Job Monitoring MIB. There's a difference between "Good" and "Good Enough". There is always Version 2 (and 3 and 4...). If NASA took the same approach to designing rockets as was done in designing the Job MIB, then we never would have made it to the moon back in 1969...since NASA would still be trying to figure out how to design that same rocket to get to Pluto. Steve Waldbusser kept telling us (in so many words, and on so many occasions back in 1993-1994): Start off small and minimal, with (ideally) NO optional objects whatsover, to get some real market experience with a wide base of interoperable products. Then, go back and do Version 2, taking into account what you learned in Version 1. This is all I (AND OTHERS) have been asking all this time, to start off small and get product in the field ASAP. You make a reference to a "half viable standard". When the dust settles on the latest round of mapping Job MIB objects to TODAY'S EXISTING PRINTING SYSTEMS, I'll bet you will find that such systems can barely handle the majority of defined objects. The bigger the design, the more work to develop. The bigger the product, the more likely you will lose on robustness and interoperability. Please extend my apologies to the Xerox implementors. I'll need to partition quite a bit of time to review the 16 issues now presented on the list. Chances are, now that the PWG meetings are upon us (and we're hosting them), I won't get such time until the JMP meeting next Friday...if I'm lucky. ...jay ----- Begin Included Message ----- Date: Fri, 20 Jun 1997 15:12:58 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) To: hastings@cp10.es.xerox.com, jkm@underscore.com Subject: Re: JMP> Comments on JMP V0.82 from Xerox developers Cc: jmp@pwg.org Hi Jay, Would you prefer half a viable standard now to an actually usable one a little later. You certainly managed to offend the Xerox SNMP implementors who took the time to review the latest draft in detail and post their comments (thanks to Tom's editorial cleanups) BEFORE the PWG meeting. The IETF strongly urges all sanctioned working groups to make ALL substantial decisions solely via mailing list. Face to face meetings may suit some of the PWG members, but they certainly penalize the distant folks (in other countries) and those who speak English as a second language. How about constructive comment on the input from Xerox implementors? Disgruntled, - Ira McDonald (outside consultant at Xerox) High North Inc ----- End Included Message ----- From hastings at cp10.es.xerox.com Fri Jun 20 20:24:07 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on JMP V0.82 from Xerox developers In-Reply-To: Comments on JMP V0.82 from Xerox developers> Message-ID: <9706210026.AA00483@zazen.cp10.es.xerox.com> At 16:12 06/20/97 PDT, JK Martin wrote: >Ira, > >First off, it would have been nice to toss each of the 16 issues >on the mailing list as they were identified, rather than waiting >until the very last minute and throwing the whole lot onto the list >as people are getting ready to fly to the PWG meetings next week. > >I don't think that's too much to ask, do you? Moreover, I *expressly* >made such a comment to Tom during the JMP meeting in San Diego last >month, strongly encouraging him to not repeat this same scenario as >has been done so often in the past. > >And, by posting issues as they arise to the mailing list, you not >only allow for interleaving of human effort, but you also satisfy >the IETF working group rules you have referenced. Jay, I'm sorry that I didn't understand what you were suggesting in San Diego. Now that you are being *specific* that you prefer to see each issue sent as a separate mail message and sent when discovered, instead of one week ahead of the meeting (the PWG agreed deadline), I understand what you are saying. Bob also mentioned to me yesterday that he preferred short mail messages on a specific topic rather than a long list. That he tends to read a mail message that is a screenful and postpones reading longer ones. If others feel the same, lets change the way we work. The mail traffic will go up... Tom From rbergma at dpc.com Mon Jun 23 21:01:52 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:07 2009 Subject: JMP> Meeting and Comments on the MIB Draft Message-ID: <9706210026.AA00483@zazen.cp10.es.xerox.com> Tom, I will not be able to attend the meetings this week. I will try to post a proposed agenda prior to Friday. I hope you can make some good progress this month! Jay, I think you foretold the future by not including my name on the list of attendees. all, I have posted my comments on the ftp site in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ietf-rev01-comments-ron.doc These comments are mostly of an editorial nature and I believe they will clean up the document significantly. I do not propose that these changes be reviewed in the meeting this week. Tom, please review this document and incorporate all that you believe are valid into the next draft. Please provide feedback on any that you don't agree with. Hope everyone has a good meeting, Ron Bergman From bpenteco at boi.hp.com Tue Jun 24 23:13:02 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:07 2009 Subject: JMP> ACTION: Please do protocol mapping as part of your JMP review Message-ID: <01BC80F6.26C3AF40@hpb15431.boi.hp.com> I forgot to send this to JMP as well as to Tom. Oops! ---------- From: Bob Pentecost[SMTP:bpenteco@boi.hp.com] Sent: Tuesday, June 24, 1997 11:45 AM To: 'Tom Hastings' Subject: RE: JMP> ACTION: Please do protocol mapping as part of your = JMP review I have completed the job submission protocol mapping to the JMP Job = Monitoring MIB spec as part of the review of the MIB. Tom had requested = that I do: PJL pjl.doc Bob Pennacost (at least I think he was referring to me via the creative spelling of my = name :-). You can find the file at: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/pjl.doc (I think Tom wanted it there and not on ftp.external.hp.com where he = said to put it). I have included PJL along with HP's proprietary MIB objects in the = table. I will also bring copies to the JMP meeting on Friday. Bob Pentecost HP ---------- From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] Sent: Friday, June 13, 1997 11:04 AM To: jmp@pwg.org Subject: JMP> ACTION: Please do protocol mapping as part of your JMP = review Its time to do the job submission protocol mapping to the JMP Job = Monitoring MIB spec as part of the review of the MIB. Please do this before the upcoming meeting, so that we can review the mappings as part of the JMP review. This is a "paper bake off". I've put a new template into: ftp::/ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 46592 Jun 13 16:43 jmtmplt2.doc The following people have been assigned to do the mappings. If you = cannot do your assignment, please respond to me with a substitute name. Job Submission file name Responsible person Protocol=09 AppleTalk PAP applepap.doc Ron Bergman IPDS ipds.doc Harry Lewis ISO DPA iso-dpa.doc Tom Hastings LPR/LPD lpr-lpd.doc Ron Bergman NDPS ndps.doc Scott Isaacson PJL pjl.doc Bob Pennacost PostScript ps.doc Bob Setterbo PSERVER pserver.doc Scott Isaacson RPRINTER rprinter.doc Scott Isaacson SMB smb.doc Bob Setterbo TIPSI/NPAP tipsi.doc Don Wright I've put each object and attribute from the Table of contents into the template, along with the page number from the jmp-mibv.pdf version = (0.82 that corresonds to the Internet-Draft 01) which is the file you should = be=20 using. So get out the template, look at the page number and read the MIB spec to see if that attribute or object is settable or queriable in your job submission protocol. Put the name of the attribute in your protocol next to the JMP object or attribute. Put any comments, questions, data conversion, issues in = the=20 Notes column. I've listed each of the jobState and jobStateReasons1 values as well. Thanks, Tom Here are the detaile instructions from the template: 1. Copy jmtmplt2.doc from = ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmtmplt1.doc. 2. Fill in the first five lines of information about your job submission protocol immediately after the "cut here" line. 3. Delete the template before and including the "cut here". 4. Please go read each attribute, so that you are sure that the mapping = is correct and to be part of the review process on the MIB itself. The = page numbers correspond to the line numbered version with variable pitch font (jmp-mibv.pdf, V0.82), which is the one we should be using for review. = If you find a description that is unclear or ambiguous, please make a note = and send as e-mail or enter it in the Notes column here. We need to fix ambiguities now, not after we are a proposed standard. =20 5. Edit in the name of each of the job submission protocol attributes = that corresponds to each of the object/attribute in the table below. For the attributes that are read-only in your job submission protocol, such as jmGeneralNumberOfActiveJobs, jobState, and pagesConsumed, enter the name = of the attribute in your job submission protocol, if it is querable with = your job submission protocol, otherwise leave blank. 6. For objects/attributes that do not have a corresponding attribute in = your job submission protocol, please leave blank. 7. If you aren't sure whether the job attribute you found is correct, = put a question mark after the name of your job submission protocol attribute. 8. Add any notes to the last column labeled NOTES. 9. Rename your file to the xxx.doc file name indicated below for your = job submission protocol. 10. Post your file in: ftp://ftp.external.hp.com/snmpmib/jobs-mib/protomap/xxx.doc 11. Send mail to the jmp list indicating that you have posted your = mapping. From hastings at cp10.es.xerox.com Wed Jun 25 02:36:11 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> ACTION: Please do protocol mapping as part of your Message-ID: <9706250638.AA01342@zazen.cp10.es.xerox.com> Bob, Thanks for posting. I hope that others have contributions. I put a .pdf file there too: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/ -rw-r--r-- 1 pwg pwg 33792 Jun 24 17:32 pjl.doc -rw-r--r-- 1 pwg pwg 34232 Jun 25 06:34 pjl.pdf Sorry about your name being misspelled and the old URL for posting. I cut and pasted from a year old file when the PWG server was hosted by HP. Tom At 20:13 06/24/97 PDT, Bob Pentecost wrote: >I forgot to send this to JMP as well as to Tom. Oops! > >---------- >From: Bob Pentecost[SMTP:bpenteco@boi.hp.com] >Sent: Tuesday, June 24, 1997 11:45 AM >To: 'Tom Hastings' >Subject: RE: JMP> ACTION: Please do protocol mapping as part of your JMP review > >I have completed the job submission protocol mapping to the JMP Job Monitoring MIB spec as part of the review of the MIB. Tom had requested that I do: >PJL pjl.doc Bob Pennacost >(at least I think he was referring to me via the creative spelling of my name :-). > >You can find the file at: >ftp://ftp.pwg.org/pub/pwg/jmp/protomap/pjl.doc >(I think Tom wanted it there and not on ftp.external.hp.com where he said to put it). > >I have included PJL along with HP's proprietary MIB objects in the table. > >I will also bring copies to the JMP meeting on Friday. > >Bob Pentecost >HP > > > >---------- >From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] >Sent: Friday, June 13, 1997 11:04 AM >To: jmp@pwg.org >Subject: JMP> ACTION: Please do protocol mapping as part of your JMP review > >Its time to do the job submission protocol mapping to the JMP Job Monitoring >MIB spec as part of the review of the MIB. Please do this before >the upcoming meeting, so that we can review the mappings as part of the >JMP review. This is a "paper bake off". > >I've put a new template into: > >ftp::/ftp.pwg.org/pub/pwg/jmp/protomap/ >-rw-r--r-- 1 pwg pwg 46592 Jun 13 16:43 jmtmplt2.doc > >The following people have been assigned to do the mappings. If you cannot >do your assignment, please respond to me with a substitute name. > >Job Submission file name Responsible person >Protocol >AppleTalk PAP applepap.doc Ron Bergman >IPDS ipds.doc Harry Lewis >ISO DPA iso-dpa.doc Tom Hastings >LPR/LPD lpr-lpd.doc Ron Bergman >NDPS ndps.doc Scott Isaacson >PJL pjl.doc Bob Pennacost >PostScript ps.doc Bob Setterbo >PSERVER pserver.doc Scott Isaacson >RPRINTER rprinter.doc Scott Isaacson >SMB smb.doc Bob Setterbo >TIPSI/NPAP tipsi.doc Don Wright > >I've put each object and attribute from the Table of contents into >the template, along with the page number from the jmp-mibv.pdf version (0.82 >that corresonds to the Internet-Draft 01) which is the file you should be >using. > >So get out the template, look at the page number and read the MIB spec >to see if that attribute or object is settable or queriable in your >job submission protocol. > >Put the name of the attribute in your protocol next to the JMP object >or attribute. Put any comments, questions, data conversion, issues in the >Notes column. > >I've listed each of the jobState and jobStateReasons1 values as well. > >Thanks, >Tom > >Here are the detaile instructions from the template: > >1. Copy jmtmplt2.doc from ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmtmplt1.doc. >2. Fill in the first five lines of information about your job submission >protocol immediately after the "cut here" line. >3. Delete the template before and including the "cut here". >4. Please go read each attribute, so that you are sure that the mapping is >correct and to be part of the review process on the MIB itself. The page >numbers correspond to the line numbered version with variable pitch font >(jmp-mibv.pdf, V0.82), which is the one we should be using for review. If >you find a description that is unclear or ambiguous, please make a note and >send as e-mail or enter it in the Notes column here. We need to fix >ambiguities now, not after we are a proposed standard. > >5. Edit in the name of each of the job submission protocol attributes that >corresponds to each of the object/attribute in the table below. For the >attributes that are read-only in your job submission protocol, such as >jmGeneralNumberOfActiveJobs, jobState, and pagesConsumed, enter the name of >the attribute in your job submission protocol, if it is querable with your >job submission protocol, otherwise leave blank. >6. For objects/attributes that do not have a corresponding attribute in your >job submission protocol, please leave blank. >7. If you aren't sure whether the job attribute you found is correct, put a >question mark after the name of your job submission protocol attribute. >8. Add any notes to the last column labeled NOTES. >9. Rename your file to the xxx.doc file name indicated below for your job >submission protocol. >10. Post your file in: > ftp://ftp.external.hp.com/snmpmib/jobs-mib/protomap/xxx.doc >11. Send mail to the jmp list indicating that you have posted your mapping. > > > > > From hastings at cp10.es.xerox.com Wed Jun 25 02:56:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Are we still agreed that we need mappings BEFORE progressing Message-ID: <9706250658.AA01350@zazen.cp10.es.xerox.com> I'm real worried about the lack of mappings posted from the job submission protocols to JMP. Only IPP and PJL so far. Are we still in agreement with Ron's strategy that we need to do the mappings BEFORE we forward the MIB to the IESG to become a proposed standard? By "mapping" I mean how does a JMP agent respond to a Get for JMP object xxx or JMP attribute yyy when instrumenting a device that supports the particular job submission protocol, i.e., how does the agent map from one or more job submission protocol attributes to return the value of the xxx JMP object or yyy attribute when the agent receives a Get operation for the JMP xxx object or yyy attribute? I think that this is a very important strategy. The printer vendors who will be putting the Job Monitoring MIB into printers have a problem with changes, because we have customers who will have written monitoring code that use the MIB. So we want to minimize the incompatible changes when the document goes from proposed to draft (additions are fine and deletions that no one implemented are fine). Doing the mapping is one way to reduce the number of incompatible changes, because the mapping is really a "paper bake off". This "paper bake off" will flush out ambiguities as we all look at each others mappings and ask, "Why did you map to that submission protocol attribute to that JMP object/attribute? I would have though that you would have..." I hope that we can use some of the time Thursday night or Friday to finish some more mappings, if they are not forthcoming, and compare one anothers so that we can forward this MIB right after this meeting. Comments? Tom From rbergma at dpc.com Wed Jun 25 21:37:46 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments on Comments from Harry Lewis Message-ID: <9706250658.AA01350@zazen.cp10.es.xerox.com> Here are my comments since I will not be attending the meeting. 1. deviceAlertCode (6) needs pointer to the SNMP alert table. I thought that this issue had been discussed before. It was agreed that, if the printer MIB was implemented, all the details could be obtained from the Alert Table. The application would automatically go to the Alert Table. No index would be needed since all critical alerts would be applicable. (Warnings could be ignored or displayed.) Especially since it is proposed that this attribute be multi row, let's not provide any information that can easily be obtained from the alert table. Also, remember that this condition is an exception and does not have to be retrieved except during the fault. ISSUE 104: My vote is NO. 2. deviceAlertCode (6) it may be multivalued I agree. 3. What happened to serverAssignedJobNumber ISSUE 105: I agree, but just a very short, simple sentence. No examples or detailed discussion of how to encode a numeric into an ASCII string. 4. Persistence of serverAssignedJobName I wish I could hear the discussion on this topic! I am not in favor of a different persistence for objects within a table. However, as we said in San Diego, this will increase the size of the Job State table. ISSUE 106: I will support the groups decision. ISSUE 93: If it is agreed that this attribute requires a longer persistence then it should be moved to the Job State table. The request to make more attributes mandatory should be rejected. jobName and jobSubmissionTime are not available in all devices. 5. jobProcessAfterDateAndTime (51) - Octets vs Integer Agree this should be Octet String. 6. Eliminate "timeSince" attributes ISSUE 107: Yes! 7. IMPLIED/IMPLICIT ISSUE 108: If Ira Mcdonald is correct, this cannot change. 8. "Requested Attribute" defaults ISSUE 109: The agent cannot supply the defaults since it is not a part of the Job Submission process or can it set parameters on the printer. (This is related to the "Cameras not missiles" slogan.) If the agent has knowledge of the value the printer will use, it should be provided regardless if it is the value requested or the default. Ron Bergman From rbergma at dpc.com Thu Jun 26 14:54:37 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:07 2009 Subject: JMP> Comments regarding Comments from Xerox Developers Message-ID: <9706250658.AA01350@zazen.cp10.es.xerox.com> ISSUE 88 - Add jmGeneralNumberOfJobsProcessed Since this proposed object has the same range as jmJobIndex, it does not provide any added value. It will always be equal to jmJobIndex. ISSUE 89 - Add jmGeneralAttributesImplemented object with bits for each attribute implemented I do not know how valuable this object would be to a management application. Unless Jay Martin and David Kellerman indicate strong support, I would reject this request. ISSUE 90 - The (MANDATORY) OCTET STRING objects should have a minimum MAX size required ISSUE 91 - The MANDATORY jobOwner attribute should have a minimum MAX size required I do not have a strong opinion on these issues. I would support this as long as a strong objection is not raised More on the other issues later. Ron Bergman From imcdonal at eso.mc.xerox.com Sat Jun 28 17:58:46 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> Conformance/Indexing of Job ID table Message-ID: <9706282158.AA06526@snorkel.eso.mc.xerox.com> Hi Tom and Harry, Saturday (28 June 1997) First, some IETF Job Mon MIB structure/conformance recommendations: 1) Rename the 'jmJobSetIndex' object to 'jmGeneralJobSetIndex' - move the definition from the Job ID group (a subordinate group) to the Job General group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobSetIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 2) Move the 'jmJobIndex' object definition from the Job ID group to the Job (State) group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 3) Do NOT move 'jobOwner' to the Job (State) table, since the Job ID table will overlap (in some implementations) with this attribute. 4) Change the conformance for the Job ID group from 'Mandatory' to 'Optional' - since the Job ID group would no longer contain the two major index objects (and itself consists of long strings). 5) Change the conformance for the Job Attribute group from 'Mandatory' to 'Optional' - since the 'jobOwner' attribute is NOT necessary to find client jobs, if the 'jobOwner' format is used (by the client OR by the managed system) to assign 'jmJobSubmissionID' values (and find entries in the Job ID table). Second, some Job ID table indexing recommendations: 1) Remove length byte, by SMIv1 (RFC 1212, pg 9) and SMIv2 (RFC 1902, pg 21) encoding rules, from instance qualifiers of the Job ID table (without resorting to IMPLIED keyword) by using fixed length strings - change SYNTAX of 'jmJobSubmissionID' to 'OCTET STRING (SIZE(32))' - change MAX-ACCESS from 'not-accessible' (current) to 'read-only' - define padding rules for (current) variable length job ID elements - avoids impossible translation to SMIv1 for SMIv2 IMPLIED keyword. Note: Fixed length Job ID elements may be blank padded on the right (eg, NO need to stuff spaces between the MAC address and sequence number), as the high-order key then becomes the format specifier. 2) Based on Xerox's experience with a similar Job ID mapping table - add 'jmJobSetIndex' and 'jmJobIndex' to INDEX of the Job ID table - ensures that ALL jobs appear in table, even w/ duplicate job IDs. Note: Using the IMPLIED keyword on 'jmJobSubmissionID' (no longer the low-order index element) is NOT legal in SMIv2 (RFC 1902, pg 22) - causes a fatal compile error with SMICng (by David Perkins). Tom, I believe it is CRITICAL not to use SMIv2 extensions which FORCE a different 'over-the-wire' encoding between SNMPv1 and SNMPv2 for a given object instance. Doing so would permanently preclude any SNMPv1/SNMPv2 gateway or proxy for the IETF Job Mon MIB (because nobody will translate semantics for unique objects in such a gateway, so this IMPORTANT table will be lost from the remote management station's MIB view). Harry, if a remote client wants to walk the table (with ONE visible column, the high-order index element 'jmJobSubmissionID'), GetNext will work just fine. Unless we change the SYNTAX of 'jmJobSubmissionID' to be 'OCTET STRING (SIZE(32))', to remove the length byte from instance qualifiers by both SMIv1 and SMIv2 encoding rules, and define padding rules for variable length first elements, you CANNOT look for all the jobs with a given job submission ID format, because the high-order key of the 'jmJobIDTable' is ACTUALLY the length of each particular job submission ID value, and NOT the format specifier. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 PS - I made all of the above changes to a copy of the IETF Job Mon MIB V0.82 - it compiled without errors using both the SMICng (1997 version) and Epilogue (1994 and 1996 versions) MIB compilers. From harryl at us.ibm.com Tue Jul 1 12:36:31 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> Conformance/Indexing of Job ID table Message-ID: <5030100004234305000002L052*@MHS> I do not favor such dramatic changes at this late date. I don't see the purpose of most of these changes i.e. they don't appear to make anything work any better. The one change I would support is making jmJobSubmissionID a fixed length string and eliminating the length byte which gets us around the IMPLIED SMIv1/v2 problem. Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 07/01/97 10:24 AM -------- jmp-owner@pwg.org 06/28/97 04:02 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: JMP> Conformance/Indexing of Job ID table Hi Tom and Harry, Saturday (28 June 1997) First, some IETF Job Mon MIB structure/conformance recommendations: 1) Rename the 'jmJobSetIndex' object to 'jmGeneralJobSetIndex' - move the definition from the Job ID group (a subordinate group) to the Job General group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobSetIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 2) Move the 'jmJobIndex' object definition from the Job ID group to the Job (State) group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 3) Do NOT move 'jobOwner' to the Job (State) table, since the Job ID table will overlap (in some implementations) with this attribute. 4) Change the conformance for the Job ID group from 'Mandatory' to 'Optional' - since the Job ID group would no longer contain the two major index objects (and itself consists of long strings). 5) Change the conformance for the Job Attribute group from 'Mandatory' to 'Optional' - since the 'jobOwner' attribute is NOT necessary to find client jobs, if the 'jobOwner' format is used (by the client OR by the managed system) to assign 'jmJobSubmissionID' values (and find entries in the Job ID table). Second, some Job ID table indexing recommendations: 1) Remove length byte, by SMIv1 (RFC 1212, pg 9) and SMIv2 (RFC 1902, pg 21) encoding rules, from instance qualifiers of the Job ID table (without resorting to IMPLIED keyword) by using fixed length strings - change SYNTAX of 'jmJobSubmissionID' to 'OCTET STRING (SIZE(32))' - change MAX-ACCESS from 'not-accessible' (current) to 'read-only' - define padding rules for (current) variable length job ID elements - avoids impossible translation to SMIv1 for SMIv2 IMPLIED keyword. Note: Fixed length Job ID elements may be blank padded on the right (eg, NO need to stuff spaces between the MAC address and sequence number), as the high-order key then becomes the format specifier. 2) Based on Xerox's experience with a similar Job ID mapping table - add 'jmJobSetIndex' and 'jmJobIndex' to INDEX of the Job ID table - ensures that ALL jobs appear in table, even w/ duplicate job IDs. Note: Using the IMPLIED keyword on 'jmJobSubmissionID' (no longer the low-order index element) is NOT legal in SMIv2 (RFC 1902, pg 22) - causes a fatal compile error with SMICng (by David Perkins). Tom, I believe it is CRITICAL not to use SMIv2 extensions which FORCE a different 'over-the-wire' encoding between SNMPv1 and SNMPv2 for a given object instance. Doing so would permanently preclude any SNMPv1/SNMPv2 gateway or proxy for the IETF Job Mon MIB (because nobody will translate semantics for unique objects in such a gateway, so this IMPORTANT table will be lost from the remote management station's MIB view). Harry, if a remote client wants to walk the table (with ONE visible column, the high-order index element 'jmJobSubmissionID'), GetNext will work just fine. Unless we change the SYNTAX of 'jmJobSubmissionID' to be 'OCTET STRING (SIZE(32))', to remove the length byte from instance qualifiers by both SMIv1 and SMIv2 encoding rules, and define padding rules for variable length first elements, you CANNOT look for all the jobs with a given job submission ID format, because the high-order key of the 'jmJobIDTable' is ACTUALLY the length of each particular job submission ID value, and NOT the format specifier. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 PS - I made all of the above changes to a copy of the IETF Job Mon MIB V0.82 - it compiled without errors using both the SMICng (1997 version) and Epilogue (1994 and 1996 versions) MIB compilers. From imcdonal at eso.mc.xerox.com Tue Jul 1 16:14:29 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:07 2009 Subject: JMP> Conformance/Indexing of Job ID table In-Reply-To: Conformance/Indexing of Job ID table> Message-ID: <9707012014.AA08074@snorkel.eso.mc.xerox.com> Hi Harry, Glad you think going to fixed length is a good idea. The other changes aren't especially important, except for the misplaced definitions for job set index and job index (which were also pointed out by David Perkins, recently). I understand from Tom that there is resistance to using the extra indices in the Job ID table to handle duplicates (after all that was the submitting client's screw up, anyway). Without adding them (once the true definitions of the job set index and job index are moved to their respective primary tables, which David Perkins feels is necessary to remove illegal usage and I would certainly say is removing NON-STANDARD usage), you'll need 'shadow' objects in the Job ID table (not indices, just data) to return the matching values for a given client job submission ID. Cheers, - Ira McDonald ------------------------ Harry's note ------------------------ Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA07975; Tue, 1 Jul 97 12:43:10 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA14408; Tue, 1 Jul 97 12:40:12 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <14858(3)>; Tue, 1 Jul 1997 09:40:14 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28482 for ; Tue, 1 Jul 1997 12:36:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 1 Jul 1997 12:35:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28372 for jmp-outgoing; Tue, 1 Jul 1997 12:34:47 -0400 (EDT) From: Harry Lewis To: Subject: JMP> Conformance/Indexing of Job ID table Message-Id: <5030100004234305000002L052*@MHS> Date: Tue, 1 Jul 1997 09:36:31 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R I do not favor such dramatic changes at this late date. I don't see the purpose of most of these changes i.e. they don't appear to make anything work any better. The one change I would support is making jmJobSubmissionID a fixed length string and eliminating the length byte which gets us around the IMPLIED SMIv1/v2 problem. Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 07/01/97 10:24 AM -------- jmp-owner@pwg.org 06/28/97 04:02 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: JMP> Conformance/Indexing of Job ID table Hi Tom and Harry, Saturday (28 June 1997) First, some IETF Job Mon MIB structure/conformance recommendations: 1) Rename the 'jmJobSetIndex' object to 'jmGeneralJobSetIndex' - move the definition from the Job ID group (a subordinate group) to the Job General group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobSetIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 2) Move the 'jmJobIndex' object definition from the Job ID group to the Job (State) group (as the first member of the SEQUENCE) - change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2) - and import it (by reference) into the INDEX of the Job ID table. The current location of the 'jmJobIndex' object is non-standard, because it is NOT defined in the group where it is a primary index. 3) Do NOT move 'jobOwner' to the Job (State) table, since the Job ID table will overlap (in some implementations) with this attribute. 4) Change the conformance for the Job ID group from 'Mandatory' to 'Optional' - since the Job ID group would no longer contain the two major index objects (and itself consists of long strings). 5) Change the conformance for the Job Attribute group from 'Mandatory' to 'Optional' - since the 'jobOwner' attribute is NOT necessary to find client jobs, if the 'jobOwner' format is used (by the client OR by the managed system) to assign 'jmJobSubmissionID' values (and find entries in the Job ID table). Second, some Job ID table indexing recommendations: 1) Remove length byte, by SMIv1 (RFC 1212, pg 9) and SMIv2 (RFC 1902, pg 21) encoding rules, from instance qualifiers of the Job ID table (without resorting to IMPLIED keyword) by using fixed length strings - change SYNTAX of 'jmJobSubmissionID' to 'OCTET STRING (SIZE(32))' - change MAX-ACCESS from 'not-accessible' (current) to 'read-only' - define padding rules for (current) variable length job ID elements - avoids impossible translation to SMIv1 for SMIv2 IMPLIED keyword. Note: Fixed length Job ID elements may be blank padded on the right (eg, NO need to stuff spaces between the MAC address and sequence number), as the high-order key then becomes the format specifier. 2) Based on Xerox's experience with a similar Job ID mapping table - add 'jmJobSetIndex' and 'jmJobIndex' to INDEX of the Job ID table - ensures that ALL jobs appear in table, even w/ duplicate job IDs. Note: Using the IMPLIED keyword on 'jmJobSubmissionID' (no longer the low-order index element) is NOT legal in SMIv2 (RFC 1902, pg 22) - causes a fatal compile error with SMICng (by David Perkins). Tom, I believe it is CRITICAL not to use SMIv2 extensions which FORCE a different 'over-the-wire' encoding between SNMPv1 and SNMPv2 for a given object instance. Doing so would permanently preclude any SNMPv1/SNMPv2 gateway or proxy for the IETF Job Mon MIB (because nobody will translate semantics for unique objects in such a gateway, so this IMPORTANT table will be lost from the remote management station's MIB view). Harry, if a remote client wants to walk the table (with ONE visible column, the high-order index element 'jmJobSubmissionID'), GetNext will work just fine. Unless we change the SYNTAX of 'jmJobSubmissionID' to be 'OCTET STRING (SIZE(32))', to remove the length byte from instance qualifiers by both SMIv1 and SMIv2 encoding rules, and define padding rules for variable length first elements, you CANNOT look for all the jobs with a given job submission ID format, because the high-order key of the 'jmJobIDTable' is ACTUALLY the length of each particular job submission ID value, and NOT the format specifier. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 PS - I made all of the above changes to a copy of the IETF Job Mon MIB V0.82 - it compiled without errors using both the SMICng (1997 version) and Epilogue (1994 and 1996 versions) MIB compilers. From hastings at cp10.es.xerox.com Wed Jul 2 19:03:19 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Request to add unknown(2) to PrtInterpreterLangFamilyTC Message-ID: <9707022305.AA03427@zazen.cp10.es.xerox.com> Printer MIB editor, For use in the Job Monitoring MIB, all enums need to have an unknown(2) value, to cover the case when the agent doesn't know the value. Fortunately, the Printer MIB either used 2 for unknown or didn't allocate 2. Now the Job Monitoring MIB needs unknown(2) to be added to the PrtInterpreterLangFamilyTC in the Printer MIB. Thanks, Tom The new definition will start off with: This value is a type 2 enumeration." SYNTAX INTEGER { other(1), unknown(2), langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard Company. From harryl at us.ibm.com Tue Jul 8 16:38:19 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> JMP FAQ? Message-ID: <5030100004501081000002L012*@MHS> The Job MIB is tending to be fairly "open" with respect to mandatory attributes and jobStateReasons. We've struggled with how this may effect interoperability. Following is an example we've run into that illustrates the problem: Consider a print job that gets canceled by the user (of course, with our trusty camers - ONLY - we have no idea HOW the job got canceled;-). Consider the two main applications monitoring via the Job MIB, 1) the End User job monitor; and 2) the accounting application. We feel the end user, in this situation, wants relatively instant feedback that the job state has changed to CANCELED. But, cancel is a completion state. We envision the accounting application waiting for jobs to be complete then "harvesting" FINAL STATE attribute information. Problem... there is some "intertia" in the print system. If the agent changes state to CANCEL as soon as it becomes aware of the cancel command (to satisfy the end user), there may still be a page or two in the pipeline that the accounting application would miss if it noticed the state change and performed it's data collection. So, we suggest using jobStateReasons in this case. CANCEL - processingToStopPoint which progresses to CANCEL - jobCanceledByUser The question is, since these jobStateReasons are not "mandatory", how do we communicate and agree on this recommendation? In other words, how do we achieve interoperability? I am suggesting a FAQ. I would like your comments on how effective you feel this might be. If a FAQ is not effective, then, should be we deciding on more mandatory attributes? I don't really want to pursue this path unless it is absolutely necessary, because I feel we've been there... and it's UGLY! >>> Harry Lewis <<< From jkm at underscore.com Tue Jul 8 19:11:26 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:07 2009 Subject: JMP> JMP FAQ? In-Reply-To: JMP FAQ?> Message-ID: <199707082311.TAA02915@uscore.underscore.com> You know what's needed here? None other than an equivalent of the Printer MIB's "Top 25 Conditions" summary table. That is, the JMP folks get together and devise the top-most set of job-related scenarios, then determine the values for the relevant Job MIB objects. What say ye? ...jay ----- Begin Included Message ----- From: Harry Lewis To: Subject: JMP> JMP FAQ? Date: Tue, 8 Jul 1997 16:38:19 -0400 The Job MIB is tending to be fairly "open" with respect to mandatory attributes and jobStateReasons. We've struggled with how this may effect interoperability. Following is an example we've run into that illustrates the problem: Consider a print job that gets canceled by the user (of course, with our trusty camers - ONLY - we have no idea HOW the job got canceled;-). Consider the two main applications monitoring via the Job MIB, 1) the End User job monitor; and 2) the accounting application. We feel the end user, in this situation, wants relatively instant feedback that the job state has changed to CANCELED. But, cancel is a completion state. We envision the accounting application waiting for jobs to be complete then "harvesting" FINAL STATE attribute information. Problem... there is some "intertia" in the print system. If the agent changes state to CANCEL as soon as it becomes aware of the cancel command (to satisfy the end user), there may still be a page or two in the pipeline that the accounting application would miss if it noticed the state change and performed it's data collection. So, we suggest using jobStateReasons in this case. CANCEL - processingToStopPoint which progresses to CANCEL - jobCanceledByUser The question is, since these jobStateReasons are not "mandatory", how do we communicate and agree on this recommendation? In other words, how do we achieve interoperability? I am suggesting a FAQ. I would like your comments on how effective you feel this might be. If a FAQ is not effective, then, should be we deciding on more mandatory attributes? I don't really want to pursue this path unless it is absolutely necessary, because I feel we've been there... and it's UGLY! >>> Harry Lewis <<< ----- End Included Message ----- From harryl at us.ibm.com Tue Jul 8 22:49:29 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> JMP FAQ? In-Reply-To: JMP FAQ?> Message-ID: <5030100004516292000002L022*@MHS> Agreed, as long as it doesn't open the MIB for re-design! But a top 25 list of uses, based on the current MIB, would be an excellent idea. Harry Lewis - IBM Printing Systems -------- Forwarded by Harry Lewis/Boulder/IBM on 07/08/97 08:46 PM --------- jkm@underscore.com 07/08/97 05:56 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: jmp@pwg.org @ internet Subject: Re: JMP> JMP FAQ? You know what's needed here? None other than an equivalent of the Printer MIB's "Top 25 Conditions" summary table. That is, the JMP folks get together and devise the top-most set of job-related scenarios, then determine the values for the relevant Job MIB objects. What say ye? ...jay ----- Begin Included Message ----- From: Harry Lewis To: Subject: JMP> JMP FAQ? Date: Tue, 8 Jul 1997 16:38:19 -0400 The Job MIB is tending to be fairly "open" with respect to mandatory attributes and jobStateReasons. We've struggled with how this may effect interoperability. Following is an example we've run into that illustrates the problem: Consider a print job that gets canceled by the user (of course, with our trusty camers - ONLY - we have no idea HOW the job got canceled;-). Consider the two main applications monitoring via the Job MIB, 1) the End User job monitor; and 2) the accounting application. We feel the end user, in this situation, wants relatively instant feedback that the job state has changed to CANCELED. But, cancel is a completion state. We envision the accounting application waiting for jobs to be complete then "harvesting" FINAL STATE attribute information. Problem... there is some "intertia" in the print system. If the agent changes state to CANCEL as soon as it becomes aware of the cancel command (to satisfy the end user), there may still be a page or two in the pipeline that the accounting application would miss if it noticed the state change and performed it's data collection. So, we suggest using jobStateReasons in this case. CANCEL - processingToStopPoint which progresses to CANCEL - jobCanceledByUser The question is, since these jobStateReasons are not "mandatory", how do we communicate and agree on this recommendation? In other words, how do we achieve interoperability? I am suggesting a FAQ. I would like your comments on how effective you feel this might be. If a FAQ is not effective, then, should be we deciding on more mandatory attributes? I don't really want to pursue this path unless it is absolutely necessary, because I feel we've been there... and it's UGLY! >>> Harry Lewis <<< ----- End Included Message ----- From lpyoung at lexmark.com Wed Jul 9 07:27:39 1997 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:07 2009 Subject: JMP> JMP FAQ? In-Reply-To: JMP FAQ?> Message-ID: <199707091127.AA01808@interlock2.lexmark.com> I agree with Jay that I think a list of "Top 25 Job Conditions" would be the best way of handling the ambiguity of how to report various job states. Lloyd Young From hastings at cp10.es.xerox.com Wed Jul 9 21:20:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> ISSUE: split jmAttributeTable or not Message-ID: <9707100122.AA04937@zazen.cp10.es.xerox.com> At 01:18 06/27/97 PDT, David T. Perkins wrote: snip... >There is one change that would affect any current implementations >that I strongly suggest that you do. Table jmAttributeTable has >three accessible columnar objects. The first tells you the "type" >(either integer, octet, or both) of the value of the attribute. >The second two columns are the attribute's value. I suggest that >instead of this single table, that you have two tables. Each table >would have a single accessible column. The first table would contain >integer valued attributes, and the second table would contain >octet string valued attributes. [David did not mention that there is actually a fourth index which is an "instance" index for those attributes that can have more than one value per job. I'm not sure whether this fact changes the argument or not.] snip... We need to consider this suggestion and either accept it or justify why not. Lets get collected comments (such as Harry's below) and respond to David. David is a noted authority on SNMP, so accommodating his comments will help forward our document. Xerox developers have several views and we are in the process of reaching a consensus (I'll send you results Thursday, 7/10). Harry Lewis's developers have made a review and are not convinced that it is a good idea to split the table: >Return-Path: >From: Harry Lewis >To: >Cc: , , >Subject: Splitting the Attribute Table >Date: Wed, 9 Jul 1997 10:52:02 PDT > >Tom, we have conducted a review here, regarding your recommendation >to split the attribute table into two tables - one for Integer values >and one for Octets - and are of the opinion that the current attribute >table is superior. Here is our summary. > >1. First, we assume that attributes will have a null string for the >valueAsOctet and -2 for valueAsInteger if appropriate. > >2. With GetNext, we do not believe network traffic is an issue because >the "extra" null string or -2 will fit in the PUD packet. > >3. We believe, using get next, there are less calls required with the >current scheme than would be needed if the table was split. > >Example: > > Integer Octet > ------- ----- > > -2 X > X Null > X X > X Null > -2 X > > >Consider the above excerpt. It will take 5 get next calls using the current >method. But it would take 6 calls if the table were split (one for each X >which represents a real value). > >4. While, in most cases, the monitor will know whether or not the attribute >is defined as Integer, Octet or Both... there are cases where it could >be EITHER. With the current scheme, the monitor "finds out" what this >particular device has instrumented in one get next (for each attribute). >With split tables, you have to look in both tables to know (this may >just be a restatement of (3) above). > >5. There is no storage savings in the agent if done properly, where the >agent knows which syntax is being used. > >Tom, this is our summary. I think the ball is "in your court" to decide >whether or not to open this problem to a wider audience, send us a >DETAILED "rebuttal" or accept our findings. > > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed Jul 9 21:09:19 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:07 2009 Subject: JMP> Review of Job Monitoring MIB [from David Perkins] Message-ID: <9707100111.AA04934@zazen.cp10.es.xerox.com> Most of these comments are editorial, so I'm in the process of editing them in. I've finished all of the agreements from Nashua and am working on editorial stuff from David and Ron Bergman. There are three substantive issues: 1. Should we split up the jmAttribute table into two tables or not? 2. We have illegal indexing in the jmGeneralTable and jmJobTable according to SMI rules, so I've edited those fixes in, so that the IETF won't delay our MIB over such an issue. See jmp-oids.doc for the effect on the OIDs that I posted in the contributions/ sub-directory. 3. How does the application find out about which coded character set the text objects and attributes are using? I'll send out a separate mail message on the first and third issues, so reply on those issues to that mail message, not to this one, so we can have a focused discussion. I want to resolve these issues quickly (this week, if possible), as I'm just about finished with all of the other editing. Thanks, Tom >Return-Path: >Reply-To: >From: "David T. Perkins" >To: , , >Subject: Review of Job Monitoring MIB >Date: Fri, 27 Jun 1997 01:18:07 PDT >X-Msmail-Priority: Normal > >HI > >I finished looking over the document. (I spent about 5 hours) >In general, the objects that are defined in the MIB module are >relatively few in number and easy to understand. However, the >document has some problems and the MIB module has some problems >that can be easily solved without changing the semantics of >the MIB objects or losing any capabilities. > >There is one change that would affect any current implementations >that I strongly suggest that you do. Table jmAttributeTable has >three accessible columnar objects. The first tells you the "type" >(either integer, octet, or both) of the value of the attribute. >The second two columns are the attribute's value. I suggest that >instead of this single table, that you have two tables. Each table >would have a single accessible column. The first table would contain >integer valued attributes, and the second table would contain >octet string valued attributes. > >On the document itself, none of the cross references seemed valid! >In general you have way too much text in the descriptions for the >textual conventions and objects that should be in the text that >comes before the MIB module. > >The MIB and the agent don't "instrument" a managed device. An SNMP >agent provided access to instrumentation. Thus, many times throughout >the document were I saw sentences like the following, it would cause >me to grit my teeth: > An agent is the network entity that accepts SNMP requests from a > monitor and implements the Job Monitoring MIB by instrumenting > a server or a device. >This is not correct! A correction of the above text is the following >text: > An agent is the network entity that accepts SNMP requests from a > monitor (an SNMP management application) and provides access to the > instrumentation for managing jobs modeled by the management objects > defined in the Job Monitoring MIB module. > >The reason why the original text is not correct is that the instrumentation >is independent of the mechanism used to access the management information. >That is, the instrumentation could have a local interface so that a >program could be run on the server or device that displayed management >information on a local console. > >On your configurations of printers-clients-servers, you specify three >and say that configuration 2 is not the design center for the document. >I don't understand. I think that configuration 2 would be the most common >and think that configuration 3 is unworkable. (How would configuration 3 >work if there were a pool of printers?) > >The approach to specifying conformance is quite inappropriate. SMIv2 has >a well defined mechanism which is not being used properly. Yes you have >a module compliance specification, but you also have compliance >specifications all through the MIB module in ASN.1 comments. You need to >remove the ASN.1 comments with compliance specifications. In the text >of the document, you simply specify the compliance specifications by >referencing the one or more module compliance specifications in the >MIB module! >The conformances for management applications is sort of silly. You >basically say that they cannot have bugs and must correctly implement >and use SNMP. This is silly and should be removed. > >The module has a problem with all the objects that have type of OCTET >STRING. >You really need to enforce a code-point mapping. Consider a management >application. What are they to do with the values? Do they try to figure >out the encoding, or ask the user of the application for a hint, or what? > >The text of section 8.1 is invalid. No other definition of MIB objects >can cause the access for MIB objects in the current module to change. > >The text of section 9 is bogus to the max. The "normal SNMP practice" that >you describe does not exist. What you really want to say is something like >the following: > > 9. Values for Objects > SNMP requires that if an object cannot be implemented because its values > cannot be accessed, then a compliant agent must return an SNMP error in > SNMPv1 or an exception value in SNMPv2. This MIB has been designed so >that > all objects can be implemented. In general, values for objects have been > chosen so that a management application will be able to determine if > a useful value is available for an object. The approach is to define > the value 'unknown(2)' for enums, the value '-2' for integers, and the > zero length string for octet strings to mean that a useful value is > not available for an object. > >Section 10 should be called just "Notifications" and not "Notifications >and Traps". The first sentence should be "this MIB module does not specify >any notifications." > >At the beginning of the MIB module, you did a good thing by providing the >RFC editor with instructions for what to do when the document is published. >However, the details were not quite correct. You cannot have the definition >"temp OBJECT IDENTIFIER ::= { experimental 54 }" before the module identity >construct. You should delete the definition "temp OBJECT IDENTIFIER ::= { >experimental 54 }, and specify the value for jobmonMIB as >{ experimental 54 105 }, and fix the editing instructions in the comment >before the module compliance. > >Throughout the MIB module the text references pages and items in the >reference section. This is a really bad thing to do, since these references >will have not meaning after the MIB module is extracted from the document! >Get rid of them. In the description for the module identity, create >short labels for items found in the references section of the document, >and use those labels in text in the MIB module. For example, to reference >RFC 1213, you might add the following in the description: > [MIB-2] - RFC 1213 >And specify "[MIB-2]" in your other descriptions, instead of [5] from your >references section of the document. > >Add the WG email and WEB site in the CONTACT-INFO description text. I'm >sure >that you do not want to be contacted by every university student that >was assigned a project to write a management application that uses the >job monitoring MIB. > >All the ASN.1 comments for each enumerated value should be in the >description >text for the TC. Thus, a TC definition should look something like the >following: > MyTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "bla..bla..bla.. > The values are: > v1(1)...bla-bla-bla > v2(2)...bla-bla-bla > ... > vn(n)...bla-bla-bla" > SYNTAX INTEGER {v1(1), v2(2), ...vn(n)} > >In general, you provide text in the descriptions for the TCs and the values >of the TCs that should go in the text of the document. > >Figure 4 for TC JmJobState is messed up (due to formatting problems?). > >The description for TC jmAttributeTypeTC is quite bogus. It is not longer >needed, if you follow my suggestion above. > >The indexing for tables jmGeneralTable and jmJobTable is illegal. (just >because RMON-2 and a could other MIBs did something like this does not >make it legal.) > >Several of your objects need a units clause, such as >jmGeneralJobPersistence. > >I believe that the "helpful note" in the description for row jmJobIdEntry >will cause more confusion than provide help. > >You have a typo for the RFC number of the printer MIB. It should be >RFC 1759 and not RFC 1579. > >That's it for now. >Regards, >/david t. perkins > > > From harryl at us.ibm.com Thu Jul 10 12:12:02 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:07 2009 Subject: JMP> ISSUES 111 and 112: How does APP determine coded charac Message-ID: <5030100004587903000002L032*@MHS> Regarding the two new Job MIB localization issues, my comments begin with : ISSUE 111: Add jmGeneralCodedCharacterSet object that specifies the coded character set of the server or device that the agent is instrumenting as suggested by David Perkins? Then a management application could discover the coded character set for the jmGeneralJobSetName object and the following job attributes: processingMessage, deviceNameRequested, queueNameRequested, physicalDevice (name), outputBin (name), mediumRequested (name), mediumConsumed (name), colorantRequested (name), colorantConsumed (name). First, what distinction are you trying to achieve with TWO objects? The intuitive difference would seem to be that jmGeneralCodedCharacterSet applies to strings generated by the agent and jobCodedCharacterSet applies to strings passed in on submission. But I don't think your set splits out that way. My problem with trying to address localization in the Job MIB, in general, is that many job attributes are passed to the agent during job submission. If the submission protocol (PJL, for example) does not support localization, the agent will be unable to reflect any intelligent information with respect to jmGeneralCodedCharacterSet. ISSUE 112: Add jobCodedCharacterSet attribute, so that a client can determine the coded character set that each submitter used as suggested by David Perkins? Aligns with IPP "user-locale" attribute. Then a management application could discover the coded character set of the jobOwner job object and the following job attributes that are submitted with the job in a character set specified by the submitter (and it is unlikely that the agent/device would code convert them to the coded character set of the agent/device): other, unknown, jobAccountName, serverAssignedName, jobName, submittingServerName, submittingApplicationName, jobOriginatingHost, fileName, documentName, and jobComment. If some submission protocols (IPP) support localization, and we want an object for these cases, it may be appropriate, but ONLY if we accommodate submission protocols which lack localization support as a default. Until it is made absolutely clear how this default would operate, I voice in opposition to issues 111 and 112. Harry From hastings at cp10.es.xerox.com Thu Jul 10 20:17:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> RE: Localization in the Job MIB [and question about PJL] Message-ID: <9707110020.AA05250@zazen.cp10.es.xerox.com> A quick lesson in coded character sets (I was the chairman of the ANSI X3L2 committee responsible for ASCII (and worked on ISO 8859 and ISO 10646): 1. The coded character set called ASCII is defined to be the control characters 0 through 31 and the printing characters 32 (SPACE) through 126. 127 is DEL (a control) and 128 to 255 are NOT part of the ASCII coded character set. So ASCII is really a 7-bit set that is usually embedded in an 8-bit transmission, so that the high order bit SHALL be 0. Unfortunately, people use the term "ASCII" to mean any coded character set, such as the PJL manual. (Don't feel bad, you are not alone). 2. ISO Latin-1 (ISO 8859-1) is one of the 8-bit coded character sets which defined printing characters only: 32 to 126 (same as ASCII fortunately), and 160 to 255. The characters in 160-255 are accented letters and special symbols, such as pound and yen, more quotes, etc. There are at least 11 8-bit coded character sets defined by ISO 8859-n. The windows default character set is ISO Latin-1 plus Microsoft filled in additional characters in the unspecified space: 128-159. HP has an 8-bit coded character set that is similar to ISO Latin-1. (I've forgotten the name). Presumably, if a PJL printer gets an attribute with the 8th bit set, and that is the value of an attribute that the Printer prints on the banner page, such as the user's name, then some coded character set is being used for the codes in the range 128-255. So what does PJL do with characters greater than 127? Is it ISO Latin-1? Is it the HP 8-bit set? Is is Windows default 8-bit set? Unspecified so it can be any? The administrator can set the default set locally for the printer? Thanks, Tom At 15:33 07/09/97 PDT, Bob Pentecost wrote: >Harry, > >You are very close to being correct. To quote the PJL Tech Ref Manual, PJL "strings consist of any combination of characters from ASCII 32 through 255, plus ASCII 9 (horizontal tab), excluding ASCII 34 (quotation marks)." There is no localization information provided. > >Bob > > >---------- >From: Harry Lewis[SMTP:harryl@us.ibm.com] >Sent: Wednesday, July 09, 1997 3:32 PM >To: hastings@cp10.es.xerox.com >Cc: jmk@underscore.com; bpenteco@boi.hp.com; rbergma@dpc.com >Subject: Localization in the Job MIB > >Tom, I think it was David Perkins who wrote (about the Job MIB)... > >>For simplicity, this specification assumes that the clients, job monitoring >>applications, servers, and devices are all running in the same locale. >>However, this specification allows them to run in any locale, including >>locales that use two-octet coded character sets, such as ISO 10646 >>(Unicode). Job monitors applications are expected to understand the coded >>character set of the client (and job), server, or device. No special means >>is provided for the monitor to discover the coded character set used by jobs >>or by the server or device. This specification does not contain an object >>that indicates what locale the server or device is running in, let alone >>contain an object to control what locale the agent is to use to represent >>coded character set objects. > >While I sympathize with the localization problem - (I think I'm beginning >to understand Ira's arguments as they pertain to the Printer MIB), I think >we have a real limitation in the Job MIB in that we are ultimately limited >by the Job Submission protocol or language. Bob can correct me if I'm wrong, >but if we take PJL as an example of a pervasive submission language the >attributes passed in will be limited to ASCII characters 32 to 225 plus >"tab". I don't think there is a way to localize these strings or for the >agent to determine the local - but I could be wrong. > >If we want to do something to accommodate submission protocols which *do* >facilitate localization of passed in attributes, we may entertain this, >but only if it allows for status-quo as a default. > >Harry Lewis - IBM Printing Systems > > > > From hastings at cp10.es.xerox.com Thu Jul 10 22:31:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> ISSUES 111 and 112: How does APP determine coded In-Reply-To: ISSUES 111 and 112: How does APP determine coded> Message-ID: <9707110233.AA05296@zazen.cp10.es.xerox.com> At 09:12 07/10/97 PDT, Harry Lewis wrote: >Regarding the two new Job MIB localization issues, my comments begin with : > >ISSUE 111: Add jmGeneralCodedCharacterSet object that specifies the coded >character set of the server or device that the agent is instrumenting as >suggested by David Perkins? Then a management application could discover >the coded character set for the jmGeneralJobSetName object and the following >job attributes: processingMessage, deviceNameRequested, queueNameRequested, >physicalDevice (name), outputBin (name), mediumRequested (name), >mediumConsumed (name), colorantRequested (name), colorantConsumed (name). > > First, what distinction are you trying to achieve with TWO objects? >The intuitive difference would seem to be that jmGeneralCodedCharacterSet >applies to strings generated by the agent and jobCodedCharacterSet applies >to strings passed in on submission. But I don't think your set splits out >that way. You are right! I blew it when making the two lists. I was trying to split the list between objects and attributes that are ONLY supplied by the server/device and those that are supplied by the job submitter. However, when I made the list, I realized that some of the strings supplied by the submitter might naturally get code converted to the set of the server/device, if they were different, in order for the server/device to match with something that the server/device offerred, such as media or output bin. But since some implementations may code convert and some may not and the code conversion may depend on which attribute and vary from implementation to implementation, I should only include objects and attributes that relate to jmGeneralCodedCharacterSet object that come ONLY from the server/device. Anything that comes from the submitter should remain in the coded character set of the submitter when returned by the SNMP agent (whether the implementation code converts internally or not). So the (short) list of objects and attributes that the jmGeneralCodedCharacterSet describe are: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute all the other objects and attributes are specified by the requester (or as we recently agreed, could be defaulted by the server/device). See next issue (112) for the long list. We would have to clarify that if the server/device default strings, then the server/device MUST use the coded character set of the submitter. Otherwise, we would need a tag on each string that says what coded character set it is in. > > My problem with trying to address localization in the Job MIB, in >general, is that many job attributes are passed to the agent during job >submission. If the submission protocol (PJL, for example) does not >support localization, the agent will be unable to reflect any intelligent >information with respect to jmGeneralCodedCharacterSet. I'm not sure I understand your concern here. I think that jmGeneralCodedCharacterSet is the same as the prtLocalizationCharacterSet for the current localization. But since we don't want to require that the Printer MIB be implemented, the value of jmGeneralCodedCharacterSet would be a copy of the enum that is in the prtLocalizationCharacterSet for the current row specified by the prtGeneralCurrentLocalization. And it only controls the three objects/attribtes: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute In IPP, the Printer's "printer-locale" attribute supplies the coded character set enum for the jmGeneralCodedCharacterSet object. Ok? > >ISSUE 112: Add jobCodedCharacterSet attribute, so that a client can >determine the coded character set that each submitter used as suggested by >David Perkins? Aligns with IPP "user-locale" attribute. Then a management >application could discover the coded character set of the jobOwner job >object and the following job attributes that are submitted with the job in a >character set specified by the submitter (and it is unlikely that the >agent/device would code convert them to the coded character set of the >agent/device): other, unknown, jobAccountName, serverAssignedName, jobName, >submittingServerName, submittingApplicationName, jobOriginatingHost, >fileName, documentName, and jobComment. > > If some submission protocols (IPP) support localization, and we >want an object for these cases, it may be appropriate, but ONLY if >we accommodate submission protocols which lack localization support as >a default. I quite agree that we need to accomodate those protocols that do not support localization. But we also need to support IPP. IPP has the "user-locale" attribute that is submitted with the job. The coded character set part of that value would supply the value for the IETF Job Monitoring MIB jobCodedCharacterSet attribute. So the list of objects and attributes that the jobCodedCharacterSet attribute would describe include: IETF Job object/attributes Equivalent IPP attributes -------------------------- ------------------------- jmJobOwner object "job-originating-user" other, - unknown, - serverAssignedJobName, - jobName, "job-name" jobAccountName, - submittingServerName, - submittingApplicationName, - jobOriginatingHost, "job-originating-host" deviceNameRequested, "printer-uri" queueNameRequested, - fileName, "document-uri" documentName, "document-name" jobComment, - outputBin (name), - mediumRequested (name), "media" mediumConsumed (name), - colorantRequested (name), - colorantConsumed (name) - [If we add jobCodedCharacterSet and jmGeneralCodedCharacerSet, they will be constrained to be ASCII] Ok? > > Until it is made absolutely clear how this default would operate, I >voice in opposition to issues 111 and 112. I agree. I'll make a new complete proposal, including the default and see what you (and JMP) think. The gist would be: 1. agents that know what the (current or fixed) coded character set of the server/device (for the 3 objects/attribute affected) is SHALL put that value in the jmGeneralCodedCharacterSet object. Otherwise, the agent SHALL put the unknwon(2) value for the jmGeneralCodedChararacterSet object. 2. agents that know what the coded character set of the submitter is because the submitter submitted it as an attribute as in DPA and IPP in the job submission protocol SHALL implement and set that value in the jobCodedCharacterSet attribute for the job. 3. agents that assume that the coded character set of the submitter is the same as that of the server/device, MAY, but NEED NOT, implement the jobCodedCharacterSet attribute. So if an application first checks jmGeneralCodedCharacterSet, the application knows what the code set is for: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute Then the application checks for jobCodedCharacterSet attribute. If the attribute is found, then the application knows the character set of the submitted objects and attributes. If the jobCodedCharacterSet attribute is NOT found, then the application assumes that it is the same as jmGeneralCodedCharacterSet. If the PJL server/device is ASCII and assumes that the submitter is submitting in ASCII, then the agent would set the ASCII enum as the value of the jmGeneralCodedCharacterSet and would NOT need to implement the jobCodedCharacterSet attribute. Comments? Tom > >Harry > > From harryl at us.ibm.com Fri Jul 11 01:39:51 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> Nashua JMP Minutes Message-ID: <5030100004622219000002L092*@MHS> I have posted the June JMP minutes to ftp/pub/pwg/jmp/minutes/jmp-0697.pdf and txt. The minutes are quite brief. See Tom Hastings issues for more detail. A PLT (pretty lousy text) version is attached... Minutes of the PWG - JMP Nashua, June, 1997 IETF Disclaimer Although decisions regarding the development of IETF standards are ultimately wrought via the internet, face-to-face meetings of interested parties capable of attending can often accelerate the consensus process. The PWG facilitates such meetings on a monthly basis for active workgroups. These are the (very brief) minutes of the PWG meeting of the Job MIB Project which currently pertains directly to the IETF chartered Job MIB working group. JMP Meeting The PWG JMP meeting started after dinner on Thursday, June 26. The meeting ran from appx. 8pm to 11pm. The JMP meeting continued Friday, June 27 between 8:30AM and 12:30PM. During these two meetings, all known outstanding issues were covered, discussed and resolved among the attendees. See Tom Hastings PWG ftp/pub/pwg/jmp/contributions/ISSUES.pdf for complete details. Two issues resulted in structural change to the MIB. 1. Moving the attribute JobOwner directly into the JobStateTable. This was to accommodate "out-of'band" UNIX spool and print job monitors which use JobOwner as a key identifier. 2. Enlarging jmJobSubmissionID to 48 bytes total, swapping the order of the numeric vs. string parts and making this object fixed length. Two other issues have been introduced by Xerox post meeting. One, a severe change, is the recommendation to split the attribute table into separate tables for Integer and Octet values. Currently, a job attribute may have an Integer and/or Octet value, both of which are represented in the same table entry. The other new issue pertains to localization. Again, see Tom's updated issues list. There was overriding consensus at the Nashua JMP meeting that no further issues are to be encouraged! This consensus should be tested via the mailing list for IETF purposes. We did not pass a sign-up sheet, but this is my best recollection of who attended the Nashua JMP. Please feel free to correct this list. * Lee Farrell - Canon * Jeff Copeland - QMS * Bob Pentecost - HP * Tom Hastings - Xerox * Harry Lewis - IBM * Stuart Rowley - Kyocera * J.K. Martin - Underscore * Chuck Adams - Tektronix * Rick Landau - Digital * Angelo Caruso - Xerox * Jasper Wong - Xionics * Charles Gordon - Osicom * David Kellerman - Northlake Software * Lloyd Young - Lexmark * Jeff Rackowitz - Intermec Corp Harry Lewis - IBM Printing Systems rent From imcdonal at eso.mc.xerox.com Fri Jul 11 09:49:13 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:08 2009 Subject: JMP> RE: Localization in the Job MIB [and question about PJL] In-Reply-To: RE: Localization in the Job MIB [and question about PJL]> Message-ID: <9707111349.AA11300@snorkel.eso.mc.xerox.com> Hi Bob and Harry, Tom, thanks for clarifying the point I've been trying to make for the last three months, to whit, "There is no such thing as 8-bit ASCII". Harry, Xerox will use private MIB objects (probably) to determine usable full 'static locale' for the strict ASCII objects in the printer MIB. Note that since the Printer MIB only says they shall be in ASCII, they may NOT contain any character with the high-order bit set (eg, all ISO 8859-n character sets are precluded, because all of their 'useful' non-ASCII characters are in the high end). Following the advice of RFC 2130, we expect to clarify (in private MIB objects, which we'll publish, if I can convince enough of the 'Intellectual Property' types around Xerox) that the TES (Transfer Encoding Syntax) of these Printer MIB strings is US-ASCII, that the CES (Character Encoding Scheme) is UTF-7 (so-called 'mail-safe' transformation of UCS-2, in RFC 2152), and that the underlying CCS (Coded Character Set) is UCS-2 (per ISO 10646). In the cases where Unicode is not suitable, we may have to use other underlying CCS's (and of course also different) CES's. If IANA registries provide enum's for all of these, then we'll use them - otherwise, we'll define our own (private) enum's. My FujiXerox compatriots are not very happy with the PWG right now, but we still have fully internationalized product to get out the door, so we won't wait for Printer MIB v3 to adopt a fix. Scott Isaacson, be careful that your implementors do NOT put either straight Unicode (UCS-2) or 8-bit UTF-8 into the 'ptrChannelInformation' object as data. As the Printer MIB v2 is written, that is strictly forbidden. To use Unicode, you must fold it into UTF-7 (pure US-ASCII output). Feedback from any PWG members on localization issues is much appreciated. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ----------------------------- Tom's note ---------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA11143; Thu, 10 Jul 97 23:52:29 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA20968; Thu, 10 Jul 97 23:49:29 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <54246(6)>; Thu, 10 Jul 1997 20:49:18 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18594 for ; Thu, 10 Jul 1997 20:27:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 10 Jul 1997 20:26:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18485 for jmp-outgoing; Thu, 10 Jul 1997 20:25:41 -0400 (EDT) Message-Id: <9707110020.AA05250@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 17:17:49 PDT To: Bob Pentecost From: Tom Hastings Subject: JMP> RE: Localization in the Job MIB [and question about PJL] Cc: jmp@pwg.org Sender: jmp-owner@pwg.org Status: R A quick lesson in coded character sets (I was the chairman of the ANSI X3L2 committee responsible for ASCII (and worked on ISO 8859 and ISO 10646): 1. The coded character set called ASCII is defined to be the control characters 0 through 31 and the printing characters 32 (SPACE) through 126. 127 is DEL (a control) and 128 to 255 are NOT part of the ASCII coded character set. So ASCII is really a 7-bit set that is usually embedded in an 8-bit transmission, so that the high order bit SHALL be 0. Unfortunately, people use the term "ASCII" to mean any coded character set, such as the PJL manual. (Don't feel bad, you are not alone). 2. ISO Latin-1 (ISO 8859-1) is one of the 8-bit coded character sets which defined printing characters only: 32 to 126 (same as ASCII fortunately), and 160 to 255. The characters in 160-255 are accented letters and special symbols, such as pound and yen, more quotes, etc. There are at least 11 8-bit coded character sets defined by ISO 8859-n. The windows default character set is ISO Latin-1 plus Microsoft filled in additional characters in the unspecified space: 128-159. HP has an 8-bit coded character set that is similar to ISO Latin-1. (I've forgotten the name). Presumably, if a PJL printer gets an attribute with the 8th bit set, and that is the value of an attribute that the Printer prints on the banner page, such as the user's name, then some coded character set is being used for the codes in the range 128-255. So what does PJL do with characters greater than 127? Is it ISO Latin-1? Is it the HP 8-bit set? Is is Windows default 8-bit set? Unspecified so it can be any? The administrator can set the default set locally for the printer? Thanks, Tom At 15:33 07/09/97 PDT, Bob Pentecost wrote: >Harry, > >You are very close to being correct. To quote the PJL Tech Ref Manual, PJL "strings consist of any combination of characters from ASCII 32 through 255, plus ASCII 9 (horizontal tab), excluding ASCII 34 (quotation marks)." There is no localization information provided. > >Bob > > >---------- >From: Harry Lewis[SMTP:harryl@us.ibm.com] >Sent: Wednesday, July 09, 1997 3:32 PM >To: hastings@cp10.es.xerox.com >Cc: jmk@underscore.com; bpenteco@boi.hp.com; rbergma@dpc.com >Subject: Localization in the Job MIB > >Tom, I think it was David Perkins who wrote (about the Job MIB)... > >>For simplicity, this specification assumes that the clients, job monitoring >>applications, servers, and devices are all running in the same locale. >>However, this specification allows them to run in any locale, including >>locales that use two-octet coded character sets, such as ISO 10646 >>(Unicode). Job monitors applications are expected to understand the coded >>character set of the client (and job), server, or device. No special means >>is provided for the monitor to discover the coded character set used by jobs >>or by the server or device. This specification does not contain an object >>that indicates what locale the server or device is running in, let alone >>contain an object to control what locale the agent is to use to represent >>coded character set objects. > >While I sympathize with the localization problem - (I think I'm beginning >to understand Ira's arguments as they pertain to the Printer MIB), I think >we have a real limitation in the Job MIB in that we are ultimately limited >by the Job Submission protocol or language. Bob can correct me if I'm wrong, >but if we take PJL as an example of a pervasive submission language the >attributes passed in will be limited to ASCII characters 32 to 225 plus >"tab". I don't think there is a way to localize these strings or for the >agent to determine the local - but I could be wrong. > >If we want to do something to accommodate submission protocols which *do* >facilitate localization of passed in attributes, we may entertain this, >but only if it allows for status-quo as a default. > >Harry Lewis - IBM Printing Systems > > > > From bpenteco at boi.hp.com Fri Jul 11 17:05:33 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:08 2009 Subject: JMP> RE: Localization in the Job MIB [and question about PJL] Message-ID: <01BC8E0C.1FFA9980@hpb15510.boi.hp.com> Tom, Here are some answers for you. > ---------- From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] > Sent: Thursday, July 10, 1997 6:18 PM > To: Bob Pentecost > Cc: jmp@pwg.org > Subject: RE: Localization in the Job MIB [and question about PJL] >=20 > A quick lesson in coded character sets (I was the chairman of the ANSI > X3L2 committee responsible for ASCII (and worked on ISO 8859 and ISO = 10646): >=20 > 1. The coded character set called ASCII is defined to be the control > characters 0 through 31 and the printing characters 32 (SPACE) through > 126. 127 is DEL (a control) and 128 to 255 are NOT part of the ASCII > coded character set. So ASCII is really a 7-bit set that is usually > embedded in an 8-bit transmission, so that the high order bit SHALL be = 0. >=20 > Unfortunately, people use the term "ASCII" to mean any coded character = set, > such as the PJL manual. (Don't feel bad, you are not alone). I'll see if I can get a correction made to the PJL manual. >=20 > 2. ISO Latin-1 (ISO 8859-1) is one of the 8-bit coded character sets = which > defined printing characters only: 32 to 126 (same as ASCII = fortunately), > and 160 to 255. The characters in 160-255 are accented letters and > special symbols, such as pound and yen, more quotes, etc. There are > at least 11 8-bit coded character sets defined by ISO 8859-n. > The windows default character set is ISO Latin-1 plus Microsoft filled > in additional characters in the unspecified space: 128-159. >=20 > HP has an 8-bit coded character set that is similar to ISO Latin-1. > (I've forgotten the name). You're probably thinking of Roman 8. >=20 > Presumably, if a PJL printer gets an attribute with the 8th bit set, > and that is the value of an attribute that the Printer prints on > the banner page, such as the user's name, then some coded character > set is being used for the codes in the range 128-255. The only place (I can find) that characters are displayed/printed is the = RDYMSG command, which causes the string to be displayed on the control = panel. >=20 > So what does PJL do with characters greater than 127? =20 They are treated the same as the characters 9, 32, 33 and 35-127.=20 > Is it ISO Latin-1? No > Is it the HP 8-bit set? Yes, Roman 8 unless the printer localization is Japanese, in which case = the JIS X0201-76 symbol set is used. > Is is Windows default 8-bit set? No. > Unspecified so it can be any? For strings that are not displayed/printed, such as JOB NAME =3D = "string", there is no character set associated by the printer.=20 > The administrator can set the default set locally for the printer? If the printer localization is anything but Japanese, Roman 8 is used = when a string must be displayed. As mentioned above, selecting Japanese = causes the JIS X0201-76 symbol set to be used. >=20 > Thanks, You're welcome. > Tom Bob >=20 >=20 > At 15:33 07/09/97 PDT, Bob Pentecost wrote: > >Harry, > > > >You are very close to being correct. To quote the PJL Tech Ref = Manual, PJL > "strings consist of any combination of characters from ASCII 32 = through 255, > plus ASCII 9 (horizontal tab), excluding ASCII 34 (quotation marks)." = There > is no localization information provided. > > > >Bob > > > > > >---------- > >From: Harry Lewis[SMTP:harryl@us.ibm.com] > >Sent: Wednesday, July 09, 1997 3:32 PM > >To: hastings@cp10.es.xerox.com > >Cc: jmk@underscore.com; bpenteco@boi.hp.com; rbergma@dpc.com > >Subject: Localization in the Job MIB > > > >Tom, I think it was David Perkins who wrote (about the Job MIB)... > > > >>For simplicity, this specification assumes that the clients, job = monitoring > >>applications, servers, and devices are all running in the same = locale. > >>However, this specification allows them to run in any locale, = including > >>locales that use two-octet coded character sets, such as ISO 10646 > >>(Unicode). Job monitors applications are expected to understand the = coded > >>character set of the client (and job), server, or device. No = special means > >>is provided for the monitor to discover the coded character set used = by jobs > >>or by the server or device. This specification does not contain an = object > >>that indicates what locale the server or device is running in, let = alone > >>contain an object to control what locale the agent is to use to = represent > >>coded character set objects. > > > >While I sympathize with the localization problem - (I think I'm = beginning > >to understand Ira's arguments as they pertain to the Printer MIB), I = think > >we have a real limitation in the Job MIB in that we are ultimately = limited > >by the Job Submission protocol or language. Bob can correct me if I'm = wrong, > >but if we take PJL as an example of a pervasive submission language = the > >attributes passed in will be limited to ASCII characters 32 to 225 = plus > >"tab". I don't think there is a way to localize these strings or for = the > >agent to determine the local - but I could be wrong. > > > >If we want to do something to accommodate submission protocols which = *do* > >facilitate localization of passed in attributes, we may entertain = this, > >but only if it allows for status-quo as a default. > > > >Harry Lewis - IBM Printing Systems > > > > > > > > >=20 >=20 >=20 From hastings at cp10.es.xerox.com Fri Jul 11 16:32:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> ISSUE: split jmAttributeTable or not In-Reply-To: ISSUE: split jmAttributeTable or not> Message-ID: <9707112034.AA05502@zazen.cp10.es.xerox.com> Harry, Thanks for your analysis. We've looked at the problem too and think that splitting does have a few advanatages, but maybe not so overwhelming. See what you think. If there is not substantive agreement to split the table, then lets leave it the way it is. We'll need to put forth our arguments to David and see whether he thinks our arguments have merit or not. If we don't split now, there is some risk that the IESG/Area Directors might split the table for us. The bottom line is that for SNMPv1 splitting the table has no real advantages for simplifying the management applicationm, simplifying the agent, or reducing network traffic. However, for SNMPv2 where GetBulk can be used, the network traffic is cut by 1/3 to 1/2 when the table is split vs. combined for applications that want to get all the attributes (such as an accounting application). This is because the management app can get as many attributes as can fit into one PDU. Even with a limit like 540 bytes in a PDU, this means that a single PDU can return 20-30 integers in one PDU. Also a monitoring application is mostly interested in the integer values that get updated during the job's life cycle. Strings are mostly static, so even an application that was monitoring a single job, could use GetBulk to get all the integer attributes in one or more PDUs. So even with SNMPv1 a monitoring application might want to use Get Next to just walk the integer table and then look at one or two strings explicitly that might change. And a management application that is using Get Bulk is already storing an entire table and then sorting through it. That is the cost to a management application when using GetBulk. See commments below. Tom At 18:20 07/09/97 PDT, Tom Hastings wrote: >At 01:18 06/27/97 PDT, David T. Perkins wrote: > >snip... > >>There is one change that would affect any current implementations >>that I strongly suggest that you do. Table jmAttributeTable has >>three accessible columnar objects. The first tells you the "type" >>(either integer, octet, or both) of the value of the attribute. >>The second two columns are the attribute's value. I suggest that >>instead of this single table, that you have two tables. Each table >>would have a single accessible column. The first table would contain >>integer valued attributes, and the second table would contain >>octet string valued attributes. > >[David did not mention that there is actually a fourth index which >is an "instance" index for those attributes that can have more than >one value per job. I'm not sure whether this fact changes the argument >or not.] > >snip... > >We need to consider this suggestion and either accept it or justify >why not. Lets get collected comments (such as Harry's below) and >respond to David. David is a noted authority on SNMP, so accommodating >his comments will help forward our document. > >Xerox developers have several views and we are in the process of >reaching a consensus (I'll send you results Thursday, 7/10). > >Harry Lewis's developers have made a review and are not convinced that >it is a good idea to split the table: > >>Return-Path: >>From: Harry Lewis >>To: >>Cc: , , >>Subject: Splitting the Attribute Table >>Date: Wed, 9 Jul 1997 10:52:02 PDT >> >Tom, we have conducted a review here, regarding your recommendation >to split the attribute table into two tables - one for Integer values >and one for Octets - and are of the opinion that the current attribute >table is superior. Here is our summary. > >1. First, we assume that attributes will have a null string for the >valueAsOctet and -2 for valueAsInteger if appropriate. Actually, its -1, not -2. -2 is for unknow, -1 for other. (I'll clarify that in the document). > >2. With GetNext, we do not believe network traffic is an issue because >the "extra" null string or -2 will fit in the PUD packet. Agree that when doing one or two GetNext in a single PDU it fits. > >3. We believe, using get next, there are less calls required with the >current scheme than would be needed if the table was split. > >Example: > > Integer Octet > ------- ----- > > -2 X > X Null > X X > X Null > -2 X > > >Consider the above excerpt. It will take 5 get next calls using the current >method. But it would take 6 calls if the table were split (one for each X >which represents a real value). Actually, I would think that the application would two GetNext in each PDU, one for the integer table and one for the string table (and then have to merge the results, since the attributes that have both integer and string value would not be together). So the number of calls would be 3, in the example if we split, instead of 5. So spliting does reduce the number of calls (at the expense of having to sort the results). > >4. While, in most cases, the monitor will know whether or not the attribute >is defined as Integer, Octet or Both... there are cases where it could >be EITHER. With the current scheme, the monitor "finds out" what this >particular device has instrumented in one get next (for each attribute). >With split tables, you have to look in both tables to know (this may >just be a restatement of (3) above). Yes, more of a sorting is required. (Not unlike the sorting for GetBulk in SNMPv2. > >5. There is no storage savings in the agent if done properly, where the >agent knows which syntax is being used. We agree, that a good impelmentation doesn't cost any space with all the not meangingful values (-2, 2, and zero-length string). > >Tom, this is our summary. I think the ball is "in your court" to decide >whether or not to open this problem to a wider audience, send us a >DETAILED "rebuttal" or accept our findings. Lets see what others think, especially the application writers, since whether to split or not seems to affect them the most. Our implementations use Get Bulk when SNMPv2 is being used and don't when it is SNMPV1. How about others? > > >Harry Lewis - IBM Printing Systems > From hastings at cp10.es.xerox.com Sat Jul 12 06:17:20 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> MOD - Editorial comments on Model Message-ID: <9707121019.AA05738@zazen.cp10.es.xerox.com> Scott, I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) and put back in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc I've included the new enum data type and the enums values for the five attributes that we agreed to be enums instead of keywords and which aligns with the Job Monitoring MIB: "finishings" "print-quality" "printer-resolution" "job-state" "document-format" I also copied in the "job-state" and "job-state-reasons" that we agreed to jointly between the JMP and IPP. NOTE: that going back to Printer MIB document-format enums means that PDF needs to get registered. Would be nice to include PDF in the Printer MIB textual-conventions that is due this week. Tom From hastings at cp10.es.xerox.com Mon Jul 14 14:17:20 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: IPP> MOD - Editorial comments on Model In-Reply-To: MOD - Editorial comments on Model> Message-ID: <9707141819.AA06263@zazen.cp10.es.xerox.com> Carl-Uno, The Job Monitoring MIB is ahead of IPP, so your concern that one would hold up the other is not a problem. Furthermore, if there are additional values that are added to, say IPP, for printer resolution that didn't make Job Mon MIB, there is no problem. These are type 2 enums that can be added to anytime and have all the validity as if they were in the standard. Our plan is to complete the next JMP draft this week and that will be the one that we forward to IESG this month. I also want to make sure that IPP people are happy with making these 5 attribute values enums, instead of keywords. If any of them change back to keywords, then the Job Monitoring MIB would want to change them to be OCTET STRING, instead of Integer32 as well. So its important to both JMP and IPP to reach agreement on these five attributes and their data types. Tom At 09:23 07/13/97 PDT, Carl-Uno Manros wrote: >At 03:17 AM 7/12/97 PDT, you wrote: >>Scott, >> >>I edited with revisions ipp-model-970623-rev.doc (after accepting revisions) >> >>and put back in: >>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09 ipp-model-970623-th.doc >> >>I've included the new enum data type and the enums values for the >>five attributes that we agreed to be enums instead of keywords >>and which aligns with the Job Monitoring MIB: >> >> "finishings" >> "print-quality" >> "printer-resolution" >> "job-state" >> "document-format" >> >>I also copied in the "job-state" and "job-state-reasons" that we agreed >>to jointly between the JMP and IPP. >> >>NOTE: that going back to Printer MIB document-format enums means that >>PDF needs to get registered. Would be nice to include PDF in the >>Printer MIB textual-conventions that is due this week. >> >>Tom >> > >Tom, > >are we sure that we know what we are doing here? The recommended solution from >Nashua to use "enums" where they were already defined in other standards sounded >good at the time, but does the Job Monitoring MIB really fall into that category > - YET? > >I do not want the progression of IPP to be dependent and possibly delayed by the >Job Monitoring MIB project. Are we convincened that the Job Monitoring work >will >proceed with at least the same speeed as IPP? > >Carl-Uno > > > > From rbergma at dpc.com Tue Jul 15 11:09:50 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Version 0.83 Document Message-ID: <9707141819.AA06263@zazen.cp10.es.xerox.com> Tom, The latest issues list references version 0.83 of the JMP document. I cannot find this version on the PWG FTP site. Where is this version located? Ron Bergman From hastings at cp10.es.xerox.com Tue Jul 15 20:40:00 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Version 0.83 Document In-Reply-To: Version 0.83 Document> Message-ID: <9707160042.AA06788@zazen.cp10.es.xerox.com> Ron, V0.83 is the next version, so it was confusing to reference V0.83 in the issues list, before V0.83 is posted. I've finished all the editing from Nashua and from David Perkin's editorial comments. I'm awaiting the decision on whether to split the attributes table or not and whether to add the coded character set object and attribute which were the three substantive Perkin's comments. Unfortunately, the discussion on the DL has been rather scant on these three issues listed in the issues list. I hope to finish editing your editorial comments tonight. Tom At 08:09 07/15/97 PDT, Ron Bergman wrote: >Tom, > >The latest issues list references version 0.83 of the JMP document. > >I cannot find this version on the PWG FTP site. Where is this >version located? > > Ron Bergman > > > > From rbergma at dpc.com Tue Jul 15 21:07:03 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Version 0.83 Document In-Reply-To: <9707160042.AA06788@zazen.cp10.es.xerox.com> Message-ID: <9707160042.AA06788@zazen.cp10.es.xerox.com> Tom, I propose that version 0.83 not include the changes to split the attribute table or to add a coded character set attribute. Lets keep those items open for now until we can reach an agreement. (I have not reached any conclusion on either issue. I still have not read all the JMP email so I am not fully up to speed on these items.) Ron On Tue, 15 Jul 1997, Tom Hastings wrote: > Ron, > > V0.83 is the next version, so it was confusing to reference V0.83 in the > issues list, before V0.83 is posted. > > I've finished all the editing from Nashua and from David Perkin's editorial > comments. I'm awaiting the decision on whether to split the attributes > table or not and whether to add the coded character set object and attribute > which were the three substantive Perkin's comments. Unfortunately, > the discussion on the DL has been rather scant on these three issues > listed in the issues list. > > I hope to finish editing your editorial comments tonight. > > Tom > > > > At 08:09 07/15/97 PDT, Ron Bergman wrote: > >Tom, > > > >The latest issues list references version 0.83 of the JMP document. > > > >I cannot find this version on the PWG FTP site. Where is this > >version located? > > > > Ron Bergman > > From hastings at cp10.es.xerox.com Wed Jul 16 03:04:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Version 0.83 Document In-Reply-To: Version 0.83 Document> Message-ID: <9707160706.AA06875@zazen.cp10.es.xerox.com> Good idea. I'll publish V0.83 tommorrow as an Internet-Draft and we'll process these remaining 3 issues (possibly making no changes) the rest of this week. Tom At 18:07 07/15/97 PDT, Ron Bergman wrote: >Tom, > >I propose that version 0.83 not include the changes to split the >attribute table or to add a coded character set attribute. Lets >keep those items open for now until we can reach an agreement. > >(I have not reached any conclusion on either issue. I still have >not read all the JMP email so I am not fully up to speed on these >items.) > > Ron > > >On Tue, 15 Jul 1997, Tom Hastings wrote: > >> Ron, >> >> V0.83 is the next version, so it was confusing to reference V0.83 in the >> issues list, before V0.83 is posted. >> >> I've finished all the editing from Nashua and from David Perkin's editorial >> comments. I'm awaiting the decision on whether to split the attributes >> table or not and whether to add the coded character set object and attribute >> which were the three substantive Perkin's comments. Unfortunately, >> the discussion on the DL has been rather scant on these three issues >> listed in the issues list. >> >> I hope to finish editing your editorial comments tonight. >> >> Tom >> >> >> >> At 08:09 07/15/97 PDT, Ron Bergman wrote: >> >Tom, >> > >> >The latest issues list references version 0.83 of the JMP document. >> > >> >I cannot find this version on the PWG FTP site. Where is this >> >version located? >> > >> > Ron Bergman >> > > > > From harryl at us.ibm.com Wed Jul 16 11:20:08 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP>Version 0.83 Document Message-ID: <5030100004848119000002L092*@MHS> I agree with Ron that we need to see v.83 ASAP! >I propose that version 0.83 not include the changes to split the >attribute table or to add a coded character set attribute. Lets >keep those items open for now until we can reach an agreement. There were many decisions made in Nashua and a major re-indexing post Nashua... all of which needs to be seen. With respect to the issues... I have posted my responses to both the table split and char set issues and have received no further "rebuttal". Aside from believing that it's just way too late for major changes such as the table split, I believe I have effectively argued the benefits of leaving things as they are. As for char set... we have established that we can't always rely on the submission protocol to "localize" the attributes which are passed in. In Nashua, we had addressed all open issues. I believe any currently open issue has been introduced since Nashua. I know the IETF rules specify that consensus happens on the e-mail, not in the meeting. I don't know whether to characterize the lack of e-mail discussion regarding these last issues as resulting from: 1. Stalemate 2. Vacations 3. Lack of interest 4. Giving-up We can't keep having meetings, closing issues and then bringing issues back up on e-mail but not resolving them there. I think we should declare the period between now and Seattle (about 3 weeks... should be plenty of time) as the time to openly air your thoughts on any and all JMP known issues with the understanding that Seattle will nail the lid on the first job MIB once and for all and agree that any unresolved or new issues that arise after Seattle, by definition, go into some future draft (like the printer MIB). Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Wed Jul 16 17:18:25 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: Nested Attributes In-Reply-To: Message-ID: <5030100004868153000002L032*@MHS> I am responding to a note which is about 13 days old... sorry... I want to agree with Tom regarding nested attributes... and suggest a FAQ that says the agent will always replace ANY nested attribute (regardless of why it got nested) with the most recent value encountered in the job stream. This is the simplest agent implementation and I think it works for all the cases we've discussed. As an example, if the client attaches JobOwner (BillyBob) to the job but, later, the server adds (ServItUp_01) to the front of the job... the JobOwner object in the JobTable would have the value ServItUp_01 for a moment which would be replaced by BillyBob. If the server added it's JobOwner at the end of the job (not a good idea) then ServItUp_01 would be the final value for JobOwner. This scenario applies to any and all job attributes. Harry Lewis - IBM Printing Systems --------- Forwarded by Harry Lewis/Boulder/IBM on 07/16/97 02:48 PM ------- hastings@cp10.es.xerox.com 07/02/97 04:57 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: hastings@cp10.es.xerox.com @ internet, jkm@underscore.com @ internet, rbergma@dpc.com @ internet, bpenteco@boi.hp.com @ internet Subject: Re: Nested Attributes At 08:49 07/02/97 PDT, Harry Lewis wrote: >I think we failed to cover this topic at the meeting in Nashua. I hope we can >come to quick resolution. I didn't bring it to the >open JMP because I want to make sure we all agree it needs to be aired before >doing so. In otherwords, if it's already documented but I'm missing something, >please provide a pointer rather then allowing me to inject instability on the >mail list. Oops! We should have brought it up at Nashua. But I don't think we really have a problem. See if you agree with my analysis (though I may not be understanding the scenario where the problem comes up). > >Bob P. had made some suggestions in the past and I think the same could apply >to all attributes, not just subID... While it could apply to all attributes, the submissionID is unique in that it is used as an index to find the job. I think that we are talking about configuration 3 here, where the client submits to a server and the server submits to the Printer and the monitoring APP is monitoring the server with some protocol (such as PSERVER?) that submits to the device and forgets about the job (in the server and in the device) as soon as the job is submitted to the device. So that management app has to use our Job Monitoring MIB in the device to finish monitoring the job. Correct? It seems to me that in this case, since the server has forgotten about the job in the device, there are two possibilities, depending on the client: 1. The client submitted the job with a jobsubmission ID to the server, so the server should just pass it on and not make up a new one. Otherwise, the client has no idea how to find the job in the device. (Having the server pass back the new job submission ID to the client seems too hard and would require new extensions to protocols, etc.). If this is implemented in the server by the server just wrapping another layer of PJL with a JOBSUBMISSIONID string, then the agent or the device needs to ignore the outer ones and just keep the inner most one as the jmJobSubmissionID. I think that having the agent ignore outer (or replace outer with inner) JOBSUBMISSIONID works for both cases: a. the client is going to depend on the server for all status and so the client had better NOT also send a JOBSUBMISSIONID (otherwise, the client's will override the server's ID). Configuration 2. b. the client is going to use the server for status while the job is queued and is going to use the job monitoring MIB in the device for status after the server submits (and forgets) the job to the device. Here the server is probably not going to wrap the job with its own JOBSUBMISSIONID, since the server isn't going to use the Job Monitoring MIB to track the job. If the server is going to use the Job Monitoring MIB to track the job, then the server SHOULD provide access to such data to the client (via either our Job Monitoring MIB with an agent implemented in the server or via IPP, ...). 2. The client did NOT submit a job submission ID to the server, so the server is free to make up one of its own and submit it to the device. On the other hand, if the server really does forget about the job in the server and the device, what is even the point? The proper thing for servers to do is to NOT forget about jobs in the server and the device and then the monitoring APP would just query the server, using our Job monitoring MIB in the server. But this is configuration 2. > >>1) The printer can keep track of the innermost JobSubmissionID (discard the >>previous ID when a new one is received). Pro: Fewer jobs for the printer to >>keep track of. Con: The spooler can't track its job. But in configuration 3, the server isn't tracking its job in the printer. If the server is tracking the job in the printer, why doesn't the server show the job to the client and the client only bother talking to the server, not the device? This is configuration 2. > >>2) The printer could keep track of all ID's and have them point to the same >>jmJobIndex. Pro: Fewer jobs for the printer to keep track of. Con: May >>cause problems in that the job attributes would be a summary of all the >>nested jobs. > >>3) The printer could keep track of the nested jobs as separate jobs. Pro: >>The attributes are separate for each job. Con: More jobs in the printer. > >We think 1 is the easiest to do and have been looking into whether or not it >makes sense to have the "spooler" >actually replace jmJobSubmissionID if it finds it was assigned by the client. I think that the spooler should NOT replace (or override or place an outer wrap with a new JOBSUBMISSIONID), unless the server is keeping track of the job in the device using the Job Monitoring MIB. If the server is, then the server SHOULD also provide that information back to the client by either: (1) implement the Job Monitoring agent in the server or (2) implementing some other protocol for the clients to get status, such as IPP. That is why I don't see that we have a problem. I think we should add some statement/assumption like the above to the MIB spec. What do you think? > >Our prototype currently does (1) for all attributes. > >Harry Lewis - IBM Printing Systems > > About other attributes that might have a value for the client-server hop and a different value for the server-device hop: We have doubled a few attributes in order to handle the few attributes that might have different values for each hop, such as submission-time. In a quick scan of the attributes we have: jmJobSubmissionID serverAssignedJobName(22) submittingServerName(27) jobOriginatingHost(29) deviceNameRequested(30) queueNameRequested(31) impressionsSpooled(110) impressionsSentToDevice(111) jobSubmissionToServerTime(190) jobSubmissionToDeviceTime(191) I'm not sure we have clearly defined when each is used, but the point it that there are only 5 out of 70 that have a need for more than one value because of two-hop systems. So I think we don't need a general solution to the multi-hop problem. Besides, I would hope that configuration 3 is only a interim thing. The long term should be configurations 1 and 2. CLARIFICATION ISSUE: By the way, what about serverAssignedJobName(22)? We agreed in Nashua to clarify that the name assigned by the server could be either a name or a number. I assumed that when it was a number, that the number was serving the purpose of a server-to-device submission ID (except that this ID isn't used as the index in the jmJobSubmissionIDTable, because the server isn't using the Job Monitoring MIB to track the job). So shouldn't I replace the definition for serverAssignedJobName(22): "Configuration 3: The human readable string name of the job as assigned by the server that submitted the job to the device that the agent is instrumenting with this MIB." with "Configuration 3: The human readable string name, number, or ID of the job as assigned by the server that submitted the job to the device that the agent is instrumenting with this MIB." Comments (before sending to JMP)? Tom From hastings at cp10.es.xerox.com Fri Jul 18 11:11:54 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Internet-Draft draft-ietf-printmib-job-monitor-02.txt posted Message-ID: <9707181514.AA07762@zazen.cp10.es.xerox.com> I've posted the usual files for version V0.83: ftp::/ftp.pwg.org/pub/pwg/jmp/mibs -rw-r--r-- 1 pwg pwg 113517 Jul 18 15:06 jmp-mib.mib -rw-r--r-- 1 pwg pwg 285912 Jul 18 14:24 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 197357 Jul 18 14:19 jmp-mib.txt -rw-r--r-- 1 pwg pwg 387584 Jul 18 14:29 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 368368 Jul 18 14:25 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 379887 Jul 18 14:25 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 8054 Jul 18 14:07 jmp.dic The jmp-mib.pdf is without revision marks and has line numbers. This is the version that JMP should make any comments against. The jmp-mib.txt == draft-ietf-printmib-job-monitor-02.txt The jmp-mibr.doc is with revision marks. The jmp-mibr.pdr is with red revision marks. The jmp-mibr.pdf is with black revision marks. The jmp-mib.mib file compiles with one warning (assignment of the temporary OID). I've also posted a copy of the plain text in the internet drafts (and sent it in to the IETF for publication) ftp::/ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 189247 Apr 29 01:00 draft-ietf-printmib-job-monitor-00.txt -rw-r--r-- 1 pwg pwg 190215 Jun 11 08:33 draft-ietf-printmib-job-monitor-01.txt -rw-r--r-- 1 pwg pwg 197357 Jul 18 14:09 draft-ietf-printmib-job-monitor-02.txt Sixth draft MIB that corresponds to the changes agreed to at the JMP meeting, on Friday, 6/27/97. The major changes were to move the jobOwner attribute to the jmJobTable, so that no attributes are MANDATORY. However, we agreed to restore Ron's requirement that an attribute SHALL be implemented, if the server or device implements the corresponding functionality and it is available to the agent. We also deleted the deviceAlertCode attribute since it is in the Printer MIB. We deleted the timeSinceXxxx attributes since they can be computed from other attributes. We agreed to make the random number and sequential numbers in the jmJobSubmissionID be last, so that a partial ID could be specified in a GetNext and step through all jobs with the same more significant part of jmJobSubmissionID. Harry and I had an action item about the use of IMPLIED and its interaction with such a specification. We have agreed that making jmJobSubmissionID fixed length with trailing spaces before the 8-digit number works with V1 and V2, since no length tag shall be present for fixed length. See the change history in the separate file: changes.doc .pdf. We agreed that the MIB specification is finished except for any editorial comments that people may have. We resolved all PWG issues. I've included Ron Bergman's and David Perkin's extensive editorial comments. Three issues came from IETF reviewers (David Perkins), which have not been resolved. See the separate issues.doc and .pdf file. From don at lexmark.com Fri Jul 18 12:14:51 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> Seattle PING Message-ID: <199707181614.AA11348@interlock2.lexmark.com> Blank lines to keep the reflector from rejecting this mail... -- -- -- -- -- Sorry for the cross post but there are still many who do not subscribe to the PWG administrative reflector. If you did not see this post off that reflector, please subscribe immediately. Please send me your PING for the Seattle/Redmond meetings including which meetings you will be attending. Those of you who have already done so, there is no need to re-PING. Don From don at lexmark.com Fri Jul 18 18:07:11 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> August PWG meetings Message-ID: <199707182207.AA22181@interlock2.lexmark.com> Just a reminder... The August meetings of the PWG working groups will be held at Microsoft in Redmond, WA. from August 4th through 8th. Here are the details on the meeting times and locations: Mon/Tue 1394 Printing 9:00AM to 6:00PM Building 27N, Olympic Room Wed/Thur IPP 8:30AM to 6:00PM Building 31, Pebble Beach Fri JMP/SENSE 8:30AM to 6:00PM Building 31, Pebble Beach There is a PDF of a map of the Microsoft site on the Chair's page (http://www.pwg.org/chair/mssite.psf). The map is a little hard to read because it fits the whole campus on a single page but buildings 27N and 31 are marked. See you in Redmond!! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From rbergma at dpc.com Sun Jul 20 23:07:54 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP>Version 0.83 Document In-Reply-To: <5030100004848119000002L092*@MHS> Message-ID: <199707182207.AA22181@interlock2.lexmark.com> I agree with Harry on both of these issues. And I also agrre that since there has not been any support presented via email, these issues should be dropped. If anyone has a different opinon, please respond. Ron Bergman Dataproducts Corp. On Wed, 16 Jul 1997, Harry Lewis wrote: > I agree with Ron that we need to see v.83 ASAP! > > >I propose that version 0.83 not include the changes to split the > >attribute table or to add a coded character set attribute. Lets > >keep those items open for now until we can reach an agreement. > > There were many decisions made in Nashua and a major re-indexing post > Nashua... all of which needs to be seen. > > With respect to the issues... I have posted my responses to both the table > split and char set issues and have received no further "rebuttal". Aside from > believing that it's just way too late for major changes such as the table > split, I believe I have effectively argued the benefits of leaving things > as they are. As for char set... we have established that we can't always > rely on the submission protocol to "localize" the attributes which are passed > in. > > In Nashua, we had addressed all open issues. I believe any currently open > issue has been introduced since Nashua. I know the IETF rules specify that > consensus happens on the e-mail, not in the meeting. I don't know whether to > characterize the lack of e-mail discussion regarding these last issues as > resulting from: > > 1. Stalemate > 2. Vacations > 3. Lack of interest > 4. Giving-up > > We can't keep having meetings, closing issues and then bringing issues back > up on e-mail but not resolving them there. I think we should declare the period > between now and Seattle (about 3 weeks... should be plenty of time) as the > time to openly air your thoughts on any and all JMP known issues with the > understanding that Seattle will nail the lid on the first job MIB once and for > all and agree that any unresolved or new issues that arise after Seattle, by > definition, go into some future draft (like the printer MIB). > > > Harry Lewis - IBM Printing Systems > From rbergma at dpc.com Sun Jul 20 23:35:25 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Counts in version 0.83 Specification Message-ID: <199707182207.AA22181@interlock2.lexmark.com> Tom, This version is getting very close! Thank you for all your work in getting this completed. I have a number of editorial comments which I will send later. First a non-editorial comment. The Abstact (page 1) and the Introduction (page 8) contain counts of the objects in the MIB. The Abstract defines the total and the Introduction defines the numbr of objects in each group. I feel that this is detail that is not needed and can easily be derived by anyone who really needs these counts. My fear is that changes to the MIB will not be reflected in changes to these counts. In fact, of the five counts presented, only one is correct! This same comment was made in my review of version 0.82 and was not incorporated in the document. What is the justification for these counts? (I believe that you have included them due to the original concerns of PWG members that the MIB was too large.) The job of the editor will certainly be easier now and in the future without this amount of detail. I propose that these counts be removed and am calling for a straw vote on this proposal. If anyone can provide a good justification for retaining this data, I will withdraw my request. Ron Bergman Dataproducts Corp. From rbergma at dpc.com Mon Jul 21 12:07:03 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Editorial Comments for version 0.83 Message-ID: <199707182207.AA22181@interlock2.lexmark.com> Tom, Here are some editorial comments on the latest draft: 1. In paragraph 1.2 - 1. - "finishing" is a bad term to use in this paragraph. It could possibility be confused with "finisher". A better term would be "ending" or "completing" (or anything but "finishing".) 2. This is really a minor nit, the sub-paragraphs in 1.2 (and also many other places in the document) do not have a space between the period and the first word of the text. This is minor, but also very easy to fix. 3. Section 2. Terminology and Job Model - contains the following: "For example, PostScript systems use the term session for what we call a job in this specification and the term job to mean what we call a document in this specification." Reword to: "For example, PostScript systems use the term session in place of job as defined in this specification and the term job as document is defined in this specification." (Maybe someone can develop a better wording. The goal is to eliminate the "we".)) It then goes on to say... "PJL systems use the term job to mean what we call a job in this specification. PJL also supports multiple documents per job, but does not support specifying per-document attributes independently for each document." This second part, while useful information, does not belong here. One example to explain why the definitions are important is sufficient. The information on PJL belongs in the RFC that provides the mapping of the job MIB to job submission protocols. 4. The definitions in section 2 should begin with a capital letter. For example: "Job set: a group of jobs..." should be: "Job Set: A group of jobs..." 5. The definitions from "User" to "Job Accounting" begin with "is". The "is" should be removed. 6. In the definition for "Device", contains the text "...interfaces to humans in human perceptible means, such as produces marks on paper,..." and the follows with: "scans marks on paper to produce an electronic representations, or writes CD-ROMS..." The first example is sufficient and I don't believe that the other examples are applicable. Is either "human perceptible"? 7. The second part of the definition of "Device" states: "...interfaces to a network..." A better definition would be "...interfaces electronically to another device..." ...More to come. Ron Bergman From hastings at cp10.es.xerox.com Mon Jul 21 13:06:50 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Counts [of MIB objects] in version 0.83 Specification In-Reply-To: Counts [of MIB objects] in version 0.83 Specification> Message-ID: <9707211709.AA08386@zazen.cp10.es.xerox.com> Ron, Whether the counts of the number of objects in the MIB that are included in the Abstract and Introduciton include in-accessible objects or not is perhaps why there is a disagreement about whether the counts are accurate or not. I considered removing them as you had suggested, but thought it gave the reader some high level feeling for the MIB. Even if the counts were absolutely accurate, I don't think anyone would be confused or mis-led. Looks like I didn't count very well. The total of 18 objects in the Abstract (line 61) is correct, from the listing of objects in the conformance section, but doesn't count the in-accessible index objects. So how about if if I change "18 SNMP MIB objects" to "18 read-only SNMP MIB objects". That will clarify what we are counting and give the valuable information in the Abstract that this MIB only defines read-only objects? On lines 252 - 254, I need to subtract one from the General Group count and add 1 to the Job Group count and add "read-only" too. (I had checked that the totals agreed with the Abstract, but forgot to check each group). But if people want me to remove the counts from lines 61 and 252-254, I can do that too. Comments? Tom At 20:35 07/20/97 PDT, Ron Bergman wrote: >Tom, > >This version is getting very close! Thank you for all your work in >getting this completed. I have a number of editorial comments which >I will send later. First a non-editorial comment. > >The Abstact (page 1) and the Introduction (page 8) contain counts of >the objects in the MIB. The Abstract defines the total and the >Introduction defines the numbr of objects in each group. I feel that >this is detail that is not needed and can easily be derived by anyone >who really needs these counts. My fear is that changes to the MIB >will not be reflected in changes to these counts. In fact, of the >five counts presented, only one is correct! > >This same comment was made in my review of version 0.82 and was not >incorporated in the document. What is the justification for these >counts? (I believe that you have included them due to the original >concerns of PWG members that the MIB was too large.) The job of the >editor will certainly be easier now and in the future without this >amount of detail. > >I propose that these counts be removed and am calling for a straw >vote on this proposal. If anyone can provide a good justification >for retaining this data, I will withdraw my request. > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Mon Jul 21 13:13:15 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Counts [of MIB objects] in version 0.83 Specification In-Reply-To: <9707211709.AA08386@zazen.cp10.es.xerox.com> Message-ID: <9707211709.AA08386@zazen.cp10.es.xerox.com> Tom, Why not make your life a little easier and just remove the counts? This is a detail that is easy to obtain for anyone who really needs this information. Ron On Mon, 21 Jul 1997, Tom Hastings wrote: > Ron, > > Whether the counts of the number of objects in the MIB that are included > in the Abstract and Introduciton include in-accessible objects or not is > perhaps why there is a disagreement about whether the counts are accurate > or not. > > I considered removing them as you had suggested, but thought it gave the > reader some high level feeling for the MIB. Even if the counts were > absolutely accurate, I don't think anyone would be confused or mis-led. > > Looks like I didn't count very well. The total of 18 objects in the > Abstract (line 61) is correct, from the listing of objects in the conformance > section, but doesn't count the in-accessible index objects. So > how about if if I change "18 SNMP MIB objects" to "18 read-only SNMP > MIB objects". That will clarify what we are counting and give the > valuable information in the Abstract that this MIB only defines read-only > objects? > > On lines 252 - 254, I need to subtract one from the General Group count > and add 1 to the Job Group count and add "read-only" too. (I had checked > that the totals agreed with the Abstract, but forgot to check each group). > > But if people want me to remove the counts from lines 61 and 252-254, > I can do that too. > > Comments? > > Tom > > At 20:35 07/20/97 PDT, Ron Bergman wrote: > >Tom, > > > >This version is getting very close! Thank you for all your work in > >getting this completed. I have a number of editorial comments which > >I will send later. First a non-editorial comment. > > > >The Abstact (page 1) and the Introduction (page 8) contain counts of > >the objects in the MIB. The Abstract defines the total and the > >Introduction defines the numbr of objects in each group. I feel that > >this is detail that is not needed and can easily be derived by anyone > >who really needs these counts. My fear is that changes to the MIB > >will not be reflected in changes to these counts. In fact, of the > >five counts presented, only one is correct! > > > >This same comment was made in my review of version 0.82 and was not > >incorporated in the document. What is the justification for these > >counts? (I believe that you have included them due to the original > >concerns of PWG members that the MIB was too large.) The job of the > >editor will certainly be easier now and in the future without this > >amount of detail. > > > >I propose that these counts be removed and am calling for a straw > >vote on this proposal. If anyone can provide a good justification > >for retaining this data, I will withdraw my request. > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > > > > From jkm at underscore.com Mon Jul 21 16:42:09 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:08 2009 Subject: JMP> Counts [of MIB objects] in version 0.83 Specification In-Reply-To: Counts [of MIB objects] in version 0.83 Specification> Message-ID: <199707212042.QAA25269@uscore.underscore.com> I agree entirely with Ron. Please REMOVE the counts, Tom. That way we'll have fewer editorial changes to make in the future. Thanks. ...jay ----- Begin Included Message ----- Date: Mon, 21 Jul 1997 10:13:15 -0700 (PDT) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org Subject: Re: JMP> Counts [of MIB objects] in version 0.83 Specification X-X-Sender: rbergma@it.dpc.com Tom, Why not make your life a little easier and just remove the counts? This is a detail that is easy to obtain for anyone who really needs this information. Ron On Mon, 21 Jul 1997, Tom Hastings wrote: > Ron, > > Whether the counts of the number of objects in the MIB that are included > in the Abstract and Introduciton include in-accessible objects or not is > perhaps why there is a disagreement about whether the counts are accurate > or not. > > I considered removing them as you had suggested, but thought it gave the > reader some high level feeling for the MIB. Even if the counts were > absolutely accurate, I don't think anyone would be confused or mis-led. > > Looks like I didn't count very well. The total of 18 objects in the > Abstract (line 61) is correct, from the listing of objects in the conformance > section, but doesn't count the in-accessible index objects. So > how about if if I change "18 SNMP MIB objects" to "18 read-only SNMP > MIB objects". That will clarify what we are counting and give the > valuable information in the Abstract that this MIB only defines read-only > objects? > > On lines 252 - 254, I need to subtract one from the General Group count > and add 1 to the Job Group count and add "read-only" too. (I had checked > that the totals agreed with the Abstract, but forgot to check each group). > > But if people want me to remove the counts from lines 61 and 252-254, > I can do that too. > > Comments? > > Tom > > At 20:35 07/20/97 PDT, Ron Bergman wrote: > >Tom, > > > >This version is getting very close! Thank you for all your work in > >getting this completed. I have a number of editorial comments which > >I will send later. First a non-editorial comment. > > > >The Abstact (page 1) and the Introduction (page 8) contain counts of > >the objects in the MIB. The Abstract defines the total and the > >Introduction defines the numbr of objects in each group. I feel that > >this is detail that is not needed and can easily be derived by anyone > >who really needs these counts. My fear is that changes to the MIB > >will not be reflected in changes to these counts. In fact, of the > >five counts presented, only one is correct! > > > >This same comment was made in my review of version 0.82 and was not > >incorporated in the document. What is the justification for these > >counts? (I believe that you have included them due to the original > >concerns of PWG members that the MIB was too large.) The job of the > >editor will certainly be easier now and in the future without this > >amount of detail. > > > >I propose that these counts be removed and am calling for a straw > >vote on this proposal. If anyone can provide a good justification > >for retaining this data, I will withdraw my request. > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > > > > ----- End Included Message ----- From jkm at underscore.com Tue Jul 22 10:43:11 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-02.txt In-Reply-To: I-D ACTION:draft-ietf-printmib-job-monitor-02.txt> Message-ID: <199707221443.KAA24091@uscore.underscore.com> ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 79 I thought the document version was supposed to be V0.83, not V0.82. Am I missing something? ...jay ----- Begin Included Message ----- To: IETF-Announce@ietf.org cc: pwg@pwg.org From: Internet-Drafts@ietf.org Subject: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-02.txt Date: Tue, 22 Jul 1997 09:49:25 -0400 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Monitoring MIB - V0.82 Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis Filename : draft-ietf-printmib-job-monitor-02.txt Pages : 95 Date : 07/21/1997 This Internet-Draft specifies a set of 18 SNMP MIB objects for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970721112814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-printmib-job-monitor-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-printmib-job-monitor-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970721112814.I-D@ietf.org> --OtherAccess-- From hastings at cp10.es.xerox.com Tue Jul 22 12:33:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: PWG> I-D In-Reply-To: Re: PWG> I-D> Message-ID: <9707221636.AA08932@zazen.cp10.es.xerox.com> I think that the IETF secretariate didn't update the version number. She must have just edited her previous e-mail message. Our version numbers are not something that the IETF nornally does. Here is the first few lines of the attachement that I sent to her: Job Monitoring MIB, V0.83 July 14, 1997 INTERNET-DRAFT Ron Bergman Dataproducts Corp. Tom Hastings Xerox Corporation Scott Isaacson Novell, Inc. Harry Lewis IBM Corp. July 1997 Job Monitoring MIB - V0.83 Expires Jan 14, 1997 Thanks for questioning this though, Tom At 07:43 07/22/97 PDT, JK Martin wrote: >---------- >X-Sun-Data-Type: text >X-Sun-Data-Description: text >X-Sun-Data-Name: text >X-Sun-Charset: us-ascii >X-Sun-Content-Lines: 79 > >I thought the document version was supposed to be V0.83, >not V0.82. Am I missing something? > > ...jay > >----- Begin Included Message ----- > >>From pwg-owner@pwg.org Tue Jul 22 09:54 EDT 1997 >To: IETF-Announce@ietf.org >cc: pwg@pwg.org >From: Internet-Drafts@ietf.org >Subject: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-02.txt >Date: Tue, 22 Jul 1997 09:49:25 -0400 > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Printer MIB Working Group of > the IETF. > > Title : Job Monitoring MIB - V0.82 > Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis > Filename : draft-ietf-printmib-job-monitor-02.txt > Pages : 95 > Date : 07/21/1997 > >This Internet-Draft specifies a set of 18 SNMP MIB objects for (1) >monitoring the status and progress of print jobs (2) obtaining resource >requirements before a job is processed, (3) monitoring resource consumption >while a job is being processed and (4) collecting resource accounting data >after the completion of a job. This MIB is intended to be implemented (1) >in a printer or (2) in a server that supports one or more printers. Use of >the object set is not limited to printing. However, support for services >other than printing is outside the scope of this Job Monitoring MIB. >Future extensions to this MIB may include, but are not limited to, >fax machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-02.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-02.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-02.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > >----- End Included Message ----- > > >---------- >X-Sun-Data-Type: Multipart >X-Sun-Charset: us-ascii >X-Sun-Content-Lines: 22 > >--OtherAccess >Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ds.internic.net" > >Content-Type: text/plain >Content-ID: <19970721112814.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-02.txt > >--OtherAccess >Content-Type: Message/External-body; > name="draft-ietf-printmib-job-monitor-02.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="internet-drafts" > >Content-Type: text/plain >Content-ID: <19970721112814.I-D@ietf.org> > >--OtherAccess-- > > From rbergma at dpc.com Wed Jul 23 12:01:03 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Third set of comments on version 0.83 Message-ID: <9707221636.AA08932@zazen.cp10.es.xerox.com> Tom, Additional editorial corrections to version 0.83. 1. Section 2.1.1 (page 14) contains the following text: ***** The client-printer configuration can accommodate multiple job submitting clients in either of two ways: 1.if each client relinquishes control of the Print Job Delivery Channel after each job (or after a number of jobs) 2.if the printer supports more than one Print Job Delivery Channel This does not appear to apply to Job Monitoring, only Job Submission. I do not see the purpose of this text and believe it should be removed. ***** 2. Section 3.2 (page 20) contains the following paragraph: ***** When a new job is accepted by the server or device that the agent is providing access to , the agent SHALL assign the next available value to the job's jmJobIndex that is used for storing job information in the jmJobTable and the jmAttributeTable. If the value would exceed the implementation-defined maximum value for jmJobIndex, the agent SHALL set the value back to 1, i.e., 'wrap' around to the beginning of the job tables. ***** I found this paragraph very confusing ans suggest rewording as follows. (Does this represent what was intended?): ***** When a new job is accepted by the server or device represented by the agent, the agent SHALL assign the next incremental value of jmJobIndex to the job. If the value would exceed the implementation-defined maximum value for jmJobIndex, the agent SHALL 'wrap' the value back to 1. ***** 3. Also, the paragraph on page 21: ***** If an application detects that the jmGeneralNewestActiveJobIndex is smaller than jmGeneralOldestActiveJobIndex, the job index has wrapped. In this case, when the application detects that the returned OID is in a different MIB (Get Next has moved to the next MIB in the agent), the application SHALL start over at 1 and continue the GetNext operations to find the rest of the active jobs. ***** I suggest should be changed to: ***** If an application detects that the jmGeneralNewestActiveJobIndex is smaller than jmGeneralOldestActiveJobIndex, the job index has wrapped. In this case, the application must reset the index to 1 when the top of the table has been reached. ***** 4. In the first paragraph on page 22, 6th line, 1st word: "attribute" should be "attributes" 5. The first sentence of the first paragraph in section 3.3.3 (page 23) is incorrect: ***** Many attributes are sub-typed to give a more specific data sub-type than ***** Change to: ***** Many attributes are sub-typed to give a more specific data type than ***** 6. The last sentence in the above paragraph is also incorrect: ***** For example, documentFormatIndex(37) in an index. ***** I believe this should read: ***** For example, documentFormatIndex(37) is an index. ***** 7. I found the second paragraph in section 3.3.3 to be unacceptable: ***** NOTE: The Table of Contents also lists the data sub-type and/or data sub-types of each attribute, using the textual-convention name when such is defined. The following abbreviations are used in the Table of Contents as shown: 'Int32(-2..)' Integer32(-2..2147483647) 'Int32(0..)' Integer32(0..2147483647) 'Int32(1..)' Integer32(1..2147483647) 'Int32(m..n)' For all other Integer ranges, the lower and upper bound of the range is indicated. 'Octets63' OCTET STRING(SIZE(0..63)) 'Octets(m..n)' For all other OCTET STRING ranges, the exact range is indicated. ***** This is too much of an overload of the table of contents. (I can hear Jay Martin's comment now... "Wow, a complete specification in the table of contents.) This information should be removed from the table of contents. 8. Section 3.3.4, in the first paragraph remove the following text: ***** Attributes that are permitted to appear multiple times in the jmAttributeTable for a job are indicated with 'MULTI-ROW:' in their specification in the JmAttributeTypeTC. However, such ... ***** The previous text in this paragraph already states this in other words. ...more to come. Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Wed Jul 23 19:09:29 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 Message-ID: <5030100005221608000003L083*@MHS> Tom, in going over the Job MIB v.83, I was surprised to see the change to JobSumbissionID format 0. Previously, format 0 was defined such that, if no submission ID was passed in, the agent would use whatever algorithm it desired to provide one. The recommendation was for the agent to simply reflect the jmJobIndex here. I recall a lot of discussion at Nashua about moving JobOwner to the Job Table and providing a new (additional) JobSubmissionID format based on JobOwner. I was expecting this to be something like format 8, not a replacement for format 0. There's a pretty big question in my mind exactly WHY we think JobOwner needs to be part of a default format 0, especially since jmJobOwner is a mandatory object in the Job Table. I only offer the following definition as a potential compromise. I would prefer to keep format 0 as previously defined... basically agent assigned. If the desire is to have the agent use JobOwner (if supplied) in the default case, we could stipulate this within format 0 but then I would still like to see a separate format (8) for JobOwner passed in as a JobSubmissionID. This way, the decimal portions can overlap without danger of ambiguity. So, to be more precise, we could define format 0 as '0' octets 2-40: last 39 bytes of jmJobOwner. octets 41-48: 8 decimal-digit sequential number (preferably equal to jmJobIndex). '8' octets 2-40: last 39 bytes of jmJobOwner. octets 41-48: 8 decimal-digit sequential number Now... for all you agent developers out there... I should warn you that having the agent add JobOwner into the JobSubmissionID may not be as simple as it sounds. Think of the fact that JobOwner may start out "blank" when you first create the format 0 ID but may assume a value from the LPR control file at the end of the job. The agent should probably feel obliged to MODIFY JobSubmissionID with the new JobOwner information. Note that, in my scenario, including JobOwner in the control file is not considered the same as passing in a format 8 jmJobSubmissionID with 8 digit sequential number. If this were to occur, then I'd say format 8 was in use. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Thu Jul 24 13:34:03 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> PMP> I-D ACTION:draft-ietf-printmib-job-monitor-03.txt Message-ID: <9707241736.AA10062@zazen.cp10.es.xerox.com> This was sent to the pmp list (since the IETF printmib wg is doing the Job Monitoring MIB). It is just updating the version number from the previous notice of a day ago from V0.82 to V0.83. I did not send a new document to them. However, the IETF Secretariat also added one to the file name to make it: draft-ietf-printmib-job-monitor-03.txt I have not checked to see if the actual text is the same between the two files that were posted by the IETF this week: draft-ietf-printmib-job-monitor-02.txt draft-ietf-printmib-job-monitor-03.txt But it should be. Both should say inside that they are version V0.83. When I get time I'll check. The good news is that the version number in the file name (03) is now the same as the digit after the 8 in V0.83, which may help us keep track. Tom >Return-Path: >To: IETF-Announce@ietf.org >Cc: pmp@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-03.txt >Date: Thu, 24 Jul 1997 07:21:36 PDT >Sender: pmp-owner@pwg.org > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Printer MIB Working Group of > the IETF. > > Title : Job Monitoring MIB - V0.83 > Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis > Filename : draft-ietf-printmib-job-monitor-03.txt > Pages : 95 > Date : 07/23/1997 > >This Internet-Draft specifies a set of 18 SNMP MIB objects for (1) >monitoring the status and progress of print jobs (2) obtaining resource >requirements before a job is processed, (3) monitoring resource consumption >while a job is being processed and (4) collecting resource accounting data >after the completion of a job. This MIB is intended to be implemented (1) >in a printer or (2) in a server that supports one or more printers. Use of >the object set is not limited to printing. However, support for services >other than printing is outside the scope of this Job Monitoring MIB. > >Future extensions to this MIB may include, but are not limited to, fax >machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-03.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-03.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-03.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. >Content-Type: text/plain >Content-ID: <19970723105031.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-03.txt >Content-Type: text/plain >Content-ID: <19970723105031.I-D@ietf.org> > From hastings at cp10.es.xerox.com Thu Jul 24 19:58:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Nashua JMP Minutes In-Reply-To: Nashua JMP Minutes> Message-ID: <9707250001.AA10311@zazen.cp10.es.xerox.com> Harry, Good summary. Tom At 22:39 07/10/97 PDT, Harry Lewis wrote: snip... > >Two other issues have been introduced by Xerox post meeting. >One, a severe change, is the recommendation to split the >attribute table into separate tables for Integer and Octet >values. Currently, a job attribute may have an Integer and/or >Octet value, both of which are represented in the same table >entry. The other new issue pertains to localization. Again, see >Tom's updated issues list. Xerox did not bring up these issues. They were brought up by David Perkins, noted SNMP expert. We had asked him to comment on our draft. Since he only send the comments back to me, I forwarded them on to the JMP. (His comments were sent to me at 1:00am on Friday of our Nashua meeting. I did not see them in the AM to bring to the meeting. Either I was too sleepy, or there was some delay in the mail systems.) From harryl at us.ibm.com Fri Jul 25 15:20:28 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> Nashua JMP Minutes In-Reply-To: Nashua JMP Minutes> Message-ID: <5030100005329434000002L042*@MHS> Tom, my apologies for assuming Dave Perkins and Xerox were one in the same. I only recall seeing Dave's comments in a note originating from you where you had performed some editing ... leading to my incorrect assumption. If Dave's note made it directly to the PWG I must have missed it. In any case, are we in agreement to leave the Attribute table as one unit, as originally designed? Harry Lewis - IBM Printing Systems ----------- Forwarded by Harry Lewis/Boulder/IBM on 07/25/97 01:16 PM ------------- hastings@cp10.es.xerox.com 07/24/97 06:04 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@IBMUS cc: JMP@pwg.org @ internet Subject: Re: JMP> Nashua JMP Minutes Harry, Good summary. Tom At 22:39 07/10/97 PDT, Harry Lewis wrote: snip... > >Two other issues have been introduced by Xerox post meeting. >One, a severe change, is the recommendation to split the >attribute table into separate tables for Integer and Octet >values. Currently, a job attribute may have an Integer and/or >Octet value, both of which are represented in the same table >entry. The other new issue pertains to localization. Again, see >Tom's updated issues list. Xerox did not bring up these issues. They were brought up by David Perkins, noted SNMP expert. We had asked him to comment on our draft. Since he only send the comments back to me, I forwarded them on to the JMP. (His comments were sent to me at 1:00am on Friday of our Nashua meeting. I did not see them in the AM to bring to the meeting. Either I was too sleepy, or there was some delay in the mail systems.) From don at lexmark.com Fri Jul 25 15:58:21 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> September Meeting in Atlanta Message-ID: <199707251958.AA18604@interlock2.lexmark.com> I have finalized the September Meeting in Atlanta. Here are the details: When: September 15-19 Where: Atlanta Marriott Suites Midtown Price: $129 per night Deadline: August 29th Reservations: 1-800-228-9290, 1-404-876-8888 Meeting Fee: in the range $35-40 expected All you Type A people should be able to start making your reservations on Monday (July 28th). Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Fri Jul 25 19:40:47 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 In-Reply-To: JobSubmission ID Format 0> Message-ID: <9707252343.AA10801@zazen.cp10.es.xerox.com> At 16:09 07/23/97 PDT, Harry Lewis wrote: >Tom, in going over the Job MIB v.83, I was surprised to see the change >to JobSumbissionID format 0. > >Previously, format 0 was defined such that, if no submission ID was passed >in, the agent would use whatever algorithm it desired to provide one. The >recommendation was for the agent to simply reflect the jmJobIndex here. > >I recall a lot of discussion at Nashua about moving JobOwner to the Job Table >and providing a new (additional) JobSubmissionID format based on JobOwner. I >was expecting this to be something like format 8, not a replacement for format >0. I think we also agreed that the agent could use any of the standard formats, if the job submitter didn't submit a jobsubmissionid, rather than constraining the agent to a particular format. So I deleted format 0. The 0 format is no longer the default format that the agent uses if the submitter didn't supply a jobsubmissionid. The agent is free to use any format. Ok? When adding the jobOwner format, I assigned it to 0, rather than the end. It seems like a particularly useful and important format. >There's a pretty big question in my mind exactly WHY we think JobOwner needs >to be part of a default format 0, especially since jmJobOwner is a mandatory >object in the Job Table. I only offer the following definition as a potential >compromise. I would prefer to keep format 0 as previously defined... basically >agent assigned. I agree that it would be a problem if the spec says that a job owner has to be part of the default format. That is why we got away from having a single default format, I thought. So now the agent is free to use any if the standard formats, not just the 0 format when the submitter doesn't submit an ID. > >If the desire is to have the agent use JobOwner (if supplied) in the default >case, we could stipulate this within format 0 but then I would still like to >see a separate format (8) for JobOwner passed in as a JobSubmissionID. This >way, the decimal portions can overlap without danger of ambiguity. > >So, to be more precise, we could define format 0 as > >'0' octets 2-40: last 39 bytes of jmJobOwner. > > octets 41-48: 8 decimal-digit sequential number (preferably equal to > jmJobIndex). > >'8' octets 2-40: last 39 bytes of jmJobOwner. > > octets 41-48: 8 decimal-digit sequential number Are you worrying that one client might not supply a job submission id for a particular job owner, but that same user from another client might. So that the second client might assign a sequence number that was the same as the agent assigned for the first one and thereby be a collision? That could happen with any of the formats, if the agent assigns the trailing number sometimes and the submitter does other times. Do we want to fix that? We could make separate format numbers for assigned by agent, versus assigned by the job submitter, for all the formats, thereby doubling the number of format numbers. > >Now... for all you agent developers out there... I should warn you that having >the agent add JobOwner into the JobSubmissionID may not be as simple as it >sounds. Think of the fact that JobOwner may start out "blank" when you first >create the format 0 ID but may assume a value from the LPR control file at the >end of the job. The agent should probably feel obliged to MODIFY >JobSubmissionID >with the new JobOwner information. > >Note that, in my scenario, including JobOwner in the control file is not >considered the same as passing in a format 8 jmJobSubmissionID with 8 digit >sequential number. If this were to occur, then I'd say format 8 was in use. > > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Mon Jul 28 03:40:37 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> 5 alternatives for indicating code set (Issues 111 and 112) Message-ID: <9707280743.AA11040@zazen.cp10.es.xerox.com> Subj: 5 alternatives to removing the code set ambiguity in the Job Mon MIB From: Tom Hastings Date: 7/25/97 File: jmpalter.doc The Job Monitoring MIB has the same problem of identifying and/or specifying coded character sets that we are currently wrestling with for the Printer MIB. The solutions do NOT necessarily need to be the same. David Perkin's has made this comment when reviewing our job mon MIB. His comment states: "The module has a problem with all the objects that have type of OCTET STRING. You really need to enforce a code-point mapping. Consider a management application. What are they to do with the values? Do they try to figure out the encoding, or ask the user of the application for a hint, or what?" Here are 5 alternatives that I can think of: 1. Leave OCTET STRING undefined as in the current draft and therefore open to any coded character set, including any of the 211 registered with IANA. 2. Restrict OCTET STRING to US-ASCII in 32 to 126; unused: 0-31, 126-255. 3. Allow ANY coded character set, even ones that don't have US-ASCII in 32 to 126, but have a (read-only) attribute to specify which coded character set the agent has used to store the data (usually the code that the submitter used for that job). 4. US-ASCII in 32-126, other specified sets in 128 to 255; unused: 0-31, 126, but have a read-only attribute to specify which coded character set the agent has used to store the data (usually the code that the submitter used for that job). (My Wednesday SYNTHESIS proposal) 5. Only UTF-8 in 32 to 126 and 128 to 255; unused: 0-31, 127 (David Kellerman's proposal) Now the PROs and CONs of each of the 5 alternatives: Unlike the Printer MIB, we can consider a "wide open" alternative which allows any coded character set, not just ones that are restricted to having US-ASCII in code positions 32 to 126. So straight unicode or any national 7-bit set could be used in this alternative (see alernative 3). We are only dealing with the coded character set (and encoding scheme) of the objects and attributes that have syntax OCTET STRING. We are NOT attempting to solve the much harder problem of localization that includes language and country for these objects and attributes. Also for the Job Monitoring MIB, unlike the Printer MIB, all objects are read-only, so the application can NOT write any. ISSUE 111 (restated): How does an application determine the coded character set for the 3 objects and attributes that the agent generates (that did not come from the job submitter)? The following objects and attributes are in question: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute ISSUE 112: (restated) How does an application tell the coded character set of the 19 objects/attributes that come from the job subitter (or are defaulted by the server/device)? The 19 objects and attributes in question are: IETF Job object/attributes Equivalent IPP attributes -------------------------- ------------------------- jmJobOwner object "job-originating-user" other, - unknown, - serverAssignedJobName, - jobName, "job-name" jobAccountName, - submittingServerName, - submittingApplicationName, - jobOriginatingHost, "job-originating-host" deviceNameRequested, "printer-uri" queueNameRequested, - fileName, "document-uri" documentName, "document-name" jobComment, - outputBin (name), - mediumRequested (name), "media" mediumConsumed (name), - colorantRequested (name), - colorantConsumed (name) - We have five alternatives proposed for these OCTET STRING objects and attributes for either of issues 111 and 112: NOTE: The solutions for issues 111 and 112 do NOT need to be the same. 1. Leave OCTET STRING undefined as in the current draft and therefore open to any coded character set, including any of the 211 registered with IANA. The current text is: "Internationalization Considerations There are a number of objects in this MIB that are represented as coded character sets with a data type of OCTET STRING. Most of the objects are supplied as job attributes by the client that submits the job to the server or device and so are represented in the coded character set specified by that client. For simplicity, this specification assumes that the clients, job monitoring applications, servers, and devices are all running in the same locale, including locales that use two-octet coded character sets, such as ISO 10646 (Unicode). Job monitoring applications are expected to understand the coded character set of the client (and job), server, or device. No special means is provided for the monitor to discover the coded character set used by jobs or by the server or device. This specification does not contain an object that indicates what locale the server or device is running in, let alone contain an object to control what locale the agent is to use to represent coded character set objects. This MIB also contains objects that are represented using the DateAndTime textual convention from SMIv2 [SMIv2]. The job management application SHALL display such objects in the locale of the user running the monitoring application." PRO: b. Easiest for us to do. d. Some job submision protocols don't specify what the coded character set is either in their specification or in the protocol, so that the agent hasn't a clue what the coded character set is that the job submission used. CON: a. Possible that our Area Director won't forward the document, since it is ambiguous about coded character set and so it would not become a draft standard. c. The Area Director might fix the problem for us (but we might not like the results, if we don't participate). d. The agent can put the value 'unknown(2)' to indicate that the coded character set is unknown, thus making it clear to the application that the application has to use other means in order to determine the coded character set, such as asking the user, assuming the default for the host platform, or assuming the default for the agent (if we add such an object). 2. Restrict OCTET STRING to US-ASCII in 32 to 126; unused: 0-31, 126-255. - Change the document to restrict OCTET STRING data to US-ASCII in 32-126 and that 128 to 255 SHALL NOT be used. - Indicate that code positions 0-32 and 127 SHALL NOT be used, unless the DESCRIPTION clause specifies otherwise. - Also add a proper reference to the ANSI X3.4:1968 that specifies ASCII. PRO: a. Satisfies David Perkin's and the Area Director by clarifying what the interpretation of these objects shall be with respect to coded character set and encoding scheme. CON: c. Would not meet market objects of many of the implementations of job submision protocols that already support other parts of the world where US-ASCII is not sufficient to represent job submitter supplied information. d. Would NOT even meet the needs of IPP, which specifies UTF-8. 3. Allow ANY coded character set, even ones that don't have US-ASCII in 32 to 126, but have a (read-only) attribute to specify which coded character set the agent has used to store the data (usually the code that the submitter used for that job). - Allow any graphic character set in 0 to 255. - Don't allow any control characters in 0 to 255. - Recommend UTF-8 as the default. - Add a read-only object for specifying the code set for the 3 objects/attributes that do not come from the job submitter. - Add a (readonly) attribute for specifyiing the code set for the 19 objects/attributes that come from the job submitter. (The agent can either keep the data in the original char set of the submitter, or can code convert to another coded character set, though there is not reason why an agent would have to convert.) - Any registered set could be used. - See: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets. PRO: a. Would satisfy David Perkins and the Area Directors to specify the coded character set (in the protocol). b. Conforms to current practice of job submission protocols, including ones that use Unicode (which doesn't have US-ASCII in 32 to 126).. c. Includes UTF-8 (recommended default) as recommended by the IAB in RFC 2130. d. Makes the agents life easier, since the agent would not have to do any code conversion from the data that is submitted with the job. The agent either plugs in the code character set or the 'unknown(2)' value. e. Allows an application to determine the coded character set of the objects and attributes, if known to the agent. CON: a. It would be too wide open. Applications would have to deal with many more sets (or hope that their host platform does). Most data can be represented in US-ASCII, so losing that even 32 to 126 is fixed would be a great burden on the application. 4. US-ASCII in 32-126, other specified sets in 128 to 255, unused: 0-31, but have a read-only attribute to specify which coded character set the agent has used to store the data (usually the code that the submitter used for that job). (My Wednesday SYNTHESIS proposal) - Allow any graphic characters in 128 to 255, but 32-126 SHALL be US-ASCII - Indicate that code positions 0-32 and 127 SHALL NOT be used. - Recommend UTF-8 as the default. - Add a read-only object for specifying the code set for the 3 objects/attributes that do not come from the job submitter. - Add a (readonly) attribute for specifyiing the code set for the 19 objects/attributes that come from the job submitter. - The agent can either keep the data in the original char set of the submitter, or can code convert to another coded character set. - The agent SHALL code convert if the job submission code set does not have US-ASCII in 32-126. For example, the agent SHALL code convert from Unicode to UTF-8. - Any of the 50 out of 211 registered set could be used that contain US-ASCII in 32 to 126. - See: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets. - List conforming examples, which include UTF-8 (recommended default), ISO 8859-1 (Latin1), HPRoman8, Code page 850, US-ASCII, US-ASCII/JIS X0208 (Japanese national two byte set in 128-255), Shift JIS (Microsoft extension to extend Katakana to represent Kanji), US-ASCII/GB2312 (PRC Chinese national two-byte set in 128-255). - Add a proper reference to the ANSI X3.4:1968 that specifies ASCII, plus all the examples. PRO: a. Conforms to current practice of most job submission protocols. b. Permits UTF-8 to be used as recommended by the IAB for new protocols in RFC 2130. c. Recommends UTF-8 as the default as recommended by the IAB in RFC 2130. d. Permits other coded character sets, as allowed by the IAB for existing protocols in RFC 2130. e. Allows Job Monitoring MIB implementations to use the coded character set that the customer's environment uses (US-ASCII, Unicode, ISO 8859-n (n=1..11), Microsoft extensions to LatinN, Code page 850, HP Roman8, JIS X0208, Shift JIS, GB 2312, ...). f. Allows the vendor supplied and the system administrator supplied data to be represented in a SINGLE coded character set established at install time. (See separate e-mail on how this works in current vendor implementations). CON: g. Harder for applications that want to process the values returned from MIB (as opposed to simplying displaying data which is usually handled by the platform), if the data includes values in 128 to 255 and the application needs to support more than one possible coded character set that the system administrator could have specified at install time. For example, if the application is supporting the Western Hemisphere and Western Europe, the application might need to support, ISO Latin1, HP Roman8 and Code page 850, depending on the customer's environment. Similar situation for Asia where the application might have to support Unicode/UTF-8, JIS X0208, and GB2312. e. If the coded character set specified for the MIB is different from that supported by the host platform in which the application is running, the application will have to perform code conversion in order to display the coded character set data to the user. f. Complicates the system administrator install procedures, since the information on the install floppy needs to be represented in different coded character sets. 5. Only UTF-8 in 32 to 126 and 128 to 255; unused: 0-31, 127 (David Kellerman's proposal) - Allow only UTF-8 which is US-ASCII in 32-126 and a multi-byte character encoding scheme in 128 to 255 that represent the characters of ISO 10646 (Unicode). - Indicate that code positions 0-32 and 127 SHALL NOT be used. - Also add a proper reference to the ANSI X3.4:1968 that specifies ASCII and a reference to UTF-8. PRO: a. It is the recommendation of the IAB in RFC 2130 for "new [Internet] protocols or new versions of old protocols" to use UTF-8 as the "default". The job monitoring MIB is a *new* protocol, we should take the opportunity to follow the IAB recommendation now. c. Only a single coded character set is permitted, so that applications only have to deal with a single fixed coded character set at design time, namely UTF-8. e. ISO 10646 and UTF-8 are winning support in many quarters for actual implementation. NT has Unicode as its internal code set. IPP specifies all text attribute values in UTF-8. Novell Netware 4.2 supports Unicode. f. Don't need to add an object or an attribute to indicte the coded character set of either the 3 objects/attributes that don't come from the job submitter and the 19 that do. CON: a. The same paragraph of RFC 2130 (page 3) goes on to say: "These defaults do not deprecate the use of other character sets when and where they are needed; they are simply intended to provide guidance and a specification for interoperability. In fact, RFC 2130 does not even mention SNMP as one of the Internet Protocols. I wonder why? Because SNMP is more likely to be deployed on a LAN, not the Internet? b. Most current job submission protocols do NOT use UTF-8, so that the agent SHALL have to perform code conversion to UTF-8. c. Forces applications to deal with UTF-8, when some applications would be far simpler to just use the coded characer set of the environment. d. Many applications do NOT actually need to process the information from the MIB; they merely pass it through to the host platform, which takes care of displaying the information. Unless the platform supports UTF-8 (or equivalently Unicode, such as NT or Novell 4.1), the applicataion will have to convert the coded character set data from UTF-8 to some other coded character set that the host platform can display to the user. e. Accpeptance of ISO 10646 (Unicode) in Asian markets has not been enthusiastic. Many customers have huge investments in data and applications that use their national two byte sets (JIS X0208 Japanese and GB2312 Chinses). So the Asian vendors have not jumped on the ISO 10646 bandwagon. Some have, some have not. I don't have good figures on the the size of each camp. I think it also depends on the application area. Code conversion between UTF-8 and JIB X0208 and GB2312 is a hugh 14-bit table lookup, i.e., a 16 mega-byte table. NOTE: both proposals 4 and 5 are upgrades from US-ASCII, so that PRO is not mentioned with either alternative. From hastings at cp10.es.xerox.com Mon Jul 28 04:11:22 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Last change to split attribute table: application writers? Message-ID: <9707280814.AA11050@zazen.cp10.es.xerox.com> Last change to split the attribute table into a table of just integers and a separate table of just OCTET STRINGs, as suggested by David Perkins: >>>There is one change that would affect any current implementations >>>that I strongly suggest that you do. Table jmAttributeTable has >>>three accessible columnar objects. The first tells you the "type" >>>(either integer, octet, or both) of the value of the attribute. >>>The second two columns are the attribute's value. I suggest that >>>instead of this single table, that you have two tables. Each table >>>would have a single accessible column. The first table would contain >>>integer valued attributes, and the second table would contain >>>octet string valued attributes. If there is no support, especially from applications writers, by Tuesday noon, 7/29, the I-D draft for Munich will NOT be split. Tom At 12:20 07/25/97 PDT, Harry Lewis wrote: >Tom, my apologies for assuming Dave Perkins and Xerox were one in the same. >I only recall seeing Dave's comments in a note originating from you where you >had performed some editing ... leading to my incorrect assumption. If Dave's >note made it directly to the PWG I must have missed it. > >In any case, are we in agreement to leave the Attribute table as one unit, as >originally designed? > >Harry Lewis - IBM Printing Systems Harry, Did you show this reply to your original analysis to splitting the attribute table to your developers. Did any of this change any of their minds? If not, lets keep the table together. Our implementors thought that it helped applications some to split, in that the application could walk either table or both together, application's choice. However, our implementors didn't feel that we absolutely must split the tables. Any other implemntors have opinions, especially application writers, since there is no burden or advantage or disadvantage to the agent with splitting or not splitting. Tom >Return-Path: >X-Sender: hastings@zazen >Date: Fri, 11 Jul 1997 13:32:04 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: Re: JMP> ISSUE: split jmAttributeTable or not >Sender: jmp-owner@pwg.org > >Harry, > >Thanks for your analysis. We've looked at the problem too and >think that splitting does have a few advanatages, but maybe not so >overwhelming. See what you think. If there is not substantive agreement >to split the table, then lets leave it the way it is. We'll need to >put forth our arguments to David and see whether he thinks our >arguments have merit or not. > >If we don't split now, there is some risk that the IESG/Area Directors >might split the table for us. > >For SNMPv2 where GetBulk can be used, the network traffic >is cut by 1/3 to 1/2 when the table is split vs. combined for applications >that want to get all the attributes (such as an accounting application). >This is because the management app can get as many attributes as can fit into >one PDU. Even with a limit like 540 bytes in a PDU, this means that >a single PDU can return 20-30 integers in one PDU, instead of 10-15. > >Also a monitoring application is mostly interested in the integer values >that get updated during the job's life cycle. Strings are mostly >static, so even an application that was monitoring a single job, >could use GetBulk to get all the integer attributes in one or more >PDUs. > >So even with SNMPv1 a monitoring application might want to use >Get Next to just walk the integer table and then look at one or >two strings explicitly that might change. > >And a management application that is using Get Bulk is already storing >an entire table and then sorting through it. That is the cost to a >management application when using GetBulk. > >See commments below. > >Tom > >At 18:20 07/09/97 PDT, Tom Hastings wrote: >>At 01:18 06/27/97 PDT, David T. Perkins wrote: >> >>snip... >> >>>There is one change that would affect any current implementations >>>that I strongly suggest that you do. Table jmAttributeTable has >>>three accessible columnar objects. The first tells you the "type" >>>(either integer, octet, or both) of the value of the attribute. >>>The second two columns are the attribute's value. I suggest that >>>instead of this single table, that you have two tables. Each table >>>would have a single accessible column. The first table would contain >>>integer valued attributes, and the second table would contain >>>octet string valued attributes. >> >>[David did not mention that there is actually a fourth index which >>is an "instance" index for those attributes that can have more than >>one value per job. I'm not sure whether this fact changes the argument >>or not.] >> >>snip... >> >>We need to consider this suggestion and either accept it or justify >>why not. Lets get collected comments (such as Harry's below) and >>respond to David. David is a noted authority on SNMP, so accommodating >>his comments will help forward our document. >> >>Xerox developers have several views and we are in the process of >>reaching a consensus (I'll send you results Thursday, 7/10). >> >>Harry Lewis's developers have made a review and are not convinced that >>it is a good idea to split the table: >> >>>Return-Path: >>>From: Harry Lewis >>>To: >>>Cc: , , >>>Subject: Splitting the Attribute Table >>>Date: Wed, 9 Jul 1997 10:52:02 PDT >>> >>Tom, we have conducted a review here, regarding your recommendation >>to split the attribute table into two tables - one for Integer values >>and one for Octets - and are of the opinion that the current attribute >>table is superior. Here is our summary. >> >>1. First, we assume that attributes will have a null string for the >>valueAsOctet and -2 for valueAsInteger if appropriate. > >Actually, its -1, not -2. -2 is for unknow, -1 for other. >(I'll clarify that in the document). > > >> >>2. With GetNext, we do not believe network traffic is an issue because >>the "extra" null string or -2 will fit in the PUD packet. > >Agree that when doing one or two GetNext in a single PDU it fits. > >> >>3. We believe, using get next, there are less calls required with the >>current scheme than would be needed if the table was split. >> >>Example: >> >> Integer Octet >> ------- ----- >> >> -2 X >> X Null >> X X >> X Null >> -2 X >> >> >>Consider the above excerpt. It will take 5 get next calls using the current >>method. But it would take 6 calls if the table were split (one for each X >>which represents a real value). > >Actually, I would think that the application would two GetNext in each >PDU, one for the integer table and one for the string table (and then >have to merge the results, since the attributes that have both integer >and string value would not be together). So the number of calls would >be 3, in the example if we split, instead of 5. So spliting does >reduce the number of calls (at the expense of having to sort the results). > > >> >>4. While, in most cases, the monitor will know whether or not the attribute >>is defined as Integer, Octet or Both... there are cases where it could >>be EITHER. With the current scheme, the monitor "finds out" what this >>particular device has instrumented in one get next (for each attribute). >>With split tables, you have to look in both tables to know (this may >>just be a restatement of (3) above). > >Yes, more of a sorting is required. (Not unlike the sorting for >GetBulk in SNMPv2. > >> >>5. There is no storage savings in the agent if done properly, where the >>agent knows which syntax is being used. > >We agree, that a good impelmentation doesn't cost any space with all the >not meangingful values (-2, 2, and zero-length string). > >> >>Tom, this is our summary. I think the ball is "in your court" to decide >>whether or not to open this problem to a wider audience, send us a >>DETAILED "rebuttal" or accept our findings. > >Lets see what others think, especially the application writers, since >whether to split or not seems to affect them the most. > >Our implementations use Get Bulk when SNMPv2 is being used and don't >when it is SNMPV1. How about others? > >> >> >>Harry Lewis - IBM Printing Systems >> > > From harryl at us.ibm.com Mon Jul 28 11:23:09 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 In-Reply-To: JobSubmission ID Format 0> Message-ID: <5030100005396773000002L032*@MHS> Tom wrote: >I think we also agreed that the agent could use any of the standard >formats, if the job submitter didn't submit a jobsubmissionid, rather >than constraining the agent to a particular format. So I deleted >format 0. The 0 format is no longer the default format that the agent >uses if the submitter didn't supply a jobsubmissionid. The agent is >free to use any format. Ok? No, This is not OK. We agreed the agent can use any scheme to derive the jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known. But, if the agent does not use a unique format ID, there is a high probability that the sequential part of the ID's will intersect - something which I think should be avoided. Sequential ID's are, by definition, fairly local constructs. Keeping format 0 for the agent prevents the agent from "stepping on" the local id's of a server, for example, because the server will always be using some format ID other than 0. >When adding the jobOwner format, I assigned it to 0, rather than the >end. It seems like a particularly useful and important format. Formats will "come and go". I don't this the enum given to the format has any significance in terms of indicating it's "importance". >>There's a pretty big question in my mind exactly WHY we think JobOwner needs >>to be part of a default format 0, especially since jmJobOwner is a mandatory >>object in the Job Table. I only offer the following definition as a potential >>compromise. I would prefer to keep format 0 as previously defined... basically >>agent assigned. > >I agree that it would be a problem if the spec says that a job owner has >to be part of the default format. That is why we got away from having >a single default format, I thought. So now the agent is free to use any >if the standard formats, not just the 0 format when the submitter doesn't >submit an ID. Here, we do agree. Format 0 was never supposed to be a "fixed" format, just an enum that assured this ID was assigned by the agent. I thought I picked up in Nashua that folks wanted JobOwner to be the primary choice if the agent had to assign an ID. We can establish preferred conventions via FAQ, if this would be useful, but format 0 is intended to be "open" for the agent to make intelligent choices based on what information is available (given the absence of a "legitimate" jmJobSubmissioID). >Are you worrying that one client might not supply a job submission id >for a particular job owner, but that same user from another client >might. So that the second client might assign a sequence number that was >the same as the agent assigned for the first one and thereby be a collision? > >That could happen with any of the formats, if the agent assigns >the trailing number sometimes and the submitter does other times. > >Do we want to fix that? > >We could make separate format numbers for assigned by agent, versus >assigned by the job submitter, for all the formats, thereby doubling >the number of format numbers. This really CAN'T happen with any format if the agent sticks to format 0. That's the point. There is not need to double the number of format numbers! Harry Lewis - IBM Printing Systems From rbergma at dpc.com Mon Jul 28 12:57:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> 4th Set of Comments on Version 0.83 Message-ID: <5030100005396773000002L032*@MHS> Some more editorial corrections to version 0.83. (I have more comments and will try to get the remainder published tonight.) 1. Section 3.3.4, first paragraph (page 24): Add to end of the paragraph: "Attributes that allow duplicates are indicated in the appropriate attribute description." Then the last two paragraphs are no longer required. (The first is a redundant example of an intensive attribute.) The two paragraphs to be deleted are: "As another example of an intensive attribute that can have multiple entries, if a document or job uses multiple types of media, there SHALL be only one row in the jmAttributeTable for each media type, not one row for each document that uses that medium type. On the other hand, if a job contains two documents of the same name, there can be separate rows for the documentName attribute with the same name, since a document name is an extensive attribute. The specification indicates that the values NEED NOT be unique for such 'MULTI-ROW: attributes'" 2. Section 3.3.5 (page 24), the following change is suggested. ("that submitted the job" seems to obvious to include.) Change: "(1) requested by the client (or intervening server) in the job submission protocol that submitted the job..." To: "(1) requested by the client (or intervening server) in the job submission protocol..." 3. section 3.6.1.2 (page 27), the following is confusing: "Those textual conventions that are labeled "[same enum values as IPP]" have the same enum values as the indicated IPP Job attribute. When IPP registers additional values, those values shall be simultaneously registered by IANA for use with the Job Monitoring MIB textual- convention, so that the enum values stay in lock step between the IPP protocol and the Job Monitoring MIB." Proposed new wording: "For those textual conventions that have the same enum values as the indicated IPP Job attribute, additional values shall be simultaneously registered by IANA for use with both IPP and the Job Monitoring MIB." 4. In the description for JmJobStateTC (page 40), there is a state "other". "other(1), The job state is not one of the defined states." I thought we had covered all possible states with the 7 primary plus the JmJobStateReasons. Why do we need other? Did we not accomplish what was claimed? 5. In the description for JmAttributeTypeTC (page 43) the paragraph: "In the following descriptions of each attribute, the tags: 'INTEGER:' or 'OCTETS:' specify whether the value SHALL be represented in the jmAttributeValueAsInteger or the jmAttributeValueAsOctets object, or both, respectively." This information seems to be adequately presented in the previous paragraphs and I recommend that it be deleted. 6. Also in the description for JmAttributeTypeTC (page 43) the paragraph: "The standard attribute types defined so far are:" This sounds like the MIB document is not final, I suggest: "The standard attribute types defined at the time of completion of this document:" 7. In the description for serverAssignedJobName (22) (page 45), the text "...that the agent is providing access to with this MIB." is obvious from the context and should be deleted. More to come... Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Mon Jul 28 18:27:06 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> 5 alternatives for indicating code set (Issues 111 and Message-ID: <5030100005423033000002L032*@MHS> I would assert that the "coded character set problem" only pertains to 3 objects (or attributes) in the Job MIB... >ISSUE 111 (restated): How does an application determine the coded character >set for the 3 objects and attributes that the agent generates (that did not >come from the job submitter)? > >The following objects and attributes are in question: > > jmGeneralJobSetName object > processingMessage attribute > physicalDevice (name value) attribute because all other strings are passed in upon submission by presumably any and many different protocols with various limitations - one of which is not being able to specify localization (PJL for example). If we accept my premise, then I suggest treating job MIB "localization" *very differently* from the way we have for PMP and IPP... I propose JUST GET RID OF THOSE 3 OBJECTS and do it quickly before we generate another 50 URGENT mail messages!! Harry Lewis - IBM Printing Systems From rbergma at dpc.com Mon Jul 28 21:17:15 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> 5th Set of Comments on Version 0.83 Message-ID: <5030100005423033000002L032*@MHS> Here is the final set of editorial comments on version 0.83. 1. The header line for the following attributes/flag bits is indented too far. (Does not match the other entries.) jobSourceChannelIndex(25) (page #46) jobProcessAfterDateAndTime(51) (page #49) jobCompletedTime(194) (page #57) jobProcessingCPUTime(195) (page #57) exceedAccountLimit (page #67) 2. In the header for physicalDevice(32) (page #47), the reference "(see HR MIB)" is not per IETF format. The proper format does appear in the text that follows. I suggest that the first reference be deleted. 3. In jobHoldUntil(53) (page #49), I do not understand " 'no-hold' ". 4. What is the difference between Toner Economy (tonerEconomyRequested and tonerEconomyUsed) and Toner Density (tonerDensityRequested and tonerDensityUsed)? (see page #51) They appear to be identical from the description. (or very very close!) 5. The reference for DateAndTime (page #56) should be: "See SNMPv2-TC [SMI-V2]" (The part in brackets is missing.) Also, as in item #2 above, the text "(SNMPv2-TC)" should be removed from the attributes that follow (numbers 190 to 195). 6. In jmJobStateReasonsTC (page #61) the third line of the description: "...to provides additional..." S/B "...to provide additional..." 7. Also in jmJobStateReasonsTC (page #61) the last sentence of the fourth paragraph: "For ease of understanding, the JmJobStateReasons1TC reasons are presented in the order in which the reason is most likely to occur, not counting the 'other' and 'unknown' reasons." This paragraph invites a challenge and I suggest that it be removed. 8. In jobProcessAfterSpecified (page #62), the text: "...specifies a time that is still in the future, either set when the job was created or subsequently by an explicit modify job operation." Do we care how this was defined? Is it possible that another method could be used? I suggest that the sentence be shortened to: "...specifies a time that is still in the future." 9. I am confused by the abortedBySystem entry (page #63). "abortedBySystem 0x2000 The job was aborted by the system. NOTE - this reason is needed only when the system aborts a job, but does not put the job in the aborted job state. For example, if the system aborts the job, but places the job in the pendingHeld state, so that a user or operator can try the job again." If the job is in the pendingHeld state, why would aborted be reported? Either provide a better explanation for this flag or remove it. 10. In heldForRetry (page #67), change the text: "...but the error might not be encountered if the job is re-tried in the future, such as phone number busy.." To: "...but the error might not be encountered in the future. Example causes are a phone number busy.." 11. In jmGeneralJobPersistence (page #72), the second paragraph: "Depending on implementation, the value of this object MAY be either: (1) set by the system administrator by means outside this specification or (2) fixed by the implementation." Since this is a read only object do we need to define how it is configured? We only need to describe the function. 12. For jmGeneralAttributePersistence (page #73) the above comment (11) also applies. 13. In jmJobIDEntry (page #74), I did not realize that jmGeneralJobSetIndex was no an index into this group. (If it is an index, the object jmJobIDSetIndex (page #75) can be removed.) Why is this not an index? 14. The object name "jmJobIDJobIndex" (page #75) is awful! I suggest "jmIDJobIndex". 15. In jmJobStateReasons1 (page #77), I find the following statement hard to disagree with, but why do we need to state this? "Furthermore, when implemented as with any MIB data, the agent SHALL return these values when the reason applies and SHALL NOT return them when the reason no longer applies whether the value of the job's jmJobState object changed or not." All this really states is that the value of an object must be valid. We do not have a similar statement for any other object. 16. Also in jmJobStateReasons1 (page #77), the next sentence: "When the job does not have any reasons for being in its current state, the agent SHALL set the value of the jmJobStateReasons1 object and jobStateReasonsN attributes to 0." I suggest it be reworded to: "When the agent cannot provide a reason for the current state of the job, the value of jmJobStateReasons1 object and jobStateReasonsN attributes shall be 0." 17. Appendix B should be moved to the Mapping RFC but we should keep it here until the Mapping RFC plans are firm. (This will be the primary agenda item next week in Redmond.) 18. The section numbering of the Appendices is somewhat strange, but I am not sure if this should be changed. 19. In section 7, the reference to ipp-model (page #89) I believe: "...in progress.." should be "...work in progress.." The end of my comments (but I reserve the right to make additional comments in the future.) Ron Bergman Dataproducts Corp. From don at lexmark.com Tue Jul 29 13:07:12 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> Potential Finisher MIB Project Message-ID: <199707291707.AA18702@interlock2.lexmark.com> At the request of several interested individuals, I have adjusted the Friday agenda of the August meeting at Microsoft. We have had some discussion of a Finisher MIB on the mailing list and a FIN mailing list has been established. Harry Lewis has agreed to moderate a discussion on Friday morning to gauge interest in kicking off a Finisher MIB project. As such, the Friday agenda is as follows: 8:30 AM - 10:30 AM Finisher MIB discussion 11:00 AM - 5:00 PM JOB MIB If the entire 2 hours is not necessary to gauge interest and if needed identify leadership, the JMP work will start early. Unfortunately due to business commitments, I will not be in attendance on Friday but I am sure the discussion will be excellent under the capable leadership of Mr. Lewis. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Tue Jul 29 14:29:42 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> From Harry and Tom: Simple solution to Code Set identification Message-ID: <9707291832.AA11595@zazen.cp10.es.xerox.com> In order to avoid a flood of mail, I talked with Harry on simple solutions to the code set identification problem (Issues 111 and 112). We agreed on the following simple solutions which should satisy David Perkin's comment and the Area Directors warning not to leave the coded character set ambiguous to applications. I'm going to edit the following into the draft this afternoon in order to meet tommorrows deadline for the next Internet-Draft, unless I hear problems. Tom ISSUE 111 (restated): How does an application determine the coded character set for the objects and attributes that the agent generates (that cannot come from the job submitter)? The following 3 objects and attributes are in question: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute Suggested solution: Use UTF-8 only for these 3 objects/attributes. ISSUE 112 (re-stated): How does a management application determine the coded character set for the per-job objects and attributes that are returned by the agent (whether submitted by the job submitter or defaulted by the agent when the job submitter does not supply). The following 19 per-job objects and attributes are in question: IETF Job object/attributes Equivalent IPP attributes -------------------------- ------------------------- jmJobOwner object "job-originating-user" other, - unknown, - serverAssignedJobName, - jobName, "job-name" jobAccountName, - submittingServerName, - submittingApplicationName, - jobOriginatingHost, "job-originating-host" deviceNameRequested, "printer-uri" queueNameRequested, - fileName, "document-uri" documentName, "document-name" jobComment, - outputBin (name), - mediumRequested (name), "media" mediumConsumed (name), - colorantRequested (name), - colorantConsumed (name) - Suggested solution: Add a jobCodedCharSet job attribute that identifies the IANA character set that the agent is using to represent the job objects and attributes whether supplied by the job submitter or defaulted by the server/device when the job submitter does not supply. If the agent doesn't know what the coded character set that the job submitter used, the agent SHALL either (1) omit the jobCodedCharSet attribute or (2) return the value 'unknown(2)' as the value of the jobCodedCharSet attribute. From rbergma at dpc.com Tue Jul 29 16:19:25 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> From Harry and Tom: Simple solution to Code Set identification In-Reply-To: <9707291832.AA11595@zazen.cp10.es.xerox.com> Message-ID: <9707291832.AA11595@zazen.cp10.es.xerox.com> Tom, I recommend that these changes NOT be incorporated into a document that is posted as an Internet-Draft until the group can do a through review. I still do not understand the impact of UTF-8 and from the recent email on the PWG issue, I am not alone. To expect responses in such a short time is unreasonable. I am sure that the update you are working on will not be the final document for Proposed Standard. We should have plenty of time to properly resolve this issue. Ron Bergman Dataproducts Corp. On Tue, 29 Jul 1997, Tom Hastings wrote: > In order to avoid a flood of mail, I talked with Harry on simple > solutions to the code set identification problem (Issues 111 and 112). > > We agreed on the following simple solutions which should satisy > David Perkin's comment and the Area Directors warning not to leave > the coded character set ambiguous to applications. > > I'm going to edit the following into the draft this afternoon > in order to meet tommorrows deadline for the next Internet-Draft, > unless I hear problems. > > Tom > > ISSUE 111 (restated): How does an application determine the coded character > set for the objects and attributes that the agent generates (that cannot come > from the job submitter)? > > The following 3 objects and attributes are in question: > > jmGeneralJobSetName object > processingMessage attribute > physicalDevice (name value) attribute > > Suggested solution: Use UTF-8 only for these 3 objects/attributes. > > > > ISSUE 112 (re-stated): How does a management application determine the > coded character set for the per-job objects and attributes that are returned > by the agent (whether submitted by the job submitter or defaulted by the > agent when the job submitter does not supply). > > The following 19 per-job objects and attributes are in question: > > IETF Job object/attributes Equivalent IPP attributes > -------------------------- ------------------------- > jmJobOwner object "job-originating-user" > other, - > unknown, - > serverAssignedJobName, - > jobName, "job-name" > jobAccountName, - > submittingServerName, - > submittingApplicationName, - > jobOriginatingHost, "job-originating-host" > deviceNameRequested, "printer-uri" > queueNameRequested, - > fileName, "document-uri" > documentName, "document-name" > jobComment, - > outputBin (name), - > mediumRequested (name), "media" > mediumConsumed (name), - > colorantRequested (name), - > colorantConsumed (name) - > > > Suggested solution: > > Add a jobCodedCharSet job attribute that identifies the IANA character set > that the agent is using to represent the job objects and attributes whether > supplied by the job submitter or defaulted by the server/device when the job > submitter does not supply. If the agent doesn't know what the coded > character set that the job submitter used, the agent SHALL either (1) omit > the jobCodedCharSet attribute or (2) return the value 'unknown(2)' as the > value of the jobCodedCharSet attribute. > > > From hastings at cp10.es.xerox.com Tue Jul 29 18:09:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> From Harry and Tom: Simple solution to Code Set In-Reply-To: From Harry and Tom: Simple solution to Code Set> Message-ID: <9707292211.AA11683@zazen.cp10.es.xerox.com> Fine. I'll leave these changes out and we will discuss issues 111 and 112 at the Seattle meeting in August. Tom At 13:19 07/29/97 PDT, Ron Bergman wrote: >Tom, > >I recommend that these changes NOT be incorporated into a document >that is posted as an Internet-Draft until the group can do a >through review. I still do not understand the impact of UTF-8 >and from the recent email on the PWG issue, I am not alone. > >To expect responses in such a short time is unreasonable. I am >sure that the update you are working on will not be the final >document for Proposed Standard. We should have plenty of time >to properly resolve this issue. > > Ron Bergman > Dataproducts Corp. > > > >On Tue, 29 Jul 1997, Tom Hastings wrote: > >> In order to avoid a flood of mail, I talked with Harry on simple >> solutions to the code set identification problem (Issues 111 and 112). >> >> We agreed on the following simple solutions which should satisy >> David Perkin's comment and the Area Directors warning not to leave >> the coded character set ambiguous to applications. >> >> I'm going to edit the following into the draft this afternoon >> in order to meet tommorrows deadline for the next Internet-Draft, >> unless I hear problems. >> >> Tom >> >> ISSUE 111 (restated): How does an application determine the coded character >> set for the objects and attributes that the agent generates (that cannot come >> from the job submitter)? >> >> The following 3 objects and attributes are in question: >> >> jmGeneralJobSetName object >> processingMessage attribute >> physicalDevice (name value) attribute >> >> Suggested solution: Use UTF-8 only for these 3 objects/attributes. >> >> >> >> ISSUE 112 (re-stated): How does a management application determine the >> coded character set for the per-job objects and attributes that are returned >> by the agent (whether submitted by the job submitter or defaulted by the >> agent when the job submitter does not supply). >> >> The following 19 per-job objects and attributes are in question: >> >> IETF Job object/attributes Equivalent IPP attributes >> -------------------------- ------------------------- >> jmJobOwner object "job-originating-user" >> other, - >> unknown, - >> serverAssignedJobName, - >> jobName, "job-name" >> jobAccountName, - >> submittingServerName, - >> submittingApplicationName, - >> jobOriginatingHost, "job-originating-host" >> deviceNameRequested, "printer-uri" >> queueNameRequested, - >> fileName, "document-uri" >> documentName, "document-name" >> jobComment, - >> outputBin (name), - >> mediumRequested (name), "media" >> mediumConsumed (name), - >> colorantRequested (name), - >> colorantConsumed (name) - >> >> >> Suggested solution: >> >> Add a jobCodedCharSet job attribute that identifies the IANA character set >> that the agent is using to represent the job objects and attributes whether >> supplied by the job submitter or defaulted by the server/device when the job >> submitter does not supply. If the agent doesn't know what the coded >> character set that the job submitter used, the agent SHALL either (1) omit >> the jobCodedCharSet attribute or (2) return the value 'unknown(2)' as the >> value of the jobCodedCharSet attribute. >> >> >> > > > From hastings at cp10.es.xerox.com Tue Jul 29 19:25:50 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 [Harry's and Tom's In-Reply-To: JobSubmission ID Format 0 [Harry's and Tom's> Message-ID: <9707292328.AA11713@zazen.cp10.es.xerox.com> Harry talked with his developers and we've come up with the following resolution: Format 0 will be reserved to the agent to use when the client does not supply a job submission id in the job submission protocol. In this format the agent SHALL use the last 39 octets of the jmJobOwner value. We will add a new format 8 for the client's to use in a job submission ID that includes the job owner's name. In the future, if agents need other formats for use when the client doesn't supply a job submission ID, they can be proposed for registration. In the meantime, agents will use the job owner format (format 0) and clients will use formats 1-8. The new text will be: JmJobSubmissionTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the format type of a job submission ID. The ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 possible formats. Each job submission ID is a fixed-length, 48-octet printable ASCII coded character string, consisting of the following fields: octet 1 The format letter. octets 2-40 A 39-character, ASCII trailing SPACE filled field specified by the format letter, if the data is less than 39 ASCII characters. octets 41-48 A sequential or random number to make the ID quasi-unique. If the client does not supply a job submission ID in the job submission protocol, then the server SHALL assign a job submission ID using any of the standard formats that are reserved to the agent. Clients SHALL not use formats that are reserved to agents. The format values registered so far are: Format Letter Description ------ ------------ '0' octets 2-40: last 39 bytes of the jmJobOwner object. octets 41-48: 8-decimal-digit sequential number This format is reserved to agents for use when the client does not supply a job submission ID. Clients wishing to use a job submission ID that incorporates the job owner, SHALL use format '8'. NOTE - other formats may be registered that are reserved to the agent for use when the client does not supply a job submission ID. '1' octets 2-40: last 39 bytes of the jobName attribute. octets 41-48: 8-decimal-digit random number '2' octets 2-40: Client MAC address: in hexadecimal with each nibble of the 6 octet address being '0'-'9' or 'A' - 'F' (uppercase only). Most significant octet first. octets 41-48: 8-decimal-digit sequential number '3' octets 2-40: last 39 bytes of the client URL [URI-spec]. octets 41-48: 8-decimal-digit sequential number '4' octets 2-40: last 39 bytes of the URI [URI-spec] assigned by the server or device to the job when the job was submitted for processing. octets 41-48: 8-decimal-digit sequential number '5' octets 2-40: last 39 bytes of a user number, such as POSIX user number. octets 41-48: 8-decimal-digit sequential number '6' octets 2-40: last 39 bytes of the user account number. octets 41-48: 8-decimal-digit sequential number '7' octets 2-40: last 39 bytes of the DTMF incoming FAX routing number. octets 41-48: 8-decimal-digit sequential number '8' octets 2-40: last 39 bytes of the job owner name (that the agent returns in the jmJobOwner object). octets 41-48: 8-decimal-digit sequential number NOTE - the job submission id is only intended to be unique between a limited set of clients for a limited duration of time, namely, for the life time of the job in the context of the server or device that is processing the job. Some of the formats include something that is unique per client and a random number so that the same job submitted by the same client will have a different job submission id. For other formats, where part of the id is guaranteed to be unique for each client, such as the MAC address or URL, a sequential number SHOULD suffice for each client (and may be easier for each client to manage). Therefore, the length of the job submission id has been selected to reduce the probability of collision to an extremely low number, but is not intended to be an absolute guarantee of uniqueness. None-the-less, collisions are remotely possible, but without bad consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them." REFERENCE "This is like a type 2 enumeration. See section 3.6.3." SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z' At 08:23 07/28/97 PDT, Harry Lewis wrote: >Tom wrote: > >>I think we also agreed that the agent could use any of the standard >>formats, if the job submitter didn't submit a jobsubmissionid, rather >>than constraining the agent to a particular format. So I deleted >>format 0. The 0 format is no longer the default format that the agent >>uses if the submitter didn't supply a jobsubmissionid. The agent is >>free to use any format. Ok? > >No, This is not OK. We agreed the agent can use any scheme to derive the >jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known. >But, if the agent does not use a unique format ID, there is a high probability >that the sequential part of the ID's will intersect - something which I think >should be avoided. Sequential ID's are, by definition, fairly local constructs. >Keeping format 0 for the agent prevents the agent from "stepping on" the local >id's of a server, for example, because the server will always be using some >format ID other than 0. > >>When adding the jobOwner format, I assigned it to 0, rather than the >>end. It seems like a particularly useful and important format. > >Formats will "come and go". I don't this the enum given to the format has any >significance in terms of indicating it's "importance". > >>>There's a pretty big question in my mind exactly WHY we think JobOwner needs >>>to be part of a default format 0, especially since jmJobOwner is a mandatory >>>object in the Job Table. I only offer the following definition as a potential >>>compromise. I would prefer to keep format 0 as previously defined... basically >>>agent assigned. >> >>I agree that it would be a problem if the spec says that a job owner has >>to be part of the default format. That is why we got away from having >>a single default format, I thought. So now the agent is free to use any >>if the standard formats, not just the 0 format when the submitter doesn't >>submit an ID. > >Here, we do agree. Format 0 was never supposed to be a "fixed" format, just >an enum that assured this ID was assigned by the agent. I thought I picked >up in Nashua that folks wanted JobOwner to be the primary choice if the agent >had to assign an ID. We can establish preferred conventions via FAQ, if this >would be useful, but format 0 is intended to be "open" for the agent to make >intelligent choices based on what information is available (given the absence >of a "legitimate" jmJobSubmissioID). > >>Are you worrying that one client might not supply a job submission id >>for a particular job owner, but that same user from another client >>might. So that the second client might assign a sequence number that was >>the same as the agent assigned for the first one and thereby be a collision? >> >>That could happen with any of the formats, if the agent assigns >>the trailing number sometimes and the submitter does other times. >> >>Do we want to fix that? >> >>We could make separate format numbers for assigned by agent, versus >>assigned by the job submitter, for all the formats, thereby doubling >>the number of format numbers. > >This really CAN'T happen with any format if the agent sticks to format 0. >That's the point. There is not need to double the number of format numbers! > >Harry Lewis - IBM Printing Systems > > From rbergma at dpc.com Tue Jul 29 19:42:25 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 [Harry's and Tom's In-Reply-To: <9707292328.AA11713@zazen.cp10.es.xerox.com> Message-ID: <9707292328.AA11713@zazen.cp10.es.xerox.com> Tom, Looks good! Ron On Tue, 29 Jul 1997, Tom Hastings wrote: > Harry talked with his developers and we've come up with the following > resolution: > > Format 0 will be reserved to the agent to use when the client does not > supply a job submission id in the job submission protocol. In this > format the agent SHALL use the last 39 octets of the jmJobOwner value. > > We will add a new format 8 for the client's to use in a job submission ID > that includes the job owner's name. > > In the future, if agents need other formats for use when the client doesn't > supply a job submission ID, they can be proposed for registration. > > In the meantime, agents will use the job owner format (format 0) and > clients will use formats 1-8. > > The new text will be: > > JmJobSubmissionTypeTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Identifies the format type of a job submission ID. > > The ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 > possible formats. > > Each job submission ID is a fixed-length, 48-octet printable ASCII coded > character string, consisting of the following fields: > > octet 1 The format letter. > octets 2-40 A 39-character, ASCII trailing SPACE filled > field specified by the format letter, if the > data is less than 39 ASCII characters. > octets 41-48 A sequential or random number to make the ID > quasi-unique. > > If the client does not supply a job submission ID in the job submission > protocol, then the server SHALL assign a job submission ID using any of the > standard formats that are reserved to the agent. Clients SHALL not use > formats that are reserved to agents. > > The format values registered so far are: > > Format > Letter Description > ------ ------------ > '0' octets 2-40: last 39 bytes of the jmJobOwner > object. > octets 41-48: 8-decimal-digit sequential number > This format is reserved to agents for use when > the client does not supply a job submission ID. > Clients wishing to use a job submission ID that > incorporates the job owner, SHALL use format '8'. > > NOTE - other formats may be registered that are > reserved to the agent for use when the client does > not supply a job submission ID. > > '1' octets 2-40: last 39 bytes of the jobName attribute. > octets 41-48: 8-decimal-digit random number > > '2' octets 2-40: Client MAC address: in hexadecimal > with each nibble of the 6 octet address being > '0'-'9' or 'A' - 'F' (uppercase only). > Most significant octet first. > octets 41-48: 8-decimal-digit sequential number > > '3' octets 2-40: last 39 bytes of the client URL > [URI-spec]. > octets 41-48: 8-decimal-digit sequential number > > '4' octets 2-40: last 39 bytes of the URI [URI-spec] > assigned by the server or device to the job when > the job was submitted for processing. > octets 41-48: 8-decimal-digit sequential number > > '5' octets 2-40: last 39 bytes of a user number, such > as POSIX user number. > octets 41-48: 8-decimal-digit sequential number > > '6' octets 2-40: last 39 bytes of the user account > number. > octets 41-48: 8-decimal-digit sequential number > > '7' octets 2-40: last 39 bytes of the DTMF incoming > FAX routing number. > octets 41-48: 8-decimal-digit sequential number > > '8' octets 2-40: last 39 bytes of the job owner name > (that the agent returns in the jmJobOwner object). > octets 41-48: 8-decimal-digit sequential number > > NOTE - the job submission id is only intended to be unique between a limited > set of clients for a limited duration of time, namely, for the life time of > the job in the context of the server or device that is processing the job. > Some of the formats include something that is unique per client and a random > number so that the same job submitted by the same client will have a > different job submission id. For other formats, where part of the id is > guaranteed to be unique for each client, such as the MAC address or URL, a > sequential number SHOULD suffice for each client (and may be easier for each > client to manage). Therefore, the length of the job submission id has been > selected to reduce the probability of collision to an extremely low number, > but is not intended to be an absolute guarantee of uniqueness. > None-the-less, collisions are remotely possible, but without bad > consequences, since this MIB is intended to be used only for monitoring > jobs, not for controlling and managing them." > REFERENCE > "This is like a type 2 enumeration. See section 3.6.3." > SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z' > > > At 08:23 07/28/97 PDT, Harry Lewis wrote: > >Tom wrote: > > > >>I think we also agreed that the agent could use any of the standard > >>formats, if the job submitter didn't submit a jobsubmissionid, rather > >>than constraining the agent to a particular format. So I deleted > >>format 0. The 0 format is no longer the default format that the agent > >>uses if the submitter didn't supply a jobsubmissionid. The agent is > >>free to use any format. Ok? > > > >No, This is not OK. We agreed the agent can use any scheme to derive the > >jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known. > >But, if the agent does not use a unique format ID, there is a high probability > >that the sequential part of the ID's will intersect - something which I think > >should be avoided. Sequential ID's are, by definition, fairly local constructs. > >Keeping format 0 for the agent prevents the agent from "stepping on" the local > >id's of a server, for example, because the server will always be using some > >format ID other than 0. > > > >>When adding the jobOwner format, I assigned it to 0, rather than the > >>end. It seems like a particularly useful and important format. > > > >Formats will "come and go". I don't this the enum given to the format has any > >significance in terms of indicating it's "importance". > > > >>>There's a pretty big question in my mind exactly WHY we think JobOwner needs > >>>to be part of a default format 0, especially since jmJobOwner is a mandatory > >>>object in the Job Table. I only offer the following definition as a potential > >>>compromise. I would prefer to keep format 0 as previously defined... > basically > >>>agent assigned. > >> > >>I agree that it would be a problem if the spec says that a job owner has > >>to be part of the default format. That is why we got away from having > >>a single default format, I thought. So now the agent is free to use any > >>if the standard formats, not just the 0 format when the submitter doesn't > >>submit an ID. > > > >Here, we do agree. Format 0 was never supposed to be a "fixed" format, just > >an enum that assured this ID was assigned by the agent. I thought I picked > >up in Nashua that folks wanted JobOwner to be the primary choice if the agent > >had to assign an ID. We can establish preferred conventions via FAQ, if this > >would be useful, but format 0 is intended to be "open" for the agent to make > >intelligent choices based on what information is available (given the absence > >of a "legitimate" jmJobSubmissioID). > > > >>Are you worrying that one client might not supply a job submission id > >>for a particular job owner, but that same user from another client > >>might. So that the second client might assign a sequence number that was > >>the same as the agent assigned for the first one and thereby be a collision? > >> > >>That could happen with any of the formats, if the agent assigns > >>the trailing number sometimes and the submitter does other times. > >> > >>Do we want to fix that? > >> > >>We could make separate format numbers for assigned by agent, versus > >>assigned by the job submitter, for all the formats, thereby doubling > >>the number of format numbers. > > > >This really CAN'T happen with any format if the agent sticks to format 0. > >That's the point. There is not need to double the number of format numbers! > > > >Harry Lewis - IBM Printing Systems > > > > > > From hastings at cp10.es.xerox.com Tue Jul 29 20:01:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> PRO - Change to the JmPrinterResolutionTC Message-ID: <9707300004.AA11741@zazen.cp10.es.xerox.com> In order to align JMP with IPP, I'm changing the JmPrinterResolutionTC to the following: JmPrinterResolutionTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Printer resolutions. Nine octets consisting of two 4-octet SIGNED-INTEGERs followed by a SIGNED-BYTE. The values are the same as those specified in the Printer MIB [printmib]. The first SIGNED-INTEGER contains the value of prtMarkerAddressabilityXFeedDir. The second SIGNED-INTEGER contains the value of prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the value of prtMarkerAddressabilityUnit. Note: the latter value is either 3 (tenThousandsOfInches) or 4 (micrometers) and the addressability is in 10,000 units of measure. Thus the SIGNED-INTEGERS represent integral values in either dots-per-inch or dots-per-centimeter. The syntax is the same as the IPP 'printer-resolution' attribute. See Section 3.6.1.2." SYNTAX OCTET STRING (SIZE(9)) and changing the two attribute affected to use OCTETS: printerResolutionRequested(72), JmPrinterResolutionTC OCTETS: MULTI-ROW: The printer resolution requested for a document in the job for printers that support resolution selection. printerResolutionUsed(73), JmPrinterResolutionTC OCTETS: MULTI-ROW: The printer resolution actually used by a document in the job for printers that support resolution selection. From jkm at underscore.com Wed Jul 30 12:25:15 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 [Harry's and Tom's In-Reply-To: JobSubmission ID Format 0 [Harry's and Tom's> Message-ID: <199707301625.MAA03531@uscore.underscore.com> Why did you decide to use the LAST 39 octets of the jmJobOwner value, rather than the FIRST 39 octets? ...jay ----- Begin Included Message ----- Date: Tue, 29 Jul 1997 16:25:50 PDT To: Harry Lewis From: Tom Hastings Subject: Re: JMP> JobSubmission ID Format 0 [Harry's and Tom's resolution] Cc: Harry talked with his developers and we've come up with the following resolution: Format 0 will be reserved to the agent to use when the client does not supply a job submission id in the job submission protocol. In this format the agent SHALL use the last 39 octets of the jmJobOwner value. We will add a new format 8 for the client's to use in a job submission ID that includes the job owner's name. In the future, if agents need other formats for use when the client doesn't supply a job submission ID, they can be proposed for registration. In the meantime, agents will use the job owner format (format 0) and clients will use formats 1-8. The new text will be: JmJobSubmissionTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the format type of a job submission ID. The ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 possible formats. Each job submission ID is a fixed-length, 48-octet printable ASCII coded character string, consisting of the following fields: octet 1 The format letter. octets 2-40 A 39-character, ASCII trailing SPACE filled field specified by the format letter, if the data is less than 39 ASCII characters. octets 41-48 A sequential or random number to make the ID quasi-unique. If the client does not supply a job submission ID in the job submission protocol, then the server SHALL assign a job submission ID using any of the standard formats that are reserved to the agent. Clients SHALL not use formats that are reserved to agents. The format values registered so far are: Format Letter Description ------ ------------ '0' octets 2-40: last 39 bytes of the jmJobOwner object. octets 41-48: 8-decimal-digit sequential number This format is reserved to agents for use when the client does not supply a job submission ID. Clients wishing to use a job submission ID that incorporates the job owner, SHALL use format '8'. NOTE - other formats may be registered that are reserved to the agent for use when the client does not supply a job submission ID. '1' octets 2-40: last 39 bytes of the jobName attribute. octets 41-48: 8-decimal-digit random number '2' octets 2-40: Client MAC address: in hexadecimal with each nibble of the 6 octet address being '0'-'9' or 'A' - 'F' (uppercase only). Most significant octet first. octets 41-48: 8-decimal-digit sequential number '3' octets 2-40: last 39 bytes of the client URL [URI-spec]. octets 41-48: 8-decimal-digit sequential number '4' octets 2-40: last 39 bytes of the URI [URI-spec] assigned by the server or device to the job when the job was submitted for processing. octets 41-48: 8-decimal-digit sequential number '5' octets 2-40: last 39 bytes of a user number, such as POSIX user number. octets 41-48: 8-decimal-digit sequential number '6' octets 2-40: last 39 bytes of the user account number. octets 41-48: 8-decimal-digit sequential number '7' octets 2-40: last 39 bytes of the DTMF incoming FAX routing number. octets 41-48: 8-decimal-digit sequential number '8' octets 2-40: last 39 bytes of the job owner name (that the agent returns in the jmJobOwner object). octets 41-48: 8-decimal-digit sequential number NOTE - the job submission id is only intended to be unique between a limited set of clients for a limited duration of time, namely, for the life time of the job in the context of the server or device that is processing the job. Some of the formats include something that is unique per client and a random number so that the same job submitted by the same client will have a different job submission id. For other formats, where part of the id is guaranteed to be unique for each client, such as the MAC address or URL, a sequential number SHOULD suffice for each client (and may be easier for each client to manage). Therefore, the length of the job submission id has been selected to reduce the probability of collision to an extremely low number, but is not intended to be an absolute guarantee of uniqueness. None-the-less, collisions are remotely possible, but without bad consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them." REFERENCE "This is like a type 2 enumeration. See section 3.6.3." SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z' At 08:23 07/28/97 PDT, Harry Lewis wrote: >Tom wrote: > >>I think we also agreed that the agent could use any of the standard >>formats, if the job submitter didn't submit a jobsubmissionid, rather >>than constraining the agent to a particular format. So I deleted >>format 0. The 0 format is no longer the default format that the agent >>uses if the submitter didn't supply a jobsubmissionid. The agent is >>free to use any format. Ok? > >No, This is not OK. We agreed the agent can use any scheme to derive the >jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known. >But, if the agent does not use a unique format ID, there is a high probability >that the sequential part of the ID's will intersect - something which I think >should be avoided. Sequential ID's are, by definition, fairly local constructs. >Keeping format 0 for the agent prevents the agent from "stepping on" the local >id's of a server, for example, because the server will always be using some >format ID other than 0. > >>When adding the jobOwner format, I assigned it to 0, rather than the >>end. It seems like a particularly useful and important format. > >Formats will "come and go". I don't this the enum given to the format has any >significance in terms of indicating it's "importance". > >>>There's a pretty big question in my mind exactly WHY we think JobOwner needs >>>to be part of a default format 0, especially since jmJobOwner is a mandatory >>>object in the Job Table. I only offer the following definition as a potential >>>compromise. I would prefer to keep format 0 as previously defined... basically >>>agent assigned. >> >>I agree that it would be a problem if the spec says that a job owner has >>to be part of the default format. That is why we got away from having >>a single default format, I thought. So now the agent is free to use any >>if the standard formats, not just the 0 format when the submitter doesn't >>submit an ID. > >Here, we do agree. Format 0 was never supposed to be a "fixed" format, just >an enum that assured this ID was assigned by the agent. I thought I picked >up in Nashua that folks wanted JobOwner to be the primary choice if the agent >had to assign an ID. We can establish preferred conventions via FAQ, if this >would be useful, but format 0 is intended to be "open" for the agent to make >intelligent choices based on what information is available (given the absence >of a "legitimate" jmJobSubmissioID). > >>Are you worrying that one client might not supply a job submission id >>for a particular job owner, but that same user from another client >>might. So that the second client might assign a sequence number that was >>the same as the agent assigned for the first one and thereby be a collision? >> >>That could happen with any of the formats, if the agent assigns >>the trailing number sometimes and the submitter does other times. >> >>Do we want to fix that? >> >>We could make separate format numbers for assigned by agent, versus >>assigned by the job submitter, for all the formats, thereby doubling >>the number of format numbers. > >This really CAN'T happen with any format if the agent sticks to format 0. >That's the point. There is not need to double the number of format numbers! > >Harry Lewis - IBM Printing Systems > > ----- End Included Message ----- From hastings at cp10.es.xerox.com Wed Jul 30 12:41:20 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 [Harry's and Tom's In-Reply-To: JobSubmission ID Format 0 [Harry's and Tom's> Message-ID: <9707301643.AA11944@zazen.cp10.es.xerox.com> At 09:25 07/30/97 PDT, JK Martin wrote: >Why did you decide to use the LAST 39 octets of the jmJobOwner value, >rather than the FIRST 39 octets? All the other ones were that way. The end is more likely to be unique than the beginning. Also now that we have 39 characters, the chances that some truncation is going to happen is even less. The idea is to try to pick the end that will increase the chances of uniqueness. So for user names that have first and last, the last name is more likely to be unique than the first names. But do you have other experience that shows we should change jobOwner to the first 39 characters? Do we need to make this an ISSUE? Tom > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Tue Jul 29 19:29 EDT 1997 >Date: Tue, 29 Jul 1997 16:25:50 PDT >To: Harry Lewis >From: Tom Hastings >Subject: Re: JMP> JobSubmission ID Format 0 [Harry's and Tom's > resolution] >Cc: > >Harry talked with his developers and we've come up with the following >resolution: > >Format 0 will be reserved to the agent to use when the client does not >supply a job submission id in the job submission protocol. In this >format the agent SHALL use the last 39 octets of the jmJobOwner value. > >We will add a new format 8 for the client's to use in a job submission ID >that includes the job owner's name. > >In the future, if agents need other formats for use when the client doesn't >supply a job submission ID, they can be proposed for registration. > >In the meantime, agents will use the job owner format (format 0) and >clients will use formats 1-8. > >The new text will be: > >JmJobSubmissionTypeTC ::= TEXTUAL-CONVENTION >STATUS current >DESCRIPTION >"Identifies the format type of a job submission ID. > >The ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 >possible formats. > >Each job submission ID is a fixed-length, 48-octet printable ASCII coded >character string, consisting of the following fields: > > octet 1 The format letter. > octets 2-40 A 39-character, ASCII trailing SPACE filled > field specified by the format letter, if the > data is less than 39 ASCII characters. > octets 41-48 A sequential or random number to make the ID > quasi-unique. > >If the client does not supply a job submission ID in the job submission >protocol, then the server SHALL assign a job submission ID using any of the >standard formats that are reserved to the agent. Clients SHALL not use >formats that are reserved to agents. > >The format values registered so far are: > > Format > Letter Description > ------ ------------ > '0' octets 2-40: last 39 bytes of the jmJobOwner > object. > octets 41-48: 8-decimal-digit sequential number > This format is reserved to agents for use when > the client does not supply a job submission ID. > Clients wishing to use a job submission ID that > incorporates the job owner, SHALL use format '8'. > > NOTE - other formats may be registered that are > reserved to the agent for use when the client does > not supply a job submission ID. > > '1' octets 2-40: last 39 bytes of the jobName attribute. > octets 41-48: 8-decimal-digit random number > > '2' octets 2-40: Client MAC address: in hexadecimal > with each nibble of the 6 octet address being > '0'-'9' or 'A' - 'F' (uppercase only). > Most significant octet first. > octets 41-48: 8-decimal-digit sequential number > > '3' octets 2-40: last 39 bytes of the client URL > [URI-spec]. > octets 41-48: 8-decimal-digit sequential number > > '4' octets 2-40: last 39 bytes of the URI [URI-spec] > assigned by the server or device to the job when > the job was submitted for processing. > octets 41-48: 8-decimal-digit sequential number > > '5' octets 2-40: last 39 bytes of a user number, such > as POSIX user number. > octets 41-48: 8-decimal-digit sequential number > > '6' octets 2-40: last 39 bytes of the user account > number. > octets 41-48: 8-decimal-digit sequential number > > '7' octets 2-40: last 39 bytes of the DTMF incoming > FAX routing number. > octets 41-48: 8-decimal-digit sequential number > > '8' octets 2-40: last 39 bytes of the job owner name > (that the agent returns in the jmJobOwner object). > octets 41-48: 8-decimal-digit sequential number > >NOTE - the job submission id is only intended to be unique between a limited >set of clients for a limited duration of time, namely, for the life time of >the job in the context of the server or device that is processing the job. >Some of the formats include something that is unique per client and a random >number so that the same job submitted by the same client will have a >different job submission id. For other formats, where part of the id is >guaranteed to be unique for each client, such as the MAC address or URL, a >sequential number SHOULD suffice for each client (and may be easier for each >client to manage). Therefore, the length of the job submission id has been >selected to reduce the probability of collision to an extremely low number, >but is not intended to be an absolute guarantee of uniqueness. >None-the-less, collisions are remotely possible, but without bad >consequences, since this MIB is intended to be used only for monitoring >jobs, not for controlling and managing them." >REFERENCE >"This is like a type 2 enumeration. See section 3.6.3." >SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z' > > >At 08:23 07/28/97 PDT, Harry Lewis wrote: >>Tom wrote: >> >>>I think we also agreed that the agent could use any of the standard >>>formats, if the job submitter didn't submit a jobsubmissionid, rather >>>than constraining the agent to a particular format. So I deleted >>>format 0. The 0 format is no longer the default format that the agent >>>uses if the submitter didn't supply a jobsubmissionid. The agent is >>>free to use any format. Ok? >> >>No, This is not OK. We agreed the agent can use any scheme to derive the >>jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known. >>But, if the agent does not use a unique format ID, there is a high probability >>that the sequential part of the ID's will intersect - something which I think >>should be avoided. Sequential ID's are, by definition, fairly local constructs. >>Keeping format 0 for the agent prevents the agent from "stepping on" the local >>id's of a server, for example, because the server will always be using some >>format ID other than 0. >> >>>When adding the jobOwner format, I assigned it to 0, rather than the >>>end. It seems like a particularly useful and important format. >> >>Formats will "come and go". I don't this the enum given to the format has any >>significance in terms of indicating it's "importance". >> >>>>There's a pretty big question in my mind exactly WHY we think JobOwner needs >>>>to be part of a default format 0, especially since jmJobOwner is a mandatory >>>>object in the Job Table. I only offer the following definition as a potential >>>>compromise. I would prefer to keep format 0 as previously defined... >basically >>>>agent assigned. >>> >>>I agree that it would be a problem if the spec says that a job owner has >>>to be part of the default format. That is why we got away from having >>>a single default format, I thought. So now the agent is free to use any >>>if the standard formats, not just the 0 format when the submitter doesn't >>>submit an ID. >> >>Here, we do agree. Format 0 was never supposed to be a "fixed" format, just >>an enum that assured this ID was assigned by the agent. I thought I picked >>up in Nashua that folks wanted JobOwner to be the primary choice if the agent >>had to assign an ID. We can establish preferred conventions via FAQ, if this >>would be useful, but format 0 is intended to be "open" for the agent to make >>intelligent choices based on what information is available (given the absence >>of a "legitimate" jmJobSubmissioID). >> >>>Are you worrying that one client might not supply a job submission id >>>for a particular job owner, but that same user from another client >>>might. So that the second client might assign a sequence number that was >>>the same as the agent assigned for the first one and thereby be a collision? >>> >>>That could happen with any of the formats, if the agent assigns >>>the trailing number sometimes and the submitter does other times. >>> >>>Do we want to fix that? >>> >>>We could make separate format numbers for assigned by agent, versus >>>assigned by the job submitter, for all the formats, thereby doubling >>>the number of format numbers. >> >>This really CAN'T happen with any format if the agent sticks to format 0. >>That's the point. There is not need to double the number of format numbers! >> >>Harry Lewis - IBM Printing Systems >> >> > > > >----- End Included Message ----- > > > From jkm at underscore.com Wed Jul 30 13:10:03 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:08 2009 Subject: JMP> JobSubmission ID Format 0 [Harry's and Tom's In-Reply-To: JobSubmission ID Format 0 [Harry's and Tom's> Message-ID: <199707301710.NAA03623@uscore.underscore.com> Nope, no issue on this one. I was just curious. ...jay ----- Begin Included Message ----- Date: Wed, 30 Jul 1997 09:41:20 PDT To: JK Martin From: Tom Hastings Subject: Re: JMP> JobSubmission ID Format 0 [Harry's and Tom's resolution] Cc: jmp@pwg.org At 09:25 07/30/97 PDT, JK Martin wrote: >Why did you decide to use the LAST 39 octets of the jmJobOwner value, >rather than the FIRST 39 octets? All the other ones were that way. The end is more likely to be unique than the beginning. Also now that we have 39 characters, the chances that some truncation is going to happen is even less. The idea is to try to pick the end that will increase the chances of uniqueness. So for user names that have first and last, the last name is more likely to be unique than the first names. But do you have other experience that shows we should change jobOwner to the first 39 characters? Do we need to make this an ISSUE? Tom ----- End Included Message ----- From harryl at us.ibm.com Wed Jul 30 15:03:25 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> Potential Finisher MIB Project Message-ID: <5030100005538722000002L022*@MHS> Thanks Don, for making room on the Seattle agenda to discuss the possibility of forming a Finisher working group. I look forward to leading this discussion on Friday morning and I feel 2 hrs (or less) is appropriate at this stage. To date, I have seen PWG e-mail from 8 individuals (aligned with 8 separate companies) interested in creating a Finisher standard and there are some 23 people from 15 different companies subscribed to the FIN e-mail reflector (fin@pwg.org). With this level of interest, I anticipate some very interesting points of view. It is my hope that we can rapidly formulate our goals, define our scope and develop the architecture to either augment the Printer MIB or create a stand-alone Finisher MIB for use in managing this aspect of the device and the print job. I invite anyone with Finisher experience or interest in print finishing to join us at the meeting or register with the FIN e-mail reflector. Harry Lewis - IBM Printing Systems -------- Forwarded by Harry Lewis/Boulder/IBM on 07/29/97 01:46 PM -------- jmp-owner@pwg.org 07/29/97 01:25 PM Please respond to jmp-owner@pwg.org @ internet To: fin@pwg.org @ internet, jmp@pwg.org @ internet, pmp@pwg.org @ internet, pwg@pwg.org @ internet cc: Subject: JMP> Potential Finisher MIB Project At the request of several interested individuals, I have adjusted the Friday agenda of the August meeting at Microsoft. We have had some discussion of a Finisher MIB on the mailing list and a FIN mailing list has been established. Harry Lewis has agreed to moderate a discussion on Friday morning to gauge interest in kicking off a Finisher MIB project. As such, the Friday agenda is as follows: 8:30 AM - 10:30 AM Finisher MIB discussion 11:00 AM - 5:00 PM JOB MIB If the entire 2 hours is not necessary to gauge interest and if needed identify leadership, the JMP work will start early. Unfortunately due to business commitments, I will not be in attendance on Friday but I am sure the discussion will be excellent under the capable leadership of Mr. Lewis. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Wed Jul 30 19:29:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Version 0.84 posted and sent as an I-D Message-ID: <9707302332.AA12281@zazen.cp10.es.xerox.com> I've posted the usual files for version V0.84 which corresponds to Internet-Draft: draft-ietf-printmib-job-monitor-04.txt: ftp::/ftp.pwg.org/pub/pwg/jmp/mibs -rw-r--r-- 1 pwg pwg 112534 Jul 30 23:23 jmp-mib.mib -rw-r--r-- 1 pwg pwg 265352 Jul 30 23:24 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 197684 Jul 30 23:24 jmp-mib.txt -rw-r--r-- 1 pwg pwg 337920 Jul 30 23:25 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 294852 Jul 30 23:25 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 299583 Jul 30 23:25 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 8054 Jul 30 23:26 jmp.dic The jmp-mib.pdf is without revision marks and has line numbers. This is the version that JMP should make any comments against. The jmp-mib.txt == draft-ietf-printmib-job-monitor-02.txt The jmp-mibr.doc is with revision marks. The jmp-mibr.pdr is with red revision marks. The jmp-mibr.pdf is with black revision marks. The jmp-mib.mib file compiles with one warning (assignment of the temporary OID). I've also posted a copy of the plain text in the internet drafts (and sent it in to the IETF for publication) ftp::/ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 189247 Apr 29 01:00 draft-ietf-printmib-job-monitor-00.txt -rw-r--r-- 1 pwg pwg 190215 Jun 11 08:33 draft-ietf-printmib-job-monitor-01.txt -rw-r--r-- 1 pwg pwg 197357 Jul 18 14:09 draft-ietf-printmib-job-monitor-02.txt -rw-r--r-- 1 pwg pwg 197684 Jul 30 22:51 draft-ietf-printmib-job-monitor-04.txt From hastings at cp10.es.xerox.com Wed Jul 30 19:54:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Changes to make V0.84 from V0.83 Message-ID: <9707302357.AA12290@zazen.cp10.es.xerox.com> V0.83 has many editorial changes from Ron and David Perkins and a few substantive changes, such as moving jobOwner from the attribute table to the job table from the agreements at the Nashua meeting. V0.84 has Ron's recent 5 sets of editorial changes, a change to printer-resolution to agree with IPP, so the syntax changes from an enum to 9 binary octets: 4 cross-feed, 4 feed, and one enum, inches or cm which means that the attribute changes from Integer32 to Octets. Also the clarification of job format id 0 is job owner for the agent and adding format 8 which is job owner for the client. There are 4 remaining issues: 2 from David Perkins about char sets, 1 Ron's comments about getting rid of other(1) for jmJobState, and one from Harry and Bob about nested jobs. We've closed the split the job attribute table suggestion from David Perkins and said we are NOT splitting the table. Tom >Return-Path: >X-Sender: hastings@zazen (Unverified) >Date: Wed, 30 Jul 1997 16:29:29 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> Version 0.84 posted and sent as an I-D >Sender: jmp-owner@pwg.org > >I've posted the usual files for version V0.84 which corresponds to >Internet-Draft: draft-ietf-printmib-job-monitor-04.txt: > >ftp::/ftp.pwg.org/pub/pwg/jmp/mibs >-rw-r--r-- 1 pwg pwg 112534 Jul 30 23:23 jmp-mib.mib >-rw-r--r-- 1 pwg pwg 265352 Jul 30 23:24 jmp-mib.pdf >-rw-r--r-- 1 pwg pwg 197684 Jul 30 23:24 jmp-mib.txt >-rw-r--r-- 1 pwg pwg 337920 Jul 30 23:25 jmp-mibr.doc >-rw-r--r-- 1 pwg pwg 294852 Jul 30 23:25 jmp-mibr.pdf >-rw-r--r-- 1 pwg pwg 299583 Jul 30 23:25 jmp-mibr.pdr >-rw-r--r-- 1 pwg pwg 8054 Jul 30 23:26 jmp.dic > >The jmp-mib.pdf is without revision marks and has line numbers. This >is the version that JMP should make any comments against. > >The jmp-mib.txt == draft-ietf-printmib-job-monitor-02.txt >The jmp-mibr.doc is with revision marks. >The jmp-mibr.pdr is with red revision marks. >The jmp-mibr.pdf is with black revision marks. >The jmp-mib.mib file compiles with one warning (assignment of the >temporary OID). > >I've also posted a copy of the plain text in the internet drafts >(and sent it in to the IETF for publication) > >ftp::/ftp.pwg.org/pub/pwg/jmp/internet-drafts/ >-rw-r--r-- 1 pwg pwg 189247 Apr 29 01:00 draft-ietf-printmib-job-monitor-00.txt >-rw-r--r-- 1 pwg pwg 190215 Jun 11 08:33 draft-ietf-printmib-job-monitor-01.txt >-rw-r--r-- 1 pwg pwg 197357 Jul 18 14:09 draft-ietf-printmib-job-monitor-02.txt >-rw-r--r-- 1 pwg pwg 197684 Jul 30 22:51 draft-ietf-printmib-job-monitor-04.txt > > > From rbergma at dpc.com Thu Jul 31 12:43:28 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Scheule for Redmond Meeting Message-ID: <9707302357.AA12290@zazen.cp10.es.xerox.com> Proposed agenda for the JMP Meeting - August 8, 1997 1. Review of Schedule and plans. 2. Discussion and closure of all open issues. I have assigned each open issue to the person who initially presented the issue. I am requesting the assigned person to present a justification for the change to start the discussion. I would like to close all issues in this meeting. - Replacing jmJobIDSetIndex with jmGeneralJobSetIndex: Assigned to Ron Bergman - Nested Attributes: Assigned to Harry Lewis / Bob Pentecost - Character set identification objects / Localization: Assigned to Tom Hastings (originated from David Perkins) 3. Mapping RFC Discussion This topic should occupy the majority of the meeting time. I would like to request that all participants think about what submission protocols we need to map. And if you have time, review the mapping documentation previously generated. Any work performed prior to the meeting will help this effort. - Format - Protocols - Assignments - Schedule 4. Top 25 list - Scope - Plan - Assignments ------------------------------------------------------------------ See y'all next week. Ron Bergman From rbergma at dpc.com Thu Jul 31 21:19:39 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> jmJobIdJobSetIndex Replacement Proposal Message-ID: <9707302357.AA12290@zazen.cp10.es.xerox.com> After further analysis of my proposal to replace jmJobIdJobSetIndex with jmGeneralJobSetIndex, I withdraw the proposal. The current configuration is much better since my proposal would require the manager to know the job set index to find his job. Ron Bergman Dataproducts Corp. From don at lexmark.com Fri Aug 1 07:18:22 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> October Meeting in Denver Message-ID: <199708011118.AA01752@interlock2.lexmark.com> I have had a request that we move the Denver meeting out one week to Novemebr 3-7 to avoid a conflict with a major UNIX show. Please respond to this note only if you have a problem with moving the meeting. Additionally, as a part of reviewing the proposed dates and locations for the 1998 meeting, please compare my proposal against major shows and other events that could be a problem. Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From lstein at fapo.com Fri Aug 1 10:13:17 1997 From: lstein at fapo.com (Larry Stein) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: P1394> October Meeting in Denver In-Reply-To: October Meeting in Denver> Message-ID: <3.0.32.19970801070650.00738f90@pop3.fapo.com> That week is bad for me. We're doing a 2 day 1284 class in Amsterdam that week. Thanks, Larry At 07:18 AM 8/1/97 -0400, don@lexmark.com wrote: > >I have had a request that we move the Denver meeting out one week >to Novemebr 3-7 to avoid a conflict with a major UNIX show. Please >respond to this note only if you have a problem with moving the >meeting. > >Additionally, as a part of reviewing the proposed dates and locations >for the 1998 meeting, please compare my proposal against major >shows and other events that could be a problem. > >Thanks! > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Manager, Strategic Alliances and Standards * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > ***************************************************************************** Larry A. Stein Phone: (619)292-2740 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************************** From szilles at Adobe.COM Fri Aug 1 12:07:43 1997 From: szilles at Adobe.COM (Steve Zilles) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: PWG> October Meeting in Denver In-Reply-To: October Meeting in Denver> Message-ID: <199708011607.JAA29614@bulletin> I have a major problem because I will be on vacation that week. Steve Z From don at lexmark.com Mon Aug 4 13:56:49 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> October Meeting in Denver Message-ID: <199708041821.AA18609@interlock2.lexmark.com> --0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny Content-type: text/plain; charset=us-ascii OK, I had 2 no's on moving the meeting out a week. What about moving it in one week to October 20-24? Only those that can make those dates should reply. Remember 1394 Printing on Monday/Tuesday, IPP on Wednesday/Thursday and JMP, SENSE, etc. on Friday. Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 08/04/97 01:54 PM --------------------------- Don Wright Note sent on 08/01/97 07:18 AM (Embedded image moved to file: PIC31204.PCX) Manager, Strategic Alliances and Standards Lexmark International 606-232-4808 606-232-6740 (fax) don@lexmark.com To: pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org cc: Subject: October Meeting in Denver I have had a request that we move the Denver meeting out one week to Novemebr 3-7 to avoid a conflict with a major UNIX show. Please respond to this note only if you have a problem with moving the meeting. Additionally, as a part of reviewing the proposed dates and locations for the 1998 meeting, please compare my proposal against major shows and other events that could be a problem. Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** --0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny Content-type: application/octet-stream; name="PIC31204.PCX" Content-transfer-encoding: base64 CgUBCAAAAADCAQ8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABwwEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAP/wf/B/8H/wf/B/8H5QfSB8QHxw/ED8IPD/8L/QsPwwsPwwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsP Cw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwv/D+EP0Q/ID8QPwg8PD+ULD8cLD8MLD8MLD8ML D8MLD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPC8MPC8MPC8MPC8cPC9cPzA/G D8MPDw//C/8L2AsPxwsPwwsPwwsPwwsPwwsPwwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwvDDwvDDwvDDwvDDwvHDwv/D+4P1w/MD8YPww8PD8cLD8cLD8cLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPwwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MP C8MPC8MPC8cPC8cPC8gPxA/CDw8P/wv5Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/D Cw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwvDDwsPCw8L ww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cP C8cPC8cPC/sP3Q/PD8cPxA/CDw/hCw/HCw/HCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP C8MPCw8LDwvDDwsPCw8Lww8Lww8Lxw8Lxw8L1Q/LD8UPww8PD/8L/wvUCw/HCw/HCw/DCw/DCw/D Cw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvHDwvHDwv/D+wP 1g/LD8YPww8PD8sLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPC8MPC8MP C8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cPC8YPww/C Dw//C/0LD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8Lww8Lww8Lww8L ww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8L/w/hD9EPyA/E D8IPDw/lCw/HCw/DCw/DCw/DCw/DCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvD DwvDDwvDDwvDDwvHDwvXD8wPxg/DDw8P/wv/C9gLD8cLD8MLD8MLD8MLD8MLD8MLDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8Lww8Lww8Lww8Lww8Lxw8L/w/uD9cPzA/GD8MPDw/H Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8L DwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvID8QPwg8PD/8L+QsPxwsPxwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8L DwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvHDwv7D90Pzw/HD8QPwg8P4QsPxwsPxwsPwwsPwwsPwwsP Cw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8cPC8cPC9UPyw/FD8MPDw// C/8L1AsPxwsPxwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwsPCw8L ww8Lww8Lww8Lxw8Lxw8L/w/sD9YPyw/GD8MPDwwAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/ AAAA/wD//wAAAP//AP8A//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny-- From don at lexmark.com Mon Aug 4 14:55:31 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: PWG> October Meeting in Denver In-Reply-To: October Meeting in Denver> Message-ID: <199708041907.AA20512@interlock2.lexmark.com> --0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5 Content-type: text/plain; charset=us-ascii Opps -- only those who CAN NOT make October 20-24 should reply. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Don_Wright.LEXMARK@lexmta01.notes.lexmark.com 08/04/97 01:56 PM To: pwg%pwg.org@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com, p1394%pwg.org@interlock.lexmark.com, jmp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) Subject: PWG> October Meeting in Denver OK, I had 2 no's on moving the meeting out a week. What about moving it in one week to October 20-24? Only those that can make those dates should reply. Remember 1394 Printing on Monday/Tuesday, IPP on Wednesday/Thursday and JMP, SENSE, etc. on Friday. Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 08/04/97 01:54 PM --------------------------- Don Wright Note sent on 08/01/97 07:18 AM (Embedded image moved to file: PIC31204.PCX) Manager, Strategic Alliances and Standards Lexmark International 606-232-4808 606-232-6740 (fax) don@lexmark.com To: pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org cc: Subject: October Meeting in Denver I have had a request that we move the Denver meeting out one week to Novemebr 3-7 to avoid a conflict with a major UNIX show. Please respond to this note only if you have a problem with moving the meeting. Additionally, as a part of reviewing the proposed dates and locations for the 1998 meeting, please compare my proposal against major shows and other events that could be a problem. Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** --0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5 Content-type: application/octet-stream; name="PIC31204.PCX" Content-transfer-encoding: base64 CgUBCAAAAADCAQ8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABwwEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAP/wf/B/8H/wf/B/8H5QfSB8QHxw/ED8IPD/8L/QsPwwsPwwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsP Cw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwv/D+EP0Q/ID8QPwg8PD+ULD8cLD8MLD8MLD8ML D8MLD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPC8MPC8MPC8MPC8cPC9cPzA/G D8MPDw//C/8L2AsPxwsPwwsPwwsPwwsPwwsPwwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwvDDwvDDwvDDwvDDwvHDwv/D+4P1w/MD8YPww8PD8cLD8cLD8cLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPwwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MP C8MPC8MPC8cPC8cPC8gPxA/CDw8P/wv5Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/D Cw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwvDDwsPCw8L ww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cP C8cPC8cPC/sP3Q/PD8cPxA/CDw/hCw/HCw/HCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP C8MPCw8LDwvDDwsPCw8Lww8Lww8Lxw8Lxw8L1Q/LD8UPww8PD/8L/wvUCw/HCw/HCw/DCw/DCw/D Cw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvHDwvHDwv/D+wP 1g/LD8YPww8PD8sLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPC8MPC8MP C8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cPC8YPww/C Dw//C/0LD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8Lww8Lww8Lww8L ww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8L/w/hD9EPyA/E D8IPDw/lCw/HCw/DCw/DCw/DCw/DCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvD DwvDDwvDDwvDDwvHDwvXD8wPxg/DDw8P/wv/C9gLD8cLD8MLD8MLD8MLD8MLD8MLDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8Lww8Lww8Lww8Lww8Lxw8L/w/uD9cPzA/GD8MPDw/H Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8L DwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvID8QPwg8PD/8L+QsPxwsPxwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8L DwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvHDwv7D90Pzw/HD8QPwg8P4QsPxwsPxwsPwwsPwwsPwwsP Cw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8cPC8cPC9UPyw/FD8MPDw// C/8L1AsPxwsPxwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwsPCw8L ww8Lww8Lww8Lxw8Lxw8L/w/sD9YPyw/GD8MPDwwAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/ AAAA/wD//wAAAP//AP8A//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5-- From hastings at cp10.es.xerox.com Mon Aug 4 21:16:16 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Thursday evening: Discussion/tutorial on char sets and Message-ID: <9708050118.AA13368@zazen.cp10.es.xerox.com> I'd be glad to bring copies of relevant RFCs on character sets and localization for a discussion/tutorial/workshop Thursday night of the PWG meeting this week for those interested. Some of the JMP folks have indicated an interest for Friday's discussion. And it will speed up the discussion of the character set issues on Friday for the Job Monitoring MIB. Is there an interest? Is there time on the agenda Thursday evening? Questions explored: What is localization? What is a coded character set? What is the relationship between localization and coded character sets? What is the IANA registry? How do you tell if two characters are the same? How do you tell if two character sets are the same? How are languages indicated? Should localization be done in a client or a server? How are coded character sets represented in protocols, such as SNMP, IPP, DPA, etc. Relevant RFCs for study [I can bring copies of these]: RFC 854 J. Postel, J. Reyolds, "Telnet Protocol Specification, ISI, May 1983. RFC 1345 K. Simonsen, "Character Mnemonics & Character Sets", Rationel Alman Planlaegning, June 1992. RFC 1642 Goldsmith, D., and M. Davis, "UTF-7", RFC1642, Taligent, Inc., July 1994. RFC 1700 J. Reynolds, and J. Postel, "Assigned Numbers", STD 2, RFC 1700, ISI, October 1994. RFC 1903 J. Case, et al. "Textual Conventions for Version 2 of the Simple Network Managment Protocol (SNMPv2)", RFC 1903, January 1996. SMIv2-TC RFC 2044 F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. RFC 2130 C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 Feb-1 March, 1997", April 1997, RFC 2130. The IANA Character Set Registry itself Related ISO and national coded character set standards (I no longer have copies of these): [GB2312] GB 2312-1980, "Chinese People's Republic oF China (PRC) mixed one byte and two byte coded character set" [ISO 646] ISO/IEC 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", JTC1/SC2. [ISO 8859] ISO/IEC 8859-1:1987, "Information technology -- 8-bit single byte coded graphic character sets - Part 1: Latin alplhabet No. 1, JTC1/SC2." [ISO 2022] ISO/IEC 2022:1994 - "Information technology -- Character code structure and extension techniques", JTC1/SC2. [ISO 10646] ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2. [JIS X0208] JIS X0208-1990, "Japanese two byte coded character set." [US-ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. From don at lexmark.com Tue Aug 5 14:27:53 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> October Meeting Message-ID: <199708051832.AA29656@interlock2.lexmark.com> Well, I'm stuck between a rock and a hard place. I have three who cannot make it the week of Nov 3rd, two that can't make it the announced week of October 27th and two that can't make it the week of October 20th. Unless someone has a solution to this problem, I can't see any justification to move the meeting. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Wed Aug 6 03:58:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> ISSUE from Chris: Submitting via serial/paraller ports Message-ID: <9708060801.AB13730@zazen.cp10.es.xerox.com> I don't understand this issue. The Job Monitoring MIB requires (and has always required): 3.1.2.1 MIB II System Group objects The Job Monitoring MIB agent SHALL implement all objects in the System Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not. 3.1.2.2 MIB II Interface Group objects The Job Monitoring MIB agent SHALL implement all objects in the Interfaces Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not. But we need to discuss it this week. Tom >Return-Path: >Date: Mon, 4 Aug 1997 18:59:04 PDT >From: Chris Wellens >Reply-To: Chris Wellens >To: Tom Hastings >Cc: Ron Bergman , Lloyd Young >Subject: Re: Schedule and Plans for Job MIB > > > > >>From a network engineer's point of view, you must keep track of >all the traffic into and out of the networked device. This is >just gospel. With the Printer MIB, it seemed to me that >numerous times, the working group just wanted to sweep this >under the table. The best example of this was the efforts to >remove MIB-II as a requirement, stemming from the desire to have >hardware implementations that located the SNMP implementation >geographically removed from the device itself. > >So, yes it is a concern, and the concern comes from both >the Area Directors, and if we had different ADs, the new ones >would have the same concern. > >However, it is the people in the printer industry who do usability >testing and understand how the customers are using these printers on >networks who are in the best position to say whether this is an >issue or not. When a printer is networked, do the users tend to >use it that way, and not print via the parallel or serial ports? My >guess is that yes, that would be the case. But I don't really know. > >So, yes, I think this should be addressed because an IETF audience is >going to pounce on this, just because of how a network engineer views >the world. You could address it in the JOB MIB document, in the >introduction, or if it is going to be a long, complex discussion, then >we would send it in a separate email prior to requesting that the >document be published as a RFC. > > >On Mon, 4 Aug 1997, Tom Hastings wrote: > >> At 12:53 08/01/97 PDT, Chris Wellens wrote: >> snip... >> >> >They know that it is coming. The big concern is that from the >> >user's perspective, jobs can be submitted via serial, parallel, >> >or network connections, and the Job MIB is only going to know >> >about the network connections. I haven't studied the last >> >draft, so I don't know how you've addressed this. >> >> We never heard of "this big concern". Where is it coming from? >> >> Do we need to address it? >> >> Thanks, >> Tom >> >> > > > > From hastings at cp10.es.xerox.com Wed Aug 6 03:58:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:08 2009 Subject: JMP> Re: IPP> Thursday evening: Discussion/tutorial on char sets In-Reply-To: Thursday evening: Discussion/tutorial on char sets> Message-ID: <9708060801.AB13730@zazen.cp10.es.xerox.com> >Return-Path: >Date: Tue, 5 Aug 1997 06:12:37 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Subject: Re: IPP> Thursday evening: Discussion/tutorial on char sets and localizations? >References: <9708050118.AA13368@zazen.cp10.es.xerox.com> > >I suggest adding: > >draft-avelstrand-charset-policy-00.txt > IETF Policy on Character Sets and Language > > >Larry > > From bwagner at digprod.com Sun Aug 3 22:49:21 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:08 2009 Subject: JMP> ISSUE from Chris: Submitting via serial/paraller po In-Reply-To: ISSUE from Chris: Submitting via serial/paraller po> Message-ID: <9708060801.AB13730@zazen.cp10.es.xerox.com> Two points of clarification: 1. I know of no attempt remove MIB 2 as a necessary adjunct to the Printer MIB. There was the observation that, by specifcally calling out the System and Interface groups, some implementors felt that the other germain groups of MIB-2 were not needed. It was my suggestion that, insofar as MIB-2 is required for any network node, specifically calling out two groups of the MIB led to a lesser and more inconsistent implementation than if the printer MIB remained silent in this regard. 2. Indeed, because of various reasons, the information in the MIB-2 systems group, other than perhaps sysUpTime, must be considered applicable only to the network node (NIC or host), and not the printer. By revised convention, the systems information for the printer is within the HR MIB and some of the new objects in the Printer MIB. 3. The non-handling of local ports in the Interfaces group (I am not aware of any implementation that does include the local ports) was a result of the wording of MIB-2, the confusion over the "Evolution of the Interfaces group" MIB, and the very inappropriate way that the "Evolution" seems to handle local ports. Considering the time that was spent considering how to handle local ports, I regard the comment about "the working group just wanted to sweep this under the table." as highly inappropriate. However, I believe that, although the accepted notion that the MIB just dealt with network access was sort of accepted for the printer MIB itself, it does not work for the Job MIB. I agree that this should be discussed. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: JMP> ISSUE from Chris: Submitting via serial/paraller ports Author: Tom Hastings at Internet Date: 8/6/97 12:58 AM I don't understand this issue. The Job Monitoring MIB requires (and has always required): 3.1.2.1 MIB II System Group objects The Job Monitoring MIB agent SHALL implement all objects in the System Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not. 3.1.2.2 MIB II Interface Group objects The Job Monitoring MIB agent SHALL implement all objects in the Interfaces Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not. But we need to discuss it this week. Tom >Return-Path: >Date: Mon, 4 Aug 1997 18:59:04 PDT >From: Chris Wellens >Reply-To: Chris Wellens >To: Tom Hastings >Cc: Ron Bergman , Lloyd Young >Subject: Re: Schedule and Plans for Job MIB > > > > >>From a network engineer's point of view, you must keep track of >all the traffic into and out of the networked device. This is >just gospel. With the Printer MIB, it seemed to me that >numerous times, the working group just wanted to sweep this >under the table. The best example of this was the efforts to >remove MIB-II as a requirement, stemming from the desire to have >hardware implementations that located the SNMP implementation >geographically removed from the device itself. > >So, yes it is a concern, and the concern comes from both >the Area Directors, and if we had different ADs, the new ones >would have the same concern. > >However, it is the people in the printer industry who do usability >testing and understand how the customers are using these printers on >networks who are in the best position to say whether this is an >issue or not. When a printer is networked, do the users tend to >use it that way, and not print via the parallel or serial ports? My >guess is that yes, that would be the case. But I don't really know. > >So, yes, I think this should be addressed because an IETF audience is >going to pounce on this, just because of how a network engineer views >the world. You could address it in the JOB MIB document, in the >introduction, or if it is going to be a long, complex discussion, then >we would send it in a separate email prior to requesting that the >document be published as a RFC. > > >On Mon, 4 Aug 1997, Tom Hastings wrote: > >> At 12:53 08/01/97 PDT, Chris Wellens wrote: >> snip... >> >> >They know that it is coming. The big concern is that from the >> >user's perspective, jobs can be submitted via serial, parallel, >> >or network connections, and the Job MIB is only going to know >> >about the network connections. I haven't studied the last >> >draft, so I don't know how you've addressed this. >> >> We never heard of "this big concern". Where is it coming from? >> >> Do we need to address it? >> >> Thanks, >> Tom >> >> > > > > From imcdonal at eso.mc.xerox.com Wed Aug 6 14:20:09 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:08 2009 Subject: JMP> ISSUE from Chris: Submitting via serial/parallel... In-Reply-To: ISSUE from Chris: Submitting via serial/parallel...> Message-ID: <9708061820.AA20029@snorkel.eso.mc.xerox.com> Hi Tom and Chris, Wednesday (6 August 1997) I think the problem is that the Job Monitoring MIB presently only defines the attribute 'jobSourceChannelIndex' (a value for 'prtChannelIndex' in the Printer MIB's 'prtChannelTable' which is useless, without a Printer MIB implementation, for network management and accounting purposes). To cheaply avoid dependency on the Printer MIB for job source channel info, I suggest that we add the following two Job Mon MIB attributes: 1) 'jobSourceChannelType' (using 'PrtChannelTypeTC' from the Printer MIB, but NOT requiring implementation of the 'prtChannelTable'); 2) 'jobSourceChannelIfIndex' (a value for 'ifIndex' in the MIB-II 'ifTable', in the Interface group of RFC 1213). Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 >---------------------- Tom's and Chris's notes -----------------------< >Date: Wed, 6 Aug 1997 00:58:43 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> ISSUE from Chris: Submitting via serial/paraller ports > >I don't understand this issue. The Job Monitoring MIB requires (and has >always required): > >3.1.2.1 MIB II System Group objects > >The Job Monitoring MIB agent SHALL implement all objects in the System Group >of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not. > >3.1.2.2 MIB II Interface Group objects > >The Job Monitoring MIB agent SHALL implement all objects in the Interfaces >Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented >or not. > >But we need to discuss it this week. > >Tom > >>Date: Mon, 4 Aug 1997 18:59:04 PDT >>From: Chris Wellens >>To: Tom Hastings >>Cc: Ron Bergman , Lloyd Young >>Subject: Re: Schedule and Plans for Job MIB >> >>>From a network engineer's point of view, you must keep track of >>all the traffic into and out of the networked device. This is >>just gospel. With the Printer MIB, it seemed to me that >>numerous times, the working group just wanted to sweep this >>under the table. The best example of this was the efforts to >>remove MIB-II as a requirement, stemming from the desire to have >>hardware implementations that located the SNMP implementation >>geographically removed from the device itself. >> >>So, yes it is a concern, and the concern comes from both >>the Area Directors, and if we had different ADs, the new ones >>would have the same concern. >> >>However, it is the people in the printer industry who do usability >>testing and understand how the customers are using these printers on >>networks who are in the best position to say whether this is an >>issue or not. When a printer is networked, do the users tend to >>use it that way, and not print via the parallel or serial ports? My >>guess is that yes, that would be the case. But I don't really know. >> >>So, yes, I think this should be addressed because an IETF audience is >>going to pounce on this, just because of how a network engineer views >>the world. You could address it in the JOB MIB document, in the >>introduction, or if it is going to be a long, complex discussion, then >>we would send it in a separate email prior to requesting that the >>document be published as a RFC. >> >> >>On Mon, 4 Aug 1997, Tom Hastings wrote: >> >>> At 12:53 08/01/97 PDT, Chris Wellens wrote: >>> snip... >>> >>> >They know that it is coming. The big concern is that from the >>> >user's perspective, jobs can be submitted via serial, parallel, >>> >or network connections, and the Job MIB is only going to know >>> >about the network connections. I haven't studied the last >>> >draft, so I don't know how you've addressed this. >>> >>> We never heard of "this big concern". Where is it coming from? >>> >>> Do we need to address it? >>> >>> Thanks, >>> Tom From don at lexmark.com Mon Aug 11 02:59:40 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:08 2009 Subject: JMP> Atlanta Ping Message-ID: <199708110703.AA11063@interlock2.lexmark.com> The time has come to ping me to let me know what meetings you will be attending in Atlanta. Please include the following: Name Arrival date Meetings attending Departure date Remember, the deadline for making reservations at the Atlanta Midtown Suites hotel is August 29th. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From rbergma at dpc.com Tue Aug 12 20:46:17 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:08 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 Message-ID: <199708110703.AA11063@interlock2.lexmark.com> Tom, The following editorial corrections from revision 0.83 were not incorporated into version 0.84. Please comment if there is a reason that these should not be incorporated. I do not believe that any of the corrections change the intent of the document. Problems from 0.83: 1. Section 2. Terminology and Job Model (page 14) states: "PJL systems use the term job to mean what we call a job in this specification. PJL also supports multiple documents per job, but does not support specifying per-document attributes independently for each document." This text should be a part of the mapping document. This additional example does not provide any additional help in understanding the subject paragraph. 2. The definitions in section 2 should begin with a capital letter. Example: "Job Set: A group of jobs..." 3. The definition for "Device" (page 14): "...interfaces to humans in human perceptible means, such as produces marks on paper, scans marks on paper to produce an electronic representations, or writes CD_ROMS..." The second two examples don't appear to be human perceptible. I am not sure I understand the reason for including other than the first example. 4. In jmGeneralJobPersistence (page #75), the second paragraph: "Depending on implementation, the value of this object MAY be either: (1) set by the system administrator by means outside this specification or (2) fixed by the implementation." Since this is a read only object do we need to define how it is configured? We only need to describe the function. Suggest: "Configuration of this parameter is implementation dependent." 5. For jmGeneralAttributePersistence (page #76) the above comment also applies. 6. In jmJobStateReasons1 (page #81), I find the following statement hard to disagree with, but why do we need to state this? "Furthermore, when implemented as with any MIB data, the agent SHALL return these values when the reason applies and SHALL NOT return them when the reason no longer applies whether the value of the job's jmJobState object changed or not." All this really states is that the value of an object must be valid. We do not have a similar statement for any other object. 7. Also in jmJobStateReasons1 (page #81), the next sentence: "When the job does not have any reasons for being in its current state, the agent SHALL set the value of the jmJobStateReasons1 object and jobStateReasonsN attributes to 0." I suggest it be reworded to: "When the agent cannot provide a reason for the current state of the job, the value of jmJobStateReasons1 object and jobStateReasonsN attributes shall be 0." Ron Bergman Dataproducts Corp. From jkm at underscore.com Tue Aug 12 23:29:00 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:08 2009 Subject: JMP> The Job Monitoring MIB WG is NOT chartered??? Message-ID: <199708130329.XAA13172@uscore.underscore.com> This snippet comes from Randy Turner's recent IPP minutes from the IETF plenary last week: One note about the job MIB. Keith Moore, our area director for applications, noted that there is no formal IETF working group chartered for the Job MIB effort. Further, there may be problems with IPP achieving "proposed" status if IPP documents reference such other documents. He reiterated that the Printer Working Group had submitted an extension to the Printer MIB working group's charter to include the Job MIB, but that the request was rejected by the IESG, so there may be a problem here. I have not yet spoken with Randy about exactly what went on, but perhaps someone else (maybe the PMP chairpersons) can comment on this? ...jay From chrisw at iwl.com Wed Aug 13 01:35:20 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:08 2009 Subject: JMP> The Job Monitoring MIB WG is NOT chartered??? In-Reply-To: <199708130329.XAA13172@uscore.underscore.com> Message-ID: Neither Lloyd Young nor I received notification from the IESG that the Job MIB charter was rejected. I just sent off some email requesting a clarification. ----------------------------------------------------------------------------- --==--==--==- Chris Wellens ==--==--==--= Email: chrisw@iwl.com Web: http://www.iwl.com/ --==--==--==- InterWorking Labs, Inc. 244 Santa Cruz Ave, Aptos, CA 95003 ==--==--==--= Tel: +1 408 685 3190 Fax: +1 408 662 9065 ----------------------------------------------------------------------------- On Tue, 12 Aug 1997, JK Martin wrote: > This snippet comes from Randy Turner's recent IPP minutes > from the IETF plenary last week: > > One note about the job MIB. Keith Moore, our area director for > applications, noted that there is no formal IETF working group > chartered for the Job MIB effort. Further, there may be problems > with IPP achieving "proposed" status if IPP documents reference > such other documents. He reiterated that the Printer Working > Group had submitted an extension to the Printer MIB working > group's charter to include the Job MIB, but that the request > was rejected by the IESG, so there may be a problem here. > > I have not yet spoken with Randy about exactly what went on, > but perhaps someone else (maybe the PMP chairpersons) can > comment on this? > > ...jay > From harryl at us.ibm.com Wed Aug 13 12:03:04 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:08 2009 Subject: JMP> Seattle Minutes Message-ID: <5030100006238079000002L092*@MHS> I have posted the minutes from Seattle at pwg/jmp/minutes/jmp-0897.xxx. The primary format is PDF. I also exported the file as text but I can't vouch for the formatting. I've included a version of the text minutes below: *************************************************** JMP Seattle Minutes *********************************** IETF Disclaimer Although decisions regarding the development of IETF standards are ultimately wrought via the Internet, face-to-face meetings of interested parties capable of attending can often accelerate the consensus process. The PWG facilitates such meetings on a monthly basis for active work groups. These are the minutes of the PWG meeting of the Job MIB Project which currently pertains directly to the IETF chartered Job MIB working group. JMP Meeting Attending Attending the Seattle JMP meeting were: Yasuo Bato - Japan Computer Industry Inc. Ron Bergman - DataProducts (Chair) Andy Davidson - Tektronix Lee Farrell - Canon Jonathan Fletcher - Intermec Tom Hastings - Xerox (Editor) David Kellerman - Northlake Software Rick Landau - DEC Harry Lewis - IBM (Secretary) Paul Moore - Microsoft (Host) Bob Pentecost - HP Stuart Rowley - Kyocera Electronics Yuki Sabahi - Japan Computer Industry Inc. Bill Wagner - Osicom/DPI Plans and Schedule The Seattle JMP meeting opened on 8/8/97 with an overview of the plans and schedule for the Job MIB standards effort. 1. Job MIB version 0.85 is planned to be released 1 week following this meeting or on 8/15. 2. There will be 1 week for comments on v0.85 so these are due by 8/22. 3. There will be a Teleconference on 8/26 at 1-3 pacific 4-6 eastern to review comments. 4. If a final revision is needed, v0.86 will be published on 8/29. 5. There will be a 9/6 deadline for comments on v0.86 - EDITORIAL ONLY. 6. The final draft of the Job MIB will be submitted to the IESG on 9/8. JMP Major Outstanding ISSUES Only two major issues remained with the Job MIB as we entered the Seattle meeting. These were Nested Attributes (especially jmJobSubmissionID) and Localization (of agent and host supplies text strings). 1. Nested attributes. The general rule for nested attributes is that the Job MIB agent will always use the most recent value. Client and intermediary software must be aware of this rule. As an example, if a Novell P-Server implementation is wrapping a print job with another job for putting on a banner page, the P-Server should refrain from also supplying a jmJobSubmissionID since P-Server has an internal mechanism for tracking jobs but the client may wish to use the Job MIB. On the other hand, in an integrated, bidi port monitor environment, such as NT, the Job MIB based port monitor will want to add jmJobSubmissionID, not the client, since the client will be utilizing NT print API's to obtain job information from the port monitor. Tom will add the following to the Job MIB specification - "The agent always takes last attribute for nested situations." 2. Localization. David Perkins had submitted e-mail comments which resulted in Issues 111 and 112. Basically, how does a management application determine the coded character set for text strings in the Job MIB which have been generated by the agent (111) or passed in by the client upon job submission (112). The two basic proposals discussed were to force UTF-8 for all strings or provide a way to "tag" a string as to it's character set. Issue 111 - It was argued that printers should know the character set of text strings originating in the printer whether as part or the Job MIB implementation, the Printer or System MIB, a PDL processing message or whatever. (It was, strangely, argued later that a Printer controller and NIC could not be expected to coordinate the issuing of IPP job ID's such that the IPP ID and jmJobIndex would be identical... so it is clear we have varying perspectives among JMP members about the overall scope of the Job MIB agent within the printer.). Printers are very likely to have used 7-bit ASCII or Shift-JIS for their internal strings. Printers could implement UTF-8 as the internal character set in the future. UTF-8 presents some interesting challenges when it comes to fitting longer strings into shorter attributes - for example if there should be a mismatch between IPP and JMP and the Job MIB agent is required to truncate a job attribute text string. With UTF-8, characters may be 1 to 6 bytes, so there is no certain truncation boundary. For the agent assigned strings (Physical Device Name, Processing Message, JobSetName), issue 111 was settled by agreeing to force UTF-8 but assume 7-bit ASCII (or just don't implement the objects) if the agent really can't determine the character set. Implementations for the Asian markets would use UTF-8 but would default to Shift-JIS as a fallback rather than 7-bit ASCII. ISSUE 112 - There are 19 text strings passed in with the Job MIB. Job Owner is the only object. All others are (optional) attributes. Printers cannot be expected to transform strings which have been passed in on submission - even though the simplest transform, from 8 bit ASCII, would be relatively easy. Printers certainly should not be burdened with Shift-JIS to UTF-8 translation. It was noted that, if the agent simply "echoes" the text string which was passed in then it should be possible for management and client applications to enforce the "UTF-8" only rule by always passing in UTF-8 and, thus, always expecting it from the Job MIB. This is the preferred solution to localization of Job MIB text strings originating form the host. Still, it was argued that an attribute should be added which is the enum of character set for the host originated job attributes. This character set attribute would also be passed in on submission on a per job (NOT per attribute) basis. If the character set in unknown then the value of the character set attribute should be "unknown" or just leave attribute off. Default behavior is environment specific and generally not specified but the following are the best environment localized guesses From SISAACSON at novell.com Mon Aug 18 11:32:00 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:08 2009 Subject: JMP> The Job Monitoring MIB WG is NOT chartered??? In-Reply-To: The Job Monitoring MIB WG is NOT chartered???> Message-ID: Jay, This discussion came up during the presentation of the IPP Model that I was leading. I made the comment that over that last few months, the IPP working group has been moving to align with the Printer MIB and the Job Monitoring MIB as much as possible. I said that this was a good thing for the group to do. However, this brought on "much" discussion from many of what I would call the "non-IPP-specific IETF players". The most vocal of which was Keith Moore stating very emphatically that the proposal for including the Job Monitoring MIB in printmib working group's charter had been reviewed by the IESG and rejected. Therefore, there was no Job MIB to align with. Many of the more active PWG members in the room (myself, Randy, Carl-Uno, Steve Z., Lee F.) all seemed surprised by the statement. Several, including myself, pointed out the mailing list, presentations at Memphis and the expectation among the working group members that it had been chartered and that the draft was nearing completion. This information did not make Keith rethink the IESG decision. Sounds like from Chirs Wellen's email, she is seeking clarification. Scott I. >>> JK Martin 08/12/97 09:29PM >>> This snippet comes from Randy Turner's recent IPP minutes from the IETF plenary last week: One note about the job MIB. Keith Moore, our area director for applications, noted that there is no formal IETF working group chartered for the Job MIB effort. Further, there may be problems with IPP achieving "proposed" status if IPP documents reference such other documents. He reiterated that the Printer Working Group had submitted an extension to the Printer MIB working group's charter to include the Job MIB, but that the request was rejected by the IESG, so there may be a problem here. I have not yet spoken with Randy about exactly what went on, but perhaps someone else (maybe the PMP chairpersons) can comment on this? ...jay From harryl at us.ibm.com Mon Aug 18 16:11:37 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-Reply-To: IETF concerns regarding the Printer MIB draft?> Message-ID: <5030300008596454000002L042*@MHS> If anyone thinks the Printer MIB is "broken" (especially someone in position at the IESG or IETF) I hope they will share this with the PMP mailing list. The IETF understands not everyone can manage to attend the in-person meetings where this was evidently discussed. I suspect I may be misunderstanding Keith's comments - having heard them somewhat out of context. I find it amusing that the IESG is nervous about IPP aligning with the Printer MIB because they think it might be "broke" (even though it has wide support in the industry) when the same body (IETF/IESG) overrode the PWG initially, during development of the Printer MIB, by insisting we align with the Host Resources MIB which has resulted in most of the Printer MIB problems encountered. I don't have a problem with MIME, in particular. Things change, improve etc. If there are good reasons for IPP to use MIME (or register MIME and enums), this is valid and IESG recommendations should be followed. But the IESG must realize that the IETF has had major influence on the Printer MIB so it seems a bit odd to hear them now say the Printer MIB is "broke". I hope we can clarify and get to the bottom of recent IESG comments concerning both the Printer and the Job MIBs being broken or unchartered. Harry Lewis ------ Forwarded by Harry Lewis/Boulder/IBM on 08/18/97 12:40 PM ------- ipp-owner@pwg.org on 08/18/97 12:09:46 PM Please respond to ipp-owner@pwg.org @ internet To: jkm@underscore.com @ internet, pmp@pwg.org @ internet cc: ipp@pwg.org @ internet Subject: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? As the leader of the discussion on the IPP Model while reviewing recent issues, it became clear to me that by making statements about aligning "IPP with the Printer MIB and with the Job Montoring MIB" caused much consternation among the attendees of the working group meeting. It basicaly came down to the fact that there is no such thing as a Job Monitoring MIB and the Printer MIB is broken and will receive serious push back from the IESG. As Randy pointed out, we had to remind the group that this was an IPP working group meeting and not a printmib working group meeting. However, the feeling of the attendees can be summarized by quoting one vocal observation made during the meeting: "If Keith says that you will receive considerable pushback from the IESG if you align IPP with Printer MIB enums for document format rather than MIME types, interpret that to mean that the IESG will reject any propsal that is based on Printer MIB enums rather than MIME types for document format identifiers." Later in the meeting, Harold A. joined the meeing and also endorsed the proposal of using MIME types rather than printer MIB enums. There were several reasons voiced for using MIME types rather than IANA registered enums for document formats: 1. Levels and Versions could be captured as needed in MIME types rather than having 3 different objects in the MIB 2. There is a standard way of adding the encoding used within the MIME type itself rather than adding yet another object to identify the code set and encoding used (such as the IPP proposed "document-char-set" attribute) 3. Printer MIB enums are useful in a Management Context, but IPP is being deployed in a general, end user environment. Alignment with the Printer MIB enums satisfies only a few tools and existing practice rather than satisfying a MUCH larger set of tools and existing practice for other entities that will interact with IPP. At this point in the discussion, is where Keith suggested that the Printer MIB was "broken" in this regard and that it would need to be "fixed" before being able to be progressed by the IESG. Jay, you included a concern that public comments be addressed on the discussion list. I assumed that all comments made at the meeting were "public" comments and that they would be captured in the meeting notes and hence published on the mailing list. This is what happened, however the disucssion list and meeting minutes were for IPP, not PMP. Thanks to you, we have now started this on the PMP discussion list. As Randy's notes indicate, there was fairly persuasive and strong comments about using MIME types. I don't know if any more on this discussion should be carried out on the IPP or PWG mailing lists? Scott I. ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> JK Martin 08/12/97 09:34PM >>> at the IETF plenary last week: 16. Use of MIME types for "document-format" Currently, the model document specifies the use of Printer MIB enumerations for specification of document-format. In addition, at a recent IPP meeting, it was agreed that enumerations for PDF and HTML would be added to this list. Upon hearing the proposed alignment with the Printer MIB for these values, "a lively discussion ensued". It was the opinion of Larry Masinter (chair of HTTP WG), Keith Moore, and most of the IETF audience that alignment with the Printer MIB was a mistake, and that we should focus on sticking with MIME-type specifications. Further, Keith Moore went on to say that the current draft of the Printer MIB was "broken", and that he is seriously considering delaying advancement of the Printer MIB draft until this (and possibly other) issues are addressed. Keith did not go into any detailed analysis of why the MIB was broken, but seemed to suggest that there were more than one reason why it's broken. He went on to say that its possible that (ironically) the IESG might suggest to the working group that the Printer MIB should align itself with the MIME-types and change the way that interpreters are enumerated in the MIB. He suggested that the group should consider strings, and not enumerations, to specify these types (i.e., MIME types). Keith was pretty adamant on this issue and would have conntinued discussion, but Steve Z. and Scott suggested that discussion on the Printer MIB was not appropriate at an IPP WG meeting. This is *most* disconcerting. Can someone shed some light on this situation? In particular, I find it rather disappointing that such statements were made in Germany...yet nothing of the sort was posted on the mailing list. I could have sworn that ALL public comments were supposed to be published on the mailing lists. ...jay From harryl at us.ibm.com Mon Aug 18 18:04:06 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: PMP> IETF concerns regarding the Printer MIB draft??? In-Reply-To: IETF concerns regarding the Printer MIB draft???> Message-ID: <5030300008601672000002L022*@MHS> Thanks, Chris for your crisp, concise position, which I support. I would also like to know if either you, Lloyd or Ron ever received any kind of "rejection" from the IETF regarding the JMP charter. Is a charter rejected if you ask for one and "nothing" happens, or should there be something to reference regarding the rejection, why etc.? I think the later, and I do not recall anyone sharing such a rejection with us. (Of course, I understand a charter is not granted, either, if "nothing" happens). What is you position on the charter of JMP? Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 08/18/97 03:53 PM -------- pmp-owner@pwg.org on 08/12/97 11:51:33 PM Please respond to pmp-owner@pwg.org @ internet To: jkm@underscore.com @ internet cc: pmp@pwg.org @ internet Subject: Re: PMP> IETF concerns regarding the Printer MIB draft??? Neither Lloyd Young nor I have received any IETF communication regarding problems with the Printer MIB or a decision to hold it up from going to Draft. In fact, the MIB document was submitted, and our interoperability report was submitted, but the formal email request from the WG Chairs to advance to Draft has not been submitted yet. The PMP met every single requirement for advancing to Draft. The interoperability test results were meticulous. If there are technical decisions that need to be explained and clarified, then we will go ahead and address them with the IESG and our ADs. I have sent off more email requesting clarification on this. ----------------------------------------------------------------------------- --==--==--==- Chris Wellens President & CEO ==--==--==--= Email: chrisw@iwl.com Web: http://www.iwl.com/ --==--==--==- InterWorking Labs, Inc. 244 Santa Cruz Ave, Aptos, CA 95003 ==--==--==--= Tel: +1 408 685 3190 Fax: +1 408 662 9065 ----------------------------------------------------------------------------- On Tue, 12 Aug 1997, JK Martin wrote: > >From Randy Turner's recent minutes on the IPP WG meeting > at the IETF plenary last week: > > 16. Use of MIME types for "document-format" > > Currently, the model document specifies the use of Printer MIB > enumerations for specification of document-format. In addition, > at a recent IPP meeting, it was agreed that enumerations for > PDF and HTML would be added to this list. > > Upon hearing the proposed alignment with the Printer MIB for > these values, "a lively discussion ensued". > > It was the opinion of Larry Masinter (chair of HTTP WG), Keith > Moore, and most of the IETF audience that alignment with the > Printer MIB was a mistake, and that we should focus on sticking > with MIME-type specifications. > > Further, Keith Moore went on to say that the current draft of > the Printer MIB was "broken", and that he is seriously > considering delaying advancement of the Printer MIB draft until > this (and possibly other) issues are addressed. Keith did not > go into any detailed analysis of why the MIB was broken, but > seemed to suggest that there were more than one reason why it's > broken. He went on to say that its possible that (ironically) > the IESG might suggest to the working group that the Printer > MIB should align itself with the MIME-types and change the way > that interpreters are enumerated in the MIB. He suggested that > the group should consider strings, and not enumerations, to > specify these types (i.e., MIME types). Keith was pretty adamant > on this issue and would have conntinued discussion, but Steve Z. > and Scott suggested that discussion on the Printer MIB was > not appropriate at an IPP WG meeting. > > > This is *most* disconcerting. Can someone shed some light on this > situation? > > In particular, I find it rather disappointing that such statements > were made in Germany...yet nothing of the sort was posted on the > mailing list. > > I could have sworn that ALL public comments were supposed to be > published on the mailing lists. > > ...jay > From Harald.T.Alvestrand at uninett.no Tue Aug 19 02:46:58 1997 From: Harald.T.Alvestrand at uninett.no (Harald.T.Alvestrand@uninett.no) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-Reply-To: Re: PMP> IETF concerns regarding the Printer MIB draft?> Message-ID: <5030300008601672000002L022*@MHS> Oops control, as usual.... The Applications Area Directors do not think that the Printer MIB is broken. The Apps ADs think that one particular decision was mistaken: To establish a register of print languages (the prtInterpreterLangFamily) and not to register those as MIME types. We also have doubts about the use of integers rather than names for character sets (the CodedCharSet textual convention), but since this is just 2 pointers into the same registry, and the IANA appears to be maintaining this double registry, it is less harmful overall. We think the Right Thing is that the IPP group or the PrinterMIB group should register all the currently unregistered printer formats as MIME types, and that the IPP group should use the MIME types to indicate the content of their MIME objects. With regard to the Job MIB, it seems clear that: - The IETF has no consensus position that it is a Good Thing to deploy MIBs as a means of users' access to information (as opposed to an administrator's access). In particular, the access control models currently being defined in the SNMPv3 group are not based on the idea that all users need MIB access; we do not want to bring this idea into that process, for fear of delaying it further. - The IETF has consensus that there is no need for all MIBs to be Internet standards. Informational MIBs, or MIBs developed by other organizations, are Good Things; the IETF can sometimes assist in their reviews, without necessarily taking responsibility. - Given the two positions above, we think that it's better for the Job MIB to be submitted to the IETF as an external document and given Informational status as a protocol under PWG control. There was some unfortunate fumbling of balls in the handover of this group from the NM area to the Apps area, where the status of this request for revised charter seemed to have been lost; I had hoped that we had agreement on the positions above, but it seems that we didn't. (this discussion should be moved to the Printer MIB list only, but since it seems I've fallen off it, please keep me in the CC line....) Harald Tveit Alvestrand Apps AD From harryl at us.ibm.com Tue Aug 19 15:01:45 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB dr In-Reply-To: Re: PMP> IETF concerns regarding the Printer MIB dr> Message-ID: <5030300008679786000002L062*@MHS> Harald - thank you for clarifying the IESG Printer and Job MIB issues and sharing this with the appropriate PWG projects which make up the majority of concerned parties. This is very helpful! My interpretation is that you are resigned to double registration at this point. I agree, and view double registration (integers and text) of PDLs and coded character sets as a natural result of Evolution and Overlap of application and management standards . Evolution - MIME was pretty fresh when the Printer MIB was laying down it's definitions and, while discussed, the connection between MIME and print jobs was not so obvious then. Overlap - like it or not, the Printer MIB *is* used by some end-user applications to determine device configuration and capabilities and IPP will be involved in "managing" print jobs. This unacknowledged overlap may have contributed to some of our most difficult discussion during development of IPP which related to the use of text strings vs. integers. It would be hard to avoid double registration for both reasons. AS FOR THE Job MIB, you have listed some very reasonable points which somewhat change the notion which has carried the JMP team - that of creating an Internet Standard - but do not necessarily undermine or resist the desire to have a standard Job MIB within the printer industry which is also an informational RFC. I'd like to hear more comment on this from the Chair and other members of the JMP and IPP. I have two main concerns... 1. First, the IESG may not understand the role the Job MIB plays in the administration and accounting of print jobs. Thus, I fear your statement... >- The IETF has no consensus position that it is a Good Thing to deploy > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the idea > that all users need MIB access; we do not want to bring this idea into > that process, for fear of delaying it further. ...may be applied to the Job MIB with more weight than is actually warranted. 2. Second, I'm concerned about the effect on IPP if the Job MIB is treated as informational by the IESG. It should be viewed as a Good Thing to facilitate harmony between standards - especially those routed within a particular industry and standards organization. Folks in the printer industry have been active in defining and deploying solutions based on Internet Standards, and I don't think we're unique in potentially having overloaded some. As application and management standards evolve, it is reasonable for controlling bodies, like the IETF, to project a clearer picture of the purpose and relationship between standards. But, this needs to be done in an atmosphere which acknowledges and, if possible, accommodates this evolution and the resulting current state of affairs. Thanks, again, for helping disseminate an accurate view of the IEGS's stance on these issues. Harry Lewis From hastings at cp10.es.xerox.com Tue Aug 19 15:09:13 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: Open Editorial Changes From Rev. 0.83> Message-ID: <9708191911.AA16333@zazen.cp10.es.xerox.com> At 17:46 08/12/97 PDT, Ron Bergman wrote: >Tom, > >The following editorial corrections from revision 0.83 were not >incorporated into version 0.84. Please comment if there is a >reason that these should not be incorporated. I'm sorry that I didn't have time to respond before as to why I did not include these (few) editorial comments. See if you agree with my reasoning for not including them. I did include 99% of your suggestions and they improved the document. > I do not believe >that any of the corrections change the intent of the document. I agree that none of your corrections changed the intent of the document, including these few that I did not include. > > >Problems from 0.83: > >1. Section 2. Terminology and Job Model (page 14) states: > > "PJL systems use the term job to mean what we call a job in this > specification. PJL also supports multiple documents per job, but > does not support specifying per-document attributes independently > for each document." > > This text should be a part of the mapping document. This additional > example does not provide any additional help in understanding the > subject paragraph. I disagree. I think that it is important to understand the terms that the Job Monitoring MIB is using and to have an example mapping on this term. I also didn't want to include only the PostScript example. It seems more even handed to keep both examples to show that the mapping varies depending on the job submission protocol. > >2. The definitions in section 2 should begin with a capital letter. > Example: "Job Set: A group of jobs..." I agree and both the .doc and .txt files have "Job Set", not "job set". None of the definitions themselves start with a capital letter, so I assume that you are not talking about "A group of jobs...", as opposed to "a group of jobs..." > >3. The definition for "Device" (page 14): > > "...interfaces to humans in human perceptible means, such as produces > marks on paper, scans marks on paper to produce an electronic > representations, or writes CD_ROMS..." > > The second two examples don't appear to be human perceptible. I am > not sure I understand the reason for including other than the first > example. It is important to clarify that the device can produce other forms of human perciptable output than just printing devices, as we agreed in the requirements document. So I left these other examples in. > >4. In jmGeneralJobPersistence (page #75), the second paragraph: > > "Depending on implementation, the value of this object MAY be > either: (1) set by the system administrator by means outside > this specification or (2) fixed by the implementation." > > Since this is a read only object do we need to define how it is > configured? We only need to describe the function. Suggest: > > "Configuration of this parameter is implementation dependent." I think that it helps to clarify that there are several ways that an implementation can set the value, so I left in both ways. > >5. For jmGeneralAttributePersistence (page #76) the above comment > also applies. I left both in for the same reason. > >6. In jmJobStateReasons1 (page #81), I find the following statement > hard to disagree with, but why do we need to state this? > > "Furthermore, when implemented as with any MIB data, the > agent SHALL return these values when the reason applies and > SHALL NOT return them when the reason no longer applies whether > the value of the job's jmJobState object changed or not." > > All this really states is that the value of an object must be valid. > We do not have a similar statement for any other object. I disagree. One commentor asked whether the bits had to be turned off or not, so I felt it was important to clarify that these bits are meaningful while the job is in each job state, not just when the job transitions from one state to another. There are hardware implementations in which such bits are only meaningful on the state transitions. As far as I'm concerned, if someone asks about something it can't hurt to include the explanation in the document. There will be others who will ask the same question, but we won't be there to answer. > >7. Also in jmJobStateReasons1 (page #81), the next sentence: > > "When > the job does not have any reasons for being in its current > state, the agent SHALL set the value of the jmJobStateReasons1 > object and jobStateReasonsN attributes to 0." > > I suggest it be reworded to: > > "When the agent cannot provide a reason for the current > state of the job, the value of jmJobStateReasons1 object > and jobStateReasonsN attributes shall be 0." > I had taken your suggestion in V0.84, but kept it in the active voice: When the agent cannot provide a reason for the current state of the job, the agent SHALL set the value of the jmJobStateReasons1 object and jobStateReasonsN attributes to 0." I have tried hard to avoid the passive voice, since there are many entities in the system that do things: the agent, the device, the server, the management app, etc. So I indicated that is the agent that sets the values to 0. > > > Ron Bergman > Dataproducts Corp. > So I hope you agree that all of your editorial suggestions are closed. Thanks, Tom From chrisw at iwl.com Wed Aug 20 00:12:06 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: PMP> IETF concerns regarding the Printer MIB draft??? In-Reply-To: <5030300008601672000002L022*@MHS> Message-ID: On Mon, 18 Aug 1997, Harry Lewis wrote: > Thanks, Chris for your crisp, concise position, which I support. I would also > like to know if either you, Lloyd or Ron ever received any kind of "rejection" > from the IETF regarding the JMP charter. Since we now have a statement from the AD, it probably does not matter, but just for the record ... Lloyd and I as co-Chairs did not ask for a charter for the JMP; we merely asked that the JMP work be tacked on to the PMP charter. This way we thought we could add what would be a small MIB that would probably have either the same people or a subset of those people. Our previous AD said okay, but then apparently the changes did not go into effect. The issue next came up when we submitted updated charters and our new AD said there was no charter for the JMP. We said "oh there must be a mistake..." I know that the IESG has been trying to figure out a good model for handling the huge number of requests for chartered Working Groups surrounding MIBs. I was actually hoping they would put together a group to define What Makes a Good MIB, and publish a document, so that interested parties could kind of follow a workbook approach. If a clear decision had been made and communicated to us, we would certainly have forwarded it to the jmp list promptly. It is not productive to guess, speculate, and communicate partial information to the list that would just get people anxious and confused and turn out to be wrong in the final analysis. From rbergma at dpc.com Wed Aug 20 11:28:00 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Non-Network Ports in the Job MIB Message-ID: Chris, Now that some of the dust has settled regarding the comments from the Munich IETF meeting, I thought it was a good time to discuss some of the conclusions reached at the PWG meeting in Redmond. Everyone was quite surprised regarding the issue of "lack of support for non-networked ports" in the Job Monitoring MIB. It was mutually agreed in the meeting that the Job MIB would apply to all jobs processed by the printer regardless of the received port. Some implementations may not be able to support this requirement, but they should be considered "non-conforming". (Of the companies currently planning to implement the Job MIB, none indicated that jobs from non-networked ports would be ignored.) The only current prototype, from IBM, does include all ports supported by the printer. One problem with jobs received on serial or parallel ports is the issue of job boundaries. Most jobs today received on these ports do not indicate the start and end of the job. The ports simply rely on a timeout to detect the end of the job. (Note that there are exceptions to this rule, such as print jobs received using PJL.) The only consequence, in this case, is that several jobs may be reported as one. For a further discussion relative to ports and the Printer MIB, see the excellent discussion from Bill Wagner dated August 3, 1997 "Re: JMP> ISSUE from Chris: Submitting via serial/parallel ports". Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Wed Aug 20 11:37:00 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: PMP> IETF concerns regarding the Printer MIB dr In-Reply-To: Re: PMP> IETF concerns regarding the Printer MIB dr> Message-ID: <5030300008748293000002L032*@MHS> Chris and Lloyd... I'm sure you would have informed the JMP promptly had there been clear signals from the IESG. No doubt in my mind! >If a clear decision had been made and communicated to us, we >would certainly have forwarded it to the jmp list promptly. >It is not productive to guess, speculate, and communicate >partial information to the list that would just get people >anxious and confused and turn out to be wrong in the final >analysis. Given where we are, however, does it seem at all feasible that we could be considered "chartered" and, if not, what do we do now? My interpretation of the IESG comments is that the authors should submit an informational RFC describing the Job MIB and the PWG should maintain the standard. This would be the first "PWG standard". Is the PWG ready for this? Harry Lewis - IBM Printing Systems From rbergma at dpc.com Wed Aug 20 12:23:33 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB dr In-Reply-To: <5030300008679786000002L062*@MHS> Message-ID: <5030300008748293000002L032*@MHS> Harry, Thank you for some of the history as to why the Printer MIB selected enums rather than MIME types. However, I would argue that double registration is not an acceptable solution. This will require an embedded print server to support both enums and MIME types. It would be best if we only had to deal with one form or the other. My preference would certainly be enums! I have listened to the argument for and against MIME types since the start of the IPP effort. I am of the opinion that this is more of a religious issue than a technical one. And like other religious issues, will never be settled! So, unless the IETF will agree to accept enums, we will be stuck with having to support both. I also am disappointed that the IETF has announced the strong stand against accepting the Job MIB as a Proposed Standard. The support for this standard by printer vendors has indicated a real need for this effort to progress. I believe that a Proposed Standard would encourage the development of more applications that support the MIB than if the MIB was an Informational RFC. I would like to obtain a straw vote from the group on this topic. To my understanding, the real objection from the IETF is that they believe that the MIB is primarily intended for users. I do not fully agree with this position. In small installations where peer- to-peer printing is the norm, this is most likely to be true. In large installations, where printing is directed through a server, I expect that the server will be the central point of communications. (This is configuration 3 in the Job MIB document.) SNMP would be used between the server and the printer and the user would obtain status using a new (e.g. IPP) or existing (e.g. lpd) protocol. It should also be noted that usage of the Job MIB would be primarily on intranet and not internet applications. These discussions are not new to the JMP participants. All of these details have been discussed to death in the PWG meetings and on the mail list. Would a more complete presentation of these issues to the IETF change their minds regarding the decision regarding the status and acceptance of the MIB? Ron Bergman Dataproducts Corp. On Tue, 19 Aug 1997, Harry Lewis wrote: > Harald - thank you for clarifying the IESG Printer and Job MIB issues > and sharing this with the appropriate PWG projects which make up the > majority of concerned parties. This is very helpful! > > My interpretation is that you are resigned to double registration at > this point. I agree, and view double registration (integers and text) > of PDLs and coded character sets as a natural result of Evolution and > Overlap of application and management standards . > > Evolution - MIME was pretty fresh when the Printer MIB was laying down > it's definitions and, while discussed, the connection between MIME and > print jobs was not so obvious then. > > Overlap - like it or not, the Printer MIB *is* used by some end-user > applications to determine device configuration and capabilities and > IPP will be involved in "managing" print jobs. This unacknowledged > overlap may have contributed to some of our most difficult discussion > during development of IPP which related to the use of text strings vs. > integers. > > It would be hard to avoid double registration for both reasons. > > AS FOR THE Job MIB, you have listed some very reasonable points which > somewhat change the notion which has carried the JMP team - that of > creating an Internet Standard - but do not necessarily undermine or > resist the desire to have a standard Job MIB within the printer industry > which is also an informational RFC. I'd like to hear more comment on > this from the Chair and other members of the JMP and IPP. > > I have two main concerns... > > 1. First, the IESG may not understand the role the Job MIB plays in the > administration and accounting of print jobs. Thus, I fear your statement... > > >- The IETF has no consensus position that it is a Good Thing to deploy > > MIBs as a means of users' access to information (as opposed to an > > administrator's access). In particular, the access control models > > currently being defined in the SNMPv3 group are not based on the idea > > that all users need MIB access; we do not want to bring this idea into > > that process, for fear of delaying it further. > > ...may be applied to the Job MIB with more weight than is actually warranted. > > 2. Second, I'm concerned about the effect on IPP if the Job MIB is > treated as informational by the IESG. It should be viewed as a Good Thing > to facilitate harmony between standards - especially those routed within > a particular industry and standards organization. Folks in the printer > industry have been active in defining and deploying solutions based on > Internet Standards, and I don't think we're unique in potentially having > overloaded some. As application and management standards evolve, it is > reasonable for controlling bodies, like the IETF, to project a clearer > picture of the purpose and relationship between standards. But, this > needs to be done in an atmosphere which acknowledges and, if possible, > accommodates this evolution and the resulting current state of affairs. > > Thanks, again, for helping disseminate an accurate view of the IEGS's > stance on these issues. > > Harry Lewis > From bwagner at digprod.com Wed Aug 20 13:00:22 1997 From: bwagner at digprod.com (Bill Wagner) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: PMP> IETF concerns regarding the Printer MIB In-Reply-To: Re: PMP> IETF concerns regarding the Printer MIB> Message-ID: <5030300008748293000002L032*@MHS> The message from Harald Tveit Alvestrand suggests that his recommendation to not make the JOB Monitoring MIB standards track might be based on a misunderstanding that the JMM is "a means of users' access to information (as opposed to an administrator's access)." SNMP for users rather than administrators apparently is a point of contention. However, I understand that the major purpose of the JMM is administrator and administration agent access to printer utilization information. Indeed, the inherent inappropriateness of SNMP for extensive end user access would suggest that the JMM would be used by an administrative agent for traffic monitoring and accounting purposes and that the information may be relayed to the end user via something like SENSE or the IBM or HP SNMP/HTTP capabilities. However, another point implicit in the recommendation is that an industry might know more about the needs of their product and their customers than the IETF/IESG. There may be some merit in this. Bill Wagner, Osicom/DPI ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Re: PMP> IETF concerns regarding the Printer MIB dr Author: Harry Lewis at Internet Date: 8/20/97 11:37 AM Chris and Lloyd... I'm sure you would have informed the JMP promptly had there been clear signals from the IESG. No doubt in my mind! >If a clear decision had been made and communicated to us, we >would certainly have forwarded it to the jmp list promptly. >It is not productive to guess, speculate, and communicate >partial information to the list that would just get people >anxious and confused and turn out to be wrong in the final >analysis. Given where we are, however, does it seem at all feasible that we could be considered "chartered" and, if not, what do we do now? My interpretation of the IESG comments is that the authors should submit an informational RFC describing the Job MIB and the PWG should maintain the standard. This would be the first "PWG standard". Is the PWG ready for this? Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed Aug 20 18:09:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> MOD - document-format-supported using MIME types and Message-ID: <9708202212.AA16790@zazen.cp10.es.xerox.com> We had an IPP telecon today and discussed the issue of changing IPP from using Printer MIB enums for document-format to using MIME-types. Attending: Steve Zilles, Ira McDonald, Lee Farrell, Roger deBry, Tom Hastings I took the action item to write up the discussion on this point. A problem that Don brought up in the e-mail was that we would have trouble registering a MIME-type for the Printer MIB langAutomatic enum: langAutomatic(37), -- Automatic PDL sensing. Automatic -- sensing of the interpreter -- language family by the printer -- examining the document content. -- Which actual interpreter language -- families are sensed depends on -- the printer implementation. The solution that we came up with today for IPP is to add a Printer attribute called: "document-formats-detected" (or "document-formats-auto-sensed"?). This new IPP attribute solves two problems: 1. it would eliminate the need to register an equivalent langAutomatic MIME type which would probably be refused 2. we make it clear to the client which of the document-formats-supported can be auto-sensed. Some implementations support more document-formats than can be automatically sensed. For example, some implementation support PostScript, PJL, and some document format that cannot be reliabilbly sensed. The "document-formats-detected" Printer attribute would be multi-valued that parallels the "document-formats-supporter Printer attribute and has a value for each of the values of the "document-formats-supported" Printer attribute. Each value would be a keyword that indicates whether the corresponding document format is auto-sensed or not. Perhaps, we can even have more than two keyword values depending on the degree or reliability that the PDL can be sensed. The keyword values might be: 'auto-detected' 'auto-detectedd-best-effort' 'not-auto-detected' or using the Printer MIB terminology of 'sense', insted of 'detect': 'auto-sensed' 'auto-sensed-best-effort' 'not-auto-sensed' Alternatively, the same values could indicate whether the client needs to supply the "document-format" attribute when submitting each document or not, so that the following keyword values might be better names for the corresponding semantics: 'document-format-not-required' 'document-format-recommended' 'document-format-required' Job Monitoring MIB ------------------ The Job Monitoring MIB has both representations for document format, so we'll certainly leave the Job Monitoring MIB with both Printer enum and MIME-type. Printer MIB ----------- We also discussed the suggestion from Munich that the Printer MIB should add a new object to contain the MIME-type that corresponds to the interpreter language. There was support for having BOTH the current enum and the MIME-type and the both are useful. For example, the Printer MIB still needs to indicate langAutomatic(37), since we would not be adding the equivalent of the IPP "document-formats-detected" to the MIB. For interpreter table entries that indicate langAutomatic(37), the corresponding MIME-type name would be a zero-length string. So we would reject the suggestion to make the prtInterpreterLangFamily object obsolete. We even can give the above reason not to deprecate it. Comments? Tom From rbergma at dpc.com Wed Aug 20 19:59:11 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: <9708191911.AA16333@zazen.cp10.es.xerox.com> Message-ID: <9708202212.AA16790@zazen.cp10.es.xerox.com> We need to get the following issues resolved ASAP. I am requesting anyone involved with the Job MIB, please comment immediately if you have an opinion for either position on these issues. None of these issues are of any technical consequence and I will agree with the majority vote. All issues are only editorial but should result in a cleaner and more readable document. The original comments were submitted by me (Ron Bergman) with respect to the version 0.83 document and were not included in the 0.84 issue. Tom has included his reasons for not including these comments followed by my rebuttal. Ron Bergman On Tue, 19 Aug 1997, Tom Hastings wrote: > At 17:46 08/12/97 PDT, Ron Bergman wrote: > >Tom, > > > >The following editorial corrections from revision 0.83 were not > >incorporated into version 0.84. Please comment if there is a > >reason that these should not be incorporated. > > I'm sorry that I didn't have time to respond before as to why I did not > include these (few) editorial comments. See if you agree with my reasoning > for not including them. I did include 99% of your suggestions and they > improved the document. > > > I do not believe > >that any of the corrections change the intent of the document. > > I agree that none of your corrections changed the intent of the document, > including these few that I did not include. > > > > > > >Problems from 0.83: > > > >1. Section 2. Terminology and Job Model (page 14) states: > > > > "PJL systems use the term job to mean what we call a job in this > > specification. PJL also supports multiple documents per job, but > > does not support specifying per-document attributes independently > > for each document." > > > > This text should be a part of the mapping document. This additional > > example does not provide any additional help in understanding the > > subject paragraph. > > I disagree. I think that it is important to understand the terms that > the Job Monitoring MIB is using and to have an example mapping on this > term. I also didn't want to include only the PostScript example. It seems > more even handed to keep both examples to show that the mapping varies > depending on the job submission protocol. > This subject is not difficult to understand and I would argue that no examples are required. (All you are stating is that the definitions are being locked down in this section.) The PJL example is much too deep and really belongs in the mapping document. I do not see where the PJL example provides any additional explaination as to why we need the definitions. > > > >2. The definitions in section 2 should begin with a capital letter. > > Example: "Job Set: A group of jobs..." > > I agree and both the .doc and .txt files have "Job Set", not "job set". > None of the definitions themselves start with a capital letter, so I assume > that you are not talking about "A group of jobs...", as opposed to "a group of > jobs..." > My comment was the latter. I always believed that sentences should start with a capital letter. > > > >3. The definition for "Device" (page 14): > > > > "...interfaces to humans in human perceptible means, such as produces > > marks on paper, scans marks on paper to produce an electronic > > representations, or writes CD_ROMS..." > > > > The second two examples don't appear to be human perceptible. I am > > not sure I understand the reason for including other than the first > > example. > > It is important to clarify that the device can produce other forms of > human perciptable output than just printing devices, as we agreed in > the requirements document. So I left these other examples in. > How is scaning marks on paper or writing a CD ROM human perceptible? The only way you know for sure the operation was completed (or even started) was a message on display or a printer. > > > >4. In jmGeneralJobPersistence (page #75), the second paragraph: > > > > "Depending on implementation, the value of this object MAY be > > either: (1) set by the system administrator by means outside > > this specification or (2) fixed by the implementation." > > > > Since this is a read only object do we need to define how it is > > configured? We only need to describe the function. Suggest: > > > > "Configuration of this parameter is implementation dependent." > > I think that it helps to clarify that there are several ways that > an implementation can set the value, so I left in both ways. > Ok, then who does this help? If I say implementation dependent, the designer can devise any method he desires. If you feel this info is really important, it should go into the FAQ. The specification should only contain the requirements and restrictions. Helpful hints, unless not obvious to the average developer, should be in the FAQ. In this case, the alternatives are obvious. > > > >5. For jmGeneralAttributePersistence (page #76) the above comment > > also applies. > > I left both in for the same reason. > > > > >6. In jmJobStateReasons1 (page #81), I find the following statement > > hard to disagree with, but why do we need to state this? > > > > "Furthermore, when implemented as with any MIB data, the > > agent SHALL return these values when the reason applies and > > SHALL NOT return them when the reason no longer applies whether > > the value of the job's jmJobState object changed or not." > > > > All this really states is that the value of an object must be valid. > > We do not have a similar statement for any other object. > > I disagree. One commentor asked whether the bits had to be turned off or not, > so I felt it was important to clarify that these bits are meaningful while > the job is in each job state, not just when the job transitions from one > state to another. There are hardware implementations in which such bits > are only meaningful on the state transitions. As far as I'm concerned, > if someone asks about something it can't hurt to include the explanation > in the document. There will be others who will ask the same question, but > we won't be there to answer. > Since the question was asked, this should be in the FAQ and not in the specification. All this sentence states is "thou shall not lie". If the document states that this attribute indicates this condition and the implementation sets the attribute when the condition is not true, the implementation is violating the specification! I do not believe that the document should answer every question that was asked. That is why we should have a FAQ. > > > >7. Also in jmJobStateReasons1 (page #81), the next sentence: > > > > "When > > the job does not have any reasons for being in its current > > state, the agent SHALL set the value of the jmJobStateReasons1 > > object and jobStateReasonsN attributes to 0." > > > > I suggest it be reworded to: > > > > "When the agent cannot provide a reason for the current > > state of the job, the value of jmJobStateReasons1 object > > and jobStateReasonsN attributes shall be 0." > > > > I had taken your suggestion in V0.84, but kept it in the active voice: > > When the agent cannot provide a reason for the current state of the > job, the agent SHALL set the value of the jmJobStateReasons1 > object and jobStateReasonsN attributes to 0." > > I have tried hard to avoid the passive voice, since there are many entities > in the system that do things: the agent, the device, the server, > the management app, etc. So I indicated that is the agent that sets > the values to 0. > Actually I prefer the passive voice since it may not be the agent that sets the value. The agent may just collect the information from the printer controller and pass it to the SNMP agent. > > > > > > Ron Bergman > > Dataproducts Corp. > > > > So I hope you agree that all of your editorial suggestions are closed. > > Thanks, > Tom > > From Harald.T.Alvestrand at uninett.no Thu Aug 21 03:32:35 1997 From: Harald.T.Alvestrand at uninett.no (Harald.T.Alvestrand@uninett.no) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: IPP> MOD - document-format-supported using MIME types and In-Reply-To: MOD - document-format-supported using MIME types and> Message-ID: <9708202212.AA16790@zazen.cp10.es.xerox.com> The langAutomatic doesn't have to be a MIME type, necessarily. If you want to, you can define an "application/printable", but just saying that it's legal to ship "application/octet-stream" to a printer and let the printer figure out what to do with it would work just as well. In E-mail currently, application/octet-stream is used heavily to ship documents in "let the recipient figure it out" mode. Harald A From jkm at underscore.com Thu Aug 21 14:21:39 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: Open Editorial Changes From Rev. 0.83> Message-ID: <199708211821.OAA23388@uscore.underscore.com> After very carefully reading Ron Bergman's message, I find myself agreeing with Ron pretty much up and down the line. Quick comments: - I like Ron's proposed wording in every single case; I find the Job MIB tends to read more like a legal contract than a useful specification. Sorry, but the comments about "active voice" are just not all that useful, given that Ron's sentence is far cleaner and completely unambiguous. (I mean, who cares that you call out the agent versus something else?? If a value is supposed to be 0, then IT IS ZERO, regardless of who sets it or receives it.) - Ron's insistence on moving certain examples to the "mapping section" of the document is also right on track. I find the PCL "example" only marginally useful and not worth the many words used to describe it. If words exist in the main body of the spec, then the reader will be compelled to carefully read and evaluate them; if those words exist only to "clarify" a rather nitty point, then the reader grows quite weary and distracted. This is Not Good. Move all such stuff to the mapping section. - I found the interchange on "human perceptibility" to be totally bizarre. (At first I thought it was some kind of joke.) Get rid of it! This is the Job MIB for heaven's sake, and not some treatise on a cure for cancer, or a discourse on human strife and suffering. Keep it SIMPLE. - A FAQ is always, ALWAYS an excellent addition to any specification, and we should try to move things to the FAQ whenever possible, IMHO. I like Ron's suggestions in this area, and strongly suggest adopting his suggestions. Ron had asked for opinions. ;-) I must say, however, to the JMP group at large: I am totally appalled by this situation. The MIB Editor is supposed to maintain the document according to group consensus, and such consensus is managed by the project chairperson, based on open dialog on the JMP mailing list. I thought everyone was aware of these "rules" of conduct within the PWG (as "borrowed" from the essential rules of IETF working groups). The fact that the JMP MIB Editor made a number of unilateral decisions on the document--and then posted the document without first responding to Ron's editorial proposals--is TOTALLY unacceptable. The fact that Ron Bergman is the JMP Chairperson makes the situation even more unacceptable, especially since Ron has done such a fine job in eagle-eyeing the document all along. I trust this kind of situation does not happen in the future, because if it does, we'd be wise to appoint a new MIB Editor. Yes, I realize these are harsh words, but this is a completely UNACCEPTABLE situation that should never have happened in the first place. ...jay From hastings at cp10.es.xerox.com Fri Aug 22 08:00:12 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Job MIB schedule Message-ID: <9708221202.AA17233@zazen.cp10.es.xerox.com> I just finished the editing and compiling. I tried to upload it and could get no response from the PWG server. I left a phone message. I'll try again later today. I updated the issues list as well to show the changes. A telecon this coming Tuesday is probably a little soon. Sorry I missed last Friday's deadline. Tom >Return-Path: >From: Harry Lewis >To: >Cc: >Subject: Job MIB schedule >Date: Thu, 21 Aug 1997 08:30:21 PDT > >Tom, I know you must be real busy. I'm just wondering, however, what will >become of the schedule we laid out in Redmond which said v0.85 on 8/15, >comments by 8/22, telecon 8/26, v0.86 by 8/29 and 9/6 editorial closure. > >Harry Lewis - IBM Printing Systems > > From jds at underscore.com Fri Aug 22 10:55:14 1997 From: jds at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:00:09 2009 Subject: JMP> Job MIB schedule In-Reply-To: Job MIB schedule> Message-ID: <9708221202.AA17233@zazen.cp10.es.xerox.com> Tom Hastings wrote: > > I just finished the editing and compiling. I tried to upload it > and could get no response from the PWG server. I left a phone > message. > Tom, The mail log shows that your message got through to the PWG server one minute and thirty four seconds after you sent it. The FTP log shows successful access throughout the night (from Japan) and this morning (Denmark and the U.S.). The problem was/is probably with the Xerox firewall. Note that your mail got thru effectively immediately. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From harryl at us.ibm.com Fri Aug 22 12:16:45 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline Message-ID: <5030300008930690000002L002*@MHS> BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons 2 to job state reasons 1 as we agreed to use this reason to distinguish a CANCEL state where sheets might still be cleared from the paper path from a CANCEL operation that has completed. PROBLEM -- In prototyping, we find one other job state reason which we feel is useful enough to be migrated into the (mandatory) job state reasons 1 category. This reason is serviceOffLine. CLARIFICATION -- First, I am seeking agreement from the JMP that using job state reason serviceOffLine is valid when the printer is off-line. (I know... we usually get really tied up whenever the word off-line is used in conversation). If so, do you agree that Off-line is a common, likely or significant enough condition to warrant becoming part of the "reasons 1" group. PROPOSAL -- I'd like to propose this simple change be added to Tom's pending draft, if possible, so I'm asking for discussion and straw poll (assuming the Chair deems this appropriate). Thanks. Harry Lewis - IBM Printing Systems From jkm at underscore.com Fri Aug 22 12:21:29 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: serviceOffline> Message-ID: <199708221621.MAA28093@uscore.underscore.com> Declaring serviceOffline as a mandatory reason is very appropriate, IMHO. While I always despise the word "offline", there's just no getting away from it. :-( So, we should probably be consistent (rather than accurate) and continue this trend in nomenclature. Let's go for it. Thanks for discovering this situation, Harry. ...jay ----- Begin Included Message ----- From: Harry Lewis To: Cc: , Subject: JMP> serviceOffline Date: Fri, 22 Aug 1997 12:16:45 -0400 BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons 2 to job state reasons 1 as we agreed to use this reason to distinguish a CANCEL state where sheets might still be cleared from the paper path from a CANCEL operation that has completed. PROBLEM -- In prototyping, we find one other job state reason which we feel is useful enough to be migrated into the (mandatory) job state reasons 1 category. This reason is serviceOffLine. CLARIFICATION -- First, I am seeking agreement from the JMP that using job state reason serviceOffLine is valid when the printer is off-line. (I know... we usually get really tied up whenever the word off-line is used in conversation). If so, do you agree that Off-line is a common, likely or significant enough condition to warrant becoming part of the "reasons 1" group. PROPOSAL -- I'd like to propose this simple change be added to Tom's pending draft, if possible, so I'm asking for discussion and straw poll (assuming the Chair deems this appropriate). Thanks. Harry Lewis - IBM Printing Systems ----- End Included Message ----- From rbergma at dpc.com Fri Aug 22 19:28:33 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: Message-ID: <199708221621.MAA28093@uscore.underscore.com> I have received only one response regarding the following proposal. If anyone objects please reply immediately, otherwise the following will be incorporated into the document. (No reply indicates acceptance.) Ron Bergman On Wed, 20 Aug 1997, Ron Bergman wrote: > We need to get the following issues resolved ASAP. I am requesting > anyone involved with the Job MIB, please comment immediately if you > have an opinion for either position on these issues. > > None of these issues are of any technical consequence and I will > agree with the majority vote. All issues are only editorial but > should result in a cleaner and more readable document. > > The original comments were submitted by me (Ron Bergman) with > respect to the version 0.83 document and were not included in the > 0.84 issue. Tom has included his reasons for not including these > comments followed by my rebuttal. > > Ron Bergman > > > On Tue, 19 Aug 1997, Tom Hastings wrote: > > > At 17:46 08/12/97 PDT, Ron Bergman wrote: > > >Tom, > > > > > >The following editorial corrections from revision 0.83 were not > > >incorporated into version 0.84. Please comment if there is a > > >reason that these should not be incorporated. > > > > I'm sorry that I didn't have time to respond before as to why I did not > > include these (few) editorial comments. See if you agree with my reasoning > > for not including them. I did include 99% of your suggestions and they > > improved the document. > > > > > I do not believe > > >that any of the corrections change the intent of the document. > > > > I agree that none of your corrections changed the intent of the document, > > including these few that I did not include. > > > > > > > > > > >Problems from 0.83: > > > > > >1. Section 2. Terminology and Job Model (page 14) states: > > > > > > "PJL systems use the term job to mean what we call a job in this > > > specification. PJL also supports multiple documents per job, but > > > does not support specifying per-document attributes independently > > > for each document." > > > > > > This text should be a part of the mapping document. This additional > > > example does not provide any additional help in understanding the > > > subject paragraph. > > > > I disagree. I think that it is important to understand the terms that > > the Job Monitoring MIB is using and to have an example mapping on this > > term. I also didn't want to include only the PostScript example. It seems > > more even handed to keep both examples to show that the mapping varies > > depending on the job submission protocol. > > > This subject is not difficult to understand and I would argue that no > examples are required. (All you are stating is that the definitions > are being locked down in this section.) The PJL example is much too > deep and really belongs in the mapping document. I do not see where > the PJL example provides any additional explaination as to why we > need the definitions. > > > > > >2. The definitions in section 2 should begin with a capital letter. > > > Example: "Job Set: A group of jobs..." > > > > I agree and both the .doc and .txt files have "Job Set", not "job set". > > None of the definitions themselves start with a capital letter, so I assume > > that you are not talking about "A group of jobs...", as opposed to "a group of > > jobs..." > > > My comment was the latter. I always believed that sentences should > start with a capital letter. > > > > > >3. The definition for "Device" (page 14): > > > > > > "...interfaces to humans in human perceptible means, such as produces > > > marks on paper, scans marks on paper to produce an electronic > > > representations, or writes CD_ROMS..." > > > > > > The second two examples don't appear to be human perceptible. I am > > > not sure I understand the reason for including other than the first > > > example. > > > > It is important to clarify that the device can produce other forms of > > human perciptable output than just printing devices, as we agreed in > > the requirements document. So I left these other examples in. > > > How is scaning marks on paper or writing a CD ROM human perceptible? > The only way you know for sure the operation was completed (or even > started) was a message on display or a printer. > > > > > >4. In jmGeneralJobPersistence (page #75), the second paragraph: > > > > > > "Depending on implementation, the value of this object MAY be > > > either: (1) set by the system administrator by means outside > > > this specification or (2) fixed by the implementation." > > > > > > Since this is a read only object do we need to define how it is > > > configured? We only need to describe the function. Suggest: > > > > > > "Configuration of this parameter is implementation dependent." > > > > I think that it helps to clarify that there are several ways that > > an implementation can set the value, so I left in both ways. > > > Ok, then who does this help? If I say implementation dependent, the > designer can devise any method he desires. If you feel this info > is really important, it should go into the FAQ. The specification > should only contain the requirements and restrictions. Helpful > hints, unless not obvious to the average developer, should be in the > FAQ. In this case, the alternatives are obvious. > > > > > >5. For jmGeneralAttributePersistence (page #76) the above comment > > > also applies. > > > > I left both in for the same reason. > > > > > > > >6. In jmJobStateReasons1 (page #81), I find the following statement > > > hard to disagree with, but why do we need to state this? > > > > > > "Furthermore, when implemented as with any MIB data, the > > > agent SHALL return these values when the reason applies and > > > SHALL NOT return them when the reason no longer applies whether > > > the value of the job's jmJobState object changed or not." > > > > > > All this really states is that the value of an object must be valid. > > > We do not have a similar statement for any other object. > > > > I disagree. One commentor asked whether the bits had to be turned off or not, > > so I felt it was important to clarify that these bits are meaningful while > > the job is in each job state, not just when the job transitions from one > > state to another. There are hardware implementations in which such bits > > are only meaningful on the state transitions. As far as I'm concerned, > > if someone asks about something it can't hurt to include the explanation > > in the document. There will be others who will ask the same question, but > > we won't be there to answer. > > > Since the question was asked, this should be in the FAQ and not in the > specification. All this sentence states is "thou shall not lie". If > the document states that this attribute indicates this condition and > the implementation sets the attribute when the condition is not true, > the implementation is violating the specification! I do not believe > that the document should answer every question that was asked. That > is why we should have a FAQ. > > > > > >7. Also in jmJobStateReasons1 (page #81), the next sentence: > > > > > > "When > > > the job does not have any reasons for being in its current > > > state, the agent SHALL set the value of the jmJobStateReasons1 > > > object and jobStateReasonsN attributes to 0." > > > > > > I suggest it be reworded to: > > > > > > "When the agent cannot provide a reason for the current > > > state of the job, the value of jmJobStateReasons1 object > > > and jobStateReasonsN attributes shall be 0." > > > > > > > I had taken your suggestion in V0.84, but kept it in the active voice: > > > > When the agent cannot provide a reason for the current state of the > > job, the agent SHALL set the value of the jmJobStateReasons1 > > object and jobStateReasonsN attributes to 0." > > > > I have tried hard to avoid the passive voice, since there are many entities > > in the system that do things: the agent, the device, the server, > > the management app, etc. So I indicated that is the agent that sets > > the values to 0. > > > Actually I prefer the passive voice since it may not be the agent that > sets the value. The agent may just collect the information from the > printer controller and pass it to the SNMP agent. > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > So I hope you agree that all of your editorial suggestions are closed. > > > > Thanks, > > Tom > > > > > > From rbergma at dpc.com Fri Aug 22 19:24:05 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: <5030300008930690000002L002*@MHS> Message-ID: <199708221621.MAA28093@uscore.underscore.com> Harry, I support your proposal. There appears to be bits available for this change. If anyone objects, please respond asap so this issue can be closed. Ron Bergman On Fri, 22 Aug 1997, Harry Lewis wrote: > BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons > 2 to job state reasons 1 as we agreed to use this reason to distinguish a > CANCEL state where sheets might still be cleared from the paper path from a > CANCEL operation that has completed. > > PROBLEM -- In prototyping, we find one other job state reason which we feel is > useful enough to be migrated into the (mandatory) job state reasons 1 category. > This reason is serviceOffLine. > > CLARIFICATION -- First, I am seeking agreement from the JMP that using job > state reason serviceOffLine is valid when the printer is off-line. (I know... > we usually get really tied up whenever the word off-line is used in > conversation). If so, do you agree that Off-line is a common, likely or > significant enough condition to warrant becoming part of the "reasons 1" group. > > PROPOSAL -- I'd like to propose this simple change be added to Tom's pending > draft, if possible, so I'm asking for discussion and straw poll (assuming the > Chair deems this appropriate). > > Thanks. > > Harry Lewis - IBM Printing Systems > From rbergma at dpc.com Fri Aug 22 20:00:43 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: (no subject) Message-ID: <199708221621.MAA28093@uscore.underscore.com> Tom, I looked for the new Job MIB document and could not find it anywhere on the server. When will it be available, or did I not look in the right place? Ron Bergman From STUART at KEI-CA.CCMAIL.compuserve.com Mon Aug 25 11:51:47 1997 From: STUART at KEI-CA.CCMAIL.compuserve.com (STUART@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: serviceOffline> Message-ID: <199708221621.MAA28093@uscore.underscore.com> Harry, I personally think that deviceStopped is sufficient to cover all printer stoppage conditions including off-line. So I don't think it is necessary to move serviceOffline. Also, if serviceOffline means that the printer is off-line, it is well disguised in the DPA-ish description which I put for reference below. serviceOffline The service/document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This could be true if its input is impaired or broken. Stuart --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 STUART@KEI-CA.ccmail.compuserve.com Lafayette, CA 94549 510 299-7206 Fax: 510 299-2489 --------------------------------------------------------------------- ______________________________ Reply Separator _________________________________ Subject: JMP> serviceOffline Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 8/22/97 12:15 PM BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons 2 to job state reasons 1 as we agreed to use this reason to distinguish a CANCEL state where sheets might still be cleared from the paper path from a CANCEL operation that has completed. PROBLEM -- In prototyping, we find one other job state reason which we feel is useful enough to be migrated into the (mandatory) job state reasons 1 category. This reason is serviceOffLine. CLARIFICATION -- First, I am seeking agreement from the JMP that using job state reason serviceOffLine is valid when the printer is off-line. (I know... we usually get really tied up whenever the word off-line is used in conversation). If so, do you agree that Off-line is a common, likely or significant enough condition to warrant becoming part of the "reasons 1" group. PROPOSAL -- I'd like to propose this simple change be added to Tom's pending draft, if possible, so I'm asking for discussion and straw poll (assuming the Chair deems this appropriate). Thanks. Harry Lewis - IBM Printing Systems From STUART at KEI-CA.CCMAIL.compuserve.com Mon Aug 25 11:51:47 1997 From: STUART at KEI-CA.CCMAIL.compuserve.com (STUART@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: serviceOffline> Message-ID: <199708221621.MAA28093@uscore.underscore.com> Harry, I personally think that deviceStopped is sufficient to cover all printer stoppage conditions including off-line. So I don't think it is necessary to move serviceOffline. Also, if serviceOffline means that the printer is off-line, it is well disguised in the DPA-ish description which I put for reference below. serviceOffline The service/document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This could be true if its input is impaired or broken. Stuart --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 STUART@KEI-CA.ccmail.compuserve.com Lafayette, CA 94549 510 299-7206 Fax: 510 299-2489 --------------------------------------------------------------------- ______________________________ Reply Separator _________________________________ Subject: JMP> serviceOffline Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 8/22/97 12:15 PM BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons 2 to job state reasons 1 as we agreed to use this reason to distinguish a CANCEL state where sheets might still be cleared from the paper path from a CANCEL operation that has completed. PROBLEM -- In prototyping, we find one other job state reason which we feel is useful enough to be migrated into the (mandatory) job state reasons 1 category. This reason is serviceOffLine. CLARIFICATION -- First, I am seeking agreement from the JMP that using job state reason serviceOffLine is valid when the printer is off-line. (I know... we usually get really tied up whenever the word off-line is used in conversation). If so, do you agree that Off-line is a common, likely or significant enough condition to warrant becoming part of the "reasons 1" group. PROPOSAL -- I'd like to propose this simple change be added to Tom's pending draft, if possible, so I'm asking for discussion and straw poll (assuming the Chair deems this appropriate). Thanks. Harry Lewis - IBM Printing Systems From STUART at KEI-CA.CCMAIL.CompuServe.COM Mon Aug 25 11:51:49 1997 From: STUART at KEI-CA.CCMAIL.CompuServe.COM (STUART@KEI-CA.CCMAIL.CompuServe.COM) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: serviceOffline> Message-ID: <199708221621.MAA28093@uscore.underscore.com> Harry, I personally think that deviceStopped is sufficient to cover all printer stoppage conditions including off-line. So I don't think it is necessary to move serviceOffline. Also, if serviceOffline means that the printer is off-line, it is well disguised in the DPA-ish description which I put for reference below. serviceOffline The service/document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This could be true if its input is impaired or broken. Stuart --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 STUART@KEI-CA.ccmail.compuserve.com Lafayette, CA 94549 510 299-7206 Fax: 510 299-2489 --------------------------------------------------------------------- ______________________________ Reply Separator _________________________________ Subject: JMP> serviceOffline Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 8/22/97 12:15 PM BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons 2 to job state reasons 1 as we agreed to use this reason to distinguish a CANCEL state where sheets might still be cleared from the paper path from a CANCEL operation that has completed. PROBLEM -- In prototyping, we find one other job state reason which we feel is useful enough to be migrated into the (mandatory) job state reasons 1 category. This reason is serviceOffLine. CLARIFICATION -- First, I am seeking agreement from the JMP that using job state reason serviceOffLine is valid when the printer is off-line. (I know... we usually get really tied up whenever the word off-line is used in conversation). If so, do you agree that Off-line is a common, likely or significant enough condition to warrant becoming part of the "reasons 1" group. PROPOSAL -- I'd like to propose this simple change be added to Tom's pending draft, if possible, so I'm asking for discussion and straw poll (assuming the Chair deems this appropriate). Thanks. Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon Aug 25 15:38:14 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: Open Editorial Changes From Rev. 0.83> Message-ID: <5030300009105717000002L072*@MHS> Ron, I, for one, have printed your issues list but have not had the opportunity to review it. I did not seem to be able to make determinations "on line". There lots of "embedded" statements and the issues appear to have more depth than one would expect for purely editorial comments. I would like another day or two. The fact that there seems to be little conversation on these items implies they must be OK or else others are in the same boat as me. Harry Lewis - IBM Printing Systems -------- Forwarded by Harry Lewis/Boulder/IBM on 08/25/97 01:27 PM --------- jmp-owner@pwg.org on 08/23/97 04:21:19 AM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: Re: JMP> Open Editorial Changes From Rev. 0.83 I have received only one response regarding the following proposal. If anyone objects please reply immediately, otherwise the following will be incorporated into the document. (No reply indicates acceptance.) Ron Bergman On Wed, 20 Aug 1997, Ron Bergman wrote: > We need to get the following issues resolved ASAP. I am requesting > anyone involved with the Job MIB, please comment immediately if you > have an opinion for either position on these issues. > > None of these issues are of any technical consequence and I will > agree with the majority vote. All issues are only editorial but > should result in a cleaner and more readable document. > > The original comments were submitted by me (Ron Bergman) with > respect to the version 0.83 document and were not included in the > 0.84 issue. Tom has included his reasons for not including these > comments followed by my rebuttal. > > Ron Bergman > > > On Tue, 19 Aug 1997, Tom Hastings wrote: > > > At 17:46 08/12/97 PDT, Ron Bergman wrote: > > >Tom, > > > > > >The following editorial corrections from revision 0.83 were not > > >incorporated into version 0.84. Please comment if there is a > > >reason that these should not be incorporated. > > > > I'm sorry that I didn't have time to respond before as to why I did not > > include these (few) editorial comments. See if you agree with my reasoning > > for not including them. I did include 99% of your suggestions and they > > improved the document. > > > > > I do not believe > > >that any of the corrections change the intent of the document. > > > > I agree that none of your corrections changed the intent of the document, > > including these few that I did not include. > > > > > > > > > > >Problems from 0.83: > > > > > >1. Section 2. Terminology and Job Model (page 14) states: > > > > > > "PJL systems use the term job to mean what we call a job in this > > > specification. PJL also supports multiple documents per job, but > > > does not support specifying per-document attributes independently > > > for each document." > > > > > > This text should be a part of the mapping document. This additional > > > example does not provide any additional help in understanding the > > > subject paragraph. > > > > I disagree. I think that it is important to understand the terms that > > the Job Monitoring MIB is using and to have an example mapping on this > > term. I also didn't want to include only the PostScript example. It seems > > more even handed to keep both examples to show that the mapping varies > > depending on the job submission protocol. > > > This subject is not difficult to understand and I would argue that no > examples are required. (All you are stating is that the definitions > are being locked down in this section.) The PJL example is much too > deep and really belongs in the mapping document. I do not see where > the PJL example provides any additional explaination as to why we > need the definitions. > > > > > >2. The definitions in section 2 should begin with a capital letter. > > > Example: "Job Set: A group of jobs..." > > > > I agree and both the .doc and .txt files have "Job Set", not "job set". > > None of the definitions themselves start with a capital letter, so I assume > > that you are not talking about "A group of jobs...", as opposed to "a group of > > jobs..." > > > My comment was the latter. I always believed that sentences should > start with a capital letter. > > > > > >3. The definition for "Device" (page 14): > > > > > > "...interfaces to humans in human perceptible means, such as produces > > > marks on paper, scans marks on paper to produce an electronic > > > representations, or writes CD_ROMS..." > > > > > > The second two examples don't appear to be human perceptible. I am > > > not sure I understand the reason for including other than the first > > > example. > > > > It is important to clarify that the device can produce other forms of > > human perciptable output than just printing devices, as we agreed in > > the requirements document. So I left these other examples in. > > > How is scaning marks on paper or writing a CD ROM human perceptible? > The only way you know for sure the operation was completed (or even > started) was a message on display or a printer. > > > > > >4. In jmGeneralJobPersistence (page #75), the second paragraph: > > > > > > "Depending on implementation, the value of this object MAY be > > > either: (1) set by the system administrator by means outside > > > this specification or (2) fixed by the implementation." > > > > > > Since this is a read only object do we need to define how it is > > > configured? We only need to describe the function. Suggest: > > > > > > "Configuration of this parameter is implementation dependent." > > > > I think that it helps to clarify that there are several ways that > > an implementation can set the value, so I left in both ways. > > > Ok, then who does this help? If I say implementation dependent, the > designer can devise any method he desires. If you feel this info > is really important, it should go into the FAQ. The specification > should only contain the requirements and restrictions. Helpful > hints, unless not obvious to the average developer, should be in the > FAQ. In this case, the alternatives are obvious. > > > > > >5. For jmGeneralAttributePersistence (page #76) the above comment > > > also applies. > > > > I left both in for the same reason. > > > > > > > >6. In jmJobStateReasons1 (page #81), I find the following statement > > > hard to disagree with, but why do we need to state this? > > > > > > "Furthermore, when implemented as with any MIB data, the > > > agent SHALL return these values when the reason applies and > > > SHALL NOT return them when the reason no longer applies whether > > > the value of the job's jmJobState object changed or not." > > > > > > All this really states is that the value of an object must be valid. > > > We do not have a similar statement for any other object. > > > > I disagree. One commentor asked whether the bits had to be turned off or not, > > so I felt it was important to clarify that these bits are meaningful while > > the job is in each job state, not just when the job transitions from one > > state to another. There are hardware implementations in which such bits > > are only meaningful on the state transitions. As far as I'm concerned, > > if someone asks about something it can't hurt to include the explanation > > in the document. There will be others who will ask the same question, but > > we won't be there to answer. > > > Since the question was asked, this should be in the FAQ and not in the > specification. All this sentence states is "thou shall not lie". If > the document states that this attribute indicates this condition and > the implementation sets the attribute when the condition is not true, > the implementation is violating the specification! I do not believe > that the document should answer every question that was asked. That > is why we should have a FAQ. > > > > > >7. Also in jmJobStateReasons1 (page #81), the next sentence: > > > > > > "When > > > the job does not have any reasons for being in its current > > > state, the agent SHALL set the value of the jmJobStateReasons1 > > > object and jobStateReasonsN attributes to 0." > > > > > > I suggest it be reworded to: > > > > > > "When the agent cannot provide a reason for the current > > > state of the job, the value of jmJobStateReasons1 object > > > and jobStateReasonsN attributes shall be 0." > > > > > > > I had taken your suggestion in V0.84, but kept it in the active voice: > > > > When the agent cannot provide a reason for the current state of the > > job, the agent SHALL set the value of the jmJobStateReasons1 > > object and jobStateReasonsN attributes to 0." > > > > I have tried hard to avoid the passive voice, since there are many entities > > in the system that do things: the agent, the device, the server, > > the management app, etc. So I indicated that is the agent that sets > > the values to 0. > > > Actually I prefer the passive voice since it may not be the agent that > sets the value. The agent may just collect the information from the > printer controller and pass it to the SNMP agent. > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > So I hope you agree that all of your editorial suggestions are closed. > > > > Thanks, > > Tom > > > > > > From rbergma at dpc.com Mon Aug 25 16:05:15 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: <5030300009105717000002L072*@MHS> Message-ID: <5030300009105717000002L072*@MHS> Harry, I will close this issue then Wednesday evening. Let mw know if you will need more time. I certainly would like these items to have a good review before we close the document. ...Ron On Mon, 25 Aug 1997, Harry Lewis wrote: > Ron, I, for one, have printed your issues list but have not had the > opportunity to review it. I did not seem to be able to make determinations > "on line". There lots of "embedded" statements and the issues appear to > have more depth than one would expect for purely editorial comments. > I would like another day or two. > > The fact that there seems to be little conversation on these items > implies they must be OK or else others are in the same boat as me. > > Harry Lewis - IBM Printing Systems > > > -------- Forwarded by Harry Lewis/Boulder/IBM on 08/25/97 01:27 PM --------- > > > jmp-owner@pwg.org on 08/23/97 04:21:19 AM > Please respond to jmp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet > cc: > Subject: Re: JMP> Open Editorial Changes From Rev. 0.83 > > > I have received only one response regarding the following proposal. > If anyone objects please reply immediately, otherwise the following > will be incorporated into the document. (No reply indicates > acceptance.) > > Ron Bergman > > ...snip...snip. From hastings at cp10.es.xerox.com Mon Aug 25 20:13:09 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Version 0.85 posted and sent as an I-D Message-ID: <9708260015.AA17920@zazen.cp10.es.xerox.com> I've posted the usual files for version V0.85 which corresponds to Internet-Draft: draft-ietf-printmib-job-monitor-05.txt. Please make any comments this week or by next Tuesday, 9/2 (day after Labor Day), so we can decide whether to have a telecon later that week (or beginning of the following week). Also please do your mapping assignments. Use them as a way to review the MIB specification. Pretend you are an SNMP agent responding to a Get for each object and attribute listed in the mapping template and determine how to get that information from the job submission protocol for the service or device that your agent is providing access. ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ -rw-r--r-- 1 pwg pwg 119999 Aug 25 23:06 jmp-mib.mib -rw-r--r-- 1 pwg pwg 285892 Aug 25 23:08 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 212538 Aug 25 23:10 jmp-mib.txt -rw-r--r-- 1 pwg pwg 355840 Aug 25 23:14 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 312336 Aug 25 23:17 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 317841 Aug 25 23:19 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 8631 Aug 25 23:20 jmp.dic The jmp-mib.pdf is without revision marks and has line numbers. This is the version that JMP should make any comments against. The jmp-mib.txt == draft-ietf-printmib-job-monitor-02.txt The jmp-mibr.doc is with revision marks. The jmp-mibr.pdr is with red revision marks. The jmp-mibr.pdf is with black revision marks. The jmp-mib.mib file compiles with one warning (assignment of the temporary OID). ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 212538 Aug 26 00:01 draft-ietf-printmib-job-monitor-05.txt The issues list and the issues that we closed at the 8/8/97 JMP meeting are available: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 7177 Aug 25 23:23 issue111.txt -rw-r--r-- 1 pwg pwg 6683 Aug 25 23:23 issue112.txt -rw-r--r-- 1 pwg pwg 104448 Aug 25 23:24 issues.doc -rw-rw-r-- 1 pwg pwg 113295 Aug 25 23:25 issues.pdf -rw-r--r-- 1 pwg pwg 118819 Aug 25 23:27 issues.pdr -rw-r--r-- 1 pwg pwg 78168 Aug 25 23:28 issues.txt We closed issues 110 to 120 at the 8/6/97 meeting. The text portion of those issues is: ISSUE 110: Break jmAttributeTable into two tables: jmAttributeAsIntegerTable and jmAttributeAsOctetsTable as suggested by David Perkins? Then an application will need about half as many Get Next operations in order to "harvest" all of the attributes, since there won't be any zero-length string values for attributes that don't have strings and -1 or 1 values representing 'other' for attributes that don't have integer values. Closed: Do not divide the table into two tables. There is some benefit to walking the table in pairs even though most attributes are either integer or octet string, and not both. ISSUE 111 (restated): How does an application determine the coded character set for the objects and attributes that the agent generates (that cannot come from the job submitting client)? Raised by David Perkins. The following 3 objects and attributes are in question: jmGeneralJobSetName object processingMessage attribute physicalDevice (name value) attribute Closed: Add the JmUTF8StringTC for these three object/attributes. See separate issue111.doc .pdf. ISSUE 112 (re-stated): How does a management application determine the coded character set for the per-job objects and attributes that are returned by the agent whether submitted by the job submitting client or defaulted by the agent when the job submitting client does not supply? Raised by David Perkins. Closed: Add the JmUTF8StringTC for these objects and add a jobCodedCharSet attribute to indicate the set being used. ISSUE 113: The big concern [from the Area directors] is that from the user's perspective, jobs can be submitted via serial, parallel, or network connections, and the Job MIB is only going to know about the network connections. Raised by Chris Wellens. Closed: Add additional text to clarify that the device may be directly connected over a serial or parallel port or networked to the client and/or server. ISSUE 114: If nested jobs are sent to the printer and all have a JobSubmissionID attached, what does the agent do? When a spooler receives a job, it can put a banner page on the job by wrapping it inside of a job. When this occurs, there can be separate JobSubmissionID's for each job. In fact, if the printer doesn't find a JobSubmissionID on the outer job, it will assign one. When the printer gets to the inner job, it will get the true JobSubmissionID that was attached to the client's job. Raised by Bob 'Pentecost on 4/17/97 and re-raised by Harry Lewis on 7/16/97. Closed: Add a reference to the Appendix B where PJL use of the job submission ID is included and indicate in Appendix B that the later occurrence of a job submission ID is the one that the agent uses. The Appendix B text is: NOTE - Some PJL implementations wrap a banner page as a PJL job around a job submitted by a client. In this case, there will be two job submission ids. The outer one being the one with the banner page and the inner one being the original user's job. The agent SHALL use the last received job submission ID for the jmJobSubmissionID index, so that the original user's job submission ID will be used, not the banner page job ID. ISSUE 115: If the agent changes state to CANCEL as soon as it becomes aware of the cancel command (to satisfy the end user), there may still be a page or two in the pipeline that the accounting application would miss if it noticed the state change and performed it's data collection. So, we suggest using jobStateReasons in this case. CANCEL - processingToStopPoint which progresses to CANCEL - jobCanceledByUser The question is, since these jobStateReasons are not "mandatory", how do we communicate and agree on this recommendation? In other words, how do we achieve interoperability? Raised by Harry Lewis on 7/8/97. Closed: Move the processingToStopPoint reason from the jobStateReasons2 attribute to the jmJobStateReasons1 object immediately after abortedBySystem reason and renumber the ones following. Also recommend using processingToStopPoint reason with the aborted and canceled states. The new text is: processingToStopPoint 0x4000 The requester has issued an operation to cancel or interrupt the job or the server/device has aborted the job but the server/device is still performing some actions on the job until a specified stop point occurs or job termination/cleanup is completed. This reason is recommended to be used in conjunction with the canceled or aborted job state to indicate that the server/device is still performing some actions on the job after the job leaves the processing state, so that some of the jobs resources consumed counters may still be incrementing while the job is in the canceled or aborted job states. ISSUE 116: Delete the 'other(1)' jmJobState value? I thought we had covered all possible states with the 7 primary plus the JmJobStateReasons. Why do we need other? Did we not accomplish what was claimed?Raised by Ron Bergman on 7/28/97. Closed: delete the 'other(1)' jmJobState value. ISSUE 117: What is the difference between Toner Economy (tonerEconomyRequested and tonerEconomyUsed) and Toner Density (tonerDensityRequested and tonerDensityUsed)? (see page #51) They appear to be identical from the description (or very very close!) Raised by Ron Bergman on 7/28/97. Closed: Cut and paste error copied the explanation from one to the other. Change the tonerEconomy to say toner economy. Economy is an enum, density is a number from 1 to 100. Several printers have both, so we need both. ISSUE 118: Alignment of IPP and JMP. A job monitoring MIB agent providing access to an IPP system should be able to access the same data as is created by IPP. Lengths of text characters should be the same, not different (255 vs 63, respectively). Are there any other differences that would cause problems. See ietf-ipp.doc .pdf in protomap sub-directory. Raised by Paul Moore on 8/7/97. Closed: Leave the lengths as they are. Most real IPP implementations will not exceed the 63 length in practice. ISSUE 119: Is the new 32-bit IPP "job-identifier" now the same as the 32-bit jmJobIndex? Is the maximum range 31-bits: 1 to 2**31-1 in both? Raised by Paul Moore on 8/7/97. Closed: Clarify that the jmJobIndex is the same as the IPP "job-identifier", if IPP keeps the job-identifier. However, push back since the IPP meeting indicates that maybe this issue isn't settled. Also there was discussion that an agent that is providing access to a device that supports multiple job submission protocols, including IPP, may have a problem using the IPP "job-identifiers", unless the device also assigns the identifiers for the other job submission protocols from the same job-identifier number space. The following text has been incorporated into section 3.6: It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then the jobs will have the same job identifier value as the jmJobIndex value, so that users viewing jobs by management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. Agents providing access to systems that contain jobs with a job identifier of 0 SHALL map the job identifier value 0 to a jmJobIndex value that is one higher than the highest job identifier value that any job can have on that system. Then only job 0 will have a different job-identifier value than the job's jmJobIndex value. NOTE - If a server or device accepts jobs using multiple job submission protocols, it may be difficult for the agent to meet the recommendation to use the job-identifier values that the server or device assigns as the jmJobIndex value, unless the server/device assigns job-identifiers for each of its job submision protocols from the same job-identifier number space. ISSUE 120: The management app should be able to read an object(s) to get the number of consecutive rows in a "packed" table to put into a single Get, so as to reduce network traffic and decrease the time to get the data. What about falling off the end of the job and attribute tables? Raised by Paul Moore on 8/7/97 after having this trouble with the Printer MIB Alert table. Closed: The attribute table is by definition sparse, since the fourth index is present. For the other tables, since jobs may be canceled or aborted before completing, there can be holes in the job tables, even though we require that the jmJobIndex be assigned incrementally on job acceptance. So we can't add any objects that can help in addition to the jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex that we already have that say where to start and end. SNMP v2 solves the problem of reducing network traffic by using bulk get. ISSUE 121: jmJobKOctetesProcessed can be a multiple of jmJobKOctetsRequested, for implementations that make multiple passes over the data. However, the same difference is not specified for jmJobImpressionsComplete/jmJobImpressionsRequested objects and for pagesCompleted/pagesRequested attributes. Brought up by the JMP committee at the meeting. Closed: Make jmJobImpressionsComplete/jmJobImpressionsRequested objects and for pagesCompleted/pagesRequested attributes consistent with jmJobKOctetesProcessed/jmJobKOctetsRequested. From don at lexmark.com Tue Aug 26 10:31:44 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:09 2009 Subject: JMP> Last Reminder: September Meeting in Atlanta Message-ID: <199708261431.AA16627@interlock2.lexmark.com> --0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5 Content-type: text/plain; charset=us-ascii Don't forget to make your reservations for the Atlanta meeting. The deadline is this Friday - 8/29. While you are at it --- drop me a ping if you haven't already! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 08/26/97 10:31 AM --------------------------- Don Wright Note sent on 07/25/97 03:58 PM (Embedded image moved to file: PIC32704.PCX) Manager, Strategic Alliances and Standards Lexmark International 606-232-4808 606-232-6740 (fax) don@lexmark.com To: IPP, P1394, JMP, pwg@pwg.org cc: Subject: September Meeting in Atlanta I have finalized the September Meeting in Atlanta. Here are the details: When: September 15-19 Where: Atlanta Marriott Suites Midtown Price: $129 per night Deadline: August 29th Reservations: 1-800-228-9290, 1-404-876-8888 Meeting Fee: in the range $35-40 expected All you Type A people should be able to start making your reservations on Monday (July 28th). Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** --0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5 Content-type: application/octet-stream; name="PIC32704.PCX" Content-transfer-encoding: base64 CgUBCAAAAADCAQ8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABwwEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAP/wf/B/8H/wf/B/8H5QfSB8QHxw/ED8IPD/8L/QsPwwsPwwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsP Cw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwv/D+EP0Q/ID8QPwg8PD+ULD8cLD8MLD8MLD8ML D8MLD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPC8MPC8MPC8MPC8cPC9cPzA/G D8MPDw//C/8L2AsPxwsPwwsPwwsPwwsPwwsPwwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwvDDwvDDwvDDwvDDwvHDwv/D+4P1w/MD8YPww8PD8cLD8cLD8cLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPwwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MP C8MPC8MPC8cPC8cPC8gPxA/CDw8P/wv5Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/D Cw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwvDDwsPCw8L ww8LDwsPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cP C8cPC8cPC/sP3Q/PD8cPxA/CDw/hCw/HCw/HCw/DCw/DCw/DCw8LDwsPwwsPCw8LD8MLDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP C8MPCw8LDwvDDwsPCw8Lww8Lww8Lxw8Lxw8L1Q/LD8UPww8PD/8L/wvUCw/HCw/HCw/DCw/DCw/D Cw8LDwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvHDwvHDwv/D+wP 1g/LD8YPww8PD8sLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPC8MPC8MP C8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8MPC8cPC8YPww/C Dw//C/0LD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8MLD8ML D8MLD8MLD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8Lww8Lww8Lww8L ww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8Lww8L/w/hD9EPyA/E D8IPDw/lCw/HCw/DCw/DCw/DCw/DCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwvD DwvDDwvDDwvDDwvHDwvXD8wPxg/DDw8P/wv/C9gLD8cLD8MLD8MLD8MLD8MLD8MLDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8Lww8Lww8Lww8Lww8Lxw8L/w/uD9cPzA/GD8MPDw/H Cw/HCw/HCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw/DCw8L DwsPwwsPCw8LD8MLDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvID8QPwg8PD/8L+QsPxwsPxwsPwwsPwwsP wwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8L DwsPCw8LDwsPCw8Lww8LDwsPC8MPCw8LDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvDDwvD DwvDDwvDDwvDDwvDDwvDDwvHDwvHDwvHDwv7D90Pzw/HD8QPwg8P4QsPxwsPxwsPwwsPwwsPwwsP Cw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8L DwsPCw8LDwsPCw8LDwsPCw8LDwvDDwsPCw8Lww8LDwsPC8MPC8MPC8cPC8cPC9UPyw/FD8MPDw// C/8L1AsPxwsPxwsPwwsPwwsPwwsPCw8LD8MLDwsPCw/DCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsP Cw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPCw8LDwsPC8MPCw8LDwvDDwsPCw8L ww8Lww8Lww8Lxw8Lxw8L/w/sD9YPyw/GD8MPDwwAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/ AAAA/wD//wAAAP//AP8A//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5-- From hastings at cp10.es.xerox.com Tue Aug 26 16:18:24 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> serviceOffline In-Reply-To: serviceOffline> Message-ID: <9708262021.AA18188@zazen.cp10.es.xerox.com> Harry, If you've found it useful, we should move the reason to the jmJobStateReason1 object. The current spec is: serviceOffLine 0x400000 The service/document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This could be true if its input is impaired or broken. Is the description what you want? So the 'serviceOffLine' reason bit is set for each job that has not yet completed in the service or device? So the bit gets set for each job that is: 'pending', 'pendingHeld', 'processing', or 'procesingStopped'. And the pending jobs are moved to pendingHeld? Thanks, Tom At 09:16 08/22/97 PDT, Harry Lewis wrote: >BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons >2 to job state reasons 1 as we agreed to use this reason to distinguish a >CANCEL state where sheets might still be cleared from the paper path from a >CANCEL operation that has completed. > >PROBLEM -- In prototyping, we find one other job state reason which we feel is >useful enough to be migrated into the (mandatory) job state reasons 1 category. >This reason is serviceOffLine. > >CLARIFICATION -- First, I am seeking agreement from the JMP that using job >state reason serviceOffLine is valid when the printer is off-line. (I know... >we usually get really tied up whenever the word off-line is used in >conversation). If so, do you agree that Off-line is a common, likely or >significant enough condition to warrant becoming part of the "reasons 1" group. > >PROPOSAL -- I'd like to propose this simple change be added to Tom's pending >draft, if possible, so I'm asking for discussion and straw poll (assuming the >Chair deems this appropriate). > >Thanks. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Tue Aug 26 20:47:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: Open Editorial Changes From Rev. 0.83> Message-ID: <9708270050.AA18237@zazen.cp10.es.xerox.com> Ron, I can go along with making your suggested changes for items 1, 2, 4, 5, and 7: 1. Removing the PJL example use of "job" and "document", though it was a long standing action item for Bob Pentecost and me that we finally did. 2. Starting each definition with a capital letter, even though they aren't sentences. 4. Removing the explanation that the jmGeneralJobPersistence object can be set either by the system administrator or by the implementation in an implementation-dependent manner, but instead of "Configuration of this parameter is implementation dependent." how about: Configuring this object is implementation-dependent. (We haven't used the term "parameter" before to describe an object). I agree that we can explain in the FAQ at least these two ways. 5. Same for jmGeneralAttributePersistence? 7. Ordinarily, I avoid the passive voice in order to make it clear which side of the interface is performing the action. But in this case its OK to use the passive voice on setting the read-only object, since it couldn't be the application that sets a read-only object, and I agree that it could be either the agent or the device (and doesn't matter which). I'll reply to items 3 and 6 as separate messages, since I have some variations to propose, in case anyone else is interested. Tom At 16:59 08/20/97 PDT, Ron Bergman wrote: >We need to get the following issues resolved ASAP. I am requesting >anyone involved with the Job MIB, please comment immediately if you >have an opinion for either position on these issues. > >None of these issues are of any technical consequence and I will >agree with the majority vote. All issues are only editorial but >should result in a cleaner and more readable document. > >The original comments were submitted by me (Ron Bergman) with >respect to the version 0.83 document and were not included in the >0.84 issue. Tom has included his reasons for not including these >comments followed by my rebuttal. > > Ron Bergman > > >On Tue, 19 Aug 1997, Tom Hastings wrote: > >> At 17:46 08/12/97 PDT, Ron Bergman wrote: >> >Tom, >> > >> >The following editorial corrections from revision 0.83 were not >> >incorporated into version 0.84. Please comment if there is a >> >reason that these should not be incorporated. >> >> I'm sorry that I didn't have time to respond before as to why I did not >> include these (few) editorial comments. See if you agree with my reasoning >> for not including them. I did include 99% of your suggestions and they >> improved the document. >> >> > I do not believe >> >that any of the corrections change the intent of the document. >> >> I agree that none of your corrections changed the intent of the document, >> including these few that I did not include. >> >> > >> > >> >Problems from 0.83: >> > >> >1. Section 2. Terminology and Job Model (page 14) states: >> > >> > "PJL systems use the term job to mean what we call a job in this >> > specification. PJL also supports multiple documents per job, but >> > does not support specifying per-document attributes independently >> > for each document." >> > >> > This text should be a part of the mapping document. This additional >> > example does not provide any additional help in understanding the >> > subject paragraph. >> >> I disagree. I think that it is important to understand the terms that >> the Job Monitoring MIB is using and to have an example mapping on this >> term. I also didn't want to include only the PostScript example. It seems >> more even handed to keep both examples to show that the mapping varies >> depending on the job submission protocol. >> >This subject is not difficult to understand and I would argue that no >examples are required. (All you are stating is that the definitions >are being locked down in this section.) The PJL example is much too >deep and really belongs in the mapping document. I do not see where >the PJL example provides any additional explaination as to why we >need the definitions. >> > >> >2. The definitions in section 2 should begin with a capital letter. >> > Example: "Job Set: A group of jobs..." >> >> I agree and both the .doc and .txt files have "Job Set", not "job set". >> None of the definitions themselves start with a capital letter, so I assume >> that you are not talking about "A group of jobs...", as opposed to "a group of >> jobs..." >> >My comment was the latter. I always believed that sentences should >start with a capital letter. >> > >> >3. The definition for "Device" (page 14): >> > >> > "...interfaces to humans in human perceptible means, such as produces >> > marks on paper, scans marks on paper to produce an electronic >> > representations, or writes CD_ROMS..." >> > >> > The second two examples don't appear to be human perceptible. I am >> > not sure I understand the reason for including other than the first >> > example. >> >> It is important to clarify that the device can produce other forms of >> human perciptable output than just printing devices, as we agreed in >> the requirements document. So I left these other examples in. >> >How is scaning marks on paper or writing a CD ROM human perceptible? >The only way you know for sure the operation was completed (or even >started) was a message on display or a printer. >> > >> >4. In jmGeneralJobPersistence (page #75), the second paragraph: >> > >> > "Depending on implementation, the value of this object MAY be >> > either: (1) set by the system administrator by means outside >> > this specification or (2) fixed by the implementation." >> > >> > Since this is a read only object do we need to define how it is >> > configured? We only need to describe the function. Suggest: >> > >> > "Configuration of this parameter is implementation dependent." >> >> I think that it helps to clarify that there are several ways that >> an implementation can set the value, so I left in both ways. >> >Ok, then who does this help? If I say implementation dependent, the >designer can devise any method he desires. If you feel this info >is really important, it should go into the FAQ. The specification >should only contain the requirements and restrictions. Helpful >hints, unless not obvious to the average developer, should be in the >FAQ. In this case, the alternatives are obvious. >> > >> >5. For jmGeneralAttributePersistence (page #76) the above comment >> > also applies. >> >> I left both in for the same reason. >> >> > >> >6. In jmJobStateReasons1 (page #81), I find the following statement >> > hard to disagree with, but why do we need to state this? >> > >> > "Furthermore, when implemented as with any MIB data, the >> > agent SHALL return these values when the reason applies and >> > SHALL NOT return them when the reason no longer applies whether >> > the value of the job's jmJobState object changed or not." >> > >> > All this really states is that the value of an object must be valid. >> > We do not have a similar statement for any other object. >> >> I disagree. One commentor asked whether the bits had to be turned off or not, >> so I felt it was important to clarify that these bits are meaningful while >> the job is in each job state, not just when the job transitions from one >> state to another. There are hardware implementations in which such bits >> are only meaningful on the state transitions. As far as I'm concerned, >> if someone asks about something it can't hurt to include the explanation >> in the document. There will be others who will ask the same question, but >> we won't be there to answer. >> >Since the question was asked, this should be in the FAQ and not in the >specification. All this sentence states is "thou shall not lie". If >the document states that this attribute indicates this condition and >the implementation sets the attribute when the condition is not true, >the implementation is violating the specification! I do not believe >that the document should answer every question that was asked. That >is why we should have a FAQ. >> > >> >7. Also in jmJobStateReasons1 (page #81), the next sentence: >> > >> > "When >> > the job does not have any reasons for being in its current >> > state, the agent SHALL set the value of the jmJobStateReasons1 >> > object and jobStateReasonsN attributes to 0." >> > >> > I suggest it be reworded to: >> > >> > "When the agent cannot provide a reason for the current >> > state of the job, the value of jmJobStateReasons1 object >> > and jobStateReasonsN attributes shall be 0." >> > >> >> I had taken your suggestion in V0.84, but kept it in the active voice: >> >> When the agent cannot provide a reason for the current state of the >> job, the agent SHALL set the value of the jmJobStateReasons1 >> object and jobStateReasonsN attributes to 0." >> >> I have tried hard to avoid the passive voice, since there are many entities >> in the system that do things: the agent, the device, the server, >> the management app, etc. So I indicated that is the agent that sets >> the values to 0. >> >Actually I prefer the passive voice since it may not be the agent that >sets the value. The agent may just collect the information from the >printer controller and pass it to the SNMP agent. >> > >> > >> > Ron Bergman >> > Dataproducts Corp. >> > >> >> So I hope you agree that all of your editorial suggestions are closed. >> >> Thanks, >> Tom >> >> > > > From hastings at cp10.es.xerox.com Tue Aug 26 20:48:01 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: Open Editorial Changes From Rev. 0.83: 6. when job> Message-ID: <9708270050.AB18237@zazen.cp10.es.xerox.com> At 16:59 08/20/97 PDT, Ron Bergman wrote: snip... >> >6. In jmJobStateReasons1 (page #81), I find the following statement >> > hard to disagree with, but why do we need to state this? >> > >> > "Furthermore, when implemented as with any MIB data, the >> > agent SHALL return these values when the reason applies and >> > SHALL NOT return them when the reason no longer applies whether >> > the value of the job's jmJobState object changed or not." >> > >> > All this really states is that the value of an object must be valid. >> > We do not have a similar statement for any other object. >> >> I disagree. One commentor asked whether the bits had to be turned off or not, >> so I felt it was important to clarify that these bits are meaningful while >> the job is in each job state, not just when the job transitions from one >> state to another. There are hardware implementations in which such bits >> are only meaningful on the state transitions. As far as I'm concerned, >> if someone asks about something it can't hurt to include the explanation >> in the document. There will be others who will ask the same question, but >> we won't be there to answer. >> >Since the question was asked, this should be in the FAQ and not in the >specification. All this sentence states is "thou shall not lie". If >the document states that this attribute indicates this condition and >the implementation sets the attribute when the condition is not true, >the implementation is violating the specification! I do not believe >that the document should answer every question that was asked. That >is why we should have a FAQ. The question was asked about the text that was in the spec. I believe that the FAQ should be answering questions that people have how haven't read the document or are getting into it. Of course, after we publish the specification, we can also use the FAQ to answer questions of interpretation of the standard, which would be better than nothing (since we can no longer update the spec). So if we have a question about interpretation of the text in the spec BEFORE the spec is published, the answer should go in the spec. Also from my experience with hardware devices, such as PDP-11 I/O devices, the question was whether the bits where only to be sampled when a job state transition occurred, such as in some I/O devices, or could be sampled any time. Finally, I took into account your concern/question about "why wouldn't we have to make a similar statement about other objects in the MIB", by adding the phrase: "as with any MIB data", so we don't have to add the phrase to any other object. Since you said it was hard to disagree with, lets leave it in. Ok? Tom From jkm at underscore.com Tue Aug 26 21:23:42 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition In-Reply-To: Open Editorial Changes From Rev. 0.83: 3. Definition> Message-ID: <199708270123.VAA03570@uscore.underscore.com> You know, it's great that the Job MIB *could* (not *should*) apply to, say, CD-ROM writers, FAX, etc. But don't you think we're asking for trouble by "addressing" these other devices when we really haven't opened discussions with those standards groups involved with CD-ROM and FAX (if such groups exist)? I mean, c'mon. We've been almost totally focused on PRINTERS for the Job MIB. And even though some sort of CD-ROM software _may_ be able to use the Job MIB...that's not the point. We've designed the Job MIB for printers. If other devices can use it, then fine. But we shouldn't try to make the reader feel that the Job MIB is THE solution for anything other than printers. My $0.02 worth, of course. Sorry, but I just had to mention this. ...jay ----- Begin Included Message ----- Date: Tue, 26 Aug 1997 17:47:57 PDT To: Ron Bergman From: Tom Hastings Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition of "device" Cc: jmp@pwg.org At 16:59 08/20/97 PDT, Ron Bergman wrote: snip... >> >3. The definition for "Device" (page 14): >> > >> > "...interfaces to humans in human perceptible means, such as produces >> > marks on paper, scans marks on paper to produce an electronic >> > representations, or writes CD_ROMS..." >> > >> > The second two examples don't appear to be human perceptible. I am >> > not sure I understand the reason for including other than the first >> > example. >> >> It is important to clarify that the device can produce other forms of >> human perciptable output than just printing devices, as we agreed in >> the requirements document. So I left these other examples in. >> >How is scaning marks on paper or writing a CD ROM human perceptible? >The only way you know for sure the operation was completed (or even >started) was a message on display or a printer. A scanner takes media that has human preceptible marks on it and scans it. I agree that the CD ROM writer is not human perceptible. The full definition for "device" from V0.83 is: Device: a hardware entity that (1) interfaces to humans in human perceptible means, such as produces marks on paper, scans marks on paper to produce an electronic representations, or writes CD-ROMs or (2) interfaces electronically to another device, such as sends FAX data to another FAX device. But I feel that we need to make our definition agree with the requirements that we worked on for so long that the MIB could also be used for jobs that scan, jobs that write CD-ROMs, and jobs that send FAX, though the inclusion of attributes for such jobs was beyond the scope of the current MIB. So how about: Device: a hardware entity that (1) interfaces to humans, such as produces marks on paper or scans marks on paper, (2) accesses digitial media, such as CD-ROMs, or (3) interfaces electronically to another device, such as sends FAX data to another FAX device. Tom ----- End Included Message ----- From hastings at cp10.es.xerox.com Wed Aug 27 12:30:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Operating System Types Message-ID: <9708271632.AA18447@zazen.cp10.es.xerox.com> The minutes said that we agreed to add Windows98, but I thought we agreed to change the Windows95 to just plain Windows, so that we wouldn't have to keep adding new operating system times when new versions came out. But I didn't edit either one in V0.85. Also why is Netware given the value of 33, instead of the next sequential number? I think I made a typo here. Here is the current version: JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source platform type that can submit jobs to servers or devices in any of the 3 configurations." REFERENCE "This is a type 2 enumeration. See Section 3.6.1.2." SYNTAX INTEGER { other(1), unknown(2), sptUNIX(3), -- UNIX(tm) sptOS2(4), -- OS/2 sptPCDOS(5), -- DOS sptNT(6), -- NT sptMVS(7), -- MVS sptVM(8), -- VM sptOS400(9), -- OS/400 sptVMS(10), -- VMS sptWindows95(11), -- Windows95 sptNetWare(33) -- NetWare } I propose to change the last two entries to: sptWindows(11), -- Windows sptNetWare(12) -- NetWare Ok? Tom From hastings at cp10.es.xerox.com Wed Aug 27 12:49:06 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition In-Reply-To: Open Editorial Changes From Rev. 0.83: 3. Definition> Message-ID: <9708271651.AA18455@zazen.cp10.es.xerox.com> Jay, In order not to mis-lead the reader or bend the other groups working on scanning and faxing out of shape, lets add something that indicates that support of these other devices is outside the scope of the current MIB, but that this MIB can be used with extensions for other devices. We, at Xerox, have been using our private job MIB for both scanning and FAXing as well as printing and have found no problems with doing so. Only a few additional attributs are needed for such (either in the same MIB or in an extension MIB that augments the job MIB). All of the objects and many of the attributes are just as applicable to scan and fax jobs as printing jobs. Here is the last part of the Abstract: This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. So how about the following devinition for "device": Device: A hardware entity that performs one or more document transformations between electronic and/or hardcopy forms. Use of the object set is not limited to printers. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Tom At 18:23 08/26/97 PDT, JK Martin wrote: >You know, it's great that the Job MIB *could* (not *should*) apply >to, say, CD-ROM writers, FAX, etc. > >But don't you think we're asking for trouble by "addressing" these >other devices when we really haven't opened discussions with those >standards groups involved with CD-ROM and FAX (if such groups exist)? > >I mean, c'mon. We've been almost totally focused on PRINTERS for the >Job MIB. And even though some sort of CD-ROM software _may_ be able >to use the Job MIB...that's not the point. > >We've designed the Job MIB for printers. If other devices can use it, >then fine. But we shouldn't try to make the reader feel that the Job >MIB is THE solution for anything other than printers. > >My $0.02 worth, of course. Sorry, but I just had to mention this. > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Tue Aug 26 20:53 EDT 1997 >Date: Tue, 26 Aug 1997 17:47:57 PDT >To: Ron Bergman >From: Tom Hastings >Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition > of "device" >Cc: jmp@pwg.org > >At 16:59 08/20/97 PDT, Ron Bergman wrote: >snip... >>> >3. The definition for "Device" (page 14): >>> > >>> > "...interfaces to humans in human perceptible means, such as produces >>> > marks on paper, scans marks on paper to produce an electronic >>> > representations, or writes CD_ROMS..." >>> > >>> > The second two examples don't appear to be human perceptible. I am >>> > not sure I understand the reason for including other than the first >>> > example. >>> >>> It is important to clarify that the device can produce other forms of >>> human perciptable output than just printing devices, as we agreed in >>> the requirements document. So I left these other examples in. >>> >>How is scaning marks on paper or writing a CD ROM human perceptible? >>The only way you know for sure the operation was completed (or even >>started) was a message on display or a printer. > > >A scanner takes media that has human preceptible marks on it and scans >it. I agree that the CD ROM writer is not human perceptible. > > >The full definition for "device" from V0.83 is: > >Device: a hardware entity that (1) interfaces to humans in human >perceptible means, such as produces marks on paper, scans marks on paper to >produce an electronic representations, or writes CD-ROMs or (2) interfaces >electronically to another device, such as sends FAX data to another FAX device. > > > >But I feel that we need to make our definition agree with the requirements >that we worked on for so long that the MIB could also be used for jobs that >scan, jobs that write CD-ROMs, and jobs that send FAX, though the inclusion >of attributes for such jobs was beyond the scope of the current MIB. > >So how about: > >Device: a hardware entity that (1) interfaces to humans, such as produces >marks on paper or scans marks on paper, (2) accesses digitial media, such as >CD-ROMs, or (3) interfaces electronically to another device, such as sends >FAX data to another FAX device. > >Tom > > > >----- End Included Message ----- > > > From jkm at underscore.com Wed Aug 27 17:46:08 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition In-Reply-To: Open Editorial Changes From Rev. 0.83: 3. Definition> Message-ID: <199708272146.RAA04232@uscore.underscore.com> Your proposed wording looks good to me, Tom. ...jay ----- Begin Included Message ----- Date: Wed, 27 Aug 1997 09:49:06 PDT To: JK Martin From: Tom Hastings Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition of "device" Cc: jmp@pwg.org Jay, In order not to mis-lead the reader or bend the other groups working on scanning and faxing out of shape, lets add something that indicates that support of these other devices is outside the scope of the current MIB, but that this MIB can be used with extensions for other devices. We, at Xerox, have been using our private job MIB for both scanning and FAXing as well as printing and have found no problems with doing so. Only a few additional attributs are needed for such (either in the same MIB or in an extension MIB that augments the job MIB). All of the objects and many of the attributes are just as applicable to scan and fax jobs as printing jobs. Here is the last part of the Abstract: This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. So how about the following devinition for "device": Device: A hardware entity that performs one or more document transformations between electronic and/or hardcopy forms. Use of the object set is not limited to printers. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Tom At 18:23 08/26/97 PDT, JK Martin wrote: >You know, it's great that the Job MIB *could* (not *should*) apply >to, say, CD-ROM writers, FAX, etc. > >But don't you think we're asking for trouble by "addressing" these >other devices when we really haven't opened discussions with those >standards groups involved with CD-ROM and FAX (if such groups exist)? > >I mean, c'mon. We've been almost totally focused on PRINTERS for the >Job MIB. And even though some sort of CD-ROM software _may_ be able >to use the Job MIB...that's not the point. > >We've designed the Job MIB for printers. If other devices can use it, >then fine. But we shouldn't try to make the reader feel that the Job >MIB is THE solution for anything other than printers. > >My $0.02 worth, of course. Sorry, but I just had to mention this. > > ...jay > >----- Begin Included Message ----- > >>From jmp-owner@pwg.org Tue Aug 26 20:53 EDT 1997 >Date: Tue, 26 Aug 1997 17:47:57 PDT >To: Ron Bergman >From: Tom Hastings >Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition > of "device" >Cc: jmp@pwg.org > >At 16:59 08/20/97 PDT, Ron Bergman wrote: >snip... >>> >3. The definition for "Device" (page 14): >>> > >>> > "...interfaces to humans in human perceptible means, such as produces >>> > marks on paper, scans marks on paper to produce an electronic >>> > representations, or writes CD_ROMS..." >>> > >>> > The second two examples don't appear to be human perceptible. I am >>> > not sure I understand the reason for including other than the first >>> > example. >>> >>> It is important to clarify that the device can produce other forms of >>> human perciptable output than just printing devices, as we agreed in >>> the requirements document. So I left these other examples in. >>> >>How is scaning marks on paper or writing a CD ROM human perceptible? >>The only way you know for sure the operation was completed (or even >>started) was a message on display or a printer. > > >A scanner takes media that has human preceptible marks on it and scans >it. I agree that the CD ROM writer is not human perceptible. > > >The full definition for "device" from V0.83 is: > >Device: a hardware entity that (1) interfaces to humans in human >perceptible means, such as produces marks on paper, scans marks on paper to >produce an electronic representations, or writes CD-ROMs or (2) interfaces >electronically to another device, such as sends FAX data to another FAX device. > > > >But I feel that we need to make our definition agree with the requirements >that we worked on for so long that the MIB could also be used for jobs that >scan, jobs that write CD-ROMs, and jobs that send FAX, though the inclusion >of attributes for such jobs was beyond the scope of the current MIB. > >So how about: > >Device: a hardware entity that (1) interfaces to humans, such as produces >marks on paper or scans marks on paper, (2) accesses digitial media, such as >CD-ROMs, or (3) interfaces electronically to another device, such as sends >FAX data to another FAX device. > >Tom > > > >----- End Included Message ----- > > > ----- End Included Message ----- From rbergma at dpc.com Wed Aug 27 18:10:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83 In-Reply-To: <9708270050.AA18237@zazen.cp10.es.xerox.com> Message-ID: <199708272146.RAA04232@uscore.underscore.com> Tom, Very good! I accept your new wording for items 4 and 5. You are correct in using "object' in place of "parameter". So these five issues are now closed. ...Ron On Tue, 26 Aug 1997, Tom Hastings wrote: > Ron, > > I can go along with making your suggested changes for items 1, 2, 4, 5, > and 7: > > 1. Removing the PJL example use of "job" and "document", though it was > a long standing action item for Bob Pentecost and me that we finally did. > > > 2. Starting each definition with a capital letter, even though they > aren't sentences. > > > 4. Removing the explanation that the jmGeneralJobPersistence object > can be set either by the system administrator or by the implementation > in an implementation-dependent manner, > but instead of "Configuration of this parameter is implementation dependent." > how about: > > Configuring this object is implementation-dependent. > > (We haven't used the term "parameter" before to describe an object). > > I agree that we can explain in the FAQ at least these two ways. > > > 5. Same for jmGeneralAttributePersistence? > > > 7. Ordinarily, I avoid the passive voice in order to make it clear which > side of the interface is performing the action. But in this case its OK > to use the passive voice on setting the read-only object, since > it couldn't be the application that sets a read-only object, and I agree > that it could be either the agent or the device (and doesn't matter which). > > > I'll reply to items 3 and 6 as separate messages, since I have some variations > to propose, in case anyone else is interested. > > Tom > > At 16:59 08/20/97 PDT, Ron Bergman wrote: > >We need to get the following issues resolved ASAP. I am requesting > >anyone involved with the Job MIB, please comment immediately if you > >have an opinion for either position on these issues. > > > >None of these issues are of any technical consequence and I will > >agree with the majority vote. All issues are only editorial but > >should result in a cleaner and more readable document. > > > >The original comments were submitted by me (Ron Bergman) with > >respect to the version 0.83 document and were not included in the > >0.84 issue. Tom has included his reasons for not including these > >comments followed by my rebuttal. > > > > Ron Bergman > > > > > >On Tue, 19 Aug 1997, Tom Hastings wrote: > > > >> At 17:46 08/12/97 PDT, Ron Bergman wrote: > >> >Tom, > >> > > >> >The following editorial corrections from revision 0.83 were not > >> >incorporated into version 0.84. Please comment if there is a > >> >reason that these should not be incorporated. > >> > >> I'm sorry that I didn't have time to respond before as to why I did not > >> include these (few) editorial comments. See if you agree with my reasoning > >> for not including them. I did include 99% of your suggestions and they > >> improved the document. > >> > >> > I do not believe > >> >that any of the corrections change the intent of the document. > >> > >> I agree that none of your corrections changed the intent of the document, > >> including these few that I did not include. > >> > >> > > >> > > >> >Problems from 0.83: > >> > > >> >1. Section 2. Terminology and Job Model (page 14) states: > >> > > >> > "PJL systems use the term job to mean what we call a job in this > >> > specification. PJL also supports multiple documents per job, but > >> > does not support specifying per-document attributes independently > >> > for each document." > >> > > >> > This text should be a part of the mapping document. This additional > >> > example does not provide any additional help in understanding the > >> > subject paragraph. > >> > >> I disagree. I think that it is important to understand the terms that > >> the Job Monitoring MIB is using and to have an example mapping on this > >> term. I also didn't want to include only the PostScript example. It seems > >> more even handed to keep both examples to show that the mapping varies > >> depending on the job submission protocol. > >> > >This subject is not difficult to understand and I would argue that no > >examples are required. (All you are stating is that the definitions > >are being locked down in this section.) The PJL example is much too > >deep and really belongs in the mapping document. I do not see where > >the PJL example provides any additional explaination as to why we > >need the definitions. > >> > > >> >2. The definitions in section 2 should begin with a capital letter. > >> > Example: "Job Set: A group of jobs..." > >> > >> I agree and both the .doc and .txt files have "Job Set", not "job set". > >> None of the definitions themselves start with a capital letter, so I assume > >> that you are not talking about "A group of jobs...", as opposed to "a > group of > >> jobs..." > >> > >My comment was the latter. I always believed that sentences should > >start with a capital letter. > >> > > >> >3. The definition for "Device" (page 14): > >> > > >> > "...interfaces to humans in human perceptible means, such as produces > >> > marks on paper, scans marks on paper to produce an electronic > >> > representations, or writes CD_ROMS..." > >> > > >> > The second two examples don't appear to be human perceptible. I am > >> > not sure I understand the reason for including other than the first > >> > example. > >> > >> It is important to clarify that the device can produce other forms of > >> human perciptable output than just printing devices, as we agreed in > >> the requirements document. So I left these other examples in. > >> > >How is scaning marks on paper or writing a CD ROM human perceptible? > >The only way you know for sure the operation was completed (or even > >started) was a message on display or a printer. > >> > > >> >4. In jmGeneralJobPersistence (page #75), the second paragraph: > >> > > >> > "Depending on implementation, the value of this object MAY be > >> > either: (1) set by the system administrator by means outside > >> > this specification or (2) fixed by the implementation." > >> > > >> > Since this is a read only object do we need to define how it is > >> > configured? We only need to describe the function. Suggest: > >> > > >> > "Configuration of this parameter is implementation dependent." > >> > >> I think that it helps to clarify that there are several ways that > >> an implementation can set the value, so I left in both ways. > >> > >Ok, then who does this help? If I say implementation dependent, the > >designer can devise any method he desires. If you feel this info > >is really important, it should go into the FAQ. The specification > >should only contain the requirements and restrictions. Helpful > >hints, unless not obvious to the average developer, should be in the > >FAQ. In this case, the alternatives are obvious. > >> > > >> >5. For jmGeneralAttributePersistence (page #76) the above comment > >> > also applies. > >> > >> I left both in for the same reason. > >> > >> > > >> >6. In jmJobStateReasons1 (page #81), I find the following statement > >> > hard to disagree with, but why do we need to state this? > >> > > >> > "Furthermore, when implemented as with any MIB data, the > >> > agent SHALL return these values when the reason applies and > >> > SHALL NOT return them when the reason no longer applies whether > >> > the value of the job's jmJobState object changed or not." > >> > > >> > All this really states is that the value of an object must be valid. > >> > We do not have a similar statement for any other object. > >> > >> I disagree. One commentor asked whether the bits had to be turned off or > not, > >> so I felt it was important to clarify that these bits are meaningful while > >> the job is in each job state, not just when the job transitions from one > >> state to another. There are hardware implementations in which such bits > >> are only meaningful on the state transitions. As far as I'm concerned, > >> if someone asks about something it can't hurt to include the explanation > >> in the document. There will be others who will ask the same question, but > >> we won't be there to answer. > >> > >Since the question was asked, this should be in the FAQ and not in the > >specification. All this sentence states is "thou shall not lie". If > >the document states that this attribute indicates this condition and > >the implementation sets the attribute when the condition is not true, > >the implementation is violating the specification! I do not believe > >that the document should answer every question that was asked. That > >is why we should have a FAQ. > >> > > >> >7. Also in jmJobStateReasons1 (page #81), the next sentence: > >> > > >> > "When > >> > the job does not have any reasons for being in its current > >> > state, the agent SHALL set the value of the jmJobStateReasons1 > >> > object and jobStateReasonsN attributes to 0." > >> > > >> > I suggest it be reworded to: > >> > > >> > "When the agent cannot provide a reason for the current > >> > state of the job, the value of jmJobStateReasons1 object > >> > and jobStateReasonsN attributes shall be 0." > >> > > >> > >> I had taken your suggestion in V0.84, but kept it in the active voice: > >> > >> When the agent cannot provide a reason for the current state of the > >> job, the agent SHALL set the value of the jmJobStateReasons1 > >> object and jobStateReasonsN attributes to 0." > >> > >> I have tried hard to avoid the passive voice, since there are many entities > >> in the system that do things: the agent, the device, the server, > >> the management app, etc. So I indicated that is the agent that sets > >> the values to 0. > >> > >Actually I prefer the passive voice since it may not be the agent that > >sets the value. The agent may just collect the information from the > >printer controller and pass it to the SNMP agent. > >> > > >> > > >> > Ron Bergman > >> > Dataproducts Corp. > >> > > >> > >> So I hope you agree that all of your editorial suggestions are closed. > >> > >> Thanks, > >> Tom > >> > >> > > > > > > > > From rbergma at dpc.com Wed Aug 27 18:13:29 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition In-Reply-To: <9708271651.AA18455@zazen.cp10.es.xerox.com> Message-ID: <199708272146.RAA04232@uscore.underscore.com> Tom, This looks like a much better description. I propose this be the definition to be used. This issue is now closed. ..Ron On Wed, 27 Aug 1997, Tom Hastings wrote: > Jay, > > In order not to mis-lead the reader or bend the other groups working > on scanning and faxing out of shape, lets add something that indicates > that support of these other devices is outside the scope of the current > MIB, but that this MIB can be used with extensions for other devices. > > We, at Xerox, have been using our private job MIB for both scanning and FAXing > as well as printing and have found no problems with doing so. Only a few > additional attributs are needed for such (either in the same MIB or in > an extension MIB that augments the job MIB). All of the objects and many of the > attributes are just as applicable to scan and fax jobs as printing jobs. > > Here is the last part of the Abstract: > > This MIB is intended to be implemented (1) in a printer or (2) in a server > that supports one or more printers. Use of the object set is not limited to > printing. However, support for services other than printing is outside the > scope of this Job Monitoring MIB. Future extensions to this MIB may > include, but are not limited to, fax machines and scanners. > > So how about the following devinition for "device": > > Device: A hardware entity that performs one or more document > transformations between electronic and/or hardcopy forms. Use of the object > set is not limited to printers. However, support for services other than > printing is outside the scope of this Job Monitoring MIB. Future extensions > to this MIB may include, but are not limited to, fax machines and scanners. > > Tom > > At 18:23 08/26/97 PDT, JK Martin wrote: > >You know, it's great that the Job MIB *could* (not *should*) apply > >to, say, CD-ROM writers, FAX, etc. > > > >But don't you think we're asking for trouble by "addressing" these > >other devices when we really haven't opened discussions with those > >standards groups involved with CD-ROM and FAX (if such groups exist)? > > > >I mean, c'mon. We've been almost totally focused on PRINTERS for the > >Job MIB. And even though some sort of CD-ROM software _may_ be able > >to use the Job MIB...that's not the point. > > > >We've designed the Job MIB for printers. If other devices can use it, > >then fine. But we shouldn't try to make the reader feel that the Job > >MIB is THE solution for anything other than printers. > > > >My $0.02 worth, of course. Sorry, but I just had to mention this. > > > > ...jay > > > >----- Begin Included Message ----- > > > >>From jmp-owner@pwg.org Tue Aug 26 20:53 EDT 1997 > >Date: Tue, 26 Aug 1997 17:47:57 PDT > >To: Ron Bergman > >From: Tom Hastings > >Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 3. Definition > > of "device" > >Cc: jmp@pwg.org > > > >At 16:59 08/20/97 PDT, Ron Bergman wrote: > >snip... > >>> >3. The definition for "Device" (page 14): > >>> > > >>> > "...interfaces to humans in human perceptible means, such as produces > >>> > marks on paper, scans marks on paper to produce an electronic > >>> > representations, or writes CD_ROMS..." > >>> > > >>> > The second two examples don't appear to be human perceptible. I am > >>> > not sure I understand the reason for including other than the first > >>> > example. > >>> > >>> It is important to clarify that the device can produce other forms of > >>> human perciptable output than just printing devices, as we agreed in > >>> the requirements document. So I left these other examples in. > >>> > >>How is scaning marks on paper or writing a CD ROM human perceptible? > >>The only way you know for sure the operation was completed (or even > >>started) was a message on display or a printer. > > > > > >A scanner takes media that has human preceptible marks on it and scans > >it. I agree that the CD ROM writer is not human perceptible. > > > > > >The full definition for "device" from V0.83 is: > > > >Device: a hardware entity that (1) interfaces to humans in human > >perceptible means, such as produces marks on paper, scans marks on paper to > >produce an electronic representations, or writes CD-ROMs or (2) interfaces > >electronically to another device, such as sends FAX data to another FAX device. > > > > > > > >But I feel that we need to make our definition agree with the requirements > >that we worked on for so long that the MIB could also be used for jobs that > >scan, jobs that write CD-ROMs, and jobs that send FAX, though the inclusion > >of attributes for such jobs was beyond the scope of the current MIB. > > > >So how about: > > > >Device: a hardware entity that (1) interfaces to humans, such as produces > >marks on paper or scans marks on paper, (2) accesses digitial media, such as > >CD-ROMs, or (3) interfaces electronically to another device, such as sends > >FAX data to another FAX device. > > > >Tom > > > > > > > >----- End Included Message ----- > > > > > > > > From rbergma at dpc.com Wed Aug 27 18:37:57 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: <9708270050.AB18237@zazen.cp10.es.xerox.com> Message-ID: <199708272146.RAA04232@uscore.underscore.com> Tom, I still do not like the disputed text and do not believe that it properly answers the question. I propose as an alternative: "Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time the current Job State is updated." This presents the same idea from a different perspective and also eliminates the tone of the previous statement that "this object is special and must be valid". And also implies that other objects do not have to be valid since I did not explicitly say so. Again, this is a minor issue and I am being somewhat hard-nosed, but I would like to get the wording correct now. ...Ron On Tue, 26 Aug 1997, Tom Hastings wrote: > At 16:59 08/20/97 PDT, Ron Bergman wrote: > snip... > > >> >6. In jmJobStateReasons1 (page #81), I find the following statement > >> > hard to disagree with, but why do we need to state this? > >> > > >> > "Furthermore, when implemented as with any MIB data, the > >> > agent SHALL return these values when the reason applies and > >> > SHALL NOT return them when the reason no longer applies whether > >> > the value of the job's jmJobState object changed or not." > >> > > >> > All this really states is that the value of an object must be valid. > >> > We do not have a similar statement for any other object. > >> > >> I disagree. One commentor asked whether the bits had to be turned off or > not, > >> so I felt it was important to clarify that these bits are meaningful while > >> the job is in each job state, not just when the job transitions from one > >> state to another. There are hardware implementations in which such bits > >> are only meaningful on the state transitions. As far as I'm concerned, > >> if someone asks about something it can't hurt to include the explanation > >> in the document. There will be others who will ask the same question, but > >> we won't be there to answer. > >> > >Since the question was asked, this should be in the FAQ and not in the > >specification. All this sentence states is "thou shall not lie". If > >the document states that this attribute indicates this condition and > >the implementation sets the attribute when the condition is not true, > >the implementation is violating the specification! I do not believe > >that the document should answer every question that was asked. That > >is why we should have a FAQ. > > The question was asked about the text that was in the spec. I believe > that the FAQ should be answering questions that people have how haven't > read the document or are getting into it. Of course, after we publish > the specification, we can also use the FAQ to answer questions of interpretation > of the standard, which would be better than nothing (since we can no longer > update the spec). > > So if we have a question about interpretation of the text in the spec > BEFORE the spec is published, the answer should go in the spec. > > Also from my experience with hardware devices, such as PDP-11 I/O devices, the > question was whether the bits where only to be sampled when a job state > transition occurred, such as in some I/O devices, or could be sampled any time. > > Finally, I took into account your concern/question about "why wouldn't we > have to make a similar statement about other objects in the MIB", by adding > the phrase: "as with any MIB data", so we don't have to add the phrase > to any other object. > > Since you said it was hard to disagree with, lets leave it in. Ok? > > Tom > > > From jkm at underscore.com Thu Aug 28 08:12:10 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: Open Editorial Changes From Rev. 0.83: 6. when job> Message-ID: <199708281212.IAA04691@uscore.underscore.com> I agree with Ron. ...jay ----- Begin Included Message ----- Date: Wed, 27 Aug 1997 15:37:57 -0700 (Pacific Daylight Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 6. when job state reasons must be turned on and off X-X-Sender: rbergma@it.dpc.com Tom, I still do not like the disputed text and do not believe that it properly answers the question. I propose as an alternative: "Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time the current Job State is updated." This presents the same idea from a different perspective and also eliminates the tone of the previous statement that "this object is special and must be valid". And also implies that other objects do not have to be valid since I did not explicitly say so. Again, this is a minor issue and I am being somewhat hard-nosed, but I would like to get the wording correct now. ...Ron On Tue, 26 Aug 1997, Tom Hastings wrote: > At 16:59 08/20/97 PDT, Ron Bergman wrote: > snip... > > >> >6. In jmJobStateReasons1 (page #81), I find the following statement > >> > hard to disagree with, but why do we need to state this? > >> > > >> > "Furthermore, when implemented as with any MIB data, the > >> > agent SHALL return these values when the reason applies and > >> > SHALL NOT return them when the reason no longer applies whether > >> > the value of the job's jmJobState object changed or not." > >> > > >> > All this really states is that the value of an object must be valid. > >> > We do not have a similar statement for any other object. > >> > >> I disagree. One commentor asked whether the bits had to be turned off or > not, > >> so I felt it was important to clarify that these bits are meaningful while > >> the job is in each job state, not just when the job transitions from one > >> state to another. There are hardware implementations in which such bits > >> are only meaningful on the state transitions. As far as I'm concerned, > >> if someone asks about something it can't hurt to include the explanation > >> in the document. There will be others who will ask the same question, but > >> we won't be there to answer. > >> > >Since the question was asked, this should be in the FAQ and not in the > >specification. All this sentence states is "thou shall not lie". If > >the document states that this attribute indicates this condition and > >the implementation sets the attribute when the condition is not true, > >the implementation is violating the specification! I do not believe > >that the document should answer every question that was asked. That > >is why we should have a FAQ. > > The question was asked about the text that was in the spec. I believe > that the FAQ should be answering questions that people have how haven't > read the document or are getting into it. Of course, after we publish > the specification, we can also use the FAQ to answer questions of interpretation > of the standard, which would be better than nothing (since we can no longer > update the spec). > > So if we have a question about interpretation of the text in the spec > BEFORE the spec is published, the answer should go in the spec. > > Also from my experience with hardware devices, such as PDP-11 I/O devices, the > question was whether the bits where only to be sampled when a job state > transition occurred, such as in some I/O devices, or could be sampled any time. > > Finally, I took into account your concern/question about "why wouldn't we > have to make a similar statement about other objects in the MIB", by adding > the phrase: "as with any MIB data", so we don't have to add the phrase > to any other object. > > Since you said it was hard to disagree with, lets leave it in. Ok? > > Tom > > > ----- End Included Message ----- From harryl at us.ibm.com Thu Aug 28 13:06:30 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> JobStateReasons -1 Message-ID: <5030300009484183000002L032*@MHS> In review, we have one final request to move a jobStateReason. We would like to see submissionInterrupted moved into Reasons-1. I would also like to share the jobStateReasons which we have found the most practical and useful. deviceStopped - open cover, paper jam etc. jobPrinting - from first to last page unless there is an error or the printer goes offline submissionInterrupted - I/O timeout occurs processingToStoppedPoint - between cancel request and actual end of cancel operation serviceOffline - printer is offline (with or without errors) canceledByOperator - canceled at the printer canceledByUser - canceled remotely We think there is benefit in a design that relies mainly on the Reasons-1 category due to it's mandatory distinction. This is why we have requested a few jobStateReasons be moved to Reasons-1. I'd like to offer our interpretation, above, as sort of a "Top 7" (akin to the Alert table top 25) and see if others agree. I know, offhand, that our interpretation of the canceled reasons is a bit different than the strict definitions and may not fit the server implementation exactly. If anyone reads the strict definitions, when you are finished chuckling, you may want to help explain them. I think they're from DPA;-) ;-) ;-). Harry Lewis From SISAACSON at novell.com Thu Aug 28 15:15:50 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:09 2009 Subject: JMP> Operating System Types In-Reply-To: Operating System Types> Message-ID: >>> Tom Hastings 08/27 10:30 AM >>> > I propose to change the last two entries to: > >sptWindows(11), -- Windows >sptNetWare(12) -- NetWare ok by me. Scott From hastings at cp10.es.xerox.com Thu Aug 28 19:54:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: Open Editorial Changes From Rev. 0.83: 6. when job> Message-ID: <9708282357.AA19028@zazen.cp10.es.xerox.com> Ron, Lets keep the discussion going on job state reasons, because your proposed workding is just what I am worried about. My understanding of your proposed wording suggests that the agent only need make the reasons be correct, when the job state changes. This is exactly the interpretation that the participant asked if it was ok to only make the reason be correct when the job changed state (and was like the old PDP-11 devices). In fact, an application is encouraged to look at the reasons whenever it looks at the job. Also since we don't have trapping, there is no way for an application to know when a job actually changes state, except to notice that the job state value is different on the current poll cycle from the last poll cycle. I want to make it clear that the job state reason value(s) may: 1. change when the job state changes (the usual case) Example: job changes state from 'processing' to 'completed' and the 'jobCompletedSuccessfully' reason is set at the same time. This reason remains set for the entire remaining life of the job in the 'completed' state. 2. change while the job state does not change, i.e., some job state reasons may come and go while a job remains in the same state (less likely) Example: the job is in the 'pending' state and the printer stops, so the reason 'deviceStopped' comes and goes while the job remains in the 'pending' state. Example: the job is canceled so the job transitions from 'processing' to 'canceled', with the (new) 'processingToStopPoint' reason is set and the 'jobPrinting' reason may be set. However, while the job is in the 'canceled' state, the processing to stop point completes and the marking media completes, so that the 'processingToStopPoint' and the 'jobPrinting' reasons go away (and not necessarily at the same time). 3. remain the same while a job changes state (rare, but possible). Example: a job with the "jobHold" attribute set would have the 'jobHoldSpecified' reason set as well. However, if the job was canceled, the job would change from the 'pendingHeld' state to the 'canceled' state. The implementation MAY keep the 'jobHoldSpecified' reason set during the remaining life of the job. I'm also trying to understand your concerns about the wording below: At 15:37 08/27/97 PDT, Ron Bergman wrote: >Tom, > >I still do not like the disputed text and do not believe that it properly >answers the question. I propose as an alternative: > > "Since the Job State Reasons will be more dynamic than the Job State, > it is recommended that a job monitoring application read this object > every time the current Job State is updated." > >This presents the same idea from a different perspective and also >eliminates the tone of the previous statement that "this object is >special and must be valid". And also implies that other objects do >not have to be valid since I did not explicitly say so. I'm still puzzled as to why you think the phrase: "when implemented as with any MIB data" makes the reasons be special. The statement is trying to say that reasson, like any other MIB data, must agree with the conditions of the device. I'm also puzzled as to why you think that the same phrase: "when implemented as with any MIB data" allows any other MIB data to not be valid? Is there a better way to say that reasons must be just as valid as other MIB objects and attributes and that reasons must not become stale (as with any other MIB data)? Tom > >Again, this is a minor issue and I am being somewhat hard-nosed, but >I would like to get the wording correct now. > > > ...Ron > > >On Tue, 26 Aug 1997, Tom Hastings wrote: > >> At 16:59 08/20/97 PDT, Ron Bergman wrote: >> snip... >> >> >> >6. In jmJobStateReasons1 (page #81), I find the following statement >> >> > hard to disagree with, but why do we need to state this? >> >> > >> >> > "Furthermore, when implemented as with any MIB data, the >> >> > agent SHALL return these values when the reason applies and >> >> > SHALL NOT return them when the reason no longer applies whether >> >> > the value of the job's jmJobState object changed or not." >> >> > >> >> > All this really states is that the value of an object must be valid. >> >> > We do not have a similar statement for any other object. >> >> >> >> I disagree. One commentor asked whether the bits had to be turned off or >> not, >> >> so I felt it was important to clarify that these bits are meaningful while >> >> the job is in each job state, not just when the job transitions from one >> >> state to another. There are hardware implementations in which such bits >> >> are only meaningful on the state transitions. As far as I'm concerned, >> >> if someone asks about something it can't hurt to include the explanation >> >> in the document. There will be others who will ask the same question, but >> >> we won't be there to answer. >> >> >> >Since the question was asked, this should be in the FAQ and not in the >> >specification. All this sentence states is "thou shall not lie". If >> >the document states that this attribute indicates this condition and >> >the implementation sets the attribute when the condition is not true, >> >the implementation is violating the specification! I do not believe >> >that the document should answer every question that was asked. That >> >is why we should have a FAQ. >> >> The question was asked about the text that was in the spec. I believe >> that the FAQ should be answering questions that people have how haven't >> read the document or are getting into it. Of course, after we publish >> the specification, we can also use the FAQ to answer questions of interpretation >> of the standard, which would be better than nothing (since we can no longer >> update the spec). >> >> So if we have a question about interpretation of the text in the spec >> BEFORE the spec is published, the answer should go in the spec. >> >> Also from my experience with hardware devices, such as PDP-11 I/O devices, the >> question was whether the bits where only to be sampled when a job state >> transition occurred, such as in some I/O devices, or could be sampled any time. >> >> Finally, I took into account your concern/question about "why wouldn't we >> have to make a similar statement about other objects in the MIB", by adding >> the phrase: "as with any MIB data", so we don't have to add the phrase >> to any other object. >> >> Since you said it was hard to disagree with, lets leave it in. Ok? >> >> Tom >> >> >> > > > From rbergma at dpc.com Thu Aug 28 21:46:52 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: <9708282357.AA19028@zazen.cp10.es.xerox.com> Message-ID: <9708282357.AA19028@zazen.cp10.es.xerox.com> Tom, I understand exactly what you you mean. That is not the issue. What I was trying to say in my new wording is that the Job Monitor Ap should read the Job State Reasons every time he attempted to update (i.e. read) the job state. He may read the job state many times before it changes. My meaning of "update" was "the monitor reads the job state". So let me reword again: "Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time jmJobState is read." Is this better? ...Ron On Thu, 28 Aug 1997, Tom Hastings wrote: > Ron, > > Lets keep the discussion going on job state reasons, because your proposed > workding is just what I am worried about. My understanding of your proposed > wording suggests that the agent only need make the reasons be correct, > when the job state changes. This is exactly the interpretation that > the participant asked if it was ok to only make the reason be correct > when the job changed state (and was like the old PDP-11 devices). > > In fact, an application is encouraged to look at the reasons whenever > it looks at the job. Also since we don't have trapping, there is no > way for an application to know when a job actually changes state, except > to notice that the job state value is different on the current poll cycle > from the last poll cycle. > > I want to make it clear that the job state reason value(s) may: > > 1. change when the job state changes (the usual case) > > Example: job changes state from 'processing' to 'completed' and the > 'jobCompletedSuccessfully' reason is set at the same time. This reason > remains set for the entire remaining life of the job in the 'completed' > state. > > 2. change while the job state does not change, i.e., some job state > reasons may come and go while a job remains in the same state > (less likely) > > Example: the job is in the 'pending' state and the printer stops, > so the reason 'deviceStopped' comes and goes while the job remains > in the 'pending' state. > > Example: the job is canceled so the job transitions from 'processing' > to 'canceled', with the (new) 'processingToStopPoint' reason is set > and the 'jobPrinting' reason may be set. > However, while the job is in the 'canceled' state, the processing to > stop point completes and the marking media completes, so that the > 'processingToStopPoint' and the 'jobPrinting' reasons go away (and > not necessarily at the same time). > > 3. remain the same while a job changes state (rare, but possible). > > Example: a job with the "jobHold" attribute set would have the > 'jobHoldSpecified' reason set as well. However, if the job was > canceled, the job would change from the 'pendingHeld' state to the > 'canceled' state. The implementation MAY keep the > 'jobHoldSpecified' reason set during the remaining life of the job. > > > I'm also trying to understand your concerns about the wording below: > > At 15:37 08/27/97 PDT, Ron Bergman wrote: > >Tom, > > > >I still do not like the disputed text and do not believe that it properly > >answers the question. I propose as an alternative: > > > > "Since the Job State Reasons will be more dynamic than the Job State, > > it is recommended that a job monitoring application read this object > > every time the current Job State is updated." > > > >This presents the same idea from a different perspective and also > >eliminates the tone of the previous statement that "this object is > >special and must be valid". And also implies that other objects do > >not have to be valid since I did not explicitly say so. > > I'm still puzzled as to why you think the phrase: "when implemented as > with any MIB data" makes the reasons be special. The statement is trying > to say that reasson, like any other MIB data, must agree with the conditions > of the device. > RB-- My point is, we write a specification which defines the meaning RB-- for an object. We should not then have to then say, "if you RB-- implement this object, it must be valid". > I'm also puzzled as to why you think that the same phrase: "when implemented > as with any MIB data" allows any other MIB data to not be valid? > RB-- By making a special case here it could be implied. If this is true RB-- for all other MIB data, why does have to be stated explicity here? > Is there a better way to say that reasons must be just as valid as > other MIB objects and attributes and that reasons must not become stale > (as with any other MIB data)? RB-- Good implementations always present valid information and should RB-- not have to be explicity told. I am trying to answer the question RB-- in, what I believe, is a better point of view. By indicating that RB-- the Monitoring Ap must look at this often implies what you have RB-- been trying to say. Again, I do not disagree with your statement, RB-- I just do not feel it belongs in the document. > > Tom > > > > >Again, this is a minor issue and I am being somewhat hard-nosed, but > >I would like to get the wording correct now. > > > > > > ...Ron > > > > > >On Tue, 26 Aug 1997, Tom Hastings wrote: > > > >> At 16:59 08/20/97 PDT, Ron Bergman wrote: > >> snip... > >> > >> >> >6. In jmJobStateReasons1 (page #81), I find the following statement > >> >> > hard to disagree with, but why do we need to state this? > >> >> > > >> >> > "Furthermore, when implemented as with any MIB data, the > >> >> > agent SHALL return these values when the reason applies and > >> >> > SHALL NOT return them when the reason no longer applies whether > >> >> > the value of the job's jmJobState object changed or not." > >> >> > > >> >> > All this really states is that the value of an object must be valid. > >> >> > We do not have a similar statement for any other object. > >> >> > >> >> I disagree. One commentor asked whether the bits had to be turned off or > >> not, > >> >> so I felt it was important to clarify that these bits are meaningful while > >> >> the job is in each job state, not just when the job transitions from one > >> >> state to another. There are hardware implementations in which such bits > >> >> are only meaningful on the state transitions. As far as I'm concerned, > >> >> if someone asks about something it can't hurt to include the explanation > >> >> in the document. There will be others who will ask the same question, but > >> >> we won't be there to answer. > >> >> > >> >Since the question was asked, this should be in the FAQ and not in the > >> >specification. All this sentence states is "thou shall not lie". If > >> >the document states that this attribute indicates this condition and > >> >the implementation sets the attribute when the condition is not true, > >> >the implementation is violating the specification! I do not believe > >> >that the document should answer every question that was asked. That > >> >is why we should have a FAQ. > >> > >> The question was asked about the text that was in the spec. I believe > >> that the FAQ should be answering questions that people have how haven't > >> read the document or are getting into it. Of course, after we publish > >> the specification, we can also use the FAQ to answer questions of > interpretation > >> of the standard, which would be better than nothing (since we can no longer > >> update the spec). > >> > >> So if we have a question about interpretation of the text in the spec > >> BEFORE the spec is published, the answer should go in the spec. > >> > >> Also from my experience with hardware devices, such as PDP-11 I/O > devices, the > >> question was whether the bits where only to be sampled when a job state > >> transition occurred, such as in some I/O devices, or could be sampled any > time. > >> > >> Finally, I took into account your concern/question about "why wouldn't we > >> have to make a similar statement about other objects in the MIB", by adding > >> the phrase: "as with any MIB data", so we don't have to add the phrase > >> to any other object. > >> > >> Since you said it was hard to disagree with, lets leave it in. Ok? > >> > >> Tom > >> > >> > >> > > > > > > > > From hastings at cp10.es.xerox.com Thu Aug 28 20:51:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> MOD - Re: JobStateReasons -1 [semantics of canceledByOperator] In-Reply-To: Message-ID: <9708290054.AA19056@zazen.cp10.es.xerox.com> Harry, Its very helpful to have your list of the job-state-reasons that you implemented in your Job Monitoring MIB and your interpretation of the job-state-reasons. Since the job-state-reasons that are in the JMP jmJobStateReasons1 object are intended to be the same as the IPP "job-state-reasons" attribute, we need to keep them sematically in synch. So I have copied the IPP DL as well on this. The only description that I have some question about as you draw attention to is the distinction that you make between the canceledByUser and canceledByOperator reasons: you use the canceledByOperator when a local user cancels a job. Now is the time to clarify/fix the specification. Do you have the concept of a remote operator who has more privileges than a remote user? For example, can a remote operator cancel any job, while a remote user can only cancel his/her own jobs? That was the intent of the canceledByUser versus the canceledByOperator reason (in DPA and IPP and other systems). However, you bring up a new kind of user: the local/walkup user who may have more privileges than a remote user, while having less privileges (or the same privileges) as a remote operator. Does your walkup user have to identify himself/herself to the system somehow, so that the system can prevent such a user from canceling some other user's job? Or can the local user cancel any user's job? Or can the local user cancel only the current job? We at Xerox have been wrestling with the special status of the walkup user at the local console of the machine, as well. Since the policy of such a local/walkup user may be more privileged than a remote user, but not as privileged as a remote (or local) operator, we have seen the need to introduce this additional category of user. Social pressure may be the only way to reduce the abuse of the privileges of a walkup/local user for systems where the policy is to grant local users more privileges than remote users. The current specs for the two canceled reasons are: JMP: jobCanceledByUser 0x800 The job was canceled by the user, i.e., by an unknown user or by a user whose name is the same as the value of the job's jmJobOwner object. jobCanceledByOperator 0x1000 The job was canceled by the operator, i.e., by a user whose name is different than the value of the job's jmJobOwner object. IPP: 'job-cancelled-by-user': The job was cancelled by the user using the CancelJob request, i.e., by a user whose name is the same as the value of the job's "job-originating-user" attribute. 'job-cancelled-by-operator': The job was cancelled by the operator using the CancelJob request, i.e., by a user whose name is different than the value of the job's "job-originating-user" attribute. [We ought to agree on whether canceled as one or two l's.] MS-WORDs spell checker prefers one leter l, though I suspect that both are correct. So I see two alternative for the specification (and IPP): 1. Generalize the canceledByOperator to include the local/walkup user 2. Add a new reason: canceledByLocalUser I prefer the second alternative, since it is then clear to the remote user (job owner) why/who canceled his/her job. So that for systems that do have remote operators, the distinction can be made between the remote operator and a local user by having two separate reasons. Comments? Tom At 10:06 08/28/97 PDT, Harry Lewis wrote: >In review, we have one final request to move a jobStateReason. We would >like to see submissionInterrupted moved into Reasons-1. > >I would also like to share the jobStateReasons which we have found the >most practical and useful. > > >deviceStopped - open cover, paper jam etc. > >jobPrinting - from first to last page unless there is an error or the > printer goes offline > >submissionInterrupted - I/O timeout occurs > >processingToStoppedPoint - between cancel request and actual end of > cancel operation [I'll proposing adding to IPP in a separate e-mail, since we've moved it into jmJobStateReasons1 in JMP]. > >serviceOffline - printer is offline (with or without errors) [I'll proposing adding to IPP in a separate e-mail, since JMP is considering moving it into jmJobStateReasons1 in JMP]. > >canceledByOperator - canceled at the printer > >canceledByUser - canceled remotely > > >We think there is benefit in a design that relies mainly on the Reasons-1 >category due to it's mandatory distinction. This is why we have requested >a few jobStateReasons be moved to Reasons-1. > >I'd like to offer our interpretation, above, as sort of a "Top 7" (akin to >the Alert table top 25) and see if others agree. I know, offhand, that our >interpretation of the canceled reasons is a bit different than the strict >definitions and may not fit the server implementation exactly. If anyone >reads the strict definitions, when you are finished chuckling, you may >want to help explain them. I think they're from DPA;-) ;-) ;-). Please point out what is puzzling, so we can fix it. > > >Harry Lewis > > From rbergma at dpc.com Fri Aug 29 10:45:16 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Operating System Types In-Reply-To: <9708271632.AA18447@zazen.cp10.es.xerox.com> Message-ID: <9708290054.AA19056@zazen.cp10.es.xerox.com> Tom, The changes that you stated are what I also recall as the agreement. ...Ron On Wed, 27 Aug 1997, Tom Hastings wrote: > The minutes said that we agreed to add Windows98, but I thought we agreed > to change the Windows95 to just plain Windows, so that we wouldn't have > to keep adding new operating system times when new versions came out. > > But I didn't edit either one in V0.85. > > Also why is Netware given the value of 33, instead of the next sequential > number? I think I made a typo here. > > Here is the current version: > > JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The source platform type that can submit jobs to servers or devices in any > of the 3 configurations." > REFERENCE > "This is a type 2 enumeration. See Section 3.6.1.2." > SYNTAX INTEGER { > other(1), > unknown(2), > sptUNIX(3), -- UNIX(tm) > sptOS2(4), -- OS/2 > sptPCDOS(5), -- DOS > sptNT(6), -- NT > sptMVS(7), -- MVS > sptVM(8), -- VM > sptOS400(9), -- OS/400 > sptVMS(10), -- VMS > sptWindows95(11), -- Windows95 > sptNetWare(33) -- NetWare > } > > > I propose to change the last two entries to: > > sptWindows(11), -- Windows > sptNetWare(12) -- NetWare > > Ok? > > Tom > > From harryl at us.ibm.com Fri Aug 29 11:01:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> MOD - Re: JobStateReasons -1 [semantics of canceledByOp In-Reply-To: Message-ID: <5030300009588020000002L002*@MHS> Tom, thanks for the thorough overview of possibilities related to job cancel. This topic could easily be drawn out due to distinct differences in the worlds of office network printing, operated print farms and heavy duty production environments with both system and (logged on) machine operators. I'll cut to the chase and say I'd probably go with your recommendation >2. Add a new reason: canceledByLocalUser > >I prefer (this) alternative, since it is then clear to the remote >user (job owner) why/who canceled his/her job. So that for systems >that do have remote operators, the distinction can be made between >the remote operator and a local user by having two separate reasons. but for a slightly different reason. Basically, if you look at it from the point of view of an agent in a standard network printer, the agent may distinguish between a cancel at the opPanel vs. some other means, but it is less likely to recognize the name of the person initiating either form of cancel and match it with the person who initiated the job (per the DPA definition). So I feel it will be common for "network printers", at best, to distinguish what I call LOCAL and REMOTE cancel. I don't have a problem preserving the DPA definitions for large scale systems. However, given that there remain 2 definitions for REMOTE cancel ("by User" and "by Operator"), many printers will have to "guess". I suggest "by User" because Operator has a bit more connotation of someone who might be standing at or near the printer (granted, not in all environments). Harry Lewis ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 08/29/97 08:22 AM --------------------------- jmp-owner@pwg.org on 08/29/97 12:35:50 AM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: ipp@pwg.org @ internet, jmp@pwg.org @ internet Subject: JMP> MOD - Re: JobStateReasons -1 [semantics of canceledByOp Harry, Its very helpful to have your list of the job-state-reasons that you implemented in your Job Monitoring MIB and your interpretation of the job-state-reasons. Since the job-state-reasons that are in the JMP jmJobStateReasons1 object are intended to be the same as the IPP "job-state-reasons" attribute, we need to keep them sematically in synch. So I have copied the IPP DL as well on this. The only description that I have some question about as you draw attention to is the distinction that you make between the canceledByUser and canceledByOperator reasons: you use the canceledByOperator when a local user cancels a job. Now is the time to clarify/fix the specification. Do you have the concept of a remote operator who has more privileges than a remote user? For example, can a remote operator cancel any job, while a remote user can only cancel his/her own jobs? That was the intent of the canceledByUser versus the canceledByOperator reason (in DPA and IPP and other systems). However, you bring up a new kind of user: the local/walkup user who may have more privileges than a remote user, while having less privileges (or the same privileges) as a remote operator. Does your walkup user have to identify himself/herself to the system somehow, so that the system can prevent such a user from canceling some other user's job? Or can the local user cancel any user's job? Or can the local user cancel only the current job? We at Xerox have been wrestling with the special status of the walkup user at the local console of the machine, as well. Since the policy of such a local/walkup user may be more privileged than a remote user, but not as privileged as a remote (or local) operator, we have seen the need to introduce this additional category of user. Social pressure may be the only way to reduce the abuse of the privileges of a walkup/local user for systems where the policy is to grant local users more privileges than remote users. The current specs for the two canceled reasons are: JMP: jobCanceledByUser 0x800 The job was canceled by the user, i.e., by an unknown user or by a user whose name is the same as the value of the job's jmJobOwner object. jobCanceledByOperator 0x1000 The job was canceled by the operator, i.e., by a user whose name is different than the value of the job's jmJobOwner object. IPP: 'job-cancelled-by-user': The job was cancelled by the user using the CancelJob request, i.e., by a user whose name is the same as the value of the job's "job-originating-user" attribute. 'job-cancelled-by-operator': The job was cancelled by the operator using the CancelJob request, i.e., by a user whose name is different than the value of the job's "job-originating-user" attribute. [We ought to agree on whether canceled as one or two l's.] MS-WORDs spell checker prefers one leter l, though I suspect that both are correct. So I see two alternative for the specification (and IPP): 1. Generalize the canceledByOperator to include the local/walkup user 2. Add a new reason: canceledByLocalUser I prefer the second alternative, since it is then clear to the remote user (job owner) why/who canceled his/her job. So that for systems that do have remote operators, the distinction can be made between the remote operator and a local user by having two separate reasons. Comments? Tom At 10:06 08/28/97 PDT, Harry Lewis wrote: >In review, we have one final request to move a jobStateReason. We would >like to see submissionInterrupted moved into Reasons-1. > >I would also like to share the jobStateReasons which we have found the >most practical and useful. > > >deviceStopped - open cover, paper jam etc. > >jobPrinting - from first to last page unless there is an error or the > printer goes offline > >submissionInterrupted - I/O timeout occurs > >processingToStoppedPoint - between cancel request and actual end of > cancel operation [I'll proposing adding to IPP in a separate e-mail, since we've moved it into jmJobStateReasons1 in JMP]. > >serviceOffline - printer is offline (with or without errors) [I'll proposing adding to IPP in a separate e-mail, since JMP is considering moving it into jmJobStateReasons1 in JMP]. > >canceledByOperator - canceled at the printer > >canceledByUser - canceled remotely > > >We think there is benefit in a design that relies mainly on the Reasons-1 >category due to it's mandatory distinction. This is why we have requested >a few jobStateReasons be moved to Reasons-1. > >I'd like to offer our interpretation, above, as sort of a "Top 7" (akin to >the Alert table top 25) and see if others agree. I know, offhand, that our >interpretation of the canceled reasons is a bit different than the strict >definitions and may not fit the server implementation exactly. If anyone >reads the strict definitions, when you are finished chuckling, you may >want to help explain them. I think they're from DPA;-) ;-) ;-). Please point out what is puzzling, so we can fix it. > > >Harry Lewis > > From rbergma at dpc.com Fri Aug 29 10:50:54 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> JobStateReasons -1 In-Reply-To: <5030300009484183000002L032*@MHS> Message-ID: <5030300009588020000002L002*@MHS> Since no objections to Harry's proposed change (and this could be classified as editorial), this change will be accepted. ...Ron On Thu, 28 Aug 1997, Harry Lewis wrote: > In review, we have one final request to move a jobStateReason. We would > like to see submissionInterrupted moved into Reasons-1. > > I would also like to share the jobStateReasons which we have found the > most practical and useful. > > > deviceStopped - open cover, paper jam etc. > > jobPrinting - from first to last page unless there is an error or the > printer goes offline > > submissionInterrupted - I/O timeout occurs > > processingToStoppedPoint - between cancel request and actual end of > cancel operation > > serviceOffline - printer is offline (with or without errors) > > canceledByOperator - canceled at the printer > > canceledByUser - canceled remotely > > > We think there is benefit in a design that relies mainly on the Reasons-1 > category due to it's mandatory distinction. This is why we have requested > a few jobStateReasons be moved to Reasons-1. > > I'd like to offer our interpretation, above, as sort of a "Top 7" (akin to > the Alert table top 25) and see if others agree. I know, offhand, that our > interpretation of the canceled reasons is a bit different than the strict > definitions and may not fit the server implementation exactly. If anyone > reads the strict definitions, when you are finished chuckling, you may > want to help explain them. I think they're from DPA;-) ;-) ;-). > > > Harry Lewis > From harryl at us.ibm.com Fri Aug 29 15:45:28 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel Message-ID: <5030300009612943000002L032*@MHS> We've had a bit of debate, here, about whether, upon detecting a cancel request, the agent should A. STATE=Processing REASON=processing to stop point B. STATE=Cancel REASON=processing to stop point We were dealing with plan B when we requested processingToStoppedPoint moved into Reasons-1. Our current debate does not effect that change, or require any new adjustments to the job MIB. We are more convinced, now that plan A is better and I only offer this as an interoperability issue. The crux of the discussion is whether it's better to change State to Cancel ASAP upon recognizing the request (B) or not change State to CANCEL until the cancel operation is complete and all MIB values are in their final state. Earlier, we thought it necessary to reflect the Cancel REQUEST for timely user feedback but now we think it better to favor deterministic behavior from an accounting point of view. Being remote, the user probably won't be effected by the "lag" - and if an application really wants to, it can sense, from the reason, that a cancel must be in process. I'm open to comments. I'd like to reach agreement and include a FAQ entry stating that, since CANCEL is a *completion* state, the transition should not take place until CANCEL is complete. Harry Lewis - IBM Printing Systems From SISAACSON at novell.com Fri Aug 29 16:59:56 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel In-Reply-To: Cancel> Message-ID: I am cross posting this to IPP because I believ that it has relevance to the semantics of the IPP Cancel-Job operation .. Harry writes: >>> Harry Lewis 08/29 1:45 PM >>> > We've had a bit of debate, here, about whether, upon detecting a cancel > request, the agent should > A. STATE=Processing REASON=processing to stop point > B. STATE=Cancel REASON=processing to stop point > ... > The crux of the discussion is whether it's better to change State to Cancel > ASAP upon recognizing the request (B) or > not change State to CANCEL until the cancel operation is complete and all > MIB values are in their final state. I agree with Harry that the solution should be to allow an implementation to acknowledge the cancel request yet not force it to move the job state to the cancelled immediately. It has been our experience that many implementations can NOT immediately and completely realize the full cancel semantics at the exact moment in time that a cancel request is recieved: page images may have been buffered up, paper might still be flowing through the print path, some devices simply don't support any notion of cancel at all. It is much better to allow an implementation the option of keeping the job in the 'processing' state and set a reason to 'processing-to-stop-point' rather than forcing it to move the job to the 'cancelled' state. When the implementation finally does move the job to the 'cancelled' state, then all parties can be assured that there will not be any more changes to any of the other job size and resource type attributes. I propose that this be the semantics that we apply to the Cancel-Job IPP operation. If the response to the Cancel-Job comes back as "ok", the implementation is confirming that it is doing all it can to cancel the job not that the job state is now cancelled. However, the implementation is indicating that the job state will eventually be set to 'cancelled' rather than 'completed' - this might not not happen though until some point in time after the response is sent back. If the implementation supports the "job-state-reasons" attribute, one of the reasons MUST include 'processing-to-stop-point' after receiving the Cancel-Job request. Scott From hastings at cp10.es.xerox.com Fri Aug 29 18:44:42 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: Open Editorial Changes From Rev. 0.83: 6. when job> Message-ID: <9708292247.AA19382@zazen.cp10.es.xerox.com> At 18:46 08/28/97 PDT, Ron Bergman wrote: >Tom, > >I understand exactly what you you mean. That is not the issue. > >What I was trying to say in my new wording is that the Job Monitor Ap >should read the Job State Reasons every time he attempted to update (i.e. >read) the job state. He may read the job state many times before it >changes. My meaning of "update" was "the monitor reads the job state". > >So let me reword again: > > "Since the Job State Reasons will be more dynamic than the Job State, > it is recommended that a job monitoring application read this object > every time jmJobState is read." > >Is this better? Much better! I can live with it. > > ...Ron > > > >On Thu, 28 Aug 1997, Tom Hastings wrote: > >> Ron, >> >> Lets keep the discussion going on job state reasons, because your proposed >> workding is just what I am worried about. My understanding of your proposed >> wording suggests that the agent only need make the reasons be correct, >> when the job state changes. This is exactly the interpretation that >> the participant asked if it was ok to only make the reason be correct >> when the job changed state (and was like the old PDP-11 devices). >> >> In fact, an application is encouraged to look at the reasons whenever >> it looks at the job. Also since we don't have trapping, there is no >> way for an application to know when a job actually changes state, except >> to notice that the job state value is different on the current poll cycle >> from the last poll cycle. >> >> I want to make it clear that the job state reason value(s) may: >> >> 1. change when the job state changes (the usual case) >> >> Example: job changes state from 'processing' to 'completed' and the >> 'jobCompletedSuccessfully' reason is set at the same time. This reason >> remains set for the entire remaining life of the job in the 'completed' >> state. >> >> 2. change while the job state does not change, i.e., some job state >> reasons may come and go while a job remains in the same state >> (less likely) >> >> Example: the job is in the 'pending' state and the printer stops, >> so the reason 'deviceStopped' comes and goes while the job remains >> in the 'pending' state. >> >> Example: the job is canceled so the job transitions from 'processing' >> to 'canceled', with the (new) 'processingToStopPoint' reason is set >> and the 'jobPrinting' reason may be set. >> However, while the job is in the 'canceled' state, the processing to >> stop point completes and the marking media completes, so that the >> 'processingToStopPoint' and the 'jobPrinting' reasons go away (and >> not necessarily at the same time). >> >> 3. remain the same while a job changes state (rare, but possible). >> >> Example: a job with the "jobHold" attribute set would have the >> 'jobHoldSpecified' reason set as well. However, if the job was >> canceled, the job would change from the 'pendingHeld' state to the >> 'canceled' state. The implementation MAY keep the >> 'jobHoldSpecified' reason set during the remaining life of the job. >> >> >> I'm also trying to understand your concerns about the wording below: >> >> At 15:37 08/27/97 PDT, Ron Bergman wrote: >> >Tom, >> > >> >I still do not like the disputed text and do not believe that it properly >> >answers the question. I propose as an alternative: >> > >> > "Since the Job State Reasons will be more dynamic than the Job State, >> > it is recommended that a job monitoring application read this object >> > every time the current Job State is updated." >> > >> >This presents the same idea from a different perspective and also >> >eliminates the tone of the previous statement that "this object is >> >special and must be valid". And also implies that other objects do >> >not have to be valid since I did not explicitly say so. >> >> I'm still puzzled as to why you think the phrase: "when implemented as >> with any MIB data" makes the reasons be special. The statement is trying >> to say that reasson, like any other MIB data, must agree with the conditions >> of the device. >> >RB-- My point is, we write a specification which defines the meaning >RB-- for an object. We should not then have to then say, "if you >RB-- implement this object, it must be valid". > >> I'm also puzzled as to why you think that the same phrase: "when implemented >> as with any MIB data" allows any other MIB data to not be valid? >> >RB-- By making a special case here it could be implied. If this is true >RB-- for all other MIB data, why does have to be stated explicity here? > >> Is there a better way to say that reasons must be just as valid as >> other MIB objects and attributes and that reasons must not become stale >> (as with any other MIB data)? > >RB-- Good implementations always present valid information and should >RB-- not have to be explicity told. I am trying to answer the question >RB-- in, what I believe, is a better point of view. By indicating that >RB-- the Monitoring Ap must look at this often implies what you have >RB-- been trying to say. Again, I do not disagree with your statement, >RB-- I just do not feel it belongs in the document. >> >> Tom >> >> > >> >Again, this is a minor issue and I am being somewhat hard-nosed, but >> >I would like to get the wording correct now. >> > >> > >> > ...Ron >> > >> > >> >On Tue, 26 Aug 1997, Tom Hastings wrote: >> > >> >> At 16:59 08/20/97 PDT, Ron Bergman wrote: >> >> snip... >> >> >> >> >> >6. In jmJobStateReasons1 (page #81), I find the following statement >> >> >> > hard to disagree with, but why do we need to state this? >> >> >> > >> >> >> > "Furthermore, when implemented as with any MIB data, the >> >> >> > agent SHALL return these values when the reason applies and >> >> >> > SHALL NOT return them when the reason no longer applies whether >> >> >> > the value of the job's jmJobState object changed or not." >> >> >> > >> >> >> > All this really states is that the value of an object must be valid. >> >> >> > We do not have a similar statement for any other object. >> >> >> >> >> >> I disagree. One commentor asked whether the bits had to be turned off or >> >> not, >> >> >> so I felt it was important to clarify that these bits are meaningful while >> >> >> the job is in each job state, not just when the job transitions from one >> >> >> state to another. There are hardware implementations in which such bits >> >> >> are only meaningful on the state transitions. As far as I'm concerned, >> >> >> if someone asks about something it can't hurt to include the explanation >> >> >> in the document. There will be others who will ask the same question, but >> >> >> we won't be there to answer. >> >> >> >> >> >Since the question was asked, this should be in the FAQ and not in the >> >> >specification. All this sentence states is "thou shall not lie". If >> >> >the document states that this attribute indicates this condition and >> >> >the implementation sets the attribute when the condition is not true, >> >> >the implementation is violating the specification! I do not believe >> >> >that the document should answer every question that was asked. That >> >> >is why we should have a FAQ. >> >> >> >> The question was asked about the text that was in the spec. I believe >> >> that the FAQ should be answering questions that people have how haven't >> >> read the document or are getting into it. Of course, after we publish >> >> the specification, we can also use the FAQ to answer questions of >> interpretation >> >> of the standard, which would be better than nothing (since we can no longer >> >> update the spec). >> >> >> >> So if we have a question about interpretation of the text in the spec >> >> BEFORE the spec is published, the answer should go in the spec. >> >> >> >> Also from my experience with hardware devices, such as PDP-11 I/O >> devices, the >> >> question was whether the bits where only to be sampled when a job state >> >> transition occurred, such as in some I/O devices, or could be sampled any >> time. >> >> >> >> Finally, I took into account your concern/question about "why wouldn't we >> >> have to make a similar statement about other objects in the MIB", by adding >> >> the phrase: "as with any MIB data", so we don't have to add the phrase >> >> to any other object. >> >> >> >> Since you said it was hard to disagree with, lets leave it in. Ok? >> >> >> >> Tom >> >> >> >> >> >> >> > >> > >> > >> >> > > > From rbergma at dpc.com Fri Aug 29 19:26:37 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Open Editorial Changes From Rev. 0.83: 6. when job In-Reply-To: <9708292247.AA19382@zazen.cp10.es.xerox.com> Message-ID: <9708292247.AA19382@zazen.cp10.es.xerox.com> Great! This closes the last of my issues. The text from my 8/28/97 email will replace the existing text from issue 6. The existing text: "Furthermore, when implemented as with any MIB data, the agent SHALL return these values when the reason applies and SHALL NOT return them when the reason no longer applies I hope everyone has a good weeked! I certainly will! ...Ron On Fri, 29 Aug 1997, Tom Hastings wrote: > At 18:46 08/28/97 PDT, Ron Bergman wrote: > >Tom, > > > >I understand exactly what you you mean. That is not the issue. > > > >What I was trying to say in my new wording is that the Job Monitor Ap > >should read the Job State Reasons every time he attempted to update (i.e. > >read) the job state. He may read the job state many times before it > >changes. My meaning of "update" was "the monitor reads the job state". > > > >So let me reword again: > > > > "Since the Job State Reasons will be more dynamic than the Job State, > > it is recommended that a job monitoring application read this object > > every time jmJobState is read." > > > >Is this better? > > Much better! I can live with it. > From rbergma at dpc.com Fri Aug 29 19:39:45 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel In-Reply-To: <5030300009612943000002L032*@MHS> Message-ID: <9708292247.AA19382@zazen.cp10.es.xerox.com> Harry, This was my original position when this issue was first discussed. I backed down when it was desired to only use jmJobState to indicate to the user that the job was indeed cancelled. I certainly support your change in position. ...Ron On Fri, 29 Aug 1997, Harry Lewis wrote: > We've had a bit of debate, here, about whether, upon detecting a cancel > request, the agent should > > A. STATE=Processing REASON=processing to stop point > > B. STATE=Cancel REASON=processing to stop point > > We were dealing with plan B when we requested processingToStoppedPoint moved > into Reasons-1. Our current debate does not effect that change, or require any > new adjustments to the job MIB. We are more convinced, now that > plan A is better and I only offer this as an interoperability issue. > > The crux of the discussion is whether it's better to change State to Cancel > ASAP upon recognizing the request (B) or > not change State to CANCEL until the cancel operation is complete and all MIB > values are in their final state. Earlier, we thought it necessary to reflect > the Cancel REQUEST for timely user feedback but now we think it better to favor > deterministic behavior from an accounting point of view. Being remote, the user > probably won't be effected by the "lag" - and if an application really wants > to, it can sense, from the reason, that a cancel must be in process. > > I'm open to comments. > > I'd like to reach agreement and include a FAQ entry stating that, since CANCEL > is a *completion* state, the transition should not take place until CANCEL is > complete. > > Harry Lewis - IBM Printing Systems > From papowell at astart.com Fri Aug 29 20:01:48 1997 From: papowell at astart.com (papowell@astart.com) Date: Wed May 6 14:00:09 2009 Subject: JMP> Unix(tm)? Message-ID: <199708300001.RAA08966@astart2.astart.com> I note that in your postings about adding JmJobSourcePlatformTypeTC that UNIX(TM) was in the list. In actual fact, most of the others are also (TM). Consistency would call for tracking down the (TM)s of all of the others or removing the (tm) for UNIX. Patrick ("nity picky") Powell From hastings at cp10.es.xerox.com Fri Aug 29 20:31:28 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel In-Reply-To: Cancel> Message-ID: <9708300034.AA19463@zazen.cp10.es.xerox.com> Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Sat Aug 30 12:02:05 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel In-Reply-To: Cancel> Message-ID: <5030300009649734000002L042*@MHS> Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From imcdonal at eso.mc.xerox.com Sun Aug 31 19:16:00 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:09 2009 Subject: JMP> Cancel In-Reply-To: Cancel> Message-ID: <9708312316.AA05296@snorkel.eso.mc.xerox.com> Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Tue Sep 2 00:21:15 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:09 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Cancel> Message-ID: <5030300009721184000002L042*@MHS> Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From imcdonal at eso.mc.xerox.com Tue Sep 2 10:27:28 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:09 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: <9709021427.AA05562@snorkel.eso.mc.xerox.com> Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From moore at cs.utk.edu Tue Sep 2 16:48:52 1997 From: moore at cs.utk.edu (Keith Moore) Date: Wed May 6 14:00:09 2009 Subject: JMP> Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-Reply-To: Re: PMP> IETF concerns regarding the Printer MIB draft?> Message-ID: <199709022048.QAA00161@spot.cs.utk.edu> A followup to this note from Harald: Harald explained the issues well. However, I do want to personally apologize for my poor choices of words at the Munich meeting re: the Printer MIB and the Job MIB. Keith > Oops control, as usual.... > > The Applications Area Directors do not think that the Printer MIB is > broken. > > The Apps ADs think that one particular decision was mistaken: > To establish a register of print languages (the prtInterpreterLangFamily) > and not to register those as MIME types. > > We also have doubts about the use of integers rather than names for > character sets (the CodedCharSet textual convention), but since this > is just 2 pointers into the same registry, and the IANA appears to be > maintaining this double registry, it is less harmful overall. > > We think the Right Thing is that the IPP group or the PrinterMIB group > should register all the currently unregistered printer formats as MIME > types, and that the IPP group should use the MIME types to indicate the > content of their MIME objects. > > With regard to the Job MIB, it seems clear that: > > - The IETF has no consensus position that it is a Good Thing to deploy > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the idea > that all users need MIB access; we do not want to bring this idea into > that process, for fear of delaying it further. > > - The IETF has consensus that there is no need for all MIBs to be > Internet standards. Informational MIBs, or MIBs developed by other > organizations, are Good Things; the IETF can sometimes assist in their > reviews, without necessarily taking responsibility. > > - Given the two positions above, we think that it's better for the > Job MIB to be submitted to the IETF as an external document and given > Informational status as a protocol under PWG control. > > There was some unfortunate fumbling of balls in the handover of this > group from the NM area to the Apps area, where the status of this request > for revised charter seemed to have been lost; I had hoped that we had > agreement on the positions above, but it seems that we didn't. > > (this discussion should be moved to the Printer MIB list only, but since > it seems I've fallen off it, please keep me in the CC line....) > > Harald Tveit Alvestrand > Apps AD > > > > > From harryl at us.ibm.com Wed Sep 3 12:00:08 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: <5030300009845956000002L062*@MHS> Ira, I hope we can satisfy both our concerns by recognizing that job state reasons are bits and there can be more than one reason at a time. So, in the Processing state, the reasons can be "processingToStopPoint" and "canceledByUser". I would prefer this as the interoperable model as opposed to insisting the CANCEL state be entered immediately. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ---- imcdonal@eso.mc.xerox.com on 09/02/97 09:51:55 AM Please respond to imcdonal@eso.mc.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: JMP> Cancel Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From rbergma at dpc.com Wed Sep 3 12:34:19 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Editorial Comments on Job MIB Version 0.85 Message-ID: <5030300009845956000002L062*@MHS> Tom, Please review the following comments and indicate which you will include and which require further discussion. I consider all of these editorial changes only. 1. New text on page 20, fourth paragraph: It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then the jobs will have the same job identifier value as the jmJobIndex value, so that users viewing jobs by management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. Change to: (The first part of the second sentence is a re-word of the first sentence and has no added value.) It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. 2. Page 21, second to last paragraph: NOTE - Application detect the end of the... Should be: NOTE - Applications detect the end of the... 3. New text on page 26, second paragrpah: NOTE - For a number of job submission protocols the server/device assigns an integer job identifier when accepting a job so that the submitting client can reference the job in subsequent protocol operations (For example, see IPP [ipp]). For such implementations, it is recommended that the value of the job identifier and the value of jmJobIndex be the same, so that First, this text is very similar to what is on page 20. Second, the last sentence is incomplete. 4. Revision to paragraph 3.5.1, page 26. The current text is clumsy. 3.5.1 Text generated by the server or device There are a few objects and attributes generated by the server or device that shall be represented using the Universal Multiple-Octet Coded Character Set (UCS) [ISO-10646]. These objects and attributes are always supplied (if implemented) by the agent, not by the job submitting client: 1. jmGeneralJobSetName object 2. processingMessage(6) attribute 3. physicalDevice(32) (name value) attribute The coded character set for representing these objects and attributes SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF Policy on Character Sets and Language" [char-set policy]. The 'JmUTF8StringTC' textual convention shall be used to indicate UTF-8 text strings. NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] encoding. 5. Change title of paragraph 3.5.2, page 26. 3.5.2 Text generated by the job submitter 6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph 3.5.1, which is also referenced here. This should be deleted. NOTE - The values of objects and attributes using this textual convention are generated by the server or the device, not by the job submitter. 7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph 3.5.2. "To facilitate internationalization, this TC represents information using any coded character set registered by IANA that has the following properties: (1) code positions from 0 to 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US- ASCII], (3) 127 SHALL be unused, and (4) the remaining code positions 128 to 255 SHALL represent single-byte or multi-byte graphic characters structured according to ISO 2022 [ISO 2022] or SHALL be unused. While it is recommended that the coded character set be UTF-8 [UTF-8], the actual coded character set SHALL be indicated by the value of the jobCodedCharSet(7) attribute for the job. NOTE - The values of objects and attributes using this textual convention are either generated by the job submitter or defaulted by the server or device when the job submitter does not supply values." Change to: "To facilitate internationalization, this TC represents information using any coded character set registered by IANA as specified in paragraph 3.5.2. While it is recommended that the coded character set be UTF-8 [UTF-8], the actual coded character set SHALL be indicated by the value of the jobCodedCharSet(7) attribute for the job." 8. Page 78, second paragraph. Change: ...formats that have been reserved to agents... To: ...formats that have been reserved for agents... 9. Page 81, jmNumberOfInterveningJobs. Change: "The number of jobs that are expected to complete being processed before this job has completed being processed according to the implementation's queuing algorithm if no other... To: "The number of jobs that are expected to complete processing before this job has completed processing according to the implementation's queuing algorithm, if no other... 10. Page 1, second paragraph. (Closing quote is in the wrong position.) as reference material or to cite them other than as "work in progress." Should be: as reference material or to cite them other than as "work in progress". Ron Bergman Dataproducts Corp. From imcdonal at eso.mc.xerox.com Wed Sep 3 15:52:22 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: <9709031952.AA06142@snorkel.eso.mc.xerox.com> Hi Harry, I agree entirely with your model for the states and state reasons (ie, show the leading edge of an operation via state reasons and the trailing edge via states). I wonder if we don't need an 'abortedBySystem' state reason, though. Even if the "cancel" was by the system (as an ABORT), could a job be 'processingToStopPoint' for awhile in one of your printers? I never liked making the transition to 'Cancelled' before th operation was actually completed. It doesn't feel right for resilience. Cheers, - Ira McDonald 906-494-2434 ----------------------------- Harry's note ----------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA06048; Wed, 3 Sep 97 12:00:39 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA12980; Wed, 3 Sep 97 11:56:14 EDT Received: from lms03.us1.ibm.com ([198.133.22.39]) by alpha.xerox.com with SMTP id <53385(3)>; Wed, 3 Sep 1997 08:56:55 PDT Received: from d03lms03.boulder.ibm.com by lms03.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA16984; Wed, 3 Sep 1997 14:47:37 GMT Received: by US1.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300009845956; Wed, 3 Sep 1997 12:00:08 -0400 From: Harry Lewis To: Cc: Subject: Re: IPP> Re: JMP> Cancel Message-Id: <5030300009845956000002L062*@MHS> Date: Wed, 3 Sep 1997 09:00:08 PDT Mime-Version: 1.0 Content-Type: text/plain Status: R Ira, I hope we can satisfy both our concerns by recognizing that job state reasons are bits and there can be more than one reason at a time. So, in the Processing state, the reasons can be "processingToStopPoint" and "canceledByUser". I would prefer this as the interoperable model as opposed to insisting the CANCEL state be entered immediately. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ---- imcdonal@eso.mc.xerox.com on 09/02/97 09:51:55 AM Please respond to imcdonal@eso.mc.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: JMP> Cancel Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- >From jmp-owner@pwg.org Tue Sep 2 00:26:09 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Wed Sep 3 15:51:45 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Re: PWG> The Printer Working Group as its own standards body In-Reply-To: The Printer Working Group as its own standards body> Message-ID: <9709031954.AA20292@zazen.cp10.es.xerox.com> Harald, For your review of the Job Monitoring MIB, our latest Job Monitoring MIB Internet-Draft has included indications of coded character set data for both the data originating from a job submitter and from a server. The latest draft also includes identifying documents-formats using the Printer MIB enums and the MIME-types. We are trying hard to meet the IETF and IESG requirements for a standards track document. The latest draft is: Tom At 01:02 08/21/97 PDT, Harald.T.Alvestrand@uninett.no wrote: >Jay, >good points. > >The relationship between the IETF and non-IETF groups has always been >worrisome; in some cases, we have seen things that looked as if someone >outside the IETF wanted to use the IETF as a tool to get the "community" >to endorse a position that couldn't be sold on its own merits, AND place >the IETF in a position where it couldn't insist on obvious weaknesses >in the protcol being repaired. >The discussions around Sun RPC and NFS focused around this issue; it is >also one of the things currently making the S/MIME debate so strident. > >In other cases, the IETF community knows that it does not add significant >value to the process of getting a standard done; the IETF is aggressively >uninterested in specifying the number of pins on serial plugs or the >precedence of operators in the C language, to name two instances, although >both efforts are obviously important to our user community. >Recent instances are our non-involvement in the SET payment protocol and >our closing down of work on HTML. >(This is of course a fluid point, since the set of people in the IETF >community, >and therefore its expertise, changes over time - after all, the IPP *is* >part of the IETF community.) > >The standards process is the process the IETF has that places a stamp >of approval on specifications. Obviously, we have to be careful what we >use it for. > >The IETF should, IMHO, NOT standardize things in the following cases: > >- The proposal is not going to be used in or around the Internet >- The proposal cannot be evaluated by IETF experts for lack of competence >- The proposal cannot be modified if the IETF community thinks that it > needs modification >- The proposal does not fit with IETF policy > >The last one is a flexible point again; some examples include requiring use of >patented or encumbered technology when freely available alternatives >exist, mandating use of cleartext passwords, standardizing very complex >protocols when simpler solutions solve most of the problem. >It's a judgment call. > >Since the bandwidth of those who have to do the judging (the IESG) is limited, >and since we know we're not infallible, we don't want this process to limit >publication of documents, even though we don't necessarily agree with them. > >Therefore, RFC publication, which has a reputation as a stable reference, >is available for non-IETF documents in "informational" form. We sometimes >ask for review of informationals, but only attempt to block publication of >them when we regard the content as misleading (such as labelling itself >"Internet Standard") or that publication would lead to confusion in the >community (such as having a fight about 2 approaches in a WG, and the >"loser" being published before the "standard"). > >I've scheduled the Job MIB on my list of things to look at; let's hope >things get sorted out correctly! >Regards, > > Harald T. Alvestrand > > > > > > From harryl at us.ibm.com Thu Sep 4 11:03:54 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: <5030300009932619000002L092*@MHS> Ira, I'm glad we seem to be reaching agreement. If you'll look on pg60, line 2357 of the v0.85 Job MIB, you'll find we already have the abortedBySystem reason you wished for ;-). It's even part of reasons-1... so that's good news. We feel it is sufficient to transition directly from PROCESSING - jobPrinting to ABORTED - abortedBySystem, however. This is a different situation than CANCEL, were someone has initiated a process and may be looking for leading edge feedback prior to completion of that process. With an abort by the printer, itself, even if the system recognizes the leading edge of the abort (i.e. maybe an I/O time-out?), then has to flush 3 pages (ex). to complete the abort, I'm not sure the value of showing PROCESSING - abortedBySystem as opposed to simply ABORTED - abortedBySystem. I would not strongly object to this useage... from an interoprability point of view, however, I wouldn't recommend it unless further convinced. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis 09/04/97 08:43 AM ---- jmp-owner@pwg.org on 09/03/97 09:44:09 PM Please respond to jmp-owner@pwg.org @ internet To: imcdonal@eso.mc.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: IPP> Re: JMP> Cancel Hi Harry, I agree entirely with your model for the states and state reasons (ie, show the leading edge of an operation via state reasons and the trailing edge via states). I wonder if we don't need an 'abortedBySystem' state reason, though. Even if the "cancel" was by the system (as an ABORT), could a job be 'processingToStopPoint' for awhile in one of your printers? I never liked making the transition to 'Cancelled' before th operation was actually completed. It doesn't feel right for resilience. Cheers, - Ira McDonald 906-494-2434 ----------------------------- Harry's note ----------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA06048; Wed, 3 Sep 97 12:00:39 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA12980; Wed, 3 Sep 97 11:56:14 EDT Received: from lms03.us1.ibm.com ([198.133.22.39]) by alpha.xerox.com with SMTP id <53385(3)>; Wed, 3 Sep 1997 08:56:55 PDT Received: from d03lms03.boulder.ibm.com by lms03.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA16984; Wed, 3 Sep 1997 14:47:37 GMT Received: by US1.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300009845956; Wed, 3 Sep 1997 12:00:08 -0400 From: Harry Lewis To: Cc: Subject: Re: IPP> Re: JMP> Cancel Message-Id: <5030300009845956000002L062*@MHS> Date: Wed, 3 Sep 1997 09:00:08 PDT Mime-Version: 1.0 Content-Type: text/plain Status: R Ira, I hope we can satisfy both our concerns by recognizing that job state reasons are bits and there can be more than one reason at a time. So, in the Processing state, the reasons can be "processingToStopPoint" and "canceledByUser". I would prefer this as the interoperable model as opposed to insisting the CANCEL state be entered immediately. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ---- imcdonal@eso.mc.xerox.com on 09/02/97 09:51:55 AM Please respond to imcdonal@eso.mc.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: JMP> Cancel Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- >From jmp-owner@pwg.org Tue Sep 2 00:26:09 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From SISAACSON at novell.com Thu Sep 4 12:07:58 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: Harry has nailed the solution on the head. Also, we can add as many reasons as we need to to support all of these different configurations. Scott >>> Harry Lewis 09/03 10:00 AM >>> Ira, I hope we can satisfy both our concerns by recognizing that job state reasons are bits and there can be more than one reason at a time. So, in the Processing state, the reasons can be "processingToStopPoint" and "canceledByUser". I would prefer this as the interoperable model as opposed to insisting the CANCEL state be entered immediately. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ---- imcdonal@eso.mc.xerox.com on 09/02/97 09:51:55 AM Please respond to imcdonal@eso.mc.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: JMP> Cancel Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From SISAACSON at novell.com Thu Sep 4 12:13:04 1997 From: SISAACSON at novell.com (Scott Isaacson) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> Cancel In-Reply-To: Re: JMP> Cancel> Message-ID: I will add 'abortedBySystem' to the model document. Or should it be 'abortingBySystem' given that the state 'aborted' is 'abortedBySystem'. Scott >>> Ira Mcdonald x10962 09/03 1:52 PM >>> Hi Harry, I agree entirely with your model for the states and state reasons (ie, show the leading edge of an operation via state reasons and the trailing edge via states). I wonder if we don't need an 'abortedBySystem' state reason, though. Even if the "cancel" was by the system (as an ABORT), could a job be 'processingToStopPoint' for awhile in one of your printers? I never liked making the transition to 'Cancelled' before th operation was actually completed. It doesn't feel right for resilience. Cheers, - Ira McDonald 906-494-2434 ----------------------------- Harry's note ----------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA06048; Wed, 3 Sep 97 12:00:39 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA12980; Wed, 3 Sep 97 11:56:14 EDT Received: from lms03.us1.ibm.com ([198.133.22.39]) by alpha.xerox.com with SMTP id <53385(3)>; Wed, 3 Sep 1997 08:56:55 PDT Received: from d03lms03.boulder.ibm.com by lms03.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA16984; Wed, 3 Sep 1997 14:47:37 GMT Received: by US1.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300009845956; Wed, 3 Sep 1997 12:00:08 -0400 From: Harry Lewis To: Cc: Subject: Re: IPP> Re: JMP> Cancel Message-Id: <5030300009845956000002L062*@MHS> Date: Wed, 3 Sep 1997 09:00:08 PDT Mime-Version: 1.0 Content-Type: text/plain Status: R Ira, I hope we can satisfy both our concerns by recognizing that job state reasons are bits and there can be more than one reason at a time. So, in the Processing state, the reasons can be "processingToStopPoint" and "canceledByUser". I would prefer this as the interoperable model as opposed to insisting the CANCEL state be entered immediately. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ---- imcdonal@eso.mc.xerox.com on 09/02/97 09:51:55 AM Please respond to imcdonal@eso.mc.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: JMP> Cancel Hi Harry, What I'm concerned about is that when the job remains in PROCESSING with 'processing to StopPoint', there is no way to tell (by state or state reasons) that the operation-in-progress was CANCEL versus ABORT versus (if the Job Mon MIB supported it) the DPA Job Interrupt (checkpoint the current job and then start this different one). If you are doing a checkpoint (for Job Interrupt or Job Hold operations), then 'processingToStopPoint' is a normal, healthy state reason. If the the job was 'cancelledByUser' or 'cancelledByOperator'or aborted by the system, then the only indication in the state reasons (until the exception operation COMPLETES) is 'processingToStopPoint' (in your latest, where the 'cancelledBy...' reason isn't set until the Cancel completes). Cheers, - Ira ----------------------------------------------- Harry's note ------------------- >From jmp-owner@pwg.org Tue Sep 2 00:26:09 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00385 for ; Tue, 2 Sep 1997 00:18:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Re: JMP> Cancel Message-Id: <5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Hi, Ira. Thanks for chiming in on this. You asked if there was any state that indicated "jobCancelInProgress" or "jobAbortInProgress" and I guess that's what I am suggesting "processingToStopPoint" can represent. There are other reasons to be processing to stop point like someone hitting a runout button on systems with a large pipeline of data in the printer. But, in general, we have chosen "processingToStopPoint" as an indication that, for some reason, the job is soon to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator" as reasons for the CANCEL state, not the PROCESSING state, but I don't think there would be any harm including them in both places... would there, Tom? In fact, I don't think there is harm in mixing reasons with states in any combination that appears useful... but we were trying to establish a higher degree of interoperability. I never really liked "job state reasons" in the first place, and I think this leading, trailing edge discussion demonstrated why. You can't built a state driven system. If we just had a fairly simple set of states (like we do) with the addition of a state like "canceling", then the end-user, wanting the leading edge feedback would care about this state and the accounting app wanting final state data would care about "canceled". Your point about the Cancel failing landed a bit over my head and in the corner somewhere. I *think* maybe I should be worried about this (now that you mention it) but I'm not really convinced. If a cancel fails, I'm not sure the leading/trailing edge discussion applies. That's only a matter of do you find out in 4 seconds or 16 seconds (3 more sheets in the path to flush). For interoperability sake, I continue to encourage the use of PROCESSING - processingToStopPoint CANCELED - canceledByUser(Operator). Harry Lewis - IBM Printing Systems ------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM ------- ipp-owner@pwg.org on 08/31/97 06:21:59 PM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, ipp@pwg.org @ internet Subject: IPP> Re: JMP> Cancel Hi Harry and Tom, I agree that 'processingToStopPoint' seems to make more sense in the PROCESSING state. But there aren't any state reasons names 'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you what's going on (would we still use 'cancelledByUser' BEFORE finishing the Cancel and going to the CANCELLED terminal state?). Although the Cancel takes finite time, I'm inclined to make the state show the LEADING edge of the Cancel transaction and not the TRAILING edge, so that job state-based monitoring gets a 'wakeup' to go look at job state reasons. Harry, thank you for mentioning the dreaded job events/traps. I agree that robust accounting should take advantage of such job events/traps, when available. But I'd like the LEADING edge state change to encourage ALL accounting applications to do what we want - take a new snapshot of the job's counters, in case the Cancel (or Abort) FAILS during processing. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------- Harry's note ---------------------------------- >From jmp-owner@pwg.org Sat Aug 30 12:10:15 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA05187; Sat, 30 Aug 97 12:10:14 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26109 for ; Sat, 30 Aug 1997 12:02:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: JMP> Cancel Message-Id: <5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Status: R Tom, thanks for sharing your observations about whether the CANCEL state should be entered upon request or upon completion of the CANCEL. I have two comments. You said it would be an error in IPP is CANCEL were received more than once for the same job. I agree that changing state upon request gives more timely end user feedback. But, there are inevitable always going to be system latency in any request... changing state upon completion just adds more. So I think IPP must have a way to handle multiple CANCEL commands anyway. You also gave a good explanation of a robust polling based accounting application which is basically continuously harvesting and sifting. I agree, with this type of implementation, my argument about deterministic accounting is less valid. However, this is not the only type of robust accounting system that can be designed around the job MIB. If ever there were an event driven system or SENSE type of involvement, I still feel it would be better for the CANCEL state to really mean CANCEL complete. I'm sure I've opened myself to criticism, here, in that the Job MIB is currently not event savvy. But, there is no reason it couldn't be (other than we didn't want to tackle the problem) and I am indicating, if we ever moved in that direction, a deterministic set of states is preferable. I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly discussed processingToStoppedState as a reason to be associated with CANCEL not PROCESSING. This is way I suggested an "interoperability FAQ"... so as not to require more work on the current draft. But, if you have already tied in verbiage that strongly indicates the opposite, we'd have a problem, wouldn't we. I will certainly volunteer to perform the editing task if we resolve that CANCEL state means cancel complete! Harry Lewis - IBM Printing Systems ---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM ------------- hastings@cp10.es.xerox.com on 08/29/97 08:54:36 PM Please respond to hastings@cp10.es.xerox.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Cancel Harry, A good debate. However, I hope that we can reach agreement on one or the other and put it into the specification itself. The FAQ should only be for things that come up after we've closed the specification. (I don't want to delay closing the spec either, because no matter how long we wait, there will always be some questions or issues like this that come up). I tried hard to write up the JMP and IPP specs so that your plan B was the only interpretation. If we agree that plan A is the desired plan (or that either A or B can be done depending on implementation), then I want to clarify both the IPP and JMP specs. See my comments below. Tom At 12:45 08/29/97 PDT, Harry Lewis wrote: >We've had a bit of debate, here, about whether, upon detecting a cancel >request, the agent should > >A. STATE=Processing REASON=processing to stop point > >B. STATE=Cancel REASON=processing to stop point > >We were dealing with plan B when we requested processingToStoppedPoint moved >into Reasons-1. Our current debate does not effect that change, or require any >new adjustments to the job MIB. We are more convinced, now that >plan A is better and I only offer this as an interoperability issue. I agree that having two ways might create an interoperability issue. > >The crux of the discussion is whether it's better to change State to Cancel >ASAP upon recognizing the request (B) or >not change State to CANCEL until the cancel operation is complete and all MIB >values are in their final state. Earlier, we thought it necessary to reflect >the Cancel REQUEST for timely user feedback but now we think it better to favor >deterministic behavior from an accounting point of view. Being remote, the user >probably won't be effected by the "lag" - and if an application really wants >to, it can sense, from the reason, that a cancel must be in process. >From an IPP point of view, it is very important that the job change state on receipt of the CancelJob operation. A subsequent CancelJob operation becomes an error if the job is already in the canceled state. But if the job can linger in the processing state, then multiple cancels could be done. Or the user seeing the state as still processing, might be inclined to issue the cancelJob again (like pushing the crosswalk buttom several times). But lets get down to the real debate point (thanks for including your reasons why the change): about the accounting being deterministic. We have discussed this point at Xerox too and we feel that a robust accounting program must be polling all the time and writing out about jobs onto some sort of safe storage on each poll. Then if the system, or the accounting program, or the device crash, or the acounting program doesn't get back on its next poll cycle in time before the job is deleted, there is still accounting information written (even if incomplete). If an accounting program refrains from writing anything about a job, until the job reaches one of the three terminal states (completed, aborted, canceled), then the accounting program might miss accounting information if any of the 4 contingencies happen. Thus we don't think that we should change the job state model definition (of processing to keep the job in processing until the stop point is reached) to "help" accounting, since the accounting should be written in a more robust manner anyway. Thus it doesn't matter whether the accounting program knows whether all of the data is finished changing or not (by seeing that the job has achieved one of the 3 terminal states). The accounting program might want to avoid re-writing a job's accounting record, if the data is all the same, but that can be done by filtering. In fact, each of the three terminal states, might have additional processing after immediate transition to them. Comments? Thanks, Tom > >I'm open to comments. > >I'd like to reach agreement and include a FAQ entry stating that, since CANCEL >is a *completion* state, the transition should not take place until CANCEL is >complete. Again, I'd like to resolve before close of the document and put it in the document, if we can. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Fri Sep 5 20:15:39 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Editorial Comments on Job MIB Version 0.85 In-Reply-To: Editorial Comments on Job MIB Version 0.85> Message-ID: <9709060018.AA21254@zazen.cp10.es.xerox.com> Ron, Good suggestions. Thanks, Tom At 09:34 09/03/97 PDT, Ron Bergman wrote: >Tom, > >Please review the following comments and indicate which you will include >and which require further discussion. I consider all of these editorial >changes only. > > >1. New text on page 20, fourth paragraph: > > It is recommended that agents that are providing access to > servers/devices that already allocate job-identifiers for jobs as > integers use the same integer value for the jmJobIndex. Then the jobs > will have the same job identifier value as the jmJobIndex value, so that > users viewing jobs by management applications using this MIB and > applications using other protocols will see the same job identifiers for > the same jobs. > > Change to: (The first part of the second sentence is a re-word of the > first sentence and has no added value.) > > It is recommended that agents that are providing access to > servers/devices that already allocate job-identifiers for jobs as > integers use the same integer value for the jmJobIndex. Then > management applications using this MIB and applications using other > protocols will see the same job identifiers for the same jobs. Much better. >2. Page 21, second to last paragraph: > > NOTE - Application detect the end of the... > > Should be: NOTE - Applications detect the end of the... Yes. >3. New text on page 26, second paragrpah: > > NOTE - For a number of job submission protocols the server/device > assigns an integer job identifier when accepting a job so that the > submitting client can reference the job in subsequent protocol > operations (For example, see IPP [ipp]). For such implementations, it > is recommended that the value of the job identifier and the value of > jmJobIndex be the same, so that > > First, this text is very similar to what is on page 20. Second, the > last sentence is incomplete. So how about changing it to refer back to page 20: NOTE - For a number of job submission protocols the server/device assigns an integer job identifier when accepting a job so that the submitting client can reference the job in subsequent protocol operations (For example, see IPP [ipp]). For such implementations, it is recommended that the value of the job identifier and the value of jmJobIndex be the same (see section 3.2). >4. Revision to paragraph 3.5.1, page 26. The current text is clumsy. > > 3.5.1 Text generated by the server or device > > There are a few objects and attributes generated by the server or device > that shall be represented using the Universal Multiple-Octet Coded > Character Set (UCS) [ISO-10646]. These objects and attributes are always > supplied (if implemented) by the agent, not by the job submitting client: > 1. jmGeneralJobSetName object > 2. processingMessage(6) attribute > 3. physicalDevice(32) (name value) attribute > > The coded character set for representing these objects and attributes > SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF > Policy on Character Sets and Language" [char-set policy]. The > 'JmUTF8StringTC' textual convention shall be used to indicate UTF-8 text > strings. > > NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 > representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] > encoding. Much better. The only suggestion I have would be to change the SHALL in the second to last sentence to is, since the 'JmUTF8StringTC' textual convention is UTF-8. So the sentence is just explaining what JmUTF8StringTC is. The preceding sentence has the SHALL in it. So the sentence would become: The 'JmUTF8StringTC' textual convention is used to indicate UTF-8 text strings. >5. Change title of paragraph 3.5.2, page 26. > > 3.5.2 Text generated by the job submitter Better. >6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph > 3.5.1, which is also referenced here. This should be deleted. > > NOTE - The values of objects and attributes using this textual > convention are generated by the server or the device, not by the > job submitter. I agree. >7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph > 3.5.2. > > "To facilitate internationalization, this TC represents > information using any coded character set registered by IANA > that has the following properties: (1) code positions from 0 to > 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US- > ASCII], (3) 127 SHALL be unused, and (4) the remaining code > positions 128 to 255 SHALL represent single-byte or multi-byte > graphic characters structured according to ISO 2022 [ISO 2022] > or SHALL be unused. While it is recommended that the coded > character set be UTF-8 [UTF-8], the actual coded character set > SHALL be indicated by the value of the jobCodedCharSet(7) > attribute for the job. > > NOTE - The values of objects and attributes using this textual > convention are either generated by the job submitter or > defaulted by the server or device when the job submitter does > not supply values." > > Change to: > > "To facilitate internationalization, this TC represents > information using any coded character set registered by IANA > as specified in paragraph 3.5.2. While it is recommended that > the coded character set be UTF-8 [UTF-8], the actual coded > character set SHALL be indicated by the value of the > jobCodedCharSet(7) attribute for the job." Good shortening. > >8. Page 78, second paragraph. Change: > > ...formats that have been reserved to agents... > > To: > > ...formats that have been reserved for agents... Ok. >9. Page 81, jmNumberOfInterveningJobs. Change: > > "The number of jobs that are expected to complete being > processed before this job has completed being processed > according to the implementation's queuing algorithm if no other... > > To: > > "The number of jobs that are expected to complete processing > before this job has completed processing according to the > implementation's queuing algorithm, if no other... Yes. >10. Page 1, second paragraph. (Closing quote is in the wrong position.) > > as reference material or to cite them other than as "work in > progress." > > Should be: > > as reference material or to cite them other than as "work in > progress". This is the only one I disagree with! Proper English is that the quote comes last. Look in any book. Also this is just copied from the usual IETF template (which is also correct). > > > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Mon Sep 8 18:28:11 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Draft Job Submission Protocol Mapping RFC Message-ID: <9709060018.AA21254@zazen.cp10.es.xerox.com> I have started work on the companion RFC to the Job Monitoring MIB that defines the Job Submission Protocol Mapping. To get a discussion started quickly, I have limited the scope of this first draft to only LPD. We can concentrate the efforts on the presentation format and then add the other protocols without a significant amount of extra work. A discussion of this document will likely be on the agenda for Atlanta. Ron Bergman Dataproducts Corp. Proposed document attached: INTERNET-DRAFT Ron Bergman Dataproducts Corp. September 8, 1997 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB Expires Mar 8, 1997 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet-Draft defines the recommended mapping for some currently popular Job submission protocols to the Job Monitoring MIB. 1.0 INTRODUCTION The Job Monitoring MIB [JobMIB] is functional with any job submission protocol. However, the information available and the method of presentation varies significantly by job submission protocol. A common method of mapping job submission information to the Job Monitoring MIB is essential for interoperability of Job MIB agents and monitoring applications. This document defines recommended mappings for most popular job submission protocols to insure this compatibility. 2.0 LINE PRINTER DAEMON (LPD) PROTOCOL The LPD printing protocol [LPD] is commonly used with BSD Unix systems in the client-server-printer configuration. Usage of the Job Monitoring MIB with LPD will most likely conform to Configuration 3 (see figure 2-3 in the Job Monitoring MIB [JobMIB]), where the monitor application or the server uses SNMP to obtain job information from the printer. The client communicates with the Unix server using the existing LPD protocol to obtain job information. The LPD protocol is also occasionally used in the Windows environment to implement peer-to-peer printing, as shown in configuration 1 (see figure 2-1 in the Job Monitoring MIB). In this case, SNMP is used by the client and/or the monitor application to obtain the job information. One of the major problems of LPD is the large number of vendor unique extensions currently used with the protocol and the resulting compatibility issues between available implementations. To avoid these issues, this mapping of LPD is restricted to the protocol as defined by RFC 1179. The LPD protocol provides most of the information concerning the print job in the control file. In many LPD implementations, the control file is transferred following the data file. Thus all of the information concerning the job is not available until the completion of the data transmission. 2.1 The Job Id Group Mapped to LPD jmJobSubmissionId ----------------- The LPD Receive Data File command contains a parameter which defines the name of the data file. This name field is structured as follows: dfaXXX Where XXX is the numeric job number assigned by the LPD server submitting the print job. The recommended mapping of this name field to jmJobSubmissionId is: octet 1: '1' octets 2-40: Contains the portion of the name field. If the portion is less than 40 octets, the left-most character in the string shall appear in octet position 2. Otherwise, only the last 39 bytes shall be included. octets 41-48: dfaXXX followed by two null characters. 2.2 The Job Group Mapped to LPD jmJobIndex --------------- The job index is assigned by the SNMP job monitoring agent and is independent the XXX index assigned by the LPD server. This will allow the SNMP agent to accept jobs from multiple sources. jmJobKOctetsRequested --------------------- The LPD Receive Data File command defines the number of bytes in the print data file. This value shall be saved as jmJobKOctetsRequested. jmJobOwner ---------- LPD provides a User Identification string in the control file. This string shall be the jmJobOwner by the agent. 2.3 The Attribute Group Mapped to LPD The following information is saved as either integer or string job attributes. Other attributes that are applicable, but not defined in this section, may also be included. serverAssignedJobName --------------------- The name of the data file (see jmJobSubmissionId) shall also be saved as this attribute and presented using jmAttributeValueAsOctets. jobSourceChannelIndex --------------------- If the agent also implements the Printer MIB [PrtMIB], this attribute shall contain the value of prtChannelIndex corresponding to the LPD channel. The attribute shall be presented using jmAttributeValueAsInteger. queueNameRequested ------------------ The queue name as presented in the data file shall be saved as this attribute and presented using jmAttributeValueAsOctets. fileName -------- The name of the source file, if present in the control file, shall be saved as this attribute and presented using jmAttributeValueAsOctets. documentName ------------ The document title name, if present in the control file, shall be saved as this attribute and presented using jmAttributeValueAsOctets. 3.0 APPLETALK PROTOCOL 4.0 INTERNET PRINTING PROTOCOL (IPP) 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) 6.0 DOCUMENT PRINTING APPLICATION (DPA) 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) 8.0 PRINTER JOB LANGUAGE (PJL) 9.0 POSTSCRIPT 10.0 NETWARE PSERVER 11.0 NETWARE RPRINTER 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) 14.0 REFERENCES [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document. [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational document. [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document. From hastings at cp10.es.xerox.com Mon Sep 8 18:48:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> PMP> I-D ACTION:draft-ietf-printmib-job-monitor-05.txt Message-ID: <9709082251.AA21687@zazen.cp10.es.xerox.com> These announcements get echoed to PMP, not JMP, since JMP is part of the PMP WG. Tom >Return-Path: >To: IETF-Announce@ietf.org >Cc: pmp@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-05.txt >Date: Thu, 28 Aug 1997 06:19:01 PDT >Sender: pmp-owner@pwg.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Printer MIB Working Group of the IETF. > > Title : Job Monitoring MIB - V0.85 > Author(s) : T. Hasting, H. Lewis, S. Isaacson, R. Bergman > Filename : draft-ietf-printmib-job-monitor-05.txt > Pages : 100 > Date : 1997-08-26 > > This Internet-Draft specifies a small set of read-only SNMP MIB > objects for (1) monitoring the status and progress of print jobs > (2) obtaining resource requirements before a job is processed, (3) > monitoring resource consumption while a job is being processed and > (4) collecting resource accounting data after the completion of a > job. This MIB is intended to be implemented (1) in a printer or > (2) in a server that supports one or more printers. Use of the > object set is not limited to printing. However, support for > services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, > but are not limited to, fax machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-05.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-05.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-05.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19970826145454.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-05.txt >Content-Type: text/plain >Content-ID: <19970826145454.I-D@ietf.org> > From don at lexmark.com Mon Sep 8 18:53:41 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:10 2009 Subject: JMP> Atlanta Ping List Message-ID: <199709082258.AA27950@interlock2.lexmark.com> I have created a list on the Web site of those who have pinged for the Atlanta meeting. It is available off the Atlanta meeting page or directly at http://www.pwg.org/chair/atl-ping.html. If you didn't ping me and show up --- well I'll figure out what the penalty is later. Conversely, if you pinged me and no show, the price is your share of the meeting cost anyway!!! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Mon Sep 8 22:15:22 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Can omit jobCodedCharSet(7) if char set unknown Message-ID: <9709090218.AA21804@zazen.cp10.es.xerox.com> In the discussion of the jobCodedCharSet it clearly says what an agent can do if it does not know what the coded character set that the job submitter uses in specifying attributes: If the agent doesn't know what the coded character set that the job submitting client used when submitting the job, the agent SHALL either (1) omit the jobCodedCharSet attribute or (2) return the value 'unknown(2)' as the value of the jobCodedCharSet attribute. Unfortuately, I seemed to have omitted choice (1) from the actual text: jobCodedCharSet(7) If the agent does not know what coded character set was used by the job submitting client, the agent SHALL return the 'unknown(2)' value for the jobCodedCharSet attribute for the job. See Section 3.5.2, entitled ''JmJobStringTC' for text generated by the job submitter. I propose to change the text to: If the agent does not know what coded character set was used by the job submitting client, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job. See Section 3.5.2, entitled ''JmJobStringTC' for text generated by the job submitter. Same change to 3.5.2. Ok? Tom From rbergma at dpc.com Tue Sep 9 12:03:18 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Editorial Comments on Job MIB Version 0.85 In-Reply-To: <9709060018.AA21254@zazen.cp10.es.xerox.com> Message-ID: <9709090218.AA21804@zazen.cp10.es.xerox.com> Tom, Very good! Most are closed. I only have a the following additional comments. Ron On Fri, 5 Sep 1997, Tom Hastings wrote: > Ron, > > Good suggestions. > > Thanks, > Tom > > At 09:34 09/03/97 PDT, Ron Bergman wrote: > >Tom, > > ...snip...snip... > > >3. New text on page 26, second paragrpah: > > > > NOTE - For a number of job submission protocols the server/device > > assigns an integer job identifier when accepting a job so that the > > submitting client can reference the job in subsequent protocol > > operations (For example, see IPP [ipp]). For such implementations, it > > is recommended that the value of the job identifier and the value of > > jmJobIndex be the same, so that > > > > First, this text is very similar to what is on page 20. Second, the > > last sentence is incomplete. > > So how about changing it to refer back to page 20: > > NOTE - For a number of job submission protocols the server/device > assigns an integer job identifier when accepting a job so that the > submitting client can reference the job in subsequent protocol > operations (For example, see IPP [ipp]). For such implementations, it > is recommended that the value of the job identifier and the value of > jmJobIndex be the same (see section 3.2). > In reading both sections again, I do not see a need for any additional text here at all. The end of the previous paragraph reads: "See section 3.2, entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for the specification of how the agent shall assign the jmJobIndex values." This text should be sufficient for the reference to this section. The exisiting paragraph, or your revised version, is already covered in section 3.2. > > >4. Revision to paragraph 3.5.1, page 26. The current text is clumsy. > > > > 3.5.1 Text generated by the server or device > > > > There are a few objects and attributes generated by the server or device > > that shall be represented using the Universal Multiple-Octet Coded > > Character Set (UCS) [ISO-10646]. These objects and attributes are always > > supplied (if implemented) by the agent, not by the job submitting client: > > 1. jmGeneralJobSetName object > > 2. processingMessage(6) attribute > > 3. physicalDevice(32) (name value) attribute > > > > The coded character set for representing these objects and attributes > > SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF > > Policy on Character Sets and Language" [char-set policy]. The > > 'JmUTF8StringTC' textual convention shall be used to indicate UTF-8 text > > strings. > > > > NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 > > representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] > > encoding. > > Much better. The only suggestion I have would be to change the SHALL > in the second to last sentence to is, since the 'JmUTF8StringTC' textual > convention is UTF-8. So the sentence is just explaining what JmUTF8StringTC > is. The preceding sentence has the SHALL in it. > > So the sentence would become: > > The 'JmUTF8StringTC' textual convention is used to indicate UTF-8 text > strings. > Yes, good change. > > >5. Change title of paragraph 3.5.2, page 26. > > > > 3.5.2 Text generated by the job submitter > > Better. > > > >6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph > > 3.5.1, which is also referenced here. This should be deleted. > > > > NOTE - The values of objects and attributes using this textual > > convention are generated by the server or the device, not by the > > job submitter. > > I agree. > > > >7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph > > 3.5.2. > > > > "To facilitate internationalization, this TC represents > > information using any coded character set registered by IANA > > that has the following properties: (1) code positions from 0 to > > 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US- > > ASCII], (3) 127 SHALL be unused, and (4) the remaining code > > positions 128 to 255 SHALL represent single-byte or multi-byte > > graphic characters structured according to ISO 2022 [ISO 2022] > > or SHALL be unused. While it is recommended that the coded > > character set be UTF-8 [UTF-8], the actual coded character set > > SHALL be indicated by the value of the jobCodedCharSet(7) > > attribute for the job. > > > > NOTE - The values of objects and attributes using this textual > > convention are either generated by the job submitter or > > defaulted by the server or device when the job submitter does > > not supply values." > > > > Change to: > > > > "To facilitate internationalization, this TC represents > > information using any coded character set registered by IANA > > as specified in paragraph 3.5.2. While it is recommended that > > the coded character set be UTF-8 [UTF-8], the actual coded > > character set SHALL be indicated by the value of the > > jobCodedCharSet(7) attribute for the job." > > Good shortening. > > >10. Page 1, second paragraph. (Closing quote is in the wrong position.) > > > > as reference material or to cite them other than as "work in > > progress." > > > > Should be: > > > > as reference material or to cite them other than as "work in > > progress". > > > This is the only one I disagree with! Proper English is that the > quote comes last. Look in any book. Also this is just copied from > the usual IETF template (which is also correct). > We can leave as it is, since this will not appear in the final document it is not an issue. (I did check an number of drafts and both forms were used. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Tue Sep 9 20:26:02 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Editorial Comments on Job MIB Version 0.85 In-Reply-To: Editorial Comments on Job MIB Version 0.85> Message-ID: <9709100028.AA22199@zazen.cp10.es.xerox.com> At 09:03 09/09/97 PDT, Ron Bergman wrote: >Tom, > >Very good! Most are closed. I only have a the following additional >comments. > > > Ron > > >On Fri, 5 Sep 1997, Tom Hastings wrote: > >> Ron, >> >> Good suggestions. >> >> Thanks, >> Tom >> >> At 09:34 09/03/97 PDT, Ron Bergman wrote: >> >Tom, >> > > >...snip...snip... > > >> >> >3. New text on page 26, second paragrpah: >> > >> > NOTE - For a number of job submission protocols the server/device >> > assigns an integer job identifier when accepting a job so that the >> > submitting client can reference the job in subsequent protocol >> > operations (For example, see IPP [ipp]). For such implementations, it >> > is recommended that the value of the job identifier and the value of >> > jmJobIndex be the same, so that >> > >> > First, this text is very similar to what is on page 20. Second, the >> > last sentence is incomplete. >> >> So how about changing it to refer back to page 20: >> >> NOTE - For a number of job submission protocols the server/device >> assigns an integer job identifier when accepting a job so that the >> submitting client can reference the job in subsequent protocol >> operations (For example, see IPP [ipp]). For such implementations, it >> is recommended that the value of the job identifier and the value of >> jmJobIndex be the same (see section 3.2). >> >In reading both sections again, I do not see a need for any additional >text here at all. The end of the previous paragraph reads: > > "See section 3.2, entitled 'The Job Tables and the Oldest Active and > Newest Active Indexes' for the specification of how the agent shall > assign the jmJobIndex values." > >This text should be sufficient for the reference to this section. The >exisiting paragraph, or your revised version, is already covered in >section 3.2. I agree. Even shorter. >> >> >4. Revision to paragraph 3.5.1, page 26. The current text is clumsy. >> > >> > 3.5.1 Text generated by the server or device >> > >> > There are a few objects and attributes generated by the server or device >> > that shall be represented using the Universal Multiple-Octet Coded >> > Character Set (UCS) [ISO-10646]. These objects and attributes are always >> > supplied (if implemented) by the agent, not by the job submitting client: >> > 1. jmGeneralJobSetName object >> > 2. processingMessage(6) attribute >> > 3. physicalDevice(32) (name value) attribute >> > >> > The coded character set for representing these objects and attributes >> > SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF >> > Policy on Character Sets and Language" [char-set policy]. The >> > 'JmUTF8StringTC' textual convention shall be used to indicate UTF-8 text >> > strings. >> > >> > NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 >> > representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] >> > encoding. >> >> Much better. The only suggestion I have would be to change the SHALL >> in the second to last sentence to is, since the 'JmUTF8StringTC' textual >> convention is UTF-8. So the sentence is just explaining what JmUTF8StringTC >> is. The preceding sentence has the SHALL in it. >> >> So the sentence would become: >> >> The 'JmUTF8StringTC' textual convention is used to indicate UTF-8 text >> strings. >> >Yes, good change. >> >> >5. Change title of paragraph 3.5.2, page 26. >> > >> > 3.5.2 Text generated by the job submitter >> >> Better. >> >> >> >6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph >> > 3.5.1, which is also referenced here. This should be deleted. >> > >> > NOTE - The values of objects and attributes using this textual >> > convention are generated by the server or the device, not by the >> > job submitter. >> >> I agree. >> >> >> >7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph >> > 3.5.2. >> > >> > "To facilitate internationalization, this TC represents >> > information using any coded character set registered by IANA >> > that has the following properties: (1) code positions from 0 to >> > 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US- >> > ASCII], (3) 127 SHALL be unused, and (4) the remaining code >> > positions 128 to 255 SHALL represent single-byte or multi-byte >> > graphic characters structured according to ISO 2022 [ISO 2022] >> > or SHALL be unused. While it is recommended that the coded >> > character set be UTF-8 [UTF-8], the actual coded character set >> > SHALL be indicated by the value of the jobCodedCharSet(7) >> > attribute for the job. >> > >> > NOTE - The values of objects and attributes using this textual >> > convention are either generated by the job submitter or >> > defaulted by the server or device when the job submitter does >> > not supply values." >> > >> > Change to: >> > >> > "To facilitate internationalization, this TC represents >> > information using any coded character set registered by IANA >> > as specified in paragraph 3.5.2. While it is recommended that >> > the coded character set be UTF-8 [UTF-8], the actual coded >> > character set SHALL be indicated by the value of the >> > jobCodedCharSet(7) attribute for the job." >> >> Good shortening. >> >> >10. Page 1, second paragraph. (Closing quote is in the wrong position.) >> > >> > as reference material or to cite them other than as "work in >> > progress." >> > >> > Should be: >> > >> > as reference material or to cite them other than as "work in >> > progress". >> >> >> This is the only one I disagree with! Proper English is that the >> quote comes last. Look in any book. Also this is just copied from >> the usual IETF template (which is also correct). >> >We can leave as it is, since this will not appear in the final document it >is not an issue. (I did check an number of drafts and both forms were >used. > > > > Ron Bergman > Dataproducts Corp. > > > > From hastings at cp10.es.xerox.com Tue Sep 9 21:30:04 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Unix(tm)? In-Reply-To: Unix(tm)?> Message-ID: <9709100132.AA22247@zazen.cp10.es.xerox.com> Patrick, Are you saying that UNIX should not be indicated as trade marked? Or are you indicating that I should change UNIX(TM) to UNIX(tm)? Thanks, Tom At 17:01 08/29/97 PDT, papowell@astart.com wrote: >I note that in your postings about adding JmJobSourcePlatformTypeTC >that UNIX(TM) was in the list. In actual fact, most of the others >are also (TM). Consistency would call for tracking down the (TM)s of >all of the others or removing the (tm) for UNIX. > >Patrick ("nity picky") Powell > > From hastings at cp10.es.xerox.com Wed Sep 10 11:47:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Message-ID: <9709101550.AA22451@zazen.cp10.es.xerox.com> There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom From hastings at cp10.es.xerox.com Wed Sep 10 12:57:52 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> Clarifications, additions and movements of some Message-ID: <9709101700.AA22492@zazen.cp10.es.xerox.com> Subj: Clarifications, additions and movements of some job-state-reasons From: Tom Hastings and Harry Lewis Date: 9/10/97 File: reasons.doc On the JMP DL, Harry has made the following proposals for movement of some job state reasons to jmJobStateReason1 object and clarifications. Some of these may want to be added to IPP (but IPP can remain a subset of JMP, since JMP is attempting to cover other job submission protocols as well as IPP). 1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that the server has timed out the job and closed it. Should be added to IPP as well. 2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the service has been disabled, so that all pending jobs are not going to be processed. 3. Distinguish between canceling by (authenicate) operator and canceled at local (unauthenticated) op panel, by adding 'canceled-at-device'. 4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the semantics. 5. Clarify 'canceled-by-operator' to mean authenticated as a privileged user in some way. 6. Add 'canceled-by-non-owner' for those systems that have more comprehensive security mechanisms, such as group privileges in POSIX. If we add these to JMP, Harry has indicated that we could put them in their logical place in the order of likely occurrence, but only we need to agree quickly. If we can't agree quickly, then we should put them at the end of the bit assignments in JMP. (Fortunately, in IPP, we use keywords, instead of bits, so there is no problem with ordering). I've indicated the new bit assignements below for the JMP spec. The proposed specs for each of these job state reasons becomes: For JMP: submissionInterrupted 0x8 Indicates that the job was not completely submitted for some unforeseen reason, such as: (1) the server has crashed before the job was closed by the client, (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server, (3) the client crashed or failed to close the job before the time-out period. jobCanceledByOwner 0x1000 The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's jmJobOwner object. jobCanceledByOperator 0x2000 The job was canceled by the operator, i.e., by a user whose has been authenticated as having operator privileges (whether local or remote). jobCanceledAtDevice 0x4000 The job was canceled by an unidentified local user, i.e., a user at a walkup console or operator's panel. jobCanceledByNonOwner 0x8000 The job was canceled by an authenticated user that is not the owner of the job. This reason may be used in systems that have the concept of group or other security mechanisms that allow jobs to be canceled by users other than the job owner but that are not operators. serviceOffLine 0x40000 The service or document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This situation could be true if the service's or document transform's input is impaired or broken. NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use the 3 other 32-bit job state reasons attributes. IPP: For IPP, the names change to all lower case with hyphens to follow keyword syntax. 'submission-interrupted': The job was not completely submitted for some unforeseen reason, such as: (1) the Printer has crashed before the job was closed by the client, (2) the Printer or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the Printer, (3) the client crashed or failed to close the job before the time-out period. 'job-canceled-by-owner': The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's "job-originating-user" attribute. 'job-canceled-by-operator': The job was canceled by the operator using the CancelJob request, i.e., by a user who has been granted special privileges. 'job-canceled-at-device': The job was canceled by an unidentified local user, i.e., i.e., a user at a walkup console or operator's panel. 'serviceoff-line': The Printer is off-line and accepting no jobs. All pending jobs are put into the 'pending-held' state. This situation could be true if the Printer's input is impaired or broken. Comments? Tom From imcdonal at eso.mc.xerox.com Wed Sep 10 13:05:48 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics In-Reply-To: MOD - 'canceled' and 'aborted' job state semantics> Message-ID: <9709101705.AA08446@snorkel.eso.mc.xerox.com> Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom From harryl at us.ibm.com Wed Sep 10 15:10:56 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> IPP> MOD - 'canceled' and 'aborted' job state semantics Message-ID: <9709101705.AA08446@snorkel.eso.mc.xerox.com> Tom, I support the "e-mail" conclusion in favor of changing STATE when the CANCEL or ABORT is completed and associated attributes (ex. sheets used) are at their final value. >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* This has been discussed openly for a significant duration on JMP, so I feel agreement has been reached there (unless someone objects). Yes, we do need better IPP coverage of this topic. You are correct ... >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. I would see this as a late change and overly complex, at this point. Harry Lewis From harryl at us.ibm.com Wed Sep 10 19:42:09 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema In-Reply-To: MOD - 'canceled' and 'aborted' job state sema> Message-ID: <9709101705.AA08446@snorkel.eso.mc.xerox.com> Ira, I could live with a new state if we were in the early stages of this MIB. In the beginning I argued for a succinct list of STATES rather than a caboodle of catagorized state reasons. But, long ago, we landed on a limited set of states and many, many reasons. We're in the tweaking stage, now, just trying to lay down some interoperability regarding use of what we have. I think adding a state at this point is too big a change. I believe we're expending a lot of energy to solve a very transient condition - the admittedly short time between a CANCEL request and a CANCEL (completed) state change. I don't think it's necessary, especially in light of the fact that we have state reasons such as... canceledByOwner, canceledByOperator, porcessingToStopPoint etc. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- ipp-owner@pwg.org on 09/10/97 02:23:54 PM Please respond to ipp-owner@pwg.org @ internet To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com @ internet cc: Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom From rbergma at dpc.com Wed Sep 10 20:47:16 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema In-Reply-To: <5030300010287025000002L052*@MHS> Message-ID: <9709101705.AA08446@snorkel.eso.mc.xerox.com> Harry, I agree with your position 100%. We spent considerable time developing the three state model and, in spite of the "caboodle" of state reasons, does map very well into a real environment. Keeping the job state at "Processing" for this transient period is merely a small change to the model and shoukd not be difficult for a printer to report or a management application to process. Ron Bergman Dataproducts Corp. On Wed, 10 Sep 1997, Harry Lewis wrote: > Ira, I could live with a new state if we were in the early stages of this MIB. > In the beginning I argued for a succinct list of STATES rather than a caboodle > of catagorized state reasons. But, long ago, we landed on a limited set of > states and many, many reasons. We're in the tweaking stage, now, just trying to > lay down some interoperability regarding use of what we have. I think adding a > state at this point is too big a change. > > I believe we're expending a lot of energy to solve a very transient condition - > the admittedly short time between a CANCEL request and a CANCEL (completed) > state change. I don't think it's necessary, especially in light of the fact > that we have state reasons such as... canceledByOwner, canceledByOperator, > porcessingToStopPoint etc. > > > Harry Lewis - IBM Printing Systems > > > ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- > > > ipp-owner@pwg.org on 09/10/97 02:23:54 PM > Please respond to ipp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com > @ internet > cc: > Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema > > > Hi Tom, > > After reading all that (excellent writeup, by the way), I begin to > like adding the clean and unambiguous 'terminating' state (from > ISO DPA), so that leading/trailing edge changes ALWAYS result > in a state change (and thus a notification or event, if possible) > and a client need not examine state reasons to determine if an > operation is legal at the present moment. > > Harry, could you live with a 'cleanup' state on the switchbar > of the three terminal states? It sure makes notifications (or > SNMP traps) a lot cleaner and simpler. > > Cheers, > - Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > ---------------------------------- Tom's note ---------------------- > From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com > (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from > alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT > Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with > SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost > (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 > for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: > by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from > daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for > jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: > <9709101550.AA22451@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: > Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; > charset="us-ascii" Date: Wed, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, > jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - > 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R > > There has been a good discussion in both the IPP and JMP DL about > the semantics of the 'canceled' state: whether the job moves to > 'canceled' state immediately upon acceptance of the Cancel-Job operation > or whether the job moves to the 'canceled' state when the canceling has > completed and the job is quiescent (all the job accounting counters have > stopped counting, and all the media sheets are stacked). > > Usually the time difference is just a few seconds after the Cancel-Job > operation has been accepted, but in some implementations the time could be > considerably longer than a few seconds, including fixing a paper jam or > paper out. > > The same discussion also applies to when the system aborts a job. > Does the job move to the 'aborted' state immediately, or when the > system finishes aborting the job? > > The 'completed' state is specified as being reached when all of the > processing, including "media sheets successfully stacked", so that the > 'completed' state is reached after the job is quiescent. > > It is hoped that we could discuss this issue at the IPP telecon today > and continue and resolve it at the IPP meeting next week in Atlanta > (with JMP participation). We need to keep both specs in synch. > > > > The issue is whether to continue the current IPP and JMP semantics: > > > A. Leading Edge Job State Transition: > > 1. The job changes immediately to the 'canceled' or 'aborted' states > from the 'processing' state with the 'processing-to-stop-point' > and 'canceled-by-xxx' reasons set. > > 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' > job state reason is removed (but the job state doesn't change since > the job is alread in the 'canceled' or 'aborted'). > > > OR change the IPP and JMP semantics to: > > > B. Trailing Edge Job State Transition: > > 1. The job remains in 'processing' with 'processing-to-stop-point' > and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > > 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' > is removed AND the job transitions to the 'canceled' or 'aborted' state > with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > > (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, > but if there every is another reason to abort a job, it may be good > to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' > is also useful in the pending-held state for systems that chose to > allow a user or operator to release a job that has had a problem, > perhaps after modifying the job or the environment). > > > > > PROs and CONs: > > > 1. The 'canceled' and 'aborted' states become quiescent states, like > the 'completed' state already is. > > The advantage of Trailing Edge Job State Transition is that the three > terminal states: 'completed', 'canceled', and 'aborted' would be > all quiescent state. > > With the Leading Edge Job State Transition semantics, 'completed' is > quiescent, and 'canceled' and 'aborted' are not. > > > 2. Easier rejection of operations: just use the job state, not the reasons > > The advantage of the Leading Edge Job State Transition is that it > is clearer when operations are illegal: only the job states are involved. > This is the classis job state transition diagram showing operations > and job state transitions. > > So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error > that the job is in an inappropriate state whenever the job state > is 'completed', 'canceled', or 'aborted'. > > With the Trailing Edge Job State Transition, the user and the Printer > have to look at both the job state and the job-state-reasons in order > to reject multiple Cancel-Job operations and the job state transition > diagram is more complicated. > > > 3. Better notification/trapping when job is quiescent > > The advantage of Trailing Edge Job State Transitions is that an application > program, such as an accounting program, that gets a notification or trap > on job state transitions, will get the notification or trap on entering > the 'completed', 'canceled', or 'aborted' state AFTER all the processing > has completed and all the counts have finished counting, so that polling > can be avoided for any additional processing to stop point activity. > > Also the job state reflects the completion of an operation, not just the > acceptance of the operation for those operations that are not performed > before the response is returned, such as Cancel-Job, when the job is > in the 'processing' state. > > NOTE: IPP has notification, but JMP does not have SNMP trapping, though > all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > > E-MAIL conclusion: > > The e-mail discussion seems to favor changing the IPP and JMP semantics > to "Trailing Edge Job State Transition" semantics, since many protocols > use states to mean that the operation has finished all of its work. > Also reducing polling seems to be more important than simplfying the Printer > implementation and the job state transition diagram when legal operations > are shown. > > ******************************************************************* > We need to see if the rest of the IPP and JMP participants agree > to change the spec to Traling Edge Job State Transition semantics. > ******************************************************************* > > > Probably neither side would be happy with a compromise that complicates > the state model by adding a new Job state: 'terminating' (the name > used for the ISO DPA job state). Then the 'processing-to-stop-point' reason > would not be needed for this. > > With such a compromise, there would be a job state transition when the > Cancel-job operation is accepted (leading edge transition from 'processing' > to 'terminating') and when the operation completes > (trailing edge transition from 'terminating' to 'completed', > 'canceled', or 'aborted'). The Cancel-Job operation would be rejected > when the job was in the 'terminating' job state (as well as when in the > 'completed', 'canceled', and 'aborted' job states). > > > Comments? > > Tom > > > > > From rbergma at dpc.com Wed Sep 10 21:58:00 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Unix(tm)? In-Reply-To: <9709100132.AA22247@zazen.cp10.es.xerox.com> Message-ID: <9709101705.AA08446@snorkel.eso.mc.xerox.com> Tom, T restate Patrick's case. Why are we just indicating that Unix is trademarked when most of the platform types are also trademarked? We must be consistent. Let's remove the (TM) from Unix. Ron Bergman Dataproducts Corp. On Tue, 9 Sep 1997, Tom Hastings wrote: > Patrick, > > Are you saying that UNIX should not be indicated as trade marked? > > Or are you indicating that I should change UNIX(TM) to UNIX(tm)? > > Thanks, > Tom > > > At 17:01 08/29/97 PDT, papowell@astart.com wrote: > >I note that in your postings about adding JmJobSourcePlatformTypeTC > >that UNIX(TM) was in the list. In actual fact, most of the others > >are also (TM). Consistency would call for tracking down the (TM)s of > >all of the others or removing the (tm) for UNIX. > > > >Patrick ("nity picky") Powell > > > > > > From hastings at cp10.es.xerox.com Wed Sep 10 22:42:48 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - "job-state-reason" clarifications, additions and Message-ID: <9709110245.AA22765@zazen.cp10.es.xerox.com> I'd like to put this job-state-reasons clarification, additions, and movements on the IPP agenda next week, so that we can keep IPP and JMP in synch. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 09:57:52 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: IPP> Clarifications, additions and movements of some > job-state-reasons >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org > >Subj: Clarifications, additions and movements of some job-state-reasons >From: Tom Hastings and Harry Lewis >Date: 9/10/97 >File: reasons.doc > >On the JMP DL, Harry has made the following proposals for movement >of some job state reasons to jmJobStateReason1 object and clarifications. >Some of these may want to be added to IPP (but IPP can remain a subset >of JMP, since JMP is attempting to cover other job submission protocols >as well as IPP). > >1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that >the server has timed out the job and closed it. >Should be added to IPP as well. > >2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the >service has been disabled, so that all pending jobs are not going to >be processed. > >3. Distinguish between canceling by (authenicate) operator and canceled >at local (unauthenticated) op panel, by adding 'canceled-at-device'. > >4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the >semantics. > >5. Clarify 'canceled-by-operator' to mean authenticated as a privileged >user in some way. > >6. Add 'canceled-by-non-owner' for those systems that have more >comprehensive security mechanisms, such as group privileges in POSIX. > > >If we add these to JMP, Harry has indicated that we could put them >in their logical place in the order of likely occurrence, but only >we need to agree quickly. If we can't agree quickly, then we should >put them at the end of the bit assignments in JMP. (Fortunately, in >IPP, we use keywords, instead of bits, so there is no problem with ordering). > >I've indicated the new bit assignements below for the JMP spec. > > >The proposed specs for each of these job state reasons becomes: > >For JMP: > >submissionInterrupted 0x8 >Indicates that the job was not completely submitted for some unforeseen >reason, such as: (1) the server has crashed before the job was closed by the >client, (2) the server or the document transfer method has crashed in some >non-recoverable way before the document data was entirely transferred to the >server, (3) the client crashed or failed to close the job before the >time-out period. > > >jobCanceledByOwner 0x1000 >The job was canceled by the owner of the job, i.e., by a user >whose name is the same as the value of the job's jmJobOwner object. > > >jobCanceledByOperator 0x2000 >The job was canceled by the operator, i.e., by a user whose has been >authenticated as having operator privileges (whether local or remote). > > >jobCanceledAtDevice 0x4000 >The job was canceled by an unidentified local user, i.e., a user >at a walkup console or operator's panel. > > >jobCanceledByNonOwner 0x8000 >The job was canceled by an authenticated user that is not the owner of the >job. This reason may be used in systems that have the concept of group or >other security mechanisms that allow jobs to be canceled by users other than >the job owner but that are not operators. > > >serviceOffLine 0x40000 >The service or document transform is off-line and accepting no jobs. >All pending jobs are put into the pendingHeld state. This situation >could be true if the service's or document transform's input is impaired >or broken. > > > >NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use >the 3 other 32-bit job state reasons attributes. > > > >IPP: > >For IPP, the names change to all lower case with hyphens to follow keyword >syntax. > >'submission-interrupted': The job was not completely submitted for some >unforeseen reason, such as: (1) the Printer has crashed before the job was >closed by the client, (2) the Printer or the document transfer method has >crashed in some non-recoverable way before the document data was entirely >transferred to the Printer, (3) the client crashed or failed to close the >job before the time-out period. > >'job-canceled-by-owner': The job was canceled by the owner of the job, >i.e., by a user whose name is the same as the value of the job's >"job-originating-user" attribute. > >'job-canceled-by-operator': The job was canceled by the operator >using the CancelJob request, i.e., by a user who has been granted >special privileges. > >'job-canceled-at-device': The job was canceled by an unidentified local >user, i.e., i.e., a user at a walkup console or operator's panel. > >'serviceoff-line': The Printer is off-line and accepting no jobs. All >pending jobs are put into the 'pending-held' state. This situation >could be true if the Printer's input is impaired or broken. > >Comments? > >Tom > > > From hastings at cp10.es.xerox.com Wed Sep 10 22:45:22 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - ISSUE: 'canceled' and 'aborted' job state semantics Message-ID: <9709110248.AA22768@zazen.cp10.es.xerox.com> I'd like to put this ISSUE of the 'canceled' and 'aborted' job state semantics on the IPP agenda for next week, 9/17, so that we can keep IPP and JMP in synch for job states. Please send any comments ahead of time as well. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 08:47:43 PDT >To: ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics >Sender: ipp-owner@pwg.org > >There has been a good discussion in both the IPP and JMP DL about >the semantics of the 'canceled' state: whether the job moves to >'canceled' state immediately upon acceptance of the Cancel-Job operation >or whether the job moves to the 'canceled' state when the canceling has >completed and the job is quiescent (all the job accounting counters have >stopped counting, and all the media sheets are stacked). > >Usually the time difference is just a few seconds after the Cancel-Job >operation has been accepted, but in some implementations the time could be >considerably longer than a few seconds, including fixing a paper jam or >paper out. > >The same discussion also applies to when the system aborts a job. >Does the job move to the 'aborted' state immediately, or when the >system finishes aborting the job? > >The 'completed' state is specified as being reached when all of the >processing, including "media sheets successfully stacked", so that the >'completed' state is reached after the job is quiescent. > >It is hoped that we could discuss this issue at the IPP telecon today >and continue and resolve it at the IPP meeting next week in Atlanta >(with JMP participation). We need to keep both specs in synch. > > > >The issue is whether to continue the current IPP and JMP semantics: > > >A. Leading Edge Job State Transition: > >1. The job changes immediately to the 'canceled' or 'aborted' states >from the 'processing' state with the 'processing-to-stop-point' >and 'canceled-by-xxx' reasons set. > >2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' >job state reason is removed (but the job state doesn't change since >the job is alread in the 'canceled' or 'aborted'). > > >OR change the IPP and JMP semantics to: > > >B. Trailing Edge Job State Transition: > >1. The job remains in 'processing' with 'processing-to-stop-point' >and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > >2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' >is removed AND the job transitions to the 'canceled' or 'aborted' state >with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > >(Actually, the 'aborted-by-system' is redundant with the 'aborted' state, >but if there every is another reason to abort a job, it may be good >to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' >is also useful in the pending-held state for systems that chose to >allow a user or operator to release a job that has had a problem, >perhaps after modifying the job or the environment). > > > > >PROs and CONs: > > >1. The 'canceled' and 'aborted' states become quiescent states, like >the 'completed' state already is. > >The advantage of Trailing Edge Job State Transition is that the three >terminal states: 'completed', 'canceled', and 'aborted' would be >all quiescent state. > >With the Leading Edge Job State Transition semantics, 'completed' is >quiescent, and 'canceled' and 'aborted' are not. > > >2. Easier rejection of operations: just use the job state, not the reasons > >The advantage of the Leading Edge Job State Transition is that it >is clearer when operations are illegal: only the job states are involved. >This is the classis job state transition diagram showing operations >and job state transitions. > >So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error >that the job is in an inappropriate state whenever the job state >is 'completed', 'canceled', or 'aborted'. > >With the Trailing Edge Job State Transition, the user and the Printer >have to look at both the job state and the job-state-reasons in order >to reject multiple Cancel-Job operations and the job state transition >diagram is more complicated. > > >3. Better notification/trapping when job is quiescent > >The advantage of Trailing Edge Job State Transitions is that an application >program, such as an accounting program, that gets a notification or trap >on job state transitions, will get the notification or trap on entering >the 'completed', 'canceled', or 'aborted' state AFTER all the processing >has completed and all the counts have finished counting, so that polling >can be avoided for any additional processing to stop point activity. > >Also the job state reflects the completion of an operation, not just the >acceptance of the operation for those operations that are not performed >before the response is returned, such as Cancel-Job, when the job is >in the 'processing' state. > >NOTE: IPP has notification, but JMP does not have SNMP trapping, though >all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* > > >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. > >With such a compromise, there would be a job state transition when the >Cancel-job operation is accepted (leading edge transition from 'processing' >to 'terminating') and when the operation completes >(trailing edge transition from 'terminating' to 'completed', >'canceled', or 'aborted'). The Cancel-Job operation would be rejected >when the job was in the 'terminating' job state (as well as when in the >'completed', 'canceled', and 'aborted' job states). > > >Comments? > >Tom > > > From hastings at cp10.es.xerox.com Wed Sep 10 23:00:29 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> ISSUE: Allow private attributes in IETF Job Monitoring MIB? Message-ID: <9709110303.AA22781@zazen.cp10.es.xerox.com> In IPP, we have a syntax for private (non-registered) extensions, as well as registered attribute extensions. It seems we should have the same capability for the ITEF Job Monitoring MIB, so that any private IPP attribute that an IPP implementor invents, could be supported by the same vendor in the IETF Job Monitoring MIB. My suggestion would be to reserve a range of attribute enums for private experimental use with clear warnings of interoperatbility problems for such use (and encourage registration). How about allocating a block of enum values for private JMP job attributes in the range of 2**30 to 2**31-1 (same range as for IPP private operations)? Comments? Tom From jkm at underscore.com Thu Sep 11 12:24:35 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:10 2009 Subject: JMP> ISSUE: Allow private attributes in IETF Job Monitoring MIB? In-Reply-To: ISSUE: Allow private attributes in IETF Job Monitoring MIB?> Message-ID: <9709110303.AA22781@zazen.cp10.es.xerox.com> Sounds like a prudent thing to do, Tom. Does anyone have any objections to this proposal? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Tom Hastings wrote: > > In IPP, we have a syntax for private (non-registered) extensions, as well > as registered attribute extensions. > > It seems we should have the same capability for the ITEF Job Monitoring MIB, > so that any private IPP attribute that an IPP implementor invents, could be > supported by the same vendor in the IETF Job Monitoring MIB. My suggestion > would be to reserve a range of attribute enums for private experimental use > with clear warnings of interoperatbility problems for such use (and encourage > registration). > > How about allocating a block of enum values for private JMP job attributes > in the range of 2**30 to 2**31-1 (same range as for IPP private operations)? > > Comments? > > Tom From rbergma at dpc.com Mon Sep 15 17:33:57 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Meeting Agenda Message-ID: <9709110303.AA22781@zazen.cp10.es.xerox.com> PROPOSED JOB MONITORING MIB AGENDA for September 19, 1997 1. Review "Standards Track" Vs "Individual Contribution" 2. Review Schedule and Plans 3. Job MIB changes 4. Open issues 5. Review of Job MIB Mapping Document - Document format - LPD mapping - Other protocols to map - Assignments Ron Bergman Dataproducts Corp. From rbergma at dpc.com Mon Sep 15 17:49:29 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Summary of Agreed Changes to JMP MIB Version 0.85 Message-ID: <9709110303.AA22781@zazen.cp10.es.xerox.com> The following changes have been accepted for inclusion into version 0.85. Please let me know if anything has been missed. Email from Ron Bergman, Date: Tue, 12 Aug 1997 Subject: JMP> Open Editorial Changes From Rev. 0.83 The agreed changes: 1. Section 2. Terminology and Job Model (page 14) delete the text: "PJL systems use the term job to mean what we call a job in this specification. PJL also supports multiple documents per job, but does not support specifying per-document attributes independently for each document." 2. The definitions in section 2 should begin with a capital letter. Example: "Job Set: A group of jobs..." 3. The definition for "Device" (page 14) change to: "Device: A hardware entity that (1) interfaces to humans, such as produces marks on paper or scans marks on paper, (2) accesses digital media, such as CD_ROMS, or (3) interfaces electronically to another device, such as sends FAX data to another FAX device." 4. In jmGeneralJobPersistence (page #75), the second paragraph: "Depending on implementation, the value of this object MAY be either: (1) set by the system administrator by means outside this specification or (2) fixed by the implementation." Change to: "Configuring this object is implementation-dependent." 5. For jmGeneralAttributePersistence (page #76) the same as above. 6. In jmJobStateReasons1 (page #81), change: "Furthermore, when implemented as with any MIB data, the agent SHALL return these values when the reason applies and SHALL NOT return them when the reason no longer applies whether the value of the job's jmJobState object changed or not." To: "Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time jmJobState is read." 7. Also in jmJobStateReasons1 (page #81), change: "When the job does not have any reasons for being in its current state, the agent SHALL set the value of the jmJobStateReasons1 object and jobStateReasonsN attributes to 0." To: "When the agent cannot provide a reason for the current state of the job, the value of jmJobStateReasons1 object and jobStateReasonsN attributes shall be 0." ------------------------------------------------------------------------ Email from Harry Lewis, Date Fri, 22 Aug 1997 Subject: JMP> serviceOffLine Request to move the serviceOffLine job state reason to JmJobStateReasons1TC. ------------------------------------------------------------------------------------------ Email from Harry Lewis, Date Thu, 28 Aug 1997 Subject: Job State Reasons [submissionInterrupted] Request to move submissionInterrupted to JmJobStateReasons1TC ------------------------------------------------------------------------ Email from Tom Hastings, Date Fri, 29 Aug 1997 Subject: JMP> Operating System Types In JmJobSourcePlatformTypeTC, change: sptWindows95(11), -- Windows95 sptNetWare(33) -- NetWare To: sptWindows(11), -- Windows sptNetWare(12) -- NetWare ------------------------------------------------------------------------ Email from Patrick Powell, Date Fri, 29 Aug 1997 Subject: JMP> Unix(tm)? Remove (tm) from UNIX entry in JmJobSourcePlatformTypeTC: sptUNIX(3), -- UNIX(tm) ------------------------------------------------------------------------ Email from Ron Bergman, Date: Wed, 3 Sep 1997 Subject: JMP> Editorial Comments on Job MIB version 0.85 The agreed changes: 1. New text on page 20, fourth paragraph: It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then the jobs will have the same job identifier value as the jmJobIndex value, so that users viewing jobs by management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. Change to: It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. 2. Page 21, second to last paragraph: NOTE - Application detect the end of the... Should be: NOTE - Applications detect the end of the... 3. New text on page 26, second paragraph delete text: NOTE - For a number of job submission protocols the server/device assigns an integer job identifier when accepting a job so that the submitting client can reference the job in subsequent protocol operations (For example, see IPP [ipp]). For such implementations, it is recommended that the value of the job identifier and the value of jmJobIndex be the same, so that 4. Revision to paragraph 3.5.1, page 26. Change to: 3.5.1 Text generated by the server or device There are a few objects and attributes generated by the server or device that shall be represented using the Universal Multiple-Octet Coded Character Set (UCS) [ISO-10646]. These objects and attributes are always supplied (if implemented) by the agent, not by the job submitting client: 1. jmGeneralJobSetName object 2. processingMessage(6) attribute 3. physicalDevice(32) (name value) attribute The coded character set for representing these objects and attributes SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF Policy on Character Sets and Language" [char-set policy]. The 'JmUTF8StringTC' textual convention is used to indicate UTF-8 text strings. NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] encoding. 5. Change title of paragraph 3.5.2, page 26. 3.5.2 Text generated by the job submitter 6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph 3.5.1, which is also referenced here. This should be deleted. NOTE - The values of objects and attributes using this textual convention are generated by the server or the device, not by the job submitter. 7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph 3.5.2. "To facilitate internationalization, this TC represents information using any coded character set registered by IANA that has the following properties: (1) code positions from 0 to 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US- ASCII], (3) 127 SHALL be unused, and (4) the remaining code positions 128 to 255 SHALL represent single-byte or multi-byte graphic characters structured according to ISO 2022 [ISO 2022] or SHALL be unused. While it is recommended that the coded character set be UTF-8 [UTF-8], the actual coded character set SHALL be indicated by the value of the jobCodedCharSet(7) attribute for the job. NOTE - The values of objects and attributes using this textual convention are either generated by the job submitter or defaulted by the server or device when the job submitter does not supply values." Change to: "To facilitate internationalization, this TC represents information using any coded character set registered by IANA as specified in paragraph 3.5.2. While it is recommended that the coded character set be UTF-8 [UTF-8], the actual coded character set SHALL be indicated by the value of the jobCodedCharSet(7) attribute for the job." 8. Page 78, second paragraph. Change: ...formats that have been reserved to agents... To: ...formats that have been reserved for agents... 9. Page 81, jmNumberOfInterveningJobs. Change: "The number of jobs that are expected to complete being processed before this job has completed being processed according to the implementation's queuing algorithm if no other... To: "The number of jobs that are expected to complete processing before this job has completed processing according to the implementation's queuing algorithm, if no other... ----------------------------------------------------------------------------------------- Email from Tom Hastings, Date: Mon, 8 Sep 1997 Subject: JMP> Can omit jobCodedCharSet(7) if char set unknown Change description of jobCodedCharSet(7) to: If the agent does not know what coded character set was used by the job submitting client, the agent shall either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job. See section 3.5.2, entitled 'JmJobStringTC' for text generated by the job submitter. ------------------------------------------------------------------------------------- Email from Tom Hastings, Date: Wed, 10 Sep 1997 Subject: JMP>ISSUE: Allow private attributes in IETF Job Monitoring MIB? Add to JmAttributeTypeTC description: Attribute enums in the range of 2**30 to (2**31)-1 are reserved for private job attributes. Ron Bergman Dataproducts Corp. From rbergma at dpc.com Mon Sep 15 17:53:30 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Open Issues Message-ID: <9709110303.AA22781@zazen.cp10.es.xerox.com> Job Monitoring MIB Issues as of 9/15/97 1. Cancel Agreed that Cancel and Abort should be indicated on the trailing edge. Between the leading and trailing edge acknowledgement of the Cancel shall be indicated by Job State Reasons. No indication of the the abort operation need be indicated until the trailing edge. 2. Add jobCanceledAtDevice Job State Reason (requested by Harry Lewis) Tom Hastings has proposed also adding jobCanceledByNonOwner. Any others? Ron Bergman Dataproducts Corp. From don at lexmark.com Mon Sep 15 21:55:05 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:10 2009 Subject: JMP> October PWG Meeting Details Message-ID: <199709160203.AA05599@interlock2.lexmark.com> Here are the details on the October Meeting... October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Meeting Room charges are estimated at $35-40 per person per day. Participants responsible for making their own reservations. Be sure to reference the PWG or IBM meeting to acquire the preferred rate. Limited numbers of Standard and Deluxe rooms are available. Early callers will get the Standard room/rate until this block is exhausted unless you specifically request Deluxe. The Hotel Boulderado, established in 1909, is a historic landmark with a "historic" section and a more modern wing. You may want to request your preference although I can't guarantee it will be available. Standard rooms tend to be a tad smaller in "historic" but each is unique. Deluxe rooms in the historic section are quite nice. Boulder is located appx. 50 minutes from the Denver International Airport. Free parking is available at the Boulderado for guests. From DIA, take Pena Blvd south 12 miles and merge right onto I-70 West. Take I-70 to I-270 (right) and head northwest to US 36 (right). When you reach Boulder proceed left onto Canyon Blvd (3rd light). Take Canyon to 13th (5th light) and turn right (north). Hotel Boulderado is at the corner of 13th and Spruce. You can also catch a shuttle called the "Airporter" which leaves on the hour from DIA. $14 one way - no reservation necessary. Check in with baggage, on DIA baggage level 5 across from the Hertz counter. It leaves every hr. on the 1/2 hr from the hotel for the return. Reservations recommended but not necessary. The Boulderado is a major stop. Travel time via shuttle is appx 70 minutes. The Boulderado is located in the heart of Boulder one block from "Pearl Street", an outdoor mall with shops, restaurants, etc. Forgoing the automobile is quite feasible. For more information on getting from DIA to Boulder visit http://amath-www.colorado.edu/appm/department/limos.html Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From bpenteco at boi.hp.com Thu Sep 18 14:18:39 1997 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:10 2009 Subject: JMP> Mapping of PJL to Job MIB attributes Message-ID: <199709160203.AA05599@interlock2.lexmark.com> I have uploaded the long overdue mapping of PJL to the Job MIB attributes. You can find it at: ftp://pwg.org/pub/pwg/jmp/protomap/pjl.doc Bob From harryl at us.ibm.com Mon Sep 22 18:42:10 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> October PING Message-ID: <199709160203.AA05599@interlock2.lexmark.com> Since Don will not be able to make the October meeting, please PING me (Harry Lewis) at harryl@us.ibm.com regarding your attendance to the October meeting in Boulder. Please let me know the meetings your will attend (p1394 Monday/Tuesday; IPP Wednesday/Thursday; and JMP/FIN Friday), and whether or not you are staying at the Boulderado. Please remember to make your reservations at the Boulderado before 10/3! October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Harry Lewis - IBM Printing Systems From rbergma at dpc.com Mon Sep 22 22:27:37 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> OID Assignment for an Informational RFC MIB Message-ID: <199709160203.AA05599@interlock2.lexmark.com> Chris, In a recent discussion regarding the submission of the Job Monitoring MIB as a Informational RFC, the question was raised as to the OID branch that will be assigned to the MIB. I mistakely believed that I could answer this question by looking at some existing Informational RFCs. It appears that no MIB documents in this category exist. We would certainly like to have the Job Monitoring MIB to have an OID in the mgmt.mib subtree rather than the experimental or the private subtree. Since it is likely that the Job MIB will be the first document to be accepted as an Information MIB, what is the position of the IESG as to the assignment of the base OID? If this number is in the mgmt.mib subtree, it would certainly resolve most of our fears as to submitting the MIB as an Informational RFC. If the experimental or private subtree must be used, we will certain push harder for this MIB to be a Standards Track document. The other possibility discussed was adding the Job MIB as a subtree to the Printer MIB. This is functionally not desirable, but would be proposed if it becomes the only alternative. Any help you can provide on this matter would be greatly appreciated. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Tue Sep 23 15:54:46 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - Agreed changes to IPP/JMP "job-state" and Message-ID: <9709231957.AA26388@zazen.cp10.es.xerox.com> I've cross-posted the agreements on the job-state/jmJobState and job-state-reasons /jmJobStateReason1 attributes/object specifications for IPP and JMP. In addition to the JMP changes listed in Ron's list, the JMP agreed to remove the finishing enums that IPP removed (because of a lack of a coordinate system specification for stapling), add private enum range for attributes to agree with IPP, and add 'job-interpreting', and add 'jobInterpreting', 'jobQueued', and 'jobTransforming' to JMP jmJobStateReasons1 to align with the recent additions to IPP "job-state-reasons" attribute. Only the 'jobInterpreting' is to be included in the jmJobStateReasons1 object. The file has the complete specifications for each of the attributes/objects for IPP and JMP: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 71168 Sep 23 19:40 statreas.doc -rw-r--r-- 1 pwg pwg 64184 Sep 23 19:40 statreas.pdf -rw-r--r-- 1 pwg pwg 26237 May 16 05:01 sepstate.txt The .pdf has red revision marks to show the changes. Scott will be replacing the "job-state" and "job-state-reasons" sections in the Job Model spec with the IPP text. Thanks, Tom From imcdonal at eso.mc.xerox.com Tue Sep 23 18:33:27 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:10 2009 Subject: JMP> OID Assignment for an Informational RFC MIB In-Reply-To: OID Assignment for an Informational RFC MIB> Message-ID: <9709232233.AA12311@snorkel.eso.mc.xerox.com> Copies To: jmp@pwg.org, chrisw@iwl.com Hi Ron, Tuesday (23 September 1997) Unfortunately, IETF SMIv2 (RFC 1902, see excerpt below) is very clear that BOTH the 'mgmt' and 'experimental' arcs are RESERVED, to Internet standards track RFCs and experiemental RFCs developed by chartered IETF working groups, respectively. The 'enterprises' arc under 'private' is the only acceptable place for an 'Informational RFC'. Under the IETF Printer MIB arc is also clearly illegal (since the PWG Job Mon MIB is NOT a chartered IETF working group). This is why (speaking SOLELY as an individual) I have reservations about the 'Informational RFC' approach (although I agree with Harry Lewis when he says "it's a standard if all of us printer vendors implement it"). I know this sounds dumb, but why don't we ask the IESG to charter the JMP working group as a separate project (ie, NOT as a subtask of the Printer MIB, which they are clearly not buying into)? Regards, - Ira McDonald 906-494-2434 ----------------------------- [RFC 1902] ------------------------------- Network Working Group SNMPv2 Working Group Request for Comments: 1902 J. Case Obsoletes: 1442 SNMP Research, Inc. Category: Standards Track K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services January 1996 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) [...excerpt] 4. Naming Hierarchy The root of the subtree administered by the Internet Assigned Numbers Authority (IANA) for the Internet is: internet OBJECT IDENTIFIER ::= { iso 3 6 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. Several branches underneath this subtree are used for network management: mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } However, the SMI does not prohibit the definition of objects in other portions of the object tree. The mgmt(2) subtree is used to identify "standard" objects. The experimental(3) subtree is used to identify objects being designed by working groups of the IETF. If an information module produced by a working group becomes a "standard" information module, then at the very beginning of its entry onto the Internet standards track, the objects are moved under the mgmt(2) subtree. The private(4) subtree is used to identify objects defined unilaterally. The enterprises(1) subtree beneath private is used, among other things, to permit providers of networking subsystems to register models of their products. ----------------------------- [RFC 1902] ------------------------------- >Date: Mon, 22 Sep 1997 19:27:37 PDT >From: Ron Bergman >To: chrisw@iwl.com >Cc: jmp@pwg.org >Subject: JMP> OID Assignment for an Informational RFC MIB > >Chris, > >In a recent discussion regarding the submission of the Job Monitoring MIB >as a Informational RFC, the question was raised as to the OID branch that >will be assigned to the MIB. I mistakely believed that I could answer >this question by looking at some existing Informational RFCs. It appears >that no MIB documents in this category exist. > >We would certainly like to have the Job Monitoring MIB to have an OID in >the mgmt.mib subtree rather than the experimental or the private subtree. >Since it is likely that the Job MIB will be the first document to be >accepted as an Information MIB, what is the position of the IESG as to the >assignment of the base OID? > >If this number is in the mgmt.mib subtree, it would certainly resolve most >of our fears as to submitting the MIB as an Informational RFC. If the >experimental or private subtree must be used, we will certain push harder >for this MIB to be a Standards Track document. > >The other possibility discussed was adding the Job MIB as a subtree to the >Printer MIB. This is functionally not desirable, but would be proposed if >it becomes the only alternative. > >Any help you can provide on this matter would be greatly appreciated. > > Ron Bergman > Dataproducts Corp. From rbergma at dpc.com Tue Sep 23 22:01:28 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> OID Assignment for an Informational RFC MIB In-Reply-To: <9709232233.AA12311@snorkel.eso.mc.xerox.com> Message-ID: <9709232233.AA12311@snorkel.eso.mc.xerox.com> Ira, Thanks for the update! You certainly have clarified the situation and I do agree with you regarding the Informational RFC approach. Chris, What is the possibility of requesting a working group charter for the Job Monitoring MIB as a project separate from the Printer MIB? Ron On Tue, 23 Sep 1997, Ira Mcdonald x10962 wrote: > Copies To: jmp@pwg.org, chrisw@iwl.com > > Hi Ron, Tuesday (23 September 1997) > > Unfortunately, IETF SMIv2 (RFC 1902, see excerpt below) is very clear > that BOTH the 'mgmt' and 'experimental' arcs are RESERVED, to Internet > standards track RFCs and experiemental RFCs developed by chartered IETF > working groups, respectively. The 'enterprises' arc under 'private' is > the only acceptable place for an 'Informational RFC'. Under the IETF > Printer MIB arc is also clearly illegal (since the PWG Job Mon MIB is > NOT a chartered IETF working group). > > This is why (speaking SOLELY as an individual) I have reservations about > the 'Informational RFC' approach (although I agree with Harry Lewis when > he says "it's a standard if all of us printer vendors implement it"). > > I know this sounds dumb, but why don't we ask the IESG to charter the > JMP working group as a separate project (ie, NOT as a subtask of the > Printer MIB, which they are clearly not buying into)? > > Regards, > - Ira McDonald > 906-494-2434 > > ----------------------------- [RFC 1902] ------------------------------- > > Network Working Group SNMPv2 Working Group > Request for Comments: 1902 J. Case > Obsoletes: 1442 SNMP Research, Inc. > Category: Standards Track K. McCloghrie > Cisco Systems, Inc. > M. Rose > Dover Beach Consulting, Inc. > S. Waldbusser > International Network Services > January 1996 > > > Structure of Management Information > for Version 2 of the > Simple Network Management Protocol (SNMPv2) > > > [...excerpt] > 4. Naming Hierarchy > > The root of the subtree administered by the Internet Assigned Numbers > Authority (IANA) for the Internet is: > > internet OBJECT IDENTIFIER ::= { iso 3 6 1 } > > That is, the Internet subtree of OBJECT IDENTIFIERs starts with the > prefix: > > 1.3.6.1. > > Several branches underneath this subtree are used for network > management: > > mgmt OBJECT IDENTIFIER ::= { internet 2 } > experimental OBJECT IDENTIFIER ::= { internet 3 } > private OBJECT IDENTIFIER ::= { internet 4 } > enterprises OBJECT IDENTIFIER ::= { private 1 } > > However, the SMI does not prohibit the definition of objects in other > portions of the object tree. > > The mgmt(2) subtree is used to identify "standard" objects. > > The experimental(3) subtree is used to identify objects being > designed by working groups of the IETF. If an information module > produced by a working group becomes a "standard" information module, > then at the very beginning of its entry onto the Internet standards > track, the objects are moved under the mgmt(2) subtree. > > The private(4) subtree is used to identify objects defined > unilaterally. The enterprises(1) subtree beneath private is used, > among other things, to permit providers of networking subsystems to > register models of their products. > ----------------------------- [RFC 1902] ------------------------------- > > >Date: Mon, 22 Sep 1997 19:27:37 PDT > >From: Ron Bergman > >To: chrisw@iwl.com > >Cc: jmp@pwg.org > >Subject: JMP> OID Assignment for an Informational RFC MIB > > > >Chris, > > > >In a recent discussion regarding the submission of the Job Monitoring MIB > >as a Informational RFC, the question was raised as to the OID branch that > >will be assigned to the MIB. I mistakely believed that I could answer > >this question by looking at some existing Informational RFCs. It appears > >that no MIB documents in this category exist. > > > >We would certainly like to have the Job Monitoring MIB to have an OID in > >the mgmt.mib subtree rather than the experimental or the private subtree. > >Since it is likely that the Job MIB will be the first document to be > >accepted as an Information MIB, what is the position of the IESG as to the > >assignment of the base OID? > > > >If this number is in the mgmt.mib subtree, it would certainly resolve most > >of our fears as to submitting the MIB as an Informational RFC. If the > >experimental or private subtree must be used, we will certain push harder > >for this MIB to be a Standards Track document. > > > >The other possibility discussed was adding the Job MIB as a subtree to the > >Printer MIB. This is functionally not desirable, but would be proposed if > >it becomes the only alternative. > > > >Any help you can provide on this matter would be greatly appreciated. > > > > Ron Bergman > > Dataproducts Corp. > From chrisw at iwl.com Wed Sep 24 04:56:10 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:10 2009 Subject: JMP> OID Assignment for an Informational RFC MIB In-Reply-To: Message-ID: On Tue, 23 Sep 1997, Ron Bergman wrote: > What is the possibility of requesting a working group charter for the Job > Monitoring MIB as a project separate from the Printer MIB? Zero. One of Harald A.'s last messages (to either this list or the pmp list) explained that the IETF only wants to charter working groups where they (Area Directors and above) have expertise to bring to the party. The way the process is set up, the higher you are in the organization, the more work you have to do. So, Fred Baker, Chair of the IETF, actually has to read every single RFC. It is a bit of an odd process, because it is reverse delegation of work, in a way. Obviously, then, the goal would be to restrict the number of working groups and be highly selective in what is chartered. Since printers and issues with printers do not represent core-Internet protocols or technology, there is a disincentive to include them. Given the above and given the fact that the Printer MIB was already chartered as a working group, Lloyd and I figured that the only possible way to get the Job MIB chartered was to add it to the Printer MIB. It actually did get approved by our previous Area Director, but then for some reason when the transition took place, the Job MIB request for charter was re-reviewed, and then rejected. I have some calls in about the rationale behind the IANA assignments as put forth in RFC 1902. I hope to have some answers by a week from today. From hastings at cp10.es.xerox.com Wed Sep 24 11:17:23 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> OID Assignment for an Informational RFC MIB In-Reply-To: OID Assignment for an Informational RFC MIB> Message-ID: <9709241519.AA26788@zazen.cp10.es.xerox.com> How are the SNA MIBs that IBM and Cisco produce given OIDs? Are they under IBM's enterprise? Could PWG be registered as an enterprise? The PWG has already been registered as a domain name under "org". If PWG was registered as an enterprise, then could the Job Monitoring MIB be under private.enterprises.nnn? Tom ----------------------------- [RFC 1902] ------------------------------- Network Working Group SNMPv2 Working Group Request for Comments: 1902 J. Case Obsoletes: 1442 SNMP Research, Inc. Category: Standards Track K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services January 1996 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) [...excerpt] 4. Naming Hierarchy The root of the subtree administered by the Internet Assigned Numbers Authority (IANA) for the Internet is: internet OBJECT IDENTIFIER ::= { iso 3 6 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. Several branches underneath this subtree are used for network management: mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } However, the SMI does not prohibit the definition of objects in other portions of the object tree. The mgmt(2) subtree is used to identify "standard" objects. The experimental(3) subtree is used to identify objects being designed by working groups of the IETF. If an information module produced by a working group becomes a "standard" information module, then at the very beginning of its entry onto the Internet standards track, the objects are moved under the mgmt(2) subtree. The private(4) subtree is used to identify objects defined unilaterally. The enterprises(1) subtree beneath private is used, among other things, to permit providers of networking subsystems to register models of their products. ----------------------------- [RFC 1902] ------------------------------- At 19:27 09/22/97 PDT, Ron Bergman wrote: >Chris, > >In a recent discussion regarding the submission of the Job Monitoring MIB >as a Informational RFC, the question was raised as to the OID branch that >will be assigned to the MIB. I mistakely believed that I could answer >this question by looking at some existing Informational RFCs. It appears >that no MIB documents in this category exist. > >We would certainly like to have the Job Monitoring MIB to have an OID in >the mgmt.mib subtree rather than the experimental or the private subtree. >Since it is likely that the Job MIB will be the first document to be >accepted as an Information MIB, what is the position of the IESG as to the >assignment of the base OID? > >If this number is in the mgmt.mib subtree, it would certainly resolve most >of our fears as to submitting the MIB as an Informational RFC. If the >experimental or private subtree must be used, we will certain push harder >for this MIB to be a Standards Track document. > >The other possibility discussed was adding the Job MIB as a subtree to the >Printer MIB. This is functionally not desirable, but would be proposed if >it becomes the only alternative. > >Any help you can provide on this matter would be greatly appreciated. > > > > Ron Bergman > Dataproducts Corp. > > > > From harryl at us.ibm.com Thu Sep 25 13:43:26 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> JMP Atlanta (9/97) Minutes Message-ID: <9709241519.AA26788@zazen.cp10.es.xerox.com> I have posted minutes of the Atlanta JMP meeting at ftp://ftp.pwg.org/pub/pwg/jmp/minutes/jmp-0997.pdf or.txt Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Thu Sep 25 18:44:26 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - Job Monitoring MIB V0.86 posted and sent as an I-D Message-ID: <9709252247.AA27321@zazen.cp10.es.xerox.com> I've updated the MIB with the agreements reached in Atlanta (See Harry's minutes also just posted), posted the Job Monitoring MIB V0.86 that corresponds to Internet-Draft: and forwarded the draft as an Internet-Draft. I've cross posted this announcement to the IPP mail list, since IPP and JMP are on the same schedule and the job attributes in common are aligned. The IPP Model document is finalizing editorial comments by Sept 30. See ftp://ftp.pwg.org/pub/mib/jmp/internet-drafts/ -rw-r--r-- 1 pwg pwg 214623 Sep 25 22:12 draft-ietf-printmib-job-monitor-06.txt and ftp://ftp.pwg.org/pub/mib/jmp/mibs -rw-r--r-- 1 pwg pwg 121938 Sep 25 21:27 jmp-mib.mib -rw-r--r-- 1 pwg pwg 282185 Sep 25 21:27 jmp-mib.pdf -rw-r--r-- 1 pwg pwg 214623 Sep 25 21:27 jmp-mib.txt -rw-r--r-- 1 pwg pwg 361984 Sep 25 21:27 jmp-mibr.doc -rw-r--r-- 1 pwg pwg 314041 Sep 25 21:28 jmp-mibr.pdf -rw-r--r-- 1 pwg pwg 318441 Sep 25 21:28 jmp-mibr.pdr -rw-r--r-- 1 pwg pwg 8631 Sep 25 21:28 jmp.dic -rw-r--r-- 1 pwg pwg 13309 Sep 25 22:10 mibvaria.dot ************************************************************************** * Please make any comments by Wednesday, October 8. As the JMP minutes * indicate, we've agreed to a functionality freeze, just as IPP has. * So the comments 'should' be limited to editorial comments. We plan to * do a last call on October 10, or its equivalent, for people outside the * PWG. So PWG people should consider V0.86 as the PWG last call. ************************************************************************** The jmp-mib.pdf is without revision marks and has line numbers. This is the version that JMP should make any comments against. The jmp-mib.txt == draft-ietf-printmib-job-monitor-06.txt The jmp-mibr.doc is with revision marks. The jmp-mibr.pdr is with red revision marks. The jmp-mibr.pdf is with black revision marks. The jmp-mib.mib file compiles with one warning (assignment of the temporary OID). The jmp.dic file is the spell checking dictionary The mibvaria.dot is the MS-WORD template used We got the lion's share out of the mapping exercise in Atlanta. However, please do your mapping assignments. Use them as a way to review the MIB specification. Pretend you are an SNMP agent responding to a Get for each object and attribute listed in the mapping template and determine how to get that information from the job submission protocol for the service or device that your agent is providing access. See if there are any descriptions that need clarification. The mapping assignments are: AppleTalk PAP applepap.doc Ron Bergman IETF IPP ietf-ipp.doc Tom Hastings IPDS ipds.doc Harry Lewis ISO DPA iso-dpa.doc Tom Hastings LPD 1179 lpr-lpd.doc Ron Bergman NDPS ndps.doc Scott Isaacson PJL pjl.doc Bob Pentecost PostScript ps.doc PSERVER pserver.doc Scott Isaacson RPRINTER rprinter.doc Scott Isaacson SMB smb.doc TIPSI/NPAP tipsi.doc Don Wright See Ron's draft RFC for the mapping and the minutes. There are no open issues left, except what OID are we going to be assigned? Are we going to be standards track or a PWG standard? See Harry's minutes. Tom From hastings at cp10.es.xerox.com Fri Sep 26 21:09:46 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> MOD - new text for the 6 IPP job size and progression Message-ID: <9709270112.AA00399@zazen.cp10.es.xerox.com> I've posted my action item to align the 6 IPP job size and progression attributes with JMP. I've posted them in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 24064 Sep 27 01:07 job-size.doc -rw-r--r-- 1 pwg pwg 21897 Sep 27 01:07 job-size.pdf The .doc and .pdf show the revision marks. Tom Here is the plain text without revision marks: Subj: Alignment of IPP Model with Job Monitoring MIB: job size and progression atttributes From: Tom Hastings Date: 9/26/97 File: job-size.doc This document is one of my action items for the IPP Model document to align the three IPP job size Job Template attributes and the three IPP job progression job-description attributes the corresopnding Job Monitoring MIB (JMP) objects/attributes. Specifically align the three IPP job size Job Template attributes: "job-k-octets", "job-impressions", "job-media-sheets" with their corresponding Job Monitoring MIB (JMP) objects/attributes: jmJobKOctetsRequested, jmJobImpressionsRequested, and sheetsRequested. Also align the IPP job description attributes: "job-k-octets-processed", "job-impressions-completed", and "job-media-sheets-completed" with the JMP objects/attributes: jmJobKOctetsProcessed, jmJobImpressionsCompleted, and sheetsCompleted. For JMP, we included the semantics of the two implementations for making copies: (1) one pass over the input, and (2) multiple passes. The latter produces values that are multiples of the former, where the multiple is the number of copies. We thought that it was better to have a clear and unambiguous value for the two implementations, that try to have the implementations appear to be the same and attempt to scale one to look like the other. 1. "job-k-octets" and jmJobKOctetsRequested jmJobKOctetsRequested OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total size in K (1024) octets of the document(s) being requested to be processed in the job. The agent SHALL round the actual number of octets up to the next highest K. Thus 0 octets SHALL be represented as '0', 1-1024 octets SHALL be represented as '1', 1025-2048 SHALL be represented as '2', etc. In computing this value, the server/device SHALL not include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation." ::= { jmJobEntry 5 } 4.2.18 job-k-octets (integer(0:2**31 - 1)) This attribute specifies the total size of the document data in K octets, i.e., in units of 1024 octets requested to be processed in the job. The value SHALL be rounded up, so that a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL be 2, etc. This value SHALL not include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the document data and independent of whether the output is collated or not. Thus the value is independent of the implementation. Note: This attribute and the following two attributes ("job-impressions" and "job-media-sheets") are not intended to be counters; they are intended to be useful routing and scheduling information if known. For these three attributes, the Printer may try to compute the value if it is not supplied in the create request. Even if the client does supply a value for this attribute in the create request, the Printer may choose to change the value if the Printer is able to compute a value which is more accurate than the client supplied value. The Printer may be able to determine the correct value for this attribute either right at job submission time or at any later point in time. If the value of this attribute is unknown, the Printer may choose to respond with a value of '-2' (which signifies "unknown") rather than choose to not support the attribute at all. 2. "job-impressions" and jmJobImpressionsRequested jmJobImpressionsRequested OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total size in number of impressions of the document(s) being requested by this job to produce. In computing this value, the server/device SHALL not include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation." ::= { jmJobEntry 7 } 4.2.19 job-impressions (integer(0:2**31 - 1)) This attribute specifies the total number of impressions of the document(s) being requested by this job to produce. This value SHALL not include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the document data and independent of whether the output is collated or not. Thus the value is independent of the implementation. 3. "job-media-sheets" and sheetsRequested sheetsRequested(150), Integer32(-2..2147483647) INTEGER: The number of medium sheets requested to be processed for this job. 4.2.20 job-media-sheets (integer(0:2**31 - 1)) This attribute specifies the total number of media sheets to be processed for this job. Unlike the "job-k-octets" and the "job-impressions" attributes, this value SHALL include the multiplicative factors contributes by the number of copies specified by the "copies" attribute 4. "job-k-octets-processed" and jmJobKOctetsProcessed jmJobKOctetsProcessed OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of octets processed by the server or device measured in units of K (1024) octets. The agent SHALL round the actual number of octets processed up to the next higher K. Thus 0 octets SHALL be represented as '0', 1-1024 octets SHALL be represented as '1', 1025-2048 octets SHALL be '2', etc. For printing devices, this value is the number interpreted by the page description language interpreter rather than what has been marked on media. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the jmJobKOctetsRequested object. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the jmJobKOctetsRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobKOctetsProcessed object can be used with the jmJobKOctetsRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." ::= { jmJobEntry 6 } 4.3.16 job-k-octets-processed (integer(0:2**31 - 1)) This attribute specifies the number of octets processed in K octets, i.e., in units of 1024 octets. The value SHALL be rounded up, so that a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL be 2, etc. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the "job-k-octets" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the "job-k-octets" attribute. Note: This attribute and the following two attributes ("job-impressions-completed" and "job-sheets-completed") are intended to be counters (as described in the Job Monitoring MIB [27]). That is, if the "job-state" is 'processing' or 'processing-stopped', this value is intended to contain the amount of the job that has been processed to the time at which the attributes are requested. For any of these three attributes, the Printer may choose to return the value '-2' (which represents "unknown") rather than choose to not support the attribute at all. 5. "job-impressions-completed" and jmJobImpressionsCompleted jmJobImpressionsCompleted OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the jmJobImpressionsRequested object. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the jmJobImpressionsRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with the jmJobImpressionsRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." ::= { jmJobEntry 8 } 4.3.17 job-impressions-completed (integer(0:2**31 - 1)) This job attribute specifies the number of impressions completed for the job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. This attribute is intended to be a counter as in the Job Monitoring MIB. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the "job-impressions" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the "job-impressions" attribute. 6. "job-media-sheets-completed" and sheetsCompleted sheetsCompleted(151), Integer32(-2..2147483647) INTEGER: The number of medium sheets that have completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both. 4.3.18 job-media-sheets-completed (integer(0:2**31 - 1)) This job attribute specifies the media-sheets completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both. This attribute is intended to be a counter as in the Job Monitoring MIB. From hastings at cp10.es.xerox.com Tue Sep 30 21:52:47 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> FWD: MOD - IPP Model spec Appendix comparing IPP to JMP Message-ID: <3.0.1.32.19970930185247.00ed3100@garfield> To JMP for information. Tom >Date: Tue, 30 Sep 1997 18:51:33 -0700 >To: ipp >From: Tom Hastings >Subject: MOD - Appendix comparing IPP to JMP > >I have finished my other IPP Model action item to produce an >Appendix that compares the IPP Job Attributes with the Job Monitoring MIB. > >I have compared the 9/26/97 IPP Model with the 9/19/96 V0.86 Job Monitoring MIB. > >I have stored three files in >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-jmp.doc .pdf .txt > >The .doc is in MS-WORD V7.0 (I've finally upgraded). > >I have also attached the .txt file here, but the .pdf file is much more readable, >since the table entries don't wrap: > > >Subj: Comparision of IPP job attributes with the Job Monitoring MIB Appendix >From: Tom Hastings >File: ipp-jmp.doc >Date: 9/29/97 > >Here is my action item to make an appendix for the Model specification >that compares the IPP Job object attributes with the Job Monitoring MIB. >It can be converted to CourierNew and saved as text with layout to >produce fixed pitch ASCII for the Model document, as Scott as done for >the other tables in the spec. > > >Comparison of IPP job attributes with the Job Monitoring MIB > >This appendix compares the IPP job attributes with the Job Monitoring >MIB (JMP) [27]. The notes column indicates the nature of the >comparison. A ‘-‘ that there is no equivalent or similar attribute in >the Job Monitoring MIB. The notation “identical” indicates that the >syntax and semantics are identical. For textual strings, the Job >Monitoring MIB limits values to 63 octets, with the single exception of >the JMP ‘jobURI’ attribute which as a limit of 255 octets. > >NOTE - The Job Monitoring MIB is designed to represent jobs that contain >multiple documents. The MIB permits multiple values of certain >attributes per job in order to represent when a job has more than one >value, such as ‘documentFormat’ or ‘documentName’. Some such attributes >are specified as multiple per-job, such as ‘documentFormat’, so that a >document can have more than one and repetition of the same value for >multiple documents is eliminated, while other attributes are specified >as one per document, such as the ‘documentName’ attribute. > >IPP Job Template JMP Notes >Attributes object/attribute > >job-sheets - >(type4 keyword) >notify-events - >(1setOf type2 >keyword) >notify-addresses - >(1setOf uri) >job-priority jobPriority identical >(integer(1:100)) >job-hold-until jobHoldUntil identical >(type4 keyword) >multiple- - >document- >handling >(type2 keyword) >media mediumRequested Use JmJobStringTC to >(type4 keyword) represent the keyword >number-up - >(integer) >sides sides Map keywords to ‘1’ or >(type2 keyword) ‘2’ >pinter- printerResolution identical >resolution Requested >(resoultion) >print-quality printQualityReque identical >(type2 enum) sted >finishings finishing identical >(1setOf type2 >enum) >copies jobCopiesRequeste complex mapping that >(integer(1:2**31 d AND depends on “multiple- >- 1)) documentCopiesReq document-handling” > uested >page-range - >(rangeOf >integer) >orientation - >(type2 enum) >document-format documentFormat Use the OCTET STRING >(mimeType) to hold the Media Type > name >compression - >(type3 keyword) >job-k-octets jmJobKOctetsReque identical >(integer(0:2**31 sted >- 1)) >job-impressions jmJobImpressionsR identical >(integer(0:2**31 equested >- 1)) >job-media-sheets sheetsRequested identical >(integer(0:2**31 >- 1)) >user-human- - >language >(humanLanguage) > >Job Description >Attributes >job-uri jobURI identical, except max >(uri) 255 octets in JMP >job-id jmJobIndex identical >(integer(1:MAX)) >job-more-info - >(uri) >job-name jobName identical >(name) >job-originating- jmJobOwner identical >user >(octetString) >job-human- - >language >(human-language) >job-state jmJobState identical >(type1 enum) >job-state- jmJobStateReasons JMP is a superset and >reasons 1 OR is bit encoded, >(1setOf type2 jobStateReasons2 instead of keywords >keyword) OR > jobStateReasons3 > OR > jobStateReasons4 >job-state- - >message >(text) >output-device- physicalDevice identical, both UTF-8 >assigned strings >(name) >time-at-pending jobSubmissionTime not the same, if job >(integer) , enters pendingHeld > state first >time-at- jobStartedProcess identical >processing ingTime >(integer) >time-at- jobcompletionTime identical >completed >(integer) >number-of- jmNumberOfInterve identical >intervening-jobs ningJobs >(integer(0:2**31 >- 1)) >job-message-from- - >operator >(text) >job-k-octets- jmJobKOctetsProce identical >processed ssed >(integer(0:2**31 >- 1)) >job-impressions- jmJobImpressionsC identical >completed ompleted >(integer(0:2**31 >- 1)) >job-media-sheets- sheetsCompleted identical >completed >(integer(0:2**31 >- 1)) > > > From rbergma at dpc.com Wed Oct 1 13:52:46 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Review of Job Monitoring MIB version 0.86 Message-ID: <3.0.1.32.19970930185247.00ed3100@garfield> Tom, Thanks for all your work on this document. It looks *almost* ready to submit to the IESG! I have only three comments (you can't get by without some changes): 1. The following text is repeated in both section 3.5.2 and jobCodedCharSet. I do not believe that it is needed in both places. Since the text for jobCodedCharSet also references section 3.5.2, this text could be removed from either place. However, I would rather see it remain with jobCodedCharSet. "If the agent does not know what coded character set was used by the job submitting client, the agent shall either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job." 2. In the description for jmJobStateReasons, line 2984 in the .pdf version without revisions, the word "the" is repeated. 3. A reference to the "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB" RFC should be included. Could be in the Introduction section or Appendix B. (Any other place better?) Ron From harryl at us.ibm.com Thu Oct 2 12:45:50 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> Final chance for October reservations Message-ID: <3.0.1.32.19970930185247.00ed3100@garfield> Reminder... tomorrow (Friday 10/3) is the last day the Hotel Boulderado= will accept reservations for the PWG meeting at the preferred IBM rate. Plea= se make your reservations now, if you haven't yet, and please Ping me also, if = you haven't yet done so. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Thu Oct 2 14:08:14 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> PMP> I-D ACTION:draft-ietf-printmib-job-monitor-06.txt Message-ID: <3.0.1.32.19971002110814.00f73100@garfield> >Return-Path: >To: IETF-Announce@ietf.org >Cc: pmp@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-06.txt >Date: Mon, 29 Sep 1997 06:47:40 PDT >Sender: pmp-owner@pwg.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Printer MIB Working Group of the IETF. > > Title : Job Monitoring MIB - V0.85 > Author(s) : T. Hasting, H. Lewis, S. Isaacson, R. Bergman > Filename : draft-ietf-printmib-job-monitor-06.txt > Pages : 100 > Date : 1997-09-26 > > This Internet-Draft specifies a small set of read-only SNMP MIB > objects for (1) monitoring the status and progress of print jobs > (2) obtaining resource requirements before a job is processed, (3) > monitoring resource consumption while a job is being processed and > (4) collecting resource accounting data after the completion of a > job. This MIB is intended to be implemented (1) in a printer or > (2) in a server that supports one or more printers. Use of the > object set is not limited to printing. However, support for > services other than printing is outside the scope of this Job > Monitoring MIB. Future extensions to this MIB may include, but are > not limited to, fax machines and scanners. > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-printmib-job-monitor-06.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-06.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-printmib-job-monitor-06.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19970926133830.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-printmib-job-monitor-06.txt >Content-Type: text/plain >Content-ID: <19970926133830.I-D@ietf.org> > From imcdonal at eso.mc.xerox.com Thu Oct 9 15:51:49 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:10 2009 Subject: JMP> FW: Harald's note on Internationalization Policy Message-ID: <9710091951.AA17622@snorkel.eso.mc.xerox.com> Hi folks, Thursday (9 October 1997) With Harald Alvestrand's kind permission, I am forwarding to the IPP, JMP, and PMP lists his reply to my recent question about the timeframe for adoption of the IETF Policy on Character Sets and Languages (which Harald presented at the IETF Plenary in Munich in August). I have also forwarded my original note to Harald last week (for context). As Harald makes clear, expect to have to give adequate answers for all IETF-chartered projects to the requirements stated in Harald's policy, which may be found at "ftp://ds.internic.net/Internet-Drafts" as "draft-alvestrand-charset-policy-01.txt" Please note that the Printer MIB v2 is NOT exempt from compliance with this policy on internationalization of text strings. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 >----------------------------------------------------------------------< >From: Harald.T.Alvestrand@uninett.no >To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) >Cc: hastings@cp10.es.xerox.com >Subject: Re: Timeframe of adoption for IETF Charset/Language Policy? >In-Reply-To: Your message of "Tue, 30 Sep 1997 08:45:55 PDT." >Date: Thu, 9 Oct 1997 08:10:59 PDT > >Ira, >I hope to have the rules in force some time in November. >It'll be safe to assume that I'll be asking the questions of >protocols before that time, too. > >I've got the printing MIBs and things on my list of things to check >(which unfortunately is long). I won't forget, but may be late.... > > Harald A >----------------------------------------------------------------------< >>Date: Tue, 30 Sep 97 11:45:55 EDT >>From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) >>To: Harald.T.Alvestrand@uninett.no, >> hastings@cp10.es.xerox.com, imcdonal >>Subject: Timeframe of adoption for IETF Charset/Language Policy? >> >>Hi Harald, Tuesday (30 September 1997) >> >>I just read your second draft ('...policy-01.txt') of the IETF >>Charset/Language policy. It is EXCELLENT work. >> >>I'm wondering if you could characterize the timeframe when you >>expect (or hope) for adoption of this policy (and presumably >>publication as an RFC). >> >>The PWG (Printer Working Group) members are working on three >>projects which would be affected by this policy (and the need >>for waivers for non-conformance for protocols entering OR >>advancing upon the IETF 'standards track'): >> >>Printer MIB v2.0 (updates RFC 1759) >>- clearly deficient, as numerous read-only and read-write >> descriptive text strings are entirely without labels for >> charset OR language >>- would NOT be permitted to advance to Draft Standard, if >> subject to the IETF's policy >> >>Job MIB v0.86 (latest of six I-Ds) >>- since it intends to cohere with IPP and Tom Hastings edits >> this MIB, it can safely be assumed to meet the IETF policy >> before completion >>- I'm aware that you and Keith Moore have stated that this >> is NOT a chartered IETF project, nonetheless, the PWG's >> Job Mon MIB working group are following IETF SMIv2 and >> other applicable rules >> >>Internet Print Protocol v1.0 (still in late I-D stage) >>- I'm delighted to point out to you that two weeks ago >> the IPP working group decided to add 'charset/language' >> prefixes (in the style of RFC 2184) to EACH operation >> and/or object attribute of datatype 'text' or 'name' >>- We are also working to make sure that documents sent >> directly (ie, PrintJob) or by reference (ie, SendURI) >> are labelled (EXTERNALLY) with 'document-format' (a >> MIME 'media-type') and 'document-language' (RFC 1766 tag). >> >>Cheers, >>- Ira McDonald (outside consultant at Xerox) >> High North Inc >> PO Box 221 >> Grand Marais, MI 49839 >> 906-494-2434 From harryl at us.ibm.com Mon Oct 13 19:40:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> jmTimeStamp Message-ID: <9710091951.AA17622@snorkel.eso.mc.xerox.com> We've run into an observation, here, regarding the units and range of T= imeStamp (seconds) and the range of sysUpTime. The jmTimeStampTC can count to appx 68 years, in seconds, while sysUp= Time represents time in 100ths of a second and, resets appx every 1.36 years= From imcdonal at eso.mc.xerox.com Tue Oct 14 08:47:10 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:10 2009 Subject: JMP> jmTimeStamp In-Reply-To: jmTimeStamp> Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> Hi Harry, Are you suggesting that 'JmTimeStampTC' be changed to units of 'TimeTicks' like 'sysUpTime' (in MIB-II)? I think the rationale for units of seconds was to avoid the appearance of demanding accuracy in 'TimeTicks' for processing info on print jobs, which is unlikely to be of use to client applications anyway. Separately, by a poor design decision, TimeTicks was made a fundamentally different syntax (over-the-wire) in SMIv1 and SMIv2, so that it CAN'T be stored in an 'INTEGER' type (in the job attribute table). So if we change the units of 'JmTimeStampTC' to hundredths of a second, we STILL need the TC, to avoid trying to use ACTUAL 'TimeTicks' syntax for job attributes. Does your implementation team think we should align the units? While an SNMP agent may know time in 'TimeTicks', a print language interpreter may NOT have available such accuracy (to supply the values for job attributes). Cheers, - Ira McDonald (outside consultant at Xerox) -------------------------- Harry's note -------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA18594; Mon, 13 Oct 97 19:44:45 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA11908; Mon, 13 Oct 97 19:40:33 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52105(5)>; Mon, 13 Oct 1997 16:40:32 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05791 for ; Mon, 13 Oct 1997 19:37:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Oct 1997 19:36:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05674 for jmp-outgoing; Mon, 13 Oct 1997 19:35:22 -0400 (EDT) From: Harry Lewis To: Subject: JMP> jmTimeStamp Message-Id: <5030300012186609000002L092*@MHS> Date: Mon, 13 Oct 1997 16:40:42 PDT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: jmp-owner@pwg.org Status: R We've run into an observation, here, regarding the units and range of T= imeStamp (seconds) and the range of sysUpTime. The jmTimeStampTC can count to appx 68 years, in seconds, while sysUp= Time represents time in 100ths of a second and, resets appx every 1.36 years= From harryl at us.ibm.com Tue Oct 14 10:52:53 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> jmTimeStamp In-Reply-To: jmTimeStamp> Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> Ira, I considered recommending a change back to TimeTicks but I feel it= is too late to suggest such a change and then there are the problems Ira menti= oned. Rather, I just wanted to point out the difference in range and precisio= n and clarify that a printer implementation is most likely to divide sysUpTim= e by 100, thus never utilizing a great portion of the specified range. So, I= suggest documenting a shorter range. Harry Lewis ----- Ira's Note ---- jmp-owner@pwg.org on 10/14/97 06:56:07 AM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: JMP> jmTimeStamp Hi Harry, Are you suggesting that 'JmTimeStampTC' be changed to units of 'TimeTicks' like 'sysUpTime' (in MIB-II)? I think the rationale for units of seconds was to avoid the appearance of demanding accuracy in 'TimeTicks' for processing info on print jobs, which is unlikely to be of use to client applications anyway. Separately, by a poor design decision, TimeTicks was made a fundamentally different syntax (over-the-wire) in SMIv1 and SMIv2, so that it CAN'T be stored in an 'INTEGER' type (in the job attribute table). So if we change the units of 'JmTimeStampTC' to hundredths of a second, we STILL need the TC, to avoid trying to use ACTUAL 'TimeTicks' syntax for job attributes. Does your implementation team think we should align the units? While an SNMP agent may know time in 'TimeTicks', a print language interpreter may NOT have available such accuracy (to supply the values for job attributes). Cheers, - Ira McDonald (outside consultant at Xerox) -------------------------- Harry's note -------------------------- We've run into an observation, here, regarding the units and range of T= =3D imeStamp (seconds) and the range of sysUpTime. The jmTimeStampTC can count to appx 68 years, in seconds, while sysUp= =3D Time represents time in 100ths of a second and, resets appx every 1.36 years= =3D = From rbergma at dpc.com Wed Oct 15 12:03:31 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Re: Last JMP? In-Reply-To: <5030300011918682000002L022*@MHS> Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> Harry, Good idea! I do believe that December will be the last meeting for JMP. The Job Monitoring MIB RFC is completed except for: 1) The issue of how to publish as an Informational RFC. 2) Any additional Job Submission Id formats. The primary effort for both meetings will be the completion of the Mapping RFC. I have updated this document and sent for review to those persons who provided inputs. I still need additional inputs to complete this effort. (I will publish what is available by next Wednesday.) Ron Bergman Dataproducts Corp. On Wed, 8 Oct 1997, Harry Lewis wrote: > Ron, can we think about making some sort of statement that this (or December?) > is the last JMP meeting? Aside from interop test which we should probably plan > for. > > Harry Lewis - IBM Printing Systems > From rbergma at dpc.com Wed Oct 15 12:36:36 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Request for Enterprises OID Assignment Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> I would like to request an OID Assignment in the SNMP Enterprise subtree for: Printer Working Group (PWG) c/o Ron Bergman Dataproducts Corp. 1757 Tapo Canyon Road Simi Valley, CA 93063-3394 (805)578-4421 rbergma@dpc.com Thanks, Ron Bergman From jkm at underscore.com Wed Oct 15 12:52:04 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:10 2009 Subject: JMP> Request for Enterprises OID Assignment In-Reply-To: Request for Enterprises OID Assignment> Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> Ron, Sorry, but I should have seen this coming... Thinking about it, it may be best if either Don Wright (PWG Chairman) or myself (PWG Secretary) sends the official request to IANA for the PWG Enterprise OID. Since Underscore is already the sponsor (owner?) of the PWG domain name(s), then perhaps it is best that I send the request. That way all the external PWG registrations will be under the same company name. Anyone have any comments or objections to this proposal? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Ron Bergman wrote: > > I would like to request an OID Assignment in the SNMP Enterprise subtree > for: > > Printer Working Group (PWG) > > c/o Ron Bergman > Dataproducts Corp. > 1757 Tapo Canyon Road > Simi Valley, CA 93063-3394 > (805)578-4421 > rbergma@dpc.com > > Thanks, > > Ron Bergman From rbergma at dpc.com Wed Oct 15 13:26:48 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:10 2009 Subject: JMP> Request for Enterprises OID Assignment In-Reply-To: <3444F4B4.18CC1C0D@underscore.com> Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> I have received the proper application from IANA and have forwarded same to Jay Martin. I propose that Jay Martin be the contact. Any objections. Ron Bergman Dataproducts Corp. On Wed, 15 Oct 1997, Jay Martin wrote: > Ron, > > Sorry, but I should have seen this coming... > > Thinking about it, it may be best if either Don Wright (PWG Chairman) > or myself (PWG Secretary) sends the official request to IANA for the > PWG Enterprise OID. > > Since Underscore is already the sponsor (owner?) of the PWG domain > name(s), then perhaps it is best that I send the request. That way > all the external PWG registrations will be under the same company > name. > > Anyone have any comments or objections to this proposal? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > Ron Bergman wrote: > > > > I would like to request an OID Assignment in the SNMP Enterprise subtree > > for: > > > > Printer Working Group (PWG) > > > > c/o Ron Bergman > > Dataproducts Corp. > > 1757 Tapo Canyon Road > > Simi Valley, CA 93063-3394 > > (805)578-4421 > > rbergma@dpc.com > > > > Thanks, > > > > Ron Bergman > From jkm at underscore.com Wed Oct 15 13:38:34 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:10 2009 Subject: JMP> Re: Request for Enterprises OID Assignment In-Reply-To: Message-ID: <9710141247.AA18657@snorkel.eso.mc.xerox.com> Ron Bergman does not require that his company register the Enterprise OID, and instead prefers a more "neutral" company to own the OID. However, Ron needs to have this OID number assigned in advance of the upcoming PWG meetings in Boulder at the end of this month (the week of Oct 27). The Job Monitoring MIB (JMP) project needs OID to establish the final set of OIDs for the MIB. (Closure at last!) I encourage anyone with comments/suggestions/objections/whatever to please state them to the PWG mailing list (pwg@pwg.org) immediately so that we may proceed as quickly as possible. If no qualified objections are raised by 5:00pm EDT Thursday, Oct 16, I will assume everyone in the PWG agrees with this approach. In this case we will expect to formally register for an Enterprise OID with IANA on Thursday evening. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Ron Bergman wrote: > > Jay, > > I now have the application from IANA to obtain the OID. I have no > objection to who is the contact, as long as this can be resolved quickly. > (i.e. I would like a number prior to the meeting in Boulder.) > > My personal preference would be for Underscore to be the contact, rather > than another printer company. (Makes it sort of neutral?) > > Thanks, > Ron > > ---------- Forwarded message ---------- > Date: Wed, 15 Oct 97 10:10:40 PDT > From: iana@ISI.EDU > To: rbergma@it.dpc.com > Cc: iana@ISI.EDU > Subject: Re: Request for Enterprises OID Assignment > > MIB Application > > Please complete and return application to "IANA-MIB@isi.edu" to > register for a Private Enterprise Number. The normal time for > completing the application process is 1 week. > > Thank you, > > Josh Elliott - USC/ISI > Internet Assigned Numbers Authority-MIB > > Voice: (310) 822-1511 x302 > Fax: (310) 823-6714 > Email: IANA-MIB@ISI.EDU > > ============================================================================== > > Request for SNMP/MIB Enterprise Number > > To establish a MIB/SNMP Enterprise Number, the following information > must be sent to "IANA-MIB@ISI.EDU". > > DATE OF APPLICATION: > > Company Name: > > Company Address: > > Company Phone Number: > > Contact Name: > > Contact Address: > > Contact Phone: > > Contact Email: > > FAX Number: From don at lexmark.com Mon Oct 20 16:12:15 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:10 2009 Subject: JMP> Boulder PWG Schedule / LA Meeting Details Message-ID: <199710202012.AA00130@interlock2.lexmark.com> Unfortunately, I will not be in attendance at the October PWG meetings in Boulder. (First one I have ever missed -- there goes my record.) Below is the schedule for the meetings. Please read this very close as there are a couple of new things and some new starting times. October 27, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 28, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 29, 1997 8:00 - 8:30 Printer MIB Update - Lloyd Young 8:30 - 5:30 IPP - Carl-Uno Manros October 30, 1997 8:30 - 12:00 IPP - Carl-Uno Manros 1:00 - 6:00 Sense - JK Martin October 31, 1997 8:30 - 12:00 Finisher MIB - Harry Lewis 1:00 - 5:30 Job MIB - Ron Bergman If appropriate, more detailed agendas for each working group will be posted to the appropriate mailing list by the designated chairman. ------------- The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. -------------- Enjoy! Don Wright PWG Chair ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From harryl at us.ibm.com Wed Oct 22 11:42:45 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:10 2009 Subject: JMP> Friday agenda Message-ID: <199710202012.AA00130@interlock2.lexmark.com> I've had a request to swap the JMP and FIN discussions, Friday, making = JMP first followed by FIN... this to accomodate travel. Are there any objec= tions? If not, we will make this adjustment to the agenda. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Wed Oct 22 20:31:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:10 2009 Subject: JMP> PWG> IANA has assigned the PWG its own private enterprise Message-ID: <3.0.1.32.19971022173143.0109b100@garfield> Harald, The Printer Working Group has requested and been assigned a private enterprise number for assigning OIDs for such things as the Job Monitoring MIB. Next week (10/29) the group is going to decide how to assign the OIDs for various PWG purposes. Most of us would prefer that the Job Monitoring MIB be an IETF standard MIB, as the Printer MIB has been. However, if the Job Monitoring MIB can't be an IETF standard, we are prepared to use the private enterprise OID approach and make the Job Monitoring MIB a PWG standard. We have tried hard to meet the charset policy and all other IETF policies in developing the Job Monitoring MIB. We've had David Perkins review our MIB as well. So we are not trying to get around any IETF requirements by using the private enterprise OID approach. So I'm writing to you to make you aware of what the PWG is about to do to make sure that we aren't doing something that you are unaware or that is unwise. Does what we are about to do make sense to you? Or should the Job Monitoring MIB be standardized by the PWG and assigned a private enterprise OID? Or should the Job Monitoring MIB (with the Printer MIB) project be moved back to the Network Management Area in order to be entered on the IETF standards track? Thanks, Tom Hastings, Editor of the Job Monitoring MIB Current Internet-Draft: >Return-Path: >Date: Fri, 17 Oct 1997 10:26:15 PDT >From: Jay Martin >Organization: Underscore, Inc. >To: Mailing List PWG >Cc: Mailing List PWG Admin >Subject: PWG> IANA has assigned the PWG its own private enterprise number >Sender: owner-pwg@pwg.org > >IANA has responded to our request for a private enterprise number >for the Printer Working Group. > >The PWG's private enterprise number is: 2699 > >Therefore, the PWG may now assign MIB OIDs under the SNMP SMI >OID tree: 1.3.6.1.4.2699 > >Since registration of these numbers is quite critical, the PWG >must take on the topic of OID registrations at the upcoming meeting >in Boulder, CO, the week of Oct 27. > >Don: can you ensure an adequate time slot is allocated to lay down > the guidelines and procedures for PWG OID assignements? > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >----------------------------------------------------------------------Recei ved: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by uscore.underscore.com (8.8.4/8.7.2) with SMTP id MAA18269 for ; Fri, 17 Oct 1997 12:42:58 -0400 (EDT) >Received: from ode.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29) > id ; Fri, 17 Oct 1997 09:42:49 -0700 >Received: by ode.isi.edu (4.1/4.0.3-6) > id ; Fri, 17 Oct 97 09:42:34 PDT >Date: Fri, 17 Oct 97 09:42:34 PDT >From: elliott@ISI.EDU >Posted-Date: Fri, 17 Oct 97 09:42:34 PDT >Message-Id: <9710171642.AA15401@ode.isi.edu> >To: jkm@underscore.com >Subject: PEN 2699 Re: application for enterprise number >Cc: iana-mib@ISI.EDU >Content-Type: text > > >Jeffrey, > >We have assigned Private Enterprise Number 2699 to Printer Working >Group, with you as the point of contact. Please confirm the information >listed below. > >2699 Printer Working Group Jeffrey Schnitzer admin@pwg.org > >Sincerely, > >Josh Elliott - USC/ISI >Internet Assigned Numbers Authority - MIB > >Voice: (310) 822-1511 x302 >Fax: (310) 823-6714 >EMAIL: IANA-MIB@ISI.EDU > > From harryl at us.ibm.com Wed Oct 22 21:14:20 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> October PING list Message-ID: <3.0.1.32.19971022173143.0109b100@garfield> Here's what I've got for a PING list. Please send any corrections ASAP.= My estimates were based on the larger attendance we had in the past. Sp= reading fixed costs (like the room, AV etc) across a smaller group, the meeting= cost has ended up at $42 per day. The hotel is not collecting fees, I am hav= ing to do this, myself. Please be prepared, with a company or personal check m= ade out to Harry Lewis for $42 for each day that you attend. I will provide a r= eceipt. P1394 (Monday/Tuesday) ----- Brian Batchelder - HP Alan Berkema - HP Dan Bye - SGS-Thomson (Monday) Dave Doman - Motorola Lee Farrell - Canon Osamu Hirata - Canon Greg LeClair - Epson Kerry Lee Harry Lewis - IBM Fumio Nagasaka - Epson Akihiro Shimura - Canon Greg Shue - HP Jerry Thrasher - Lexmark Atsushi Uchino - Seiko-Epson IPP (Wednesday/Thursday) --- Lee Farrell - Canon Steve Gebert - IBM Tom Hastings - Xerox Scott Isaacson - Novell David Kellerman - Northlake Software Carl Kugler - IBM Kerry Lee Harry Lewis - IBM Carl-Uno Manros - Xerox Jay Martin - Underscore Bob Pentecost - HP Jerry Podojil - Genicom (Thursday) Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson (Thursday) Yuji Sasaki - Japan Computer Industry Atsushi Uchino - Seiko-Epson Dale Wick - TrueSpectra Lloyd Young - Lexmark Peter Zehler - Xerox JMP/FIN (Friday) ------- Carlos Cantu - IBM Dennis Carney - IBM Lee Farrell - Canon Tom Hastings - Xerox David Kellerman - Northlake Software Harry Lewis - IBM Jay Martin - Underscore Kathy Melton - IBM Lisa Morgan - IBM Bob Pentecost - HP Jerry Podojil - Genicom Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson Lloyd Young - Lexmark Harry Lewis = From rbergma at dpc.com Thu Oct 23 11:47:37 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Mapping Document Message-ID: <3.0.1.32.19971022173143.0109b100@garfield> SSBoYXZlIGxvYWRlZCB0aGUgZm9sbG93aW5nIGZpbGVzIGZvciB0aGUgSm9i IE1JQiBNYXBwaW5nIHNwZWNpZmljYXRpb246DQoNCglmdHA6Ly9mdHAucHdn Lm9yZy9wdWIvcHdnL2ptcC9zcGVjcy9KTVBNQVAwMC5UWFQgKC5ET0MpDQoN Ckkgd291bGQgbGlrZSB0byByZXZpZXcgdGhpcyBkb2N1bWVudCBhdCB0aGUg Sk1QIG1lZXRpbmcgbmV4dCB3ZWVrLiAgVGhlDQptYWluIHN1YmplY3Qgd2ls bCBiZSB0aGUgbWFwcGluZyB0byBqbUpvYlN1Ym1pc3Npb25JZC4gIFdlIG5l ZWQgdG8gdmVyaWZ5DQp0aGF0IGFsbCB0aGUgbmVjZXNzYXJ5IGZvcm1hdHMg Zm9yIGptSm9iU3VibWlzc2lvbklkIGFyZSBhdmFpbGFibGUgaW4gdGhlDQpN SUIuDQoNCkF0dGFjaGVkIGlzIHRoZSB0ZXh0IHZlcnNpb24uDQoNCglSb24g QmVyZ21hbg0KDQoNCg0KDQoNCg0KDQogIElOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbiBC ZXJnbWFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIERhdGFwcm9kdWN0cyBDb3JwLg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9jdG9iZXIgMTUsIDE5OTcNCg0KDQogICAgICAgICAgICAgICBK b2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5nIFJlY29tbWVuZGF0aW9u cw0KICAgICAgICAgICAgICAgICAgICAgICAgIGZvciB0aGUgSm9iIE1vbml0 b3JpbmcgTUlCDQoNCiAgICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLXBy aW50bWliLWpvYi1wcm90b21hcC0wMC50eHQ+DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBcHIgMTUsIDE5OTcNCg0KDQoNCiAg U3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICAgICAgVGhpcyBkb2N1bWVudCBp cyBhbiBJbnRlcm5ldC1EcmFmdC4gIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZw0KICAgICAgIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywNCiAgICAgICBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICAgICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQogICAgICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXgNCiAgICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyDQogICAgICAgZG9jdW1lbnRz IGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzDQogICAgICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogICAgICAg cHJvZ3Jlc3MiLg0KDQogICAgICAgVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3Rh dHVzIG9mIGFueSBJbnRlcm5ldC1EcmFmdCwgcGxlYXNlIGNoZWNrIHRoZQ0K ICAgICAgICIxaWQtYWJzdHJhY3RzLnR4dCIgbGlzdGluZyBjb250YWluZWQg aW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgICAgICBEaXJlY3Rv cmllcyBvbiBmdHAuaXMuY28uemEgKEFmcmljYSksIG5pYy5ub3JkdS5uZXQg KEV1cm9wZSksDQogICAgICAgbXVubmFyaS5vei5hdSAoUGFjaWZpYyBSaW0p LCBkcy5pbnRlcm5pYy5uZXQgKFVTIEVhc3QgQ29hc3QpLCBvcg0KICAgICAg IGZ0cC5pc2kuZWR1IChVUyBXZXN0IENvYXN0KS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFic3RyYWN0DQoNCiAgICAgICBUaGlz IEludGVybmV0LURyYWZ0IGRlZmluZXMgdGhlIHJlY29tbWVuZGVkIG1hcHBp bmcgZm9yIG1hbnkNCiAgICAgICBjdXJyZW50bHkgcG9wdWxhciBKb2Igc3Vi bWlzc2lvbiBwcm90b2NvbHMgdG8gb2JqZWN0cyBhbmQNCiAgICAgICBhdHRy aWJ1dGVzIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KICBCZXJnbWFuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMV0NDA0KDQoNCiAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGlu ZyBSZWNvbW1lbmRhdGlvbnMgICAgICAgICAgICAgT2N0IDEwLCAxOTk3DQoN Cg0KDQogIFRBQkxFIE9GIENPTlRFTlRTDQoNCiAgMS4wICBJTlRST0RVQ1RJ T04gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4yDQogIDIuMCAgTElORSBQUklOVEVSIERBRU1PTiAoTFBS L0xQRCkgUFJPVE9DT0wgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0K ICAyLjEgIGptSm9iU3VibWlzc2lvbklkIE1hcHBlZCB0byBMUFIvTFBEIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgMi4yICBqbUpvYklu ZGV4IE1hcHBlZCB0byBMUFIvTFBEIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi40DQogIDIuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFw cGVkIHRvIExQUi9MUEQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NA0KICAyLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIExQRCAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgMy4wICBBUFBM RVRBTEsgUFJPVE9DT0wgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi41DQogIDMuMSAgam1Kb2JTdWJtaXNzaW9uSWQg TWFwcGVkIHRvIEFwcGxlVGFsayAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNQ0KICAzLjIgIE90aGVyIEFwcGxlVGFsayBNYXBwaW5ncyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgNC4wICBJ TlRFUk5FVCBQUklOVElORyBQUk9UT0NPTCAoSVBQKSAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi41DQogIDQuMSAgam1Kb2JTdWJtaXNzaW9u SWQgTWFwcGVkIHRvIElQUCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNg0KICA0LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIElQUCAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgNC4z ICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gSVBQIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQogIDQuNCAgVGhlIEF0dHJpYnV0 ZSBHcm91cCBNYXBwZWQgdG8gSVBQIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNw0KICA1LjAgIElOVEVMTElHRU5UIFBSSU5URVIgREFUQSBT VFJFQU0gKElQRFMpIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcNCiAg Ni4wICBET0NVTUVOVCBQUklOVElORyBBUFBMSUNBVElPTiAoRFBBKSAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogIDcuMCAgTk9WRUxMIERJ U1RSSUJVVEVEIFBSSU5UIFNFUlZJQ0UgKE5EUFMpIC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uOA0KICA3LjEgIGptSm9iU3VibWlzc2lvbklkIE1hcHBl ZCB0byBORFBTIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgN CiAgNy4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBORFBTIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogIDcuMyAgT3RoZXIg TUlCIE9iamVjdHMgTWFwcGVkIHRvIE5EUFMgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uOA0KICA3LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAg TWFwcGVkIHRvIE5EUFMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjgNCiAgOC4wICBQUklOVEVSIEpPQiBMQU5HVUFHRSAoUEpMKSAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogIDguMSAgam1K b2JTdWJtaXNzaW9uSWQgTWFwcGVkIHRvIFBKTCAuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOQ0KICA4LjIgIGptSm9iSW5kZXggTWFwcGVk IHRvIFBKTCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjkNCiAgOC4zICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQ SkwgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogIDkuMCAg UE9TVFNDUklQVCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAxMC4wICBORVRXQVJFIFBTRVJW RVIgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTANCiAgMTAuMSAgam1Kb2JTdWJtaXNzaW9uSWQgTWFwcGVkIHRv IFBTZXJ2ZXIgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogIDEw LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFBTZXJ2ZXIgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAxMC4zICBUaGUgQXR0cmli dXRlIEdyb3VwIE1hcHBlZCB0byBQU2VydmVyIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTANCiAgMTEuMCAgTkVUV0FSRSBOUFJJTlRFUiBvciBSUFJJ TlRFUiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQog IDEyLjAgIFNFUlZFUiBNRVNTQUdFIEJMT0NLIChTTUIpIFBST1RPQ09MIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICAxMy4wICBUUkFOU1BP UlQgSU5ERVBFTkRFTlQgUFJJTlRFUi9TWVNURU0gSU5URVJGQUNFIChUSVAv U0kpIC4uLi4uLi4uMTENCiAgMTQuMCAgUkVGRVJFTkNFUyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEx DQoNCg0KICAxLjAgIElOVFJPRFVDVElPTg0KDQogIFRoZSBKb2IgTW9uaXRv cmluZyBNSUIgW0pvYk1JQl0gaXMgZnVuY3Rpb25hbCB3aXRoIGFueSBqb2Ig c3VibWlzc2lvbg0KICBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBpbmZvcm1h dGlvbiBhdmFpbGFibGUgYW5kIHRoZSBtZXRob2Qgb2YNCiAgcHJlc2VudGF0 aW9uIHZhcmllcyBzaWduaWZpY2FudGx5IGJ5IGpvYiBzdWJtaXNzaW9uIHBy b3RvY29sLiAgQSBjb21tb24NCiAgbWV0aG9kIG9mIG1hcHBpbmcgam9iIHN1 Ym1pc3Npb24gaW5mb3JtYXRpb24gdG8gdGhlIEpvYiBNb25pdG9yaW5nIE1J Qg0KICBpcyBlc3NlbnRpYWwgZm9yIGludGVyb3BlcmFiaWxpdHkgb2YgSm9i IE1JQiBhZ2VudHMgYW5kIG1vbml0b3JpbmcNCiAgYXBwbGljYXRpb25zLiAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIHJlY29tbWVuZGVkIG1hcHBpbmdzIGZv ciBtb3N0DQogIHBvcHVsYXIgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2xzIHRv IGluc3VyZSB0aGlzIGNvbXBhdGliaWxpdHkuDQoNCiAgQWxsIG1hcHBpbmdz IGFyZSB1bmlkaXJlY3Rpb25hbCBmcm9tIHRoZSBqb2Igc3VibWlzc2lvbiBw cm90b2NvbCB0byB0aGUNCiAgTUlCLiAgSXQgaXMgYXNzdW1lZCB0aGF0IHN1 cHBvcnQgb2YgdGhlIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIGluIHRoZQ0K ICBwcmludGVyIGltcGxpZXMgdGhhdCB0aGUgcmV2ZXJzZSBpbmZvcm1hdGlv biBmbG93IGlzIHByZXNlbnRseSBkZWZpbmVkDQogIGFuZCBkb2VzIG5vdCBy ZXF1aXJlIGludGVyYWN0aW9uIGZyb20gdGhlIE1JQi4gIFRoaXMgbWFwcGlu ZyBpcyBub3QNCiAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFzIGl0IHNo b3VsZCBiZSBvYnZpb3VzLg0KDQoNCiAgQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMl0NDA0KDQoNCiAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGlu ZyBSZWNvbW1lbmRhdGlvbnMgICAgICAgICAgICAgT2N0IDEwLCAxOTk3DQoN Cg0KDQoNCiAgVGhpcyBkb2N1bWVudCByZWZlcnMgdG8gc3lzdGVtIGNvbmZp Z3VyYXRpb25zIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlDQogIEpvYiBNb25p dG9yaW5nIE1JQiBbSm9iTUlCXS4gIEZvciB0aG9zZSByZWFkZXJzIHRoYXQg YXJlIGZhbWlsaWFyIHdpdGgNCiAgdGhlIGNvbmZpZ3VyYXRpb24gZGVzY3Jp cHRpb25zLCBhIHNob3J0IHN1bW1hcnkgYXBwZWFycyBoZXJlLiAgUGxlYXNl DQogIHNlZSB0aGUgSm9iIE1JQiBkb2N1bWVudCBmb3IgZnVydGhlciBkZXRh aWxzLg0KDQogICAgIENvbmZpZ3VyYXRpb24gMTogIFRoaXMgaXMgYSBzaW1w bGUgcGVlci10by1wZWVyIHN5c3RlbSB3aGljaCBjb250YWlucw0KICAgICAg ICAgb25seSBhIGNsaWVudCBhbmQgYSBwcmludGVyLiAgVGhlIEpvYiBNSUIg YWdlbnQgaXMgcmVzaWRlbnQgaW4NCiAgICAgICAgIHRoZSBwcmludGVyLg0K DQogICAgIENvbmZpZ3VyYXRpb24gMjogIFRoaXMgc3lzdGVtIGNvbnRhaW5z IGEgY2xpZW50LCBzZXJ2ZXIsIGFuZCBhDQogICAgICAgICBwcmludGVyLiAg VGhlIEppYiBNSUIgYWdlbnQgaXMgcmVzaWRlbnQgaW4gdGhlIHNlcnZlci4N Cg0KICAgICBDb25maWd1cmF0aW9uIDM6ICBUaGlzIHN5c3RlbSwgYXMgaW4g Y29uZmlndXJhdGlvbiAyLCBjb250YWlucyBhDQogICAgICAgICBjbGllbnQs IHNlcnZlciwgYW5kIGEgcHJpbnRlci4gIEluIHRoaXMgY2FzZSB0aGUgSm9i IE1JQiBhZ2VudCBpcw0KICAgICAgICAgaW1wbGVtZW50ZWQgd2l0aGluIHRo ZSBwcmludGVyLg0KDQogIFRoZSBtb3N0IGltcG9ydGFudCBvYmplY3QgdG8g YmUgbWFwcGVkIGlzIGptSm9iU3VibWlzc2lvbklkLCBzaW5jZSB0aGlzDQog IGlzIHRoZSBrZXkgZm9yIHRoZSB1c2VyIHRvIGxvY2F0ZSBhIHN1Ym1pdHRl ZCBqb2IuICBUaGVyZWZvcmUsDQogIGptSm9iU3VibWlzc2lvbklkIGlzIHNw ZWNpZmllZCBmb3IgYWxsIGpvYiBzdWJtaXNzaW9uIHByb3RvY29scyBkZWZp bmVkDQogIGluIHRoaXMgZG9jdW1lbnQuICBUaGUgcmVtYWluaW5nIG9iamVj dHMgbWFwcGVkIGluY2x1ZGUgb25seSB0aG9zZSBpdGVtcw0KICB0aGF0IGhh dmUgdGhlIGVxdWl2YWxlbnQgaW5mb3JtYXRpb24gcHJlc2VudGVkIHRvIHRo ZSBwcmludGVyIGJ5IHRoZSBqb2INCiAgc3VibWlzc2lvbiBwcm90b2NvbC4N Cg0KDQogIDIuMCAgTElORSBQUklOVEVSIERBRU1PTiAoTFBSL0xQRCkgUFJP VE9DT0wNCg0KICBUaGUgTFBSL0xQRCBwcmludGluZyBwcm90b2NvbCBbTFBE XSBpcyB1c2VkIHdpdGggQlNEIFVuaXggc3lzdGVtcyBpbiB0aGUNCiAgY2xp ZW50LXNlcnZlci1wcmludGVyIGNvbmZpZ3VyYXRpb24uICBVc2FnZSBvZiB0 aGUgSm9iIE1vbml0b3JpbmcgTUlCDQogIHdpdGggTFBSL0xQRCB3aWxsIG1v c3QgbGlrZWx5IGNvbmZvcm0gdG8gQ29uZmlndXJhdGlvbiAzLCB3aGVyZSB0 aGUNCiAgbW9uaXRvciBhcHBsaWNhdGlvbiBvciB0aGUgc2VydmVyIHVzZXMg U05NUCB0byBvYnRhaW4gam9iIGluZm9ybWF0aW9uDQogIGZyb20gdGhlIHBy aW50ZXIuICBUaGUgY2xpZW50IGNvbW11bmljYXRlcyB3aXRoIHRoZSBVbml4 IHNlcnZlciB1c2luZw0KICB0aGUgZXhpc3RpbmcgTFBEIHByb3RvY29sIHRv IG9idGFpbiBqb2IgaW5mb3JtYXRpb24uDQoNCiAgVGhlIExQUi9MUEQgcHJv dG9jb2wgaXMgYWxzbyB1c2VkIGluIHRoZSBXaW5kb3dzIGVudmlyb25tZW50 IHRvDQogIGltcGxlbWVudCBwZWVyLXRvLXBlZXIgcHJpbnRpbmcsIGFzIHNo b3duIGluIGNvbmZpZ3VyYXRpb24gMS4gIEluIHRoaXMNCiAgY2FzZSwgU05N UCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgYW5kL29yIHRoZSBtb25pdG9yIGFw cGxpY2F0aW9uIHRvDQogIG9idGFpbiB0aGUgam9iIGluZm9ybWF0aW9uLg0K DQogIE9uZSBvZiB0aGUgbWFqb3IgcHJvYmxlbXMgb2YgTFBSL0xQRCBpcyB0 aGUgbGFyZ2UgbnVtYmVyIG9mIHZlbmRvcg0KICB1bmlxdWUgZXh0ZW5zaW9u cyBjdXJyZW50bHkgdXNlZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQgdGhlIHJl c3VsdGluZw0KICBjb21wYXRpYmlsaXR5IGlzc3VlcyBiZXR3ZWVuIGF2YWls YWJsZSBpbXBsZW1lbnRhdGlvbnMuICBUbyBhdm9pZCB0aGVzZQ0KICBpc3N1 ZXMsIHRoaXMgbWFwcGluZyBvZiBMUFIvTFBEIGlzIHJlc3RyaWN0ZWQgdG8g dGhlIHByb3RvY29sIGFzIGRlZmluZWQNCiAgYnkgUkZDIDExNzkuDQoNCiAg VGhlIExQUi9MUEQgcHJvdG9jb2wgdHJhbnNmZXJzIHByaW50IGpvYiBkYXRh IGFuZCBjb250cm9sIGluZm9ybWF0aW9uIGluDQogIHNlcGFyYXRlIGZpbGVz LCBrbm93biBhcyB0aGUgRGF0YSBGaWxlIGFuZCBDb250cm9sIEZpbGUgcmVz cGVjdGl2ZWx5Lg0KICBNb3N0IG9mIHRoZSBpbmZvcm1hdGlvbiBjb25jZXJu aW5nIHRoZSBwcmludCBqb2IgaXMgY29udGFpbmVkIGluIHRoZQ0KICBDb250 cm9sIEZpbGUuICBJbiBtYW55IExQRCBpbXBsZW1lbnRhdGlvbnMsIHRoZSBD b250cm9sIEZpbGUgaXMNCiAgdHJhbnNmZXJyZWQgZm9sbG93aW5nIHRoZSBE YXRhIEZpbGUuICBUaHVzIG11Y2ggb2YgdGhlIGluZm9ybWF0aW9uDQogIGNv bmNlcm5pbmcgdGhlIGpvYiBtYXkgbm90IGJlIGF2YWlsYWJsZSB1bnRpbCB0 aGUgY29tcGxldGlvbiBvZiB0aGUgZGF0YQ0KICB0cmFuc21pc3Npb24uDQoN Cg0KDQogIEJlcmdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDNdDQwNCg0KDQogIEpv YiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25z ICAgICAgICAgICAgIE9jdCAxMCwgMTk5Nw0KDQoNCg0KDQogIDIuMSAgam1K b2JTdWJtaXNzaW9uSWQgTWFwcGVkIHRvIExQUi9MUEQNCg0KICBUaGUgTFBS L0xQRCBSZWNlaXZlIERhdGEgRmlsZSBjb21tYW5kIGNvbnRhaW5zIGEgcGFy YW1ldGVyIHdoaWNoIGRlZmluZXMNCiAgdGhlIG5hbWUgb2YgdGhlIGRhdGEg ZmlsZS4gIFRoaXMgbmFtZSBmaWVsZCBpcyBzdHJ1Y3R1cmVkIGFzIGZvbGxv d3M6DQoNCiAgICAgICAgICBkZmFYWFg8aG9zdC1uYW1lPiAgb3IgIGRhWFhY WDxob3N0LW5hbWU+DQoNCiAgV2hlcmUgWFhYIG9yIFhYWFggaXMgdGhlIG51 bWVyaWMgam9iIG51bWJlciBhc3NpZ25lZCBieSB0aGUgTFBSL0xQRA0KICBj bGllbnQgc3VibWl0dGluZyB0aGUgcHJpbnQgam9iLiAgVGhlIHJlY29tbWVu ZGVkIG1hcHBpbmcgb2YgdGhpcyBuYW1lDQogIGZpZWxkIHRvIGptSm9iU3Vi bWlzc2lvbklkIGlzOg0KDQogICAgb2N0ZXQgMTogICAnOScNCg0KICAgIG9j dGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIDxob3N0LW5hbWU+IHBvcnRpb24g b2YgdGhlIG5hbWUgZmllbGQuICBJZg0KICAgICAgICAgICAgICAgICAgdGhl IDxob3N0LW5hbWU+IHBvcnRpb24gaXMgbGVzcyB0aGFuIDQwIG9jdGV0cywg dGhlDQogICAgICAgICAgICAgICAgICBsZWZ0LW1vc3QgY2hhcmFjdGVyIGlu IHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFyIGluIG9jdGV0DQogICAgICAgICAg ICAgICAgICBwb3NpdGlvbiAyLiAgT3RoZXJ3aXNlLCBvbmx5IHRoZSBsYXN0 IDM5IGJ5dGVzIHNoYWxsIGJlDQogICAgICAgICAgICAgICAgICBpbmNsdWRl ZC4NCg0KICAgIG9jdGV0cyA0MS00ODogIGAwMDAwMFhYWCcgIG9yICBgMDAw MFhYWFgnLg0KDQoNCiAgMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBMUFIv TFBEDQoNCiAgVGhlIGpvYiBpbmRleCAoam1Kb2JJbmRleCkgaXMgYXNzaWdu ZWQgYnkgdGhlIFNOTVAgam9iIG1vbml0b3JpbmcgYWdlbnQNCiAgYW5kIGlz IGluZGVwZW5kZW50IG9mIHRoZSBYWFggKG9yIFhYWFgpIGluZGV4IGFzc2ln bmVkIGJ5IHRoZSBMUFIvTFBEDQogIGNsaWVudC4gIFRoaXMgd2lsbCBhbGxv dyB0aGUgU05NUCBhZ2VudCB0byB0cmFjayBqb2JzIHJlY2VpdmVkIGZyb20N CiAgbXVsdGlwbGUgc291cmNlcy4NCg0KDQogIDIuMyAgT3RoZXIgTUlCIE9i amVjdHMgTWFwcGVkIHRvIExQUi9MUEQNCg0KICBNSUIgT2JqZWN0ICAgICAg ICAgICAgIHwgTFBSL0xQRCBQYXJhbWV0ZXINCiAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogIGptSm9iS09jdGV0c1JlcXVlc3RlZCAgfCBOdW1i ZXIgb2YgYnl0ZXMgYXMgZGVmaW5lZCBpbiB0aGUgRGF0YSBGaWxlDQogIGpt Sm9iT3duZXIgICAgICAgICAgICAgfCBVc2VyIElkZW50aWZpY2F0aW9uIHN0 cmluZyBpbiB0aGUgQ29udHJvbCBGaWxlDQoNCg0KICAyLjQgIFRoZSBBdHRy aWJ1dGUgR3JvdXAgTWFwcGVkIHRvIExQRA0KDQogIE90aGVyIGF0dHJpYnV0 ZXMgdGhhdCBhcmUgYXBwbGljYWJsZSwgYnV0IG5vdCBkZWZpbmVkIGluIHRo aXMgc2VjdGlvbg0KICBzdWNoIGFzIGF0dHJpYnV0ZXMgdGhhdCBtYXAgdG8g YSB2ZW5kb3IgdW5pcXVlIGV4dGVuc2lvbiwgbWF5IGFsc28gYmUNCiAgaW5j bHVkZWQuDQoNCiAgTUlCIGF0dHJpYnV0ZSAgICAgICAgIHwgTFBSL0xQRCBp bmZvcm1hdGlvbiAgICAgICAgICAgICB8IERhdGEgdHlwZQ0KICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLQ0KICBzZXJ2ZXJBc3NpZ25lZEpvYk5hbWUg fCBOYW1lIG9mIHRoZSBkYXRhIGZpbGUgKG5vdGUgMSkgIHwgT2N0ZXQgU3Ry aW5nDQogIGpvYlNvdXJjZUNoYW5uZWxJbmRleCB8IHBydENoYW5uZWxJbmRl eCAobm90ZSAyKSAgICAgICAgfCBJbnRlZ2VyDQogIHF1ZXVlTmFtZVJlcXVl c3RlZCAgICB8IFF1ZXVlIG5hbWUgZnJvbSB0aGUgRGF0YSBGaWxlICAgfCBP Y3RldCBTdHJpbmcNCiAgZmlsZU5hbWUgICAgICAgICAgICAgIHwgTmFtZSBv ZiB0aGUgc291cmNlIGZpbGUgKG5vdGUgMyl8IE9jdGV0IFN0cmluZw0KICBk b2N1bWVudE5hbWUgICAgICAgICAgfCBUaGUgZG9jdW1lbnQgdGl0bGUgbmFt ZSAobm90ZSAzKXwgT2N0ZXQgU3RyaW5nDQoNCg0KDQogIEJlcmdtYW4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtwYWdlIDRdDQwNCg0KDQogIEpvYiBTdWJtaXNzaW9uIFByb3Rv Y29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zICAgICAgICAgICAgIE9jdCAx MCwgMTk5Nw0KDQoNCg0KICAgTm90ZXM6DQogICAtLS0tLS0NCiAgICAxLiBT ZWUgc2VjdGlvbiAyLjEgKGptSm9iU3VibWlzc2lvbklkKS4NCiAgICAyLiBJ bmNsdWRlZCBpZiB0aGUgUHJpbnRlciBNSUIgaXMgYWxzbyBzdXBwb3J0ZWQg YnkgdGhlIGFnZW50Lg0KICAgIDMuIFRoZSBpbmZvcm1hdGlvbiBpcyBvcHRp b25hbCBpbiB0aGUgQ29udHJvbCBGaWxlLiAgVGhlIGF0dHJpYnV0ZQ0KICAg ICAgIHNob3VsZCBiZSBpbmNsdWRlZCBpZiBwcmVzZW50IGluIHRoZSBDb250 cm9sIEZpbGUuDQoNCg0KICAzLjAgIEFQUExFVEFMSyBQUk9UT0NPTA0KDQog IEFwcGxlVGFsayB3YXMgb3JpZ2luYWxseSBkZXZlbG9wZWQgYXMgYSBwZWVy LXRvLXBlZXIgbmV0d29yayBwcm90b2NvbCwNCiAgYXMgZGVzY3JpYmVkIGlu IGNvbmZpZ3VyYXRpb24gMSwgZm9yIHVzZSB3aXRoIEFwcGxlIE1hY2ludG9z aCBjb21wdXRlcnMuDQogIFRvZGF5LCBwcmludCBzcG9vbGVycyBhcmUgYWxz byBhdmFpbGFibGUgZm9yIHVzZSB3aXRoIE1hY2ludG9zaCBjb21wdXRlcg0K ICBuZXR3b3JrcyB0aGF0IGNvbmZvcm0gdG8gY29uZmlndXJhdGlvbnMgMi8z LiAgSW4gYWRkaXRpb24sIHByaW50aW5nIHdpdGgNCiAgdGhlIEFwcGxlVGFs ayBwcm90b2NvbCBpcyBzdXBwb3J0ZWQgZnJvbSBib3RoIFdpbmRvd3MgTlQg c2VydmVycyBhbmQNCiAgTm92ZWxsIHNlcnZlcnMgYWxzbyBwZXIgY29uZmln dXJhdGlvbnMgMi8zLg0KDQogIFRoZSBBcHBsZVRhbGsgcHJvdG9jb2wgcHJv dmlkZXMgdmVyeSBsaXR0bGUgaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgdXNl ZA0KICB3aXRoIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIuICBUaGUgTWFjaW50 b3NoIHByaW50IGRyaXZlcnMgYXJlIGFibGUgdG8NCiAgcHJvdmlkZSBpbmZv cm1hdGlvbiBjb25jZXJuaW5nIHRoZSB1c2VyIGFuZCBkb2N1bWVudCBuYW1l IGJ1dCBpbWJlZCB0aGlzDQogIGluZm9ybWF0aW9uIGluIHRoZSBQREwsIHdo aWNoIGlzIHR5cGljYWxseSBQb3N0U2NyaXB0LiAgVGhlIHByZWZlcnJlZA0K ICBqbUpvYlN1Ym1pc3Npb25JZCBpcyBjb25zdHJ1Y3RlZCBmcm9tIHRoZSBp bmZvcm1hdGlvbiBpbiB0aGUgUG9zdFNjcmlwdA0KICBmaWxlLCBhcyBkZWZp bmVkIGluIHNlY3Rpb24gOS4wLg0KDQoNCiAgMy4xICBqbUpvYlN1Ym1pc3Np b25JZCBNYXBwZWQgdG8gQXBwbGVUYWxrDQoNCiAgQW4gYWx0ZXJuYXRpdmUg am1Kb2JTdWJtaXNzaW9uSWQgbWF5IGJlIGNvbnN0cnVjdGVkIGZyb20gdGhl IENvbm5lY3Rpb24NCiAgSWRlbnRpZmllciBjb250YWluZWQgaW4gdGhlIEFw cGxlVGFsayBQcmludGVyIEFjY2VzcyBQcm90b2NvbCAoUEFQKQ0KICBoZWFk ZXIuICBTaW5jZSB0aGUgQ29ubmVjdGlvbiBJZCBpcyBub3QgcmVhZGlseSBh dmFpbGFibGUgaW4gYW55IG9mIHRoZQ0KICBkZWZpbmVkIEFwcGxlVGFsayBp bXBsZW1lbnRhdGlvbnMsIHRoaXMgYXBwcm9hY2ggbWF5IGJlIG9mIGxpdHRs ZQ0KICB1dGlsaXR5Lg0KDQogICAgb2N0ZXQgMTogICAnPycgICAqKioqKiBO RVcgVFlQRSBDT0RFID8/Pz8gKioqKioNCg0KICAgIG9jdGV0cyAyLTQwOiAg Q29udGFpbnMgdGhlIEFwcGxlVGFsayBwcmludGVyIG5hbWUsIHdpdGggdGhl IGZpcnN0DQogICAgICAgICAgICAgICAgICBjaGFyYWN0ZXIgb2YgdGhlIG5h bWUgaW4gb2N0ZXQgMi4gIChBcHBsZVRhbGsgcHJpbnRlcg0KICAgICAgICAg ICAgICAgICAgbmFtZXMgYXJlIGEgbWF4aW11bSBvZiAzMSBjaGFyYWN0ZXJz LikNCg0KICAgIG9jdGV0cyA0MS00ODogIGAwMDAwMFhYWCcsIHdoZXJlIGBY WFgnIGlzIHRoZSBkZWNpbWFsIHJlcHJlc2VudGF0aW9uDQogICAgICAgICAg ICAgICAgICAgb2YgdGhlIENvbm5lY3Rpb24gSWQuDQoNCg0KICAzLjIgIE90 aGVyIEFwcGxlVGFsayBNYXBwaW5ncw0KDQogIE5vIG90aGVyIEpvYiBNSUIg b2JqZWN0cyBvciBwYXJhbWV0ZXJzIGNhbiBiZSBkZXJpdmVkIGZyb20gaW5m b3JtYXRpb24NCiAgYXZhaWxhYmxlIGluIHRoZSBBcHBsZVRhbGsgaGVhZGVy cw0KDQoNCiAgNC4wICBJTlRFUk5FVCBQUklOVElORyBQUk9UT0NPTCAoSVBQ KQ0KDQogIFRoZSBJbnRlcm5ldCBQcmludGluZyBQcm90b2NvbCBbSVBQXSBz dXBwb3J0cyBwcmludGluZyB1c2luZyBhbnkgb25lIG9mDQogIHRoZSB0aHJl ZSBwb3NzaWJsZSBjb25maWd1cmF0aW9ucy4gIEZvciBjb25maWd1cmF0aW9u IDIsIHRoZSBtYXBwaW5nDQoNCg0KICBCZXJnbWFuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbcGFn ZSA1XQ0MDQoNCg0KICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5n IFJlY29tbWVuZGF0aW9ucyAgICAgICAgICAgICBPY3QgMTAsIDE5OTcNCg0K DQoNCiAgZGVmaW5lZCBoZXJlaW4gaXMgcGVyZm9ybWVkIG9uIGEgc2VydmVy LiAgT3RoZXJ3aXNlLCB0aGUgbWFwcGluZyBpcw0KICBwZXJmb3JtZWQgb24g YW4gYWdlbnQgd2l0aGluIHRoZSBwcmludGVyLg0KDQogIDQuMSAgam1Kb2JT dWJtaXNzaW9uSWQgTWFwcGVkIHRvIElQUA0KDQogIElQUCBjb250YWlucyBh IHJpY2ggc2V0IG9mIHBhcmFtZXRlcnMgd2hpY2ggYWxsb3cgc2V2ZXJhbCBt ZXRob2RzIG9mDQogIGNyZWF0aW5nIHRoZSBqbUpvYlN1Ym1pc3Npb25JZCBv YmplY3QuICBUaGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0byB1c2UNCiAgdGhl IElQUCBqb2ItdXJpIGF0dHJpYnV0ZSBhcyBmb2xsb3dzOg0KDQogICAgb2N0 ZXQgMTogICAnNCcNCg0KICAgIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhl IElQUCBqb2ItdXJpIGpvYiB0ZW1wbGF0ZSBhdHRyaWJ1dGUuICBJZg0KICAg ICAgICAgICAgICAgICAgdGhlIGpvYi11cmkgaXMgbGVzcyB0aGFuIDQwIG9j dGV0cywgdGhlIGxlZnQtbW9zdA0KICAgICAgICAgICAgICAgICAgY2hhcmFj dGVyIGluIHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFyIGluIG9jdGV0IHBvc2l0 aW9uDQogICAgICAgICAgICAgICAgICAyLiAgT3RoZXJ3aXNlLCBvbmx5IHRo ZSBsYXN0IDM5IGJ5dGVzIHNoYWxsIGJlIGluY2x1ZGVkLg0KDQogICAgb2N0 ZXRzIDQxLTQ4OiAgQ29udGFpbnMgdGhlIGpvYi1pZCBqb2IgdGVtcGxhdGUg YXR0cmlidXRlLg0KDQogIElmIHRoZSBqb2ItdXJpIGlzIG5vdCBhdmFpbGFi bGUgdG8gdGhlIGFnZW50LCB0aGUgam9iLW5hbWUgam9iIHRlbXBsYXRlDQog IGF0dHJpYnV0ZSBzaGFsbCBiZSB1c2VkLg0KDQogICAgb2N0ZXQgMTogICAn PycgICoqKioqIE5ldyBmb3JtYXQgcmVxdWlyZWQgPyAoMSBmb3IgY2xpZW50 cykgKioqKioNCg0KICAgIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIElQ UCBqb2ItbmFtZSBqb2IgdGVtcGxhdGUgYXR0cmlidXRlLiAgSWYNCiAgICAg ICAgICAgICAgICAgIHRoZSBqb2ItbmFtZSBpcyBsZXNzIHRoYW4gNDAgb2N0 ZXRzLCB0aGUgbGVmdC1tb3N0DQogICAgICAgICAgICAgICAgICBjaGFyYWN0 ZXIgaW4gdGhlIHN0cmluZyBzaGFsbCBhcHBlYXIgaW4gb2N0ZXQgcG9zaXRp b24NCiAgICAgICAgICAgICAgICAgIDIuICBPdGhlcndpc2UsIG9ubHkgdGhl IGxhc3QgMzkgYnl0ZXMgc2hhbGwgYmUgaW5jbHVkZWQuDQoNCiAgICBvY3Rl dHMgNDEtNDg6ICBDb250YWlucyB0aGUgam9iLWlkIGpvYiB0ZW1wbGF0ZSBh dHRyaWJ1dGUuDQoNCiAgSWYgYm90aCB0aGUgam9iLXVyaSBhbmQgdGhlIGpv Yi1uYW1lIGFyZSBub3QgYXZhaWxhYmxlLCB0aGUgam9iLQ0KICBvcmlnaW5h dGluZy11c2VyIGpvYiB0ZW1wbGF0ZSBhdHRyaWJ1dGUgc2hhbGwgYmUgdXNl ZC4NCg0KICAgIG9jdGV0IDE6ICAgJzQnDQoNCiAgICBvY3RldHMgMi00MDog IENvbnRhaW5zIHRoZSBJUFAgam9iLW9yaWdpbmF0aW5nLXVzZXIgam9iIHRl bXBsYXRlDQogICAgICAgICAgICAgICAgICBhdHRyaWJ1dGUuICBJZiB0aGUg am9iLW9yaWdpbmF0aW5nLXVzZXIgbmFtZSBpcyBsZXNzDQogICAgICAgICAg ICAgICAgICB0aGFuIDQwIG9jdGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0 ZXIgaW4gdGhlIHN0cmluZw0KICAgICAgICAgICAgICAgICAgc2hhbGwgYXBw ZWFyIGluIG9jdGV0IHBvc2l0aW9uIDIuICBPdGhlcndpc2UsIG9ubHkgdGhl DQogICAgICAgICAgICAgICAgICBsYXN0IDM5IGJ5dGVzIHNoYWxsIGJlIGlu Y2x1ZGVkLg0KDQogICAgb2N0ZXRzIDQxLTQ4OiAgQ29udGFpbnMgdGhlIGpv Yi1pZCBqb2IgdGVtcGxhdGUgYXR0cmlidXRlLg0KDQoNCiAgNC4yICBqbUpv YkluZGV4IE1hcHBlZCB0byBJUFANCg0KICBUaGUgam9iIGluZGV4IChqbUpv YkluZGV4KSBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2IgbW9uaXRvcmluZyBh Z2VudCBtYXkNCiAgYmUgaWRlbnRpY2FsIHRvIHRoZSBJUFAgam9iLWlkIGpv YiB0ZW1wbGF0ZSBhdHRyaWJ1dGUgaWYgdGhlIGFnZW50IGlzDQogIHJlY2Vp dmluZyBqb2JzIG9ubHkgZnJvbSBhIHNpbmdsZSBzZXJ2ZXIgb3IgY2xpZW50 LiAgSWYgam9icyBhcmUgdG8gYmUNCiAgcmVjZWl2ZWQgZnJvbSBtdWx0aXBs ZSBzb3VyY2VzLCBqbUpvYkluZGV4IGFuZCBqb2ItaWQgbXVzdCBiZQ0KICBp bmRlcGVuZGVudC4NCg0KDQoNCg0KICBCZXJnbWFuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbcGFn ZSA2XQ0MDQoNCg0KICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5n IFJlY29tbWVuZGF0aW9ucyAgICAgICAgICAgICBPY3QgMTAsIDE5OTcNCg0K DQoNCiAgNC4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gSVBQDQoN CiAgTUlCIE9iamVjdCAgICAgICAgICAgICAgICB8IElQUCBKb2IgdGVtcGxh dGUgYXR0cmlidXRlDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICBqbUpvYk93bmVyICAgICAgICAgICAgICAgIHwgam9iLW9yaWdpbmF0aW5n LXVzZXINCiAgam1Kb2JLT2N0ZXRzUmVxdWVzdGVkICAgICB8IGpvYi1rLW9j dGV0cw0KICBqbUpvYktPY3RldHNQcm9jZXNzZWQgICAgIHwgam9iLWstb2N0 ZXRzLXByb2Nlc3NlZA0KICBqbUpvYkltcHJlc3Npb25zUmVxdWVzdGVkIHwg am9iLWltcHJlc3Npb25zDQogIGptSm9iSW1wcmVzc2lvbnNQcm9jZXNzZWQg fCBqb2ItaW1wcmVzc2lvbnMtY29tcGxldGVkDQogIGptSm9iU3RhdGVSZWFz b25zMSAgICAgICAgfCBqb2Itc3RhdGUtcmVhc29ucyAobm90ZSAxKQ0KICBq bU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzIHwgbnVtYmVyLW9mLWludGVydmVu aW5nLWpvYnMNCg0KICAgTm90ZXM6DQogICAtLS0tLS0NCiAgICAxLiBKb2JT dGF0ZVJlYXNvbnMgaXMgYSBiaXQgbWFwIGRlc2NyaWJlZCBpbiBvbmUgb2Jq ZWN0IGFuZCB0aHJlZQ0KICAgICAgIGF0dHJpYnV0ZXMuICBUaGUgSVBQIGNv bmRpdGlvbiBtYXkgY2hhbmdlIG9uZSBvciBtb3JlIG9mIHRoZSBiaXRzDQog ICAgICAgaW4gb25lIG9yIG1vcmUgb2YgdGhlc2UgSm9iIE1JQiBpdGVtcy4N Cg0KDQogIDQuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gSVBQ DQoNCiAgVGhlIGZvbGxvd2luZyBtYXBwaW5ncyBhcmUgcmVxdWlyZWQgaWYg dGhlIGxpc3RlZCBJUFAgam9iIHRlbXBsYXRlDQogIGF0dHJpYnV0ZSBpcyBw cm92aWRlZC4NCg0KICBNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IElQ UCBqb2IgdGVtcGxhdGUgYXR0cmlidXRlICAgfCBEYXRhIHR5cGUNCiAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tDQogIGpvYk5hbWUgICAgICAgICAg ICAgICAgICAgIHwgam9iLW5hbWUgICAgICAgICAgICAgICAgICAgICB8IE9j dGV0IFN0cmluZw0KICBkb2N1bWVudEZvcm1hdCAgICAgICAgICAgICB8IGRv Y3VtZW50LWZvcm1hdCAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCiAg am9iUHJpb3JpdHkgICAgICAgICAgICAgICAgfCBqb2ItcHJpb3JpdHkgICAg ICAgICAgICAgICAgIHwgSW50ZWdlcg0KICBqb2JIb2xkVW50aWwgICAgICAg ICAgICAgICB8IGpvYi1ob2xkLXVudGlsICAgICAgICAgICAgICAgfCBPY3Rl dCBTdHJpbmcNCiAgc2lkZXMgICAgICAgICAgICAgICAgICAgICAgfCBzaWRl cyAgICAgICAgICAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KICBmaW5pc2hp bmcgICAgICAgICAgICAgICAgICB8IGZpbmlzaGluZ3MgICAgICAgICAgICAg ICAgICAgfCBJbnRlZ2VyDQogIHByaW50UXVhbGl0eVJlcXVlc3RlZCAgICAg IHwgcHJpbnQtcXVhbGl0eSAgICAgICAgICAgICAgICB8IEludGVnZXINCiAg cHJpbnRlclJlc29sdXRpb25SZXF1ZXN0ZWQgfCBwcmludGVyLXJlc29sdXRp b24gICAgICAgICAgIHwgSW50ZWdlcg0KICBqb2JDb3BpZXNSZXF1ZXN0ZWQg ICAgICAgICB8IGNvcGllcyAgICAgICAgICAgICAgICAgICAgICAgfCBJbnRl Z2VyDQogIG1lZGl1bVJlcXVlc3RlZCAgICAgICAgICAgIHwgbWVkaWEgICAg ICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBqb2JTdWJt aXNzaW9uVGltZSAgICAgICAgICB8IHRpbWUtYXQtcGVuZGluZyAgICAgICAg ICAgICAgfCBJbnRlZ2VyDQogIGpvYlN0YXJ0ZWRQcm9jZXNzaW5nVGltZSAg IHwgdGltZS1hdC1wcm9jZXNzaW5nICAgICAgICAgICB8IEludGVnZXINCiAg am9iQ29tcGxldGlvblRpbWUgICAgICAgICAgfCB0aW1lLWF0LWNvbXBsZXRl ZCAgICAgICAgICAgIHwgSW50ZWdlcg0KICBzaGVldHNSZXF1ZXN0ZWQgICAg ICAgICAgICB8IGpvYi1tZWRpYS1zaGVldHMgICAgICAgICAgICAgfCBJbnRl Z2VyDQogIGpvYlVSSSAgICAgICAgICAgICAgICAgICAgIHwgam9iLXVyaSAg ICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBqb2JTdGF0 ZVJlYXNvbnNOICAgICAgICAgICB8IGpvYi1zdGF0ZS1yZWFzb25zIChub3Rl IDEpICAgfCBJbnRlZ2VyDQogIHBoeXNpY2FsRGV2aWNlICAgICAgICAgICAg IHwgb3V0cHV0LWRldmljZS1hc3NpZ25lZCAgICAgICB8IE9jdGV0IFN0cmlu Zw0KICBzaGVldHNDb21wbGV0ZWQgICAgICAgICAgICB8IGpvYi1tZWRpYS1z aGVldHMtY29tcGxldGVkICAgfCBJbnRlZ2VyDQoNCiAgIE5vdGVzOg0KICAg LS0tLS0tDQogICAgMS4gSm9iU3RhdGVSZWFzb25zIGlzIGEgYml0IG1hcCBk ZXNjcmliZWQgaW4gb25lIG9iamVjdCBhbmQgdGhyZWUNCiAgICAgICBhdHRy aWJ1dGVzLiAgVGhlIElQUCBjb25kaXRpb24gbWF5IGNoYW5nZSBvbmUgb3Ig bW9yZSBvZiB0aGUgYml0cw0KICAgICAgIGluIG9uZSBvciBtb3JlIG9mIHRo ZXNlIEpvYiBNSUIgaXRlbXMuDQoNCg0KICA1LjAgIElOVEVMTElHRU5UIFBS SU5URVIgREFUQSBTVFJFQU0gKElQRFMpDQoNCg0KICBCZXJnbWFuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbcGFnZSA3XQ0MDQoNCg0KICBKb2IgU3VibWlzc2lvbiBQcm90b2Nv bCBNYXBwaW5nIFJlY29tbWVuZGF0aW9ucyAgICAgICAgICAgICBPY3QgMTAs IDE5OTcNCg0KDQoNCg0KDQogIDYuMCAgRE9DVU1FTlQgUFJJTlRJTkcgQVBQ TElDQVRJT04gKERQQSkNCg0KDQogIDcuMCAgTk9WRUxMIERJU1RSSUJVVEVE IFBSSU5UIFNFUlZJQ0UgKE5EUFMpDQoNCiAgTm92ZWxsIERpc3RyaWJ1dGVk IFByaW50IFNlcnZpY2VzIGlzIGEgRFBBIGJhc2VkIGpvYiBzdWJtaXNzaW9u IHByb3RvY29sDQogIHRoYXQgY29uZm9ybXMgdG8gY29uZmlndXJhdGlvbiAz Lg0KDQoNCiAgNy4xICBqbUpvYlN1Ym1pc3Npb25JZCBNYXBwZWQgdG8gTkRQ Uw0KDQogIE5EUFMgc3VwcG9ydHMgdGhlIGdlbmVyYXRpb24gb2YgYSBwcm9w ZXJseSBmb3JtYXR0ZWQgam1Kb2JTdWJtaXNzaW9uSWQNCiAgZm9yIHVzZSBp biB0aGUgSm9iIE1JQi4NCg0KDQogIDcuMiAgam1Kb2JJbmRleCBNYXBwZWQg dG8gTkRQUw0KDQogIE5EUFMgZG9lcyBub3QgcHJvdmlkZSBhIHZhbHVlIHRo YXQgY2FuIGJlIG1hcHBlZCB0byBqbUpvYkluZGV4Lg0KDQoNCiAgNy4zICBP dGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gTkRQUw0KDQogIE1JQiBPYmpl Y3QgICAgICAgICAgICAgfCBORFBTIFBhcmFtZXRlcg0KICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgam1Kb2JPd25lciAgICAgICAgICAgICB8 DQoNCg0KICA3LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIE5E UFMNCg0KICBUaGUgZm9sbG93aW5nIG1hcHBpbmdzIGFyZSByZXF1aXJlZCBp ZiB0aGUgbGlzdGVkIFBKTCBhdHRyaWJ1dGUgb3INCiAgY29tbWFuZCBvcHRp b24gaXMgcHJvdmlkZWQuDQoNCiAgTUlCIGF0dHJpYnV0ZSAgICAgICAgICAg ICAgfCBORFBTIHBhcmFtZXRlciAgICAgICAgICAgICAgIHwgRGF0YSB0eXBl DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0KICBqb2JBY2NvdW50 TmFtZSAgICAgICAgICAgICB8DQogIHNlcnZlckFzc2lnbmVkSm9iTmFtZSAg ICAgIHwNCiAgam9iTmFtZSAgICAgICAgICAgICAgICAgICAgfA0KICBqb2JT ZXJ2aWNlVHlwZXMgICAgICAgICAgICB8DQogIG51bWJlck9mRG9jdW1lbnRz ICAgICAgICAgIHwNCiAgZmlsZU5hbWUgICAgICAgICAgICAgICAgICAgfA0K ICBkb2N1bWVudE5hbWUgICAgICAgICAgICAgICB8DQogIGpvYkNvbW1lbnQg ICAgICAgICAgICAgICAgIHwNCiAgZG9jdW1lbnRGb3JtYXRJbmRleCAgICAg ICAgfA0KICBkb2N1bWVudEZvcm1hdCAgICAgICAgICAgICB8DQogIGpvYlBy aW9yaXR5ICAgICAgICAgICAgICAgIHwNCiAgam9iUHJvY2Vzc0FmdGVyRGF0 ZUFuZFRpbWUgfA0KICBqb2JIb2xkVW50aWwgICAgICAgICAgICAgICB8DQog IG91dHB1dEJpbiAgICAgICAgICAgICAgICAgIHwNCiAgc2lkZXMgICAgICAg ICAgICAgICAgICAgICAgfA0KICBmaW5pc2hpbmcgICAgICAgICAgICAgICAg ICB8DQogIHByaW50UXVhbGl0eVJlcXVlc3RlZCAgICAgIHwNCg0KDQogIEJl cmdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtwYWdlIDhdDQwNCg0KDQogIEpvYiBTdWJtaXNz aW9uIFByb3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zICAgICAgICAg ICAgIE9jdCAxMCwgMTk5Nw0KDQoNCg0KICBwcmludGVyUmVzb2x1dGlvblJl cXVlc3RlZCB8DQogIGpvYkNvcGllc1JlcXVlc3RlZCAgICAgICAgIHwNCiAg bWVkaXVtUmVxdWVzdGVkICAgICAgICAgICAgfA0KICBqb2JTdWJtaXNzaW9u VG9TZXJ2ZXJUaW1lICB8DQogIGpvYlN1Ym1pc3Npb25UaW1lICAgICAgICAg IHwNCg0KDQogIDguMCAgUFJJTlRFUiBKT0IgTEFOR1VBR0UgKFBKTCkNCg0K ICBQSkwgW1BKTF0gaGFzIGJlZW4gZGV2ZWxvcGVkIGJ5IEhld2xldHQtUGFj a2FyZCB0byBwcm92aWRlIGpvYiBjb250cm9sDQogIGluZm9ybWF0aW9uIHRv IHRoZSBwcmludGVyIGFuZCBzdGF0dXMgaW5mb3JtYXRpb24gdG8gYXBwbGlj YXRpb25zLA0KICBpbmRlcGVuZGVudCBvZiB0aGUgUERMLiAgUEpMIGlzIG5v cm1hbGx5IHRyYW5zZmVycmVkIHVzaW5nIGEgdHJhZGl0aW9uYWwNCiAgam9i IHN1Ym1pc3Npb24gbGFuZ3VhZ2Ugc3VjaCBhcyBMUFIvTFBEIG9yIE5ldFdh cmUgUFNlcnZlci4NCg0KDQogIDguMSAgam1Kb2JTdWJtaXNzaW9uSWQgTWFw cGVkIHRvIFBKTA0KDQogIFBKTCBoYXMgZGVmaW5lZCB0aGUgU1VCTUlTU0lP TklEIG9wdGlvbiBmb3IgdGhlIEpPQiBjb21tYW5kIHdoaWNoDQogIGluZGlj YXRlcyBhIHByb3Blcmx5IGZvcm1hdHRlZCBqbUpvYlN1Ym1pc3Npb25JZCBm b3IgdXNlIGluIHRoZSBKb2IgTUlCLg0KICBUaGUgUEpMIEpPQiBjb21tYW5k IGlzIHByZXNlbnRlZCBhdCB0aGUgc3RhcnQgb2YgYSBwcmludCBqb2Igd2l0 aA0KICBvcHRpb25zIHRoYXQgYXBwbHkgb25seSB0aGUgYXR0YWNoZWQgam9i LiAgVGhlIHN5bnRheCBmb3IgdGhpcyBjb21tYW5kDQogIG9wdGlvbiBpczoN Cg0KICAgICAgICBAUEpMIEpPQiBTVUJNSVNTSU9OSUQgPSBgDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGBpZCBzdHJpbmcnDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJw0KDQogIERy aXZlciBzb2Z0d2FyZSB0aGF0IGltcGxlbWVudHMgdGhpcyBQSkwgY29tbWFu ZCBvcHRpb24gbXVzdCBwcm92aWRlIHRoZQ0KICBgDSAgIGBpZCBzdHJpbmcn DSAgICAgICAgICAgICAgJyBpbiBvbmUgb2YgdGhlIGNsaWVudCB2ZXJzaW9u IGZvcm1hdHMgc3BlY2lmaWVkIGluIHRoZSBKb2INCiAgTUlCIGZvciBqbUpv YlN1Ym1pc3Npb25JZC4NCg0KICBGb3IgZHJpdmVycyB0aGF0IGFyZSBub3Qg YWJsZSB0byBjcmVhdGUgdGhlIFNVQk1JU1NJT05JRCBvcHRpb24sIGl0IGlz DQogIHJlY29tbWVuZGVkIHRoYXQgam1Kb2JTdWJtaXNzaW9uSWQgZm9ybWF0 IDAgYmUgY3JlYXRlZCBieSB0aGUgYWdlbnQNCiAgdXNpbmcgdGhlIFBKTCBh dHRyaWJ1dGUgRG9jT3duZXIgb3IgRG9jT3duZXJJZC4NCg0KICAgIG9jdGV0 IDE6ICAgJzAnDQoNCiAgICBvY3RldHMgMi00MDogIENvbnRhaW5zIHRoZSBz dHJpbmcgYXNzb2NpYXRlZCB3aXRoIERvY093bmVyIG9yDQogICAgICAgICAg ICAgICAgICBEb2NPd25lcklkLiAgSWYgdGhlIHN0cmluZyBpcyBsZXNzIHRo YW4gNDAgb2N0ZXRzLCB0aGUNCiAgICAgICAgICAgICAgICAgIGxlZnQtbW9z dCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmluZyBzaGFsbCBhcHBlYXIgaW4gb2N0 ZXQNCiAgICAgICAgICAgICAgICAgIHBvc2l0aW9uIDIuICBPdGhlcndpc2Us IG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwgYmUNCiAgICAgICAgICAg ICAgICAgIGluY2x1ZGVkLiAgSWYgRG9jT3duZXIgb3IgRG9jT3duZXJJZCBj YW5ub3QgYmUgb2J0YWluZWQsDQogICAgICAgICAgICAgICAgICB0aGlzIGZp ZWxkIHNoYWxsIGJlIGJsYW5rLg0KDQogICAgb2N0ZXRzIDQxLTQ4OiAgQ29u dGFpbnMgdGhlIHZhbHVlIG9mIGptSm9iSW5kZXggYXNzb2NpYXRlZCB3aXRo IHRoZQ0KICAgICAgICAgICAgICAgICAgIGpvYi4NCg0KDQogIDguMiAgam1K b2JJbmRleCBNYXBwZWQgdG8gUEpMDQoNCiAgUEpMIGRvZXMgbm90IHByb3Zp ZGUgYSB2YWx1ZSB0aGF0IGNhbiBiZSBtYXBwZWQgdG8gam1Kb2JJbmRleC4N Cg0KDQogIDguMyAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gUEpM DQoNCg0KDQogIEJlcmdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDldDQwNCg0KDQog IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRp b25zICAgICAgICAgICAgIE9jdCAxMCwgMTk5Nw0KDQoNCg0KICBUaGUgZm9s bG93aW5nIG1hcHBpbmdzIGFyZSByZXF1aXJlZCBpZiB0aGUgbGlzdGVkIFBK TCBhdHRyaWJ1dGUgb3INCiAgY29tbWFuZCBvcHRpb24gaXMgcHJvdmlkZWQu DQoNCiAgTUlCIGF0dHJpYnV0ZSAgICAgICAgIHwgUEpMIGF0dHJpYnV0ZSBv ciBjb21tYW5kIG9wdGlvbiAgfCBEYXRhIHR5cGUNCiAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tDQogIGpvYk93bmVyICAgICAgICAgICAgICB8IERv Y093bmVyIG9yIERvY093bmVySWQgYXR0cmlidXRlIHwgT2N0ZXQgU3RyaW5n DQogIHNlcnZlckFzc2lnbmVkSm9iTmFtZSB8IERvY05hbWUgYXR0cmlidXRl IG9yIHRoZSBjb21tYW5kIHwgT2N0ZXQgU3RyaW5nDQogICAgICAgICAgICAg ICAgICAgICAgICB8ICBAUEpMIEpPQiBOYW1lID0gYA0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGBzdHJpbmcnDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAnICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBzdWJtaXR0aW5nU2VydmVy TmFtZSAgfCBTcmNTZXJ2ZXJOYW1lIGF0dHJpYnV0ZSAgICAgICAgICB8IE9j dGV0IFN0cmluZw0KICBqb2JPcmlnaW5hdGluZ0hvc3QgICAgfCBTcmNQb3J0 IGF0dHJpYnV0ZSAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBx dWV1ZU5hbWVSZXF1ZXN0ZWQgICAgfCBTcmNRIGF0dHJpYnV0ZSAgICAgICAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBmaWxlTmFtZSAgICAgICAg ICAgICAgfCBKb2JGTmFtZSBhdHRyaWJ1dGUgICAgICAgICAgICAgICB8IE9j dGV0IFN0cmluZw0KICBqb2JDb21tZW50ICAgICAgICAgICAgfCBKb2JEZXNj IGF0dHJpYnV0ZSAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KICBq b2JTdWJtaXNzaW9uVGltZSAgICAgfCBUaW1lU3VibWl0IGF0dHJpYnV0ZSAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KDQoNCiAgOS4wICBQT1NUU0NS SVBUDQoNCg0KICAxMC4wICBORVRXQVJFIFBTRVJWRVINCg0KICBUaGUgTmV0 V2FyZSBQU2VydmVyIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIGlzIGltcGxl bWVudGVkIGluIGEgY2xpZW50LQ0KICBzZXJ2ZXItcHJpbnRlciBzeXN0ZW0g b24gdGhlIHNlcnZlciB0byBwcmludGVyIGxpbmsgYXMgZGVmaW5lZCBpbg0K ICBjb25maWd1cmF0aW9uIDMuDQoNCg0KICAxMC4xICBqbUpvYlN1Ym1pc3Np b25JZCBNYXBwZWQgdG8gUFNlcnZlcg0KDQogICAgb2N0ZXQgMTogICAnPycg ICAqKioqKiBOZXcgZm9ybWF0IHJlcSdkID8/PyAqKioqKg0KDQogICAgb2N0 ZXRzIDItNDA6ICBDb250YWlucyB0aGUgRGlyZWN0b3J5IFBhdGggTmFtZSBh cyByZWNvcmRlZCBieSB0aGUNCiAgICAgICAgICAgICAgICAgIE5vdmVsbCBG aWxlIFNlcnZlciBpbiB0aGUgcXVldWUgZGlyZWN0b3J5LiAgSWYgdGhlDQog ICAgICAgICAgICAgICAgICBzdHJpbmcgaXMgbGVzcyB0aGFuIDQwIG9jdGV0 cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0ZXINCiAgICAgICAgICAgICAgICAg IGluIHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFyIGluIG9jdGV0IHBvc2l0aW9u IDIuDQogICAgICAgICAgICAgICAgICBPdGhlcndpc2UsIG9ubHkgdGhlIGxh c3QgMzkgYnl0ZXMgc2hhbGwgYmUgaW5jbHVkZWQuDQoNCiAgICBvY3RldHMg NDEtNDg6ICBgMDAwWFhYWFgnICBUaGUgQVNDSUkgcmVwcmVzZW50YXRpb24g b2YgdGhlIEpvYiBOdW1iZXINCiAgICAgICAgICAgICAgICAgICBhcyBwZXIg dGhlIHF1ZXVlIGRpcmVjdG9yeS4NCg0KDQogIDEwLjIgIGptSm9iSW5kZXgg TWFwcGVkIHRvIFBTZXJ2ZXINCg0KICBUaGUgam9iIGluZGV4IChqbUpvYklu ZGV4KSBpcyBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2IgbW9uaXRvcmluZyBh Z2VudA0KICBhbmQgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIEpvYiBOdW1iZXIg YXNzaWduZWQgYnkgdGhlIE5ldFdhcmUgRmlsZQ0KICBTZXJ2ZXIuICBUaGlz IHdpbGwgYWxsb3cgdGhlIFNOTVAgYWdlbnQgdG8gdHJhY2sgam9icyByZWNl aXZlZCBmcm9tDQogIG11bHRpcGxlIHNvdXJjZXMuDQoNCg0KICAxMC4zICBU aGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQU2VydmVyDQoNCiAgVGhl IGZvbGxvd2luZyBtYXBwaW5ncyBhcmUgcmVxdWlyZWQgaWYgdGhlIGxpc3Rl ZCBQU2VydmVyIHBhcmFtZXRlciBpcw0KICBwcm92aWRlZCBpbiB0aGUgTm92 ZWxsIEZpbGUgU2VydmVyIHF1ZXVlIGRpcmVjdG9yeS4NCg0KDQoNCiAgQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgMTBdDQwNCg0KDQogIEpvYiBTdWJtaXNz aW9uIFByb3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zICAgICAgICAg ICAgIE9jdCAxMCwgMTk5Nw0KDQoNCg0KICBNSUIgYXR0cmlidXRlICAgICAg ICAgICAgICB8IFBTZXJ2ZXIgcGFyYW1ldGVyICAgICAgICAgICB8IERhdGEg dHlwZQ0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0NCiAgam9iT3du ZXIgICAgICAgICAgICAgICAgICAgfCBDbGllbnQgSWQgTnVtYmVyICAgICAg ICAgICAgfCBJbnRlZ2VyDQogIHNlcnZlckFzc2lnbmVkSm9iTmFtZSAgICAg IHwgSm9iIEZpbGUgTmFtZSAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5n DQogIHF1ZXVlTmFtZVJlcXVlc3RlZCAgICAgICAgIHwgUXVldWUgSWQgICAg ICAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KICBwaHlzaWNhbERldmljZSAg ICAgICAgICAgICB8IFNlcnZlciBJZCBOdW1iZXIgICAgICAgICAgICB8IElu dGVnZXINCiAgam9iQ29tbWVudCAgICAgICAgICAgICAgICAgfCBKb2IgRGVz Y3JpcHRpb24gICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCiAgam9iUHJp b3JpdHkgICAgICAgICAgICAgICAgfA0KICBqb2JQcm9jZXNzQWZ0ZXJEYXRl QW5kVGltZSB8IFRhcmdldCBFeGVjdXRpb24gVGltZSAgICAgICB8IE9jdGV0 IFN0cmluZw0KICBqb2JIb2xkVW50aWwgICAgICAgICAgICAgICB8DQogIGpv YkNvcGllc1JlcXVlc3RlZCAgICAgICAgIHwgTnVtYmVyIG9mIENvcGllcyAg ICAgICAgICAgIHwgSW50ZWdlcg0KICBtZWRpdW1SZXF1ZXN0ZWQgICAgICAg ICAgICB8IEZvcm0gTmFtZSAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0 cmluZw0KICBqb2JTdWJtaXR0ZWRUb1NlcnZlclRpbWUgICB8IEpvYiBFbnRy eSBUaW1lICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KDQoNCiAgMTEu MCAgTkVUV0FSRSBOUFJJTlRFUiBvciBSUFJJTlRFUg0KDQogIFRoZSBOZXRX YXJlIE5QcmludGVyL1JQcmludGVyIHByb3RvY29sIHdhcyBkZXNpZ25lZCB0 byB0cmFuc2ZlciBwcmludA0KICBkYXRhIGZyb20gYSBOb3ZlbGwgRmlsZSBT ZXJ2ZXIgdG8gYSBwcmludGVyIGF0dGFjaGVkIGRpcmVjdGx5IHRvIGEgbG9j YWwNCiAgcG9ydCAoZS5nLiBwYXJhbGxlbCBvciBzZXJpYWwpIG9uIGEgUEMu ICBOUHJpbnRlci9SUHJpbnRlciBpcyBhbg0KICBleHRyZW1lbHkgbGlnaHR3 ZWlnaHQgcHJpbnRpbmcgcHJvdG9jb2wuICBDb25zZXF1ZW50bHksIG5vIGlu Zm9ybWF0aW9uDQogIHJlcXVpcmVkIGJ5IHRoZSBKb2IgTW9uaXRvcmluZyBN SUIgaXMgcHJvdmlkZWQgYW5kIGEgbWVhbmluZ2Z1bA0KICBqbUpvYlN1Ym1p c3Npb25JZCBjYW5ub3QgYmUgZ2VuZXJhdGVkLg0KDQogIEl0IGlzIHJlY29t bWVuZGVkIHRoYXQgYW4gYWRkaXRpb25hbCBqb2Igc3VibWlzc2lvbiBsYXll ciwgc3VjaCBhcyBQSkwNCiAgb3IgYW5vdGhlciB2ZW5kb3IgcHJpdmF0ZSBw cm90b2NvbCwgIGJlIGluY2x1ZGVkIG9uIHRvcCBvZg0KICBOUHJpbnRlci9S UHJpbnRlciB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbi4g IFRoZSBtYXBwaW5nDQogIHNob3VsZCB0aGVuIGJlIHBlcmZvcm1lZCBhY2Nv cmRpbmcgdG8gdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGUgaGlnaGVyDQog IGxheWVyIHN1Ym1pc3Npb24gcHJvdG9jb2wuDQoNCg0KICAxMi4wICBTRVJW RVIgTUVTU0FHRSBCTE9DSyAoU01CKSBQUk9UT0NPTA0KDQoNCiAgMTMuMCAg VFJBTlNQT1JUIElOREVQRU5ERU5UIFBSSU5URVIvU1lTVEVNIElOVEVSRkFD RSAoVElQL1NJKQ0KDQoNCiAgMTQuMCAgUkVGRVJFTkNFUw0KDQogIFtJUFBd ICBUaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgUkZDIFhYWFgsIE1v ZGVsIFJGQyBYWFhYDQoNCiAgW0pvYk1JQl0gIFRoZSBKb2IgTW9uaXRvcmlu ZyBNSUIsIFJGQyBYWFhYLCBJRVRGIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQu DQoNCiAgW0xQRF0gIExpbmUgUHJpbnRlciBEYWVtb24gUHJvdG9jb2wsIFJG QyAxMTc5LCBJRVRGIGluZm9ybWF0aW9uYWwNCiAgZG9jdW1lbnQuDQoNCiAg W1BKTF0gIFByaW50ZXIgSm9iIExhbmd1YWdlIFRlY2huaWNhbCBSZWZlcmVu Y2UgTWFudWFsLCBIZXdsZXR0LVBhY2thcmQNCiAgcGFydCBudW1iZXIgNTAy MS0wMzI4Lg0KDQogIFtQcnRNSUJdICBUaGUgUHJpbnRlciBNSUIsIFJGQyAx NzU5LCBJRVRGIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudC4NCg0KDQoNCg0K DQogIEJlcmdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDExXQ0MDQoNCg== From rbergma at dpc.com Thu Oct 23 11:58:05 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Agenda for Boulder Meeting Message-ID: <3.0.1.32.19971022173143.0109b100@garfield> 1. Review status of "Standards Track" vs "Informational". 2. Review MIB updates since last meeting. 3. jmJobSubmissionId mapping - are all job submission protocols covered? For those persons with action items for mapping a job submission protocol, could you please complete this one item of the map and be prepared to discuss? 4. Review remainder of Mapping Spec (as time permits). The new schedule for JMP is 8:30 to 11:00. We will not go past 11:00AM. Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Thu Oct 23 13:38:58 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Friday schedule change Message-ID: <3.0.1.32.19971022173143.0109b100@garfield> There are people who need to do JMP first but others who need to leave = around Noon and want to discuss at least some FIN. To try and accommodate ever= yone's needs, I'd like to rearrange Friday as follows: JMP 8:30-11 FIN part -1 11-12:30 Lunch 12:30 - 1:30 FIN part -2 12:30-3 or whenever things break up (usually around 3). IT WILL TAKE RIGOR ON OUR PART TO CUT OFF JMP AND MOVE TO FIN AS SCHEDU= LED!! Please note, I recommend you leave AT LEAST 2 hr. for return to DIA to = catch you flight Friday. 2:30 would be "comfortable" if returning a car. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Thu Oct 23 21:36:24 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Mapping Document [WARNING: contains CAP In-Reply-To: Message-ID: <3.0.1.32.19971023183624.0108e870@garfield> My virus detection software detected the CAP virus in the .doc file. It claimed to remove the virus, but it was the same size, so I'm dubious. Otherwise, I would have replaced it on the PWG server. Tom At 08:47 10/23/1997 PDT, Ron Bergman wrote: >I have loaded the following files for the Job MIB Mapping specification: > > ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP00.TXT (.DOC) > >I would like to review this document at the JMP meeting next week. The >main subject will be the mapping to jmJobSubmissionId. We need to verify >that all the necessary formats for jmJobSubmissionId are available in the >MIB. > >Attached is the text version. > > Ron Bergman > > > > > > > > INTERNET-DRAFT Ron Bergman > Dataproducts Corp. > October 15, 1997 > > > Job Submission Protocol Mapping Recommendations > for the Job Monitoring MIB > > > > Expires Apr 15, 1997 > > > > Status of this Memo > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Drafts > as reference material or to cite them other than as "work in > progress". > > To learn the current status of any Internet-Draft, please check the > "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow > Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > Abstract > > This Internet-Draft defines the recommended mapping for many > currently popular Job submission protocols to objects and > attributes the Job Monitoring MIB. > > > > > > > > > > > > > > > > > > Bergman [page 1] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > TABLE OF CONTENTS > > 1.0 INTRODUCTION .....................................................2 > 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL ...........................3 > 2.1 jmJobSubmissionId Mapped to LPR/LPD ..............................4 > 2.2 jmJobIndex Mapped to LPR/LPD .....................................4 > 2.3 Other MIB Objects Mapped to LPR/LPD ..............................4 > 2.4 The Attribute Group Mapped to LPD ................................4 > 3.0 APPLETALK PROTOCOL ...............................................5 > 3.1 jmJobSubmissionId Mapped to AppleTalk ............................5 > 3.2 Other AppleTalk Mappings .........................................5 > 4.0 INTERNET PRINTING PROTOCOL (IPP) .................................5 > 4.1 jmJobSubmissionId Mapped to IPP ..................................6 > 4.2 jmJobIndex Mapped to IPP .........................................6 > 4.3 Other MIB Objects Mapped to IPP ..................................7 > 4.4 The Attribute Group Mapped to IPP ................................7 > 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) ...........................7 > 6.0 DOCUMENT PRINTING APPLICATION (DPA) ..............................8 > 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) ..........................8 > 7.1 jmJobSubmissionId Mapped to NDPS .................................8 > 7.2 jmJobIndex Mapped to NDPS ........................................8 > 7.3 Other MIB Objects Mapped to NDPS .................................8 > 7.4 The Attribute Group Mapped to NDPS ...............................8 > 8.0 PRINTER JOB LANGUAGE (PJL) .......................................9 > 8.1 jmJobSubmissionId Mapped to PJL ..................................9 > 8.2 jmJobIndex Mapped to PJL .........................................9 > 8.3 The Attribute Group Mapped to PJL ................................9 > 9.0 POSTSCRIPT ......................................................10 > 10.0 NETWARE PSERVER ................................................10 > 10.1 jmJobSubmissionId Mapped to PServer ............................10 > 10.2 jmJobIndex Mapped to PServer ...................................10 > 10.3 The Attribute Group Mapped to PServer ..........................10 > 11.0 NETWARE NPRINTER or RPRINTER ...................................11 > 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL ............................11 > 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) ........11 > 14.0 REFERENCES .....................................................11 > > > 1.0 INTRODUCTION > > The Job Monitoring MIB [JobMIB] is functional with any job submission > protocol. However, the information available and the method of > presentation varies significantly by job submission protocol. A common > method of mapping job submission information to the Job Monitoring MIB > is essential for interoperability of Job MIB agents and monitoring > applications. This document defines recommended mappings for most > popular job submission protocols to insure this compatibility. > > All mappings are unidirectional from the job submission protocol to the > MIB. It is assumed that support of the job submission protocol in the > printer implies that the reverse information flow is presently defined > and does not require interaction from the MIB. This mapping is not > defined in this document as it should be obvious. > > > Bergman [page 2] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > This document refers to system configurations that are defined in the > Job Monitoring MIB [JobMIB]. For those readers that are familiar with > the configuration descriptions, a short summary appears here. Please > see the Job MIB document for further details. > > Configuration 1: This is a simple peer-to-peer system which contains > only a client and a printer. The Job MIB agent is resident in > the printer. > > Configuration 2: This system contains a client, server, and a > printer. The Jib MIB agent is resident in the server. > > Configuration 3: This system, as in configuration 2, contains a > client, server, and a printer. In this case the Job MIB agent is > implemented within the printer. > > The most important object to be mapped is jmJobSubmissionId, since this > is the key for the user to locate a submitted job. Therefore, > jmJobSubmissionId is specified for all job submission protocols defined > in this document. The remaining objects mapped include only those items > that have the equivalent information presented to the printer by the job > submission protocol. > > > 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL > > The LPR/LPD printing protocol [LPD] is used with BSD Unix systems in the > client-server-printer configuration. Usage of the Job Monitoring MIB > with LPR/LPD will most likely conform to Configuration 3, where the > monitor application or the server uses SNMP to obtain job information > from the printer. The client communicates with the Unix server using > the existing LPD protocol to obtain job information. > > The LPR/LPD protocol is also used in the Windows environment to > implement peer-to-peer printing, as shown in configuration 1. In this > case, SNMP is used by the client and/or the monitor application to > obtain the job information. > > One of the major problems of LPR/LPD is the large number of vendor > unique extensions currently used with the protocol and the resulting > compatibility issues between available implementations. To avoid these > issues, this mapping of LPR/LPD is restricted to the protocol as defined > by RFC 1179. > > The LPR/LPD protocol transfers print job data and control information in > separate files, known as the Data File and Control File respectively. > Most of the information concerning the print job is contained in the > Control File. In many LPD implementations, the Control File is > transferred following the Data File. Thus much of the information > concerning the job may not be available until the completion of the data > transmission. > > > > Bergman [page 3] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > 2.1 jmJobSubmissionId Mapped to LPR/LPD > > The LPR/LPD Receive Data File command contains a parameter which defines > the name of the data file. This name field is structured as follows: > > dfaXXX or daXXXX > > Where XXX or XXXX is the numeric job number assigned by the LPR/LPD > client submitting the print job. The recommended mapping of this name > field to jmJobSubmissionId is: > > octet 1: '9' > > octets 2-40: Contains the portion of the name field. If > the portion is less than 40 octets, the > left-most character in the string shall appear in octet > position 2. Otherwise, only the last 39 bytes shall be > included. > > octets 41-48: `00000XXX' or `0000XXXX'. > > > 2.2 jmJobIndex Mapped to LPR/LPD > > The job index (jmJobIndex) is assigned by the SNMP job monitoring agent > and is independent of the XXX (or XXXX) index assigned by the LPR/LPD > client. This will allow the SNMP agent to track jobs received from > multiple sources. > > > 2.3 Other MIB Objects Mapped to LPR/LPD > > MIB Object | LPR/LPD Parameter > -----------------------+------------------------------------------------ > jmJobKOctetsRequested | Number of bytes as defined in the Data File > jmJobOwner | User Identification string in the Control File > > > 2.4 The Attribute Group Mapped to LPD > > Other attributes that are applicable, but not defined in this section > such as attributes that map to a vendor unique extension, may also be > included. > > MIB attribute | LPR/LPD information | Data type > ----------------------+---------------------------------+-------------- > serverAssignedJobName | Name of the data file (note 1) | Octet String > jobSourceChannelIndex | prtChannelIndex (note 2) | Integer > queueNameRequested | Queue name from the Data File | Octet String > fileName | Name of the source file (note 3)| Octet String > documentName | The document title name (note 3)| Octet String > > > > Bergman [page 4] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > Notes: > ------ > 1. See section 2.1 (jmJobSubmissionId). > 2. Included if the Printer MIB is also supported by the agent. > 3. The information is optional in the Control File. The attribute > should be included if present in the Control File. > > > 3.0 APPLETALK PROTOCOL > > AppleTalk was originally developed as a peer-to-peer network protocol, > as described in configuration 1, for use with Apple Macintosh computers. > Today, print spoolers are also available for use with Macintosh computer > networks that conform to configurations 2/3. In addition, printing with > the AppleTalk protocol is supported from both Windows NT servers and > Novell servers also per configurations 2/3. > > The AppleTalk protocol provides very little information that can be used > with the Job Monitoring MIB. The Macintosh print drivers are able to > provide information concerning the user and document name but imbed this > information in the PDL, which is typically PostScript. The preferred > jmJobSubmissionId is constructed from the information in the PostScript > file, as defined in section 9.0. > > > 3.1 jmJobSubmissionId Mapped to AppleTalk > > An alternative jmJobSubmissionId may be constructed from the Connection > Identifier contained in the AppleTalk Printer Access Protocol (PAP) > header. Since the Connection Id is not readily available in any of the > defined AppleTalk implementations, this approach may be of little > utility. > > octet 1: '?' ***** NEW TYPE CODE ???? ***** > > octets 2-40: Contains the AppleTalk printer name, with the first > character of the name in octet 2. (AppleTalk printer > names are a maximum of 31 characters.) > > octets 41-48: `00000XXX', where `XXX' is the decimal representation > of the Connection Id. > > > 3.2 Other AppleTalk Mappings > > No other Job MIB objects or parameters can be derived from information > available in the AppleTalk headers > > > 4.0 INTERNET PRINTING PROTOCOL (IPP) > > The Internet Printing Protocol [IPP] supports printing using any one of > the three possible configurations. For configuration 2, the mapping > > > Bergman [page 5] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > defined herein is performed on a server. Otherwise, the mapping is > performed on an agent within the printer. > > 4.1 jmJobSubmissionId Mapped to IPP > > IPP contains a rich set of parameters which allow several methods of > creating the jmJobSubmissionId object. The preferred method is to use > the IPP job-uri attribute as follows: > > octet 1: '4' > > octets 2-40: Contains the IPP job-uri job template attribute. If > the job-uri is less than 40 octets, the left-most > character in the string shall appear in octet position > 2. Otherwise, only the last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. > > If the job-uri is not available to the agent, the job-name job template > attribute shall be used. > > octet 1: '?' ***** New format required ? (1 for clients) ***** > > octets 2-40: Contains the IPP job-name job template attribute. If > the job-name is less than 40 octets, the left-most > character in the string shall appear in octet position > 2. Otherwise, only the last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. > > If both the job-uri and the job-name are not available, the job- > originating-user job template attribute shall be used. > > octet 1: '4' > > octets 2-40: Contains the IPP job-originating-user job template > attribute. If the job-originating-user name is less > than 40 octets, the left-most character in the string > shall appear in octet position 2. Otherwise, only the > last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. > > > 4.2 jmJobIndex Mapped to IPP > > The job index (jmJobIndex) assigned by the SNMP job monitoring agent may > be identical to the IPP job-id job template attribute if the agent is > receiving jobs only from a single server or client. If jobs are to be > received from multiple sources, jmJobIndex and job-id must be > independent. > > > > > Bergman [page 6] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > 4.3 Other MIB Objects Mapped to IPP > > MIB Object | IPP Job template attribute > --------------------------+--------------------------------------------- > jmJobOwner | job-originating-user > jmJobKOctetsRequested | job-k-octets > jmJobKOctetsProcessed | job-k-octets-processed > jmJobImpressionsRequested | job-impressions > jmJobImpressionsProcessed | job-impressions-completed > jmJobStateReasons1 | job-state-reasons (note 1) > jmNumberOfInterveningJobs | number-of-intervening-jobs > > Notes: > ------ > 1. JobStateReasons is a bit map described in one object and three > attributes. The IPP condition may change one or more of the bits > in one or more of these Job MIB items. > > > 4.4 The Attribute Group Mapped to IPP > > The following mappings are required if the listed IPP job template > attribute is provided. > > MIB attribute | IPP job template attribute | Data type > ---------------------------+------------------------------+------------- > jobName | job-name | Octet String > documentFormat | document-format | Octet String > jobPriority | job-priority | Integer > jobHoldUntil | job-hold-until | Octet String > sides | sides | Integer > finishing | finishings | Integer > printQualityRequested | print-quality | Integer > printerResolutionRequested | printer-resolution | Integer > jobCopiesRequested | copies | Integer > mediumRequested | media | Octet String > jobSubmissionTime | time-at-pending | Integer > jobStartedProcessingTime | time-at-processing | Integer > jobCompletionTime | time-at-completed | Integer > sheetsRequested | job-media-sheets | Integer > jobURI | job-uri | Octet String > jobStateReasonsN | job-state-reasons (note 1) | Integer > physicalDevice | output-device-assigned | Octet String > sheetsCompleted | job-media-sheets-completed | Integer > > Notes: > ------ > 1. JobStateReasons is a bit map described in one object and three > attributes. The IPP condition may change one or more of the bits > in one or more of these Job MIB items. > > > 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) > > > Bergman [page 7] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > > 6.0 DOCUMENT PRINTING APPLICATION (DPA) > > > 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) > > Novell Distributed Print Services is a DPA based job submission protocol > that conforms to configuration 3. > > > 7.1 jmJobSubmissionId Mapped to NDPS > > NDPS supports the generation of a properly formatted jmJobSubmissionId > for use in the Job MIB. > > > 7.2 jmJobIndex Mapped to NDPS > > NDPS does not provide a value that can be mapped to jmJobIndex. > > > 7.3 Other MIB Objects Mapped to NDPS > > MIB Object | NDPS Parameter > -----------------------+------------------------------------------------ > jmJobOwner | > > > 7.4 The Attribute Group Mapped to NDPS > > The following mappings are required if the listed PJL attribute or > command option is provided. > > MIB attribute | NDPS parameter | Data type > ---------------------------+------------------------------+------------- > jobAccountName | > serverAssignedJobName | > jobName | > jobServiceTypes | > numberOfDocuments | > fileName | > documentName | > jobComment | > documentFormatIndex | > documentFormat | > jobPriority | > jobProcessAfterDateAndTime | > jobHoldUntil | > outputBin | > sides | > finishing | > printQualityRequested | > > > Bergman [page 8] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > printerResolutionRequested | > jobCopiesRequested | > mediumRequested | > jobSubmissionToServerTime | > jobSubmissionTime | > > > 8.0 PRINTER JOB LANGUAGE (PJL) > > PJL [PJL] has been developed by Hewlett-Packard to provide job control > information to the printer and status information to applications, > independent of the PDL. PJL is normally transferred using a traditional > job submission language such as LPR/LPD or NetWare PServer. > > > 8.1 jmJobSubmissionId Mapped to PJL > > PJL has defined the SUBMISSIONID option for the JOB command which > indicates a properly formatted jmJobSubmissionId for use in the Job MIB. > The PJL JOB command is presented at the start of a print job with > options that apply only the attached job. The syntax for this command > option is: > > @PJL JOB SUBMISSIONID = ` `id string' ' > > Driver software that implements this PJL command option must provide the > ` `id string' ' in one of the client version formats specified in the Job > MIB for jmJobSubmissionId. > > For drivers that are not able to create the SUBMISSIONID option, it is > recommended that jmJobSubmissionId format 0 be created by the agent > using the PJL attribute DocOwner or DocOwnerId. > > octet 1: '0' > > octets 2-40: Contains the string associated with DocOwner or > DocOwnerId. If the string is less than 40 octets, the > left-most character in the string shall appear in octet > position 2. Otherwise, only the last 39 bytes shall be > included. If DocOwner or DocOwnerId cannot be obtained, > this field shall be blank. > > octets 41-48: Contains the value of jmJobIndex associated with the > job. > > > 8.2 jmJobIndex Mapped to PJL > > PJL does not provide a value that can be mapped to jmJobIndex. > > > 8.3 The Attribute Group Mapped to PJL > > > > Bergman [page 9] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > The following mappings are required if the listed PJL attribute or > command option is provided. > > MIB attribute | PJL attribute or command option | Data type > ----------------------+----------------------------------+-------------- > jobOwner | DocOwner or DocOwnerId attribute | Octet String > serverAssignedJobName | DocName attribute or the command | Octet String > | @PJL JOB Name = ` `string' ' | Octet String > submittingServerName | SrcServerName attribute | Octet String > jobOriginatingHost | SrcPort attribute | Octet String > queueNameRequested | SrcQ attribute | Octet String > fileName | JobFName attribute | Octet String > jobComment | JobDesc attribute | Octet String > jobSubmissionTime | TimeSubmit attribute | Octet String > > > 9.0 POSTSCRIPT > > > 10.0 NETWARE PSERVER > > The NetWare PServer job submission protocol is implemented in a client- > server-printer system on the server to printer link as defined in > configuration 3. > > > 10.1 jmJobSubmissionId Mapped to PServer > > octet 1: '?' ***** New format req'd ??? ***** > > octets 2-40: Contains the Directory Path Name as recorded by the > Novell File Server in the queue directory. If the > string is less than 40 octets, the left-most character > in the string shall appear in octet position 2. > Otherwise, only the last 39 bytes shall be included. > > octets 41-48: `000XXXXX' The ASCII representation of the Job Number > as per the queue directory. > > > 10.2 jmJobIndex Mapped to PServer > > The job index (jmJobIndex) is assigned by the SNMP job monitoring agent > and is independent of the Job Number assigned by the NetWare File > Server. This will allow the SNMP agent to track jobs received from > multiple sources. > > > 10.3 The Attribute Group Mapped to PServer > > The following mappings are required if the listed PServer parameter is > provided in the Novell File Server queue directory. > > > > Bergman [page 10] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > MIB attribute | PServer parameter | Data type > ---------------------------+-----------------------------+-------------- > jobOwner | Client Id Number | Integer > serverAssignedJobName | Job File Name | Octet String > queueNameRequested | Queue Id | Integer > physicalDevice | Server Id Number | Integer > jobComment | Job Description | Octet String > jobPriority | > jobProcessAfterDateAndTime | Target Execution Time | Octet String > jobHoldUntil | > jobCopiesRequested | Number of Copies | Integer > mediumRequested | Form Name | Octet String > jobSubmittedToServerTime | Job Entry Time | Octet String > > > 11.0 NETWARE NPRINTER or RPRINTER > > The NetWare NPrinter/RPrinter protocol was designed to transfer print > data from a Novell File Server to a printer attached directly to a local > port (e.g. parallel or serial) on a PC. NPrinter/RPrinter is an > extremely lightweight printing protocol. Consequently, no information > required by the Job Monitoring MIB is provided and a meaningful > jmJobSubmissionId cannot be generated. > > It is recommended that an additional job submission layer, such as PJL > or another vendor private protocol, be included on top of > NPrinter/RPrinter to provide the required information. The mapping > should then be performed according to the recommendations of the higher > layer submission protocol. > > > 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL > > > 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) > > > 14.0 REFERENCES > > [IPP] The Internet Printing Protocol RFC XXXX, Model RFC XXXX > > [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document. > > [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational > document. > > [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard > part number 5021-0328. > > [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document. > > > > > > Bergman [page 11] > > From hastings at cp10.es.xerox.com Fri Oct 24 12:32:58 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Mapping Document [reposed without CAP virus] In-Reply-To: <3.0.1.32.19971023183624.0108e870@garfield> Message-ID: <3.0.1.32.19971024093258.0108fe10@garfield> I checked with my support people and the virus removing software doesn't change the length of the file, so I reposted the .DOC without the CAP virus. I used the same name. (The old file seems to have been deleted anyway). Tom At 18:36 10/23/1997 PDT, Tom Hastings wrote: >My virus detection software detected the CAP virus in the .doc file. > >It claimed to remove the virus, but it was the same size, so I'm dubious. > >Otherwise, I would have replaced it on the PWG server. > >Tom > >At 08:47 10/23/1997 PDT, Ron Bergman wrote: >>I have loaded the following files for the Job MIB Mapping specification: >> >> ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP00.TXT (.DOC) >> >>I would like to review this document at the JMP meeting next week. The >>main subject will be the mapping to jmJobSubmissionId. We need to verify >>that all the necessary formats for jmJobSubmissionId are available in the >>MIB. >> >>Attached is the text version. >> >> Ron Bergman >> >> >> >> >> >> >> >> INTERNET-DRAFT Ron Bergman >> Dataproducts Corp. >> October 15, 1997 >> >> >> Job Submission Protocol Mapping Recommendations >> for the Job Monitoring MIB >> >> >> >> Expires Apr 15, 1997 >> >> >> >> Status of this Memo >> >> This document is an Internet-Draft. Internet-Drafts are working >> documents of the Internet Engineering Task Force (IETF), its areas, >> and its working groups. Note that other groups may also distribute >> working documents as Internet-Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months and may be updated, replaced, or obsoleted by other >> documents at any time. It is inappropriate to use Internet-Drafts >> as reference material or to cite them other than as "work in >> progress". >> >> To learn the current status of any Internet-Draft, please check the >> "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow >> Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), >> munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or >> ftp.isi.edu (US West Coast). >> >> Abstract >> >> This Internet-Draft defines the recommended mapping for many >> currently popular Job submission protocols to objects and >> attributes the Job Monitoring MIB. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bergman [page 1] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> TABLE OF CONTENTS >> >> 1.0 INTRODUCTION .....................................................2 >> 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL ...........................3 >> 2.1 jmJobSubmissionId Mapped to LPR/LPD ..............................4 >> 2.2 jmJobIndex Mapped to LPR/LPD .....................................4 >> 2.3 Other MIB Objects Mapped to LPR/LPD ..............................4 >> 2.4 The Attribute Group Mapped to LPD ................................4 >> 3.0 APPLETALK PROTOCOL ...............................................5 >> 3.1 jmJobSubmissionId Mapped to AppleTalk ............................5 >> 3.2 Other AppleTalk Mappings .........................................5 >> 4.0 INTERNET PRINTING PROTOCOL (IPP) .................................5 >> 4.1 jmJobSubmissionId Mapped to IPP ..................................6 >> 4.2 jmJobIndex Mapped to IPP .........................................6 >> 4.3 Other MIB Objects Mapped to IPP ..................................7 >> 4.4 The Attribute Group Mapped to IPP ................................7 >> 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) ...........................7 >> 6.0 DOCUMENT PRINTING APPLICATION (DPA) ..............................8 >> 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) ..........................8 >> 7.1 jmJobSubmissionId Mapped to NDPS .................................8 >> 7.2 jmJobIndex Mapped to NDPS ........................................8 >> 7.3 Other MIB Objects Mapped to NDPS .................................8 >> 7.4 The Attribute Group Mapped to NDPS ...............................8 >> 8.0 PRINTER JOB LANGUAGE (PJL) .......................................9 >> 8.1 jmJobSubmissionId Mapped to PJL ..................................9 >> 8.2 jmJobIndex Mapped to PJL .........................................9 >> 8.3 The Attribute Group Mapped to PJL ................................9 >> 9.0 POSTSCRIPT ......................................................10 >> 10.0 NETWARE PSERVER ................................................10 >> 10.1 jmJobSubmissionId Mapped to PServer ............................10 >> 10.2 jmJobIndex Mapped to PServer ...................................10 >> 10.3 The Attribute Group Mapped to PServer ..........................10 >> 11.0 NETWARE NPRINTER or RPRINTER ...................................11 >> 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL ............................11 >> 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) ........11 >> 14.0 REFERENCES .....................................................11 >> >> >> 1.0 INTRODUCTION >> >> The Job Monitoring MIB [JobMIB] is functional with any job submission >> protocol. However, the information available and the method of >> presentation varies significantly by job submission protocol. A common >> method of mapping job submission information to the Job Monitoring MIB >> is essential for interoperability of Job MIB agents and monitoring >> applications. This document defines recommended mappings for most >> popular job submission protocols to insure this compatibility. >> >> All mappings are unidirectional from the job submission protocol to the >> MIB. It is assumed that support of the job submission protocol in the >> printer implies that the reverse information flow is presently defined >> and does not require interaction from the MIB. This mapping is not >> defined in this document as it should be obvious. >> >> >> Bergman [page 2] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> >> This document refers to system configurations that are defined in the >> Job Monitoring MIB [JobMIB]. For those readers that are familiar with >> the configuration descriptions, a short summary appears here. Please >> see the Job MIB document for further details. >> >> Configuration 1: This is a simple peer-to-peer system which contains >> only a client and a printer. The Job MIB agent is resident in >> the printer. >> >> Configuration 2: This system contains a client, server, and a >> printer. The Jib MIB agent is resident in the server. >> >> Configuration 3: This system, as in configuration 2, contains a >> client, server, and a printer. In this case the Job MIB agent is >> implemented within the printer. >> >> The most important object to be mapped is jmJobSubmissionId, since this >> is the key for the user to locate a submitted job. Therefore, >> jmJobSubmissionId is specified for all job submission protocols defined >> in this document. The remaining objects mapped include only those items >> that have the equivalent information presented to the printer by the job >> submission protocol. >> >> >> 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL >> >> The LPR/LPD printing protocol [LPD] is used with BSD Unix systems in the >> client-server-printer configuration. Usage of the Job Monitoring MIB >> with LPR/LPD will most likely conform to Configuration 3, where the >> monitor application or the server uses SNMP to obtain job information >> from the printer. The client communicates with the Unix server using >> the existing LPD protocol to obtain job information. >> >> The LPR/LPD protocol is also used in the Windows environment to >> implement peer-to-peer printing, as shown in configuration 1. In this >> case, SNMP is used by the client and/or the monitor application to >> obtain the job information. >> >> One of the major problems of LPR/LPD is the large number of vendor >> unique extensions currently used with the protocol and the resulting >> compatibility issues between available implementations. To avoid these >> issues, this mapping of LPR/LPD is restricted to the protocol as defined >> by RFC 1179. >> >> The LPR/LPD protocol transfers print job data and control information in >> separate files, known as the Data File and Control File respectively. >> Most of the information concerning the print job is contained in the >> Control File. In many LPD implementations, the Control File is >> transferred following the Data File. Thus much of the information >> concerning the job may not be available until the completion of the data >> transmission. >> >> >> >> Bergman [page 3] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> >> 2.1 jmJobSubmissionId Mapped to LPR/LPD >> >> The LPR/LPD Receive Data File command contains a parameter which defines >> the name of the data file. This name field is structured as follows: >> >> dfaXXX or daXXXX >> >> Where XXX or XXXX is the numeric job number assigned by the LPR/LPD >> client submitting the print job. The recommended mapping of this name >> field to jmJobSubmissionId is: >> >> octet 1: '9' >> >> octets 2-40: Contains the portion of the name field. If >> the portion is less than 40 octets, the >> left-most character in the string shall appear in octet >> position 2. Otherwise, only the last 39 bytes shall be >> included. >> >> octets 41-48: `00000XXX' or `0000XXXX'. >> >> >> 2.2 jmJobIndex Mapped to LPR/LPD >> >> The job index (jmJobIndex) is assigned by the SNMP job monitoring agent >> and is independent of the XXX (or XXXX) index assigned by the LPR/LPD >> client. This will allow the SNMP agent to track jobs received from >> multiple sources. >> >> >> 2.3 Other MIB Objects Mapped to LPR/LPD >> >> MIB Object | LPR/LPD Parameter >> -----------------------+------------------------------------------------ >> jmJobKOctetsRequested | Number of bytes as defined in the Data File >> jmJobOwner | User Identification string in the Control File >> >> >> 2.4 The Attribute Group Mapped to LPD >> >> Other attributes that are applicable, but not defined in this section >> such as attributes that map to a vendor unique extension, may also be >> included. >> >> MIB attribute | LPR/LPD information | Data type >> ----------------------+---------------------------------+-------------- >> serverAssignedJobName | Name of the data file (note 1) | Octet String >> jobSourceChannelIndex | prtChannelIndex (note 2) | Integer >> queueNameRequested | Queue name from the Data File | Octet String >> fileName | Name of the source file (note 3)| Octet String >> documentName | The document title name (note 3)| Octet String >> >> >> >> Bergman [page 4] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> Notes: >> ------ >> 1. See section 2.1 (jmJobSubmissionId). >> 2. Included if the Printer MIB is also supported by the agent. >> 3. The information is optional in the Control File. The attribute >> should be included if present in the Control File. >> >> >> 3.0 APPLETALK PROTOCOL >> >> AppleTalk was originally developed as a peer-to-peer network protocol, >> as described in configuration 1, for use with Apple Macintosh computers. >> Today, print spoolers are also available for use with Macintosh computer >> networks that conform to configurations 2/3. In addition, printing with >> the AppleTalk protocol is supported from both Windows NT servers and >> Novell servers also per configurations 2/3. >> >> The AppleTalk protocol provides very little information that can be used >> with the Job Monitoring MIB. The Macintosh print drivers are able to >> provide information concerning the user and document name but imbed this >> information in the PDL, which is typically PostScript. The preferred >> jmJobSubmissionId is constructed from the information in the PostScript >> file, as defined in section 9.0. >> >> >> 3.1 jmJobSubmissionId Mapped to AppleTalk >> >> An alternative jmJobSubmissionId may be constructed from the Connection >> Identifier contained in the AppleTalk Printer Access Protocol (PAP) >> header. Since the Connection Id is not readily available in any of the >> defined AppleTalk implementations, this approach may be of little >> utility. >> >> octet 1: '?' ***** NEW TYPE CODE ???? ***** >> >> octets 2-40: Contains the AppleTalk printer name, with the first >> character of the name in octet 2. (AppleTalk printer >> names are a maximum of 31 characters.) >> >> octets 41-48: `00000XXX', where `XXX' is the decimal representation >> of the Connection Id. >> >> >> 3.2 Other AppleTalk Mappings >> >> No other Job MIB objects or parameters can be derived from information >> available in the AppleTalk headers >> >> >> 4.0 INTERNET PRINTING PROTOCOL (IPP) >> >> The Internet Printing Protocol [IPP] supports printing using any one of >> the three possible configurations. For configuration 2, the mapping >> >> >> Bergman [page 5] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> defined herein is performed on a server. Otherwise, the mapping is >> performed on an agent within the printer. >> >> 4.1 jmJobSubmissionId Mapped to IPP >> >> IPP contains a rich set of parameters which allow several methods of >> creating the jmJobSubmissionId object. The preferred method is to use >> the IPP job-uri attribute as follows: >> >> octet 1: '4' >> >> octets 2-40: Contains the IPP job-uri job template attribute. If >> the job-uri is less than 40 octets, the left-most >> character in the string shall appear in octet position >> 2. Otherwise, only the last 39 bytes shall be included. >> >> octets 41-48: Contains the job-id job template attribute. >> >> If the job-uri is not available to the agent, the job-name job template >> attribute shall be used. >> >> octet 1: '?' ***** New format required ? (1 for clients) ***** >> >> octets 2-40: Contains the IPP job-name job template attribute. If >> the job-name is less than 40 octets, the left-most >> character in the string shall appear in octet position >> 2. Otherwise, only the last 39 bytes shall be included. >> >> octets 41-48: Contains the job-id job template attribute. >> >> If both the job-uri and the job-name are not available, the job- >> originating-user job template attribute shall be used. >> >> octet 1: '4' >> >> octets 2-40: Contains the IPP job-originating-user job template >> attribute. If the job-originating-user name is less >> than 40 octets, the left-most character in the string >> shall appear in octet position 2. Otherwise, only the >> last 39 bytes shall be included. >> >> octets 41-48: Contains the job-id job template attribute. >> >> >> 4.2 jmJobIndex Mapped to IPP >> >> The job index (jmJobIndex) assigned by the SNMP job monitoring agent may >> be identical to the IPP job-id job template attribute if the agent is >> receiving jobs only from a single server or client. If jobs are to be >> received from multiple sources, jmJobIndex and job-id must be >> independent. >> >> >> >> >> Bergman [page 6] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> 4.3 Other MIB Objects Mapped to IPP >> >> MIB Object | IPP Job template attribute >> --------------------------+--------------------------------------------- >> jmJobOwner | job-originating-user >> jmJobKOctetsRequested | job-k-octets >> jmJobKOctetsProcessed | job-k-octets-processed >> jmJobImpressionsRequested | job-impressions >> jmJobImpressionsProcessed | job-impressions-completed >> jmJobStateReasons1 | job-state-reasons (note 1) >> jmNumberOfInterveningJobs | number-of-intervening-jobs >> >> Notes: >> ------ >> 1. JobStateReasons is a bit map described in one object and three >> attributes. The IPP condition may change one or more of the bits >> in one or more of these Job MIB items. >> >> >> 4.4 The Attribute Group Mapped to IPP >> >> The following mappings are required if the listed IPP job template >> attribute is provided. >> >> MIB attribute | IPP job template attribute | Data type >> ---------------------------+------------------------------+------------- >> jobName | job-name | Octet String >> documentFormat | document-format | Octet String >> jobPriority | job-priority | Integer >> jobHoldUntil | job-hold-until | Octet String >> sides | sides | Integer >> finishing | finishings | Integer >> printQualityRequested | print-quality | Integer >> printerResolutionRequested | printer-resolution | Integer >> jobCopiesRequested | copies | Integer >> mediumRequested | media | Octet String >> jobSubmissionTime | time-at-pending | Integer >> jobStartedProcessingTime | time-at-processing | Integer >> jobCompletionTime | time-at-completed | Integer >> sheetsRequested | job-media-sheets | Integer >> jobURI | job-uri | Octet String >> jobStateReasonsN | job-state-reasons (note 1) | Integer >> physicalDevice | output-device-assigned | Octet String >> sheetsCompleted | job-media-sheets-completed | Integer >> >> Notes: >> ------ >> 1. JobStateReasons is a bit map described in one object and three >> attributes. The IPP condition may change one or more of the bits >> in one or more of these Job MIB items. >> >> >> 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) >> >> >> Bergman [page 7] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> >> >> 6.0 DOCUMENT PRINTING APPLICATION (DPA) >> >> >> 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) >> >> Novell Distributed Print Services is a DPA based job submission protocol >> that conforms to configuration 3. >> >> >> 7.1 jmJobSubmissionId Mapped to NDPS >> >> NDPS supports the generation of a properly formatted jmJobSubmissionId >> for use in the Job MIB. >> >> >> 7.2 jmJobIndex Mapped to NDPS >> >> NDPS does not provide a value that can be mapped to jmJobIndex. >> >> >> 7.3 Other MIB Objects Mapped to NDPS >> >> MIB Object | NDPS Parameter >> -----------------------+------------------------------------------------ >> jmJobOwner | >> >> >> 7.4 The Attribute Group Mapped to NDPS >> >> The following mappings are required if the listed PJL attribute or >> command option is provided. >> >> MIB attribute | NDPS parameter | Data type >> ---------------------------+------------------------------+------------- >> jobAccountName | >> serverAssignedJobName | >> jobName | >> jobServiceTypes | >> numberOfDocuments | >> fileName | >> documentName | >> jobComment | >> documentFormatIndex | >> documentFormat | >> jobPriority | >> jobProcessAfterDateAndTime | >> jobHoldUntil | >> outputBin | >> sides | >> finishing | >> printQualityRequested | >> >> >> Bergman [page 8] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> printerResolutionRequested | >> jobCopiesRequested | >> mediumRequested | >> jobSubmissionToServerTime | >> jobSubmissionTime | >> >> >> 8.0 PRINTER JOB LANGUAGE (PJL) >> >> PJL [PJL] has been developed by Hewlett-Packard to provide job control >> information to the printer and status information to applications, >> independent of the PDL. PJL is normally transferred using a traditional >> job submission language such as LPR/LPD or NetWare PServer. >> >> >> 8.1 jmJobSubmissionId Mapped to PJL >> >> PJL has defined the SUBMISSIONID option for the JOB command which >> indicates a properly formatted jmJobSubmissionId for use in the Job MIB. >> The PJL JOB command is presented at the start of a print job with >> options that apply only the attached job. The syntax for this command >> option is: >> >> @PJL JOB SUBMISSIONID = ` `id >string' ' >> >> Driver software that implements this PJL command option must provide the >> ` `id string' ' in one of the client version formats >specified in the Job >> MIB for jmJobSubmissionId. >> >> For drivers that are not able to create the SUBMISSIONID option, it is >> recommended that jmJobSubmissionId format 0 be created by the agent >> using the PJL attribute DocOwner or DocOwnerId. >> >> octet 1: '0' >> >> octets 2-40: Contains the string associated with DocOwner or >> DocOwnerId. If the string is less than 40 octets, the >> left-most character in the string shall appear in octet >> position 2. Otherwise, only the last 39 bytes shall be >> included. If DocOwner or DocOwnerId cannot be obtained, >> this field shall be blank. >> >> octets 41-48: Contains the value of jmJobIndex associated with the >> job. >> >> >> 8.2 jmJobIndex Mapped to PJL >> >> PJL does not provide a value that can be mapped to jmJobIndex. >> >> >> 8.3 The Attribute Group Mapped to PJL >> >> >> >> Bergman [page 9] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> The following mappings are required if the listed PJL attribute or >> command option is provided. >> >> MIB attribute | PJL attribute or command option | Data type >> ----------------------+----------------------------------+-------------- >> jobOwner | DocOwner or DocOwnerId attribute | Octet String >> serverAssignedJobName | DocName attribute or the command | Octet String >> | @PJL JOB Name = ` > `string' >' | Octet String >> submittingServerName | SrcServerName attribute | Octet String >> jobOriginatingHost | SrcPort attribute | Octet String >> queueNameRequested | SrcQ attribute | Octet String >> fileName | JobFName attribute | Octet String >> jobComment | JobDesc attribute | Octet String >> jobSubmissionTime | TimeSubmit attribute | Octet String >> >> >> 9.0 POSTSCRIPT >> >> >> 10.0 NETWARE PSERVER >> >> The NetWare PServer job submission protocol is implemented in a client- >> server-printer system on the server to printer link as defined in >> configuration 3. >> >> >> 10.1 jmJobSubmissionId Mapped to PServer >> >> octet 1: '?' ***** New format req'd ??? ***** >> >> octets 2-40: Contains the Directory Path Name as recorded by the >> Novell File Server in the queue directory. If the >> string is less than 40 octets, the left-most character >> in the string shall appear in octet position 2. >> Otherwise, only the last 39 bytes shall be included. >> >> octets 41-48: `000XXXXX' The ASCII representation of the Job Number >> as per the queue directory. >> >> >> 10.2 jmJobIndex Mapped to PServer >> >> The job index (jmJobIndex) is assigned by the SNMP job monitoring agent >> and is independent of the Job Number assigned by the NetWare File >> Server. This will allow the SNMP agent to track jobs received from >> multiple sources. >> >> >> 10.3 The Attribute Group Mapped to PServer >> >> The following mappings are required if the listed PServer parameter is >> provided in the Novell File Server queue directory. >> >> >> >> Bergman [page 10] >> >> >> Job Submission Protocol Mapping Recommendations Oct 10, 1997 >> >> >> >> MIB attribute | PServer parameter | Data type >> ---------------------------+-----------------------------+-------------- >> jobOwner | Client Id Number | Integer >> serverAssignedJobName | Job File Name | Octet String >> queueNameRequested | Queue Id | Integer >> physicalDevice | Server Id Number | Integer >> jobComment | Job Description | Octet String >> jobPriority | >> jobProcessAfterDateAndTime | Target Execution Time | Octet String >> jobHoldUntil | >> jobCopiesRequested | Number of Copies | Integer >> mediumRequested | Form Name | Octet String >> jobSubmittedToServerTime | Job Entry Time | Octet String >> >> >> 11.0 NETWARE NPRINTER or RPRINTER >> >> The NetWare NPrinter/RPrinter protocol was designed to transfer print >> data from a Novell File Server to a printer attached directly to a local >> port (e.g. parallel or serial) on a PC. NPrinter/RPrinter is an >> extremely lightweight printing protocol. Consequently, no information >> required by the Job Monitoring MIB is provided and a meaningful >> jmJobSubmissionId cannot be generated. >> >> It is recommended that an additional job submission layer, such as PJL >> or another vendor private protocol, be included on top of >> NPrinter/RPrinter to provide the required information. The mapping >> should then be performed according to the recommendations of the higher >> layer submission protocol. >> >> >> 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL >> >> >> 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) >> >> >> 14.0 REFERENCES >> >> [IPP] The Internet Printing Protocol RFC XXXX, Model RFC XXXX >> >> [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document. >> >> [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational >> document. >> >> [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard >> part number 5021-0328. >> >> [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document. >> >> >> >> >> >> Bergman [page 11] >> >> > > From hastings at cp10.es.xerox.com Fri Oct 24 17:29:28 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Mapping Document In-Reply-To: Message-ID: <3.0.1.32.19971024142928.01117d50@garfield> Ron, Here are some initial comments. Tom At 08:47 10/23/1997 PDT, Ron Bergman wrote: >I have loaded the following files for the Job MIB Mapping specification: > > ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP00.TXT (.DOC) > >I would like to review this document at the JMP meeting next week. The >main subject will be the mapping to jmJobSubmissionId. We need to verify >that all the necessary formats for jmJobSubmissionId are available in the >MIB. > >Attached is the text version. > > Ron Bergman > > > > > > > > INTERNET-DRAFT Ron Bergman > Dataproducts Corp. > October 15, 1997 > > > Job Submission Protocol Mapping Recommendations > for the Job Monitoring MIB > > > > Expires Apr 15, 1997 > > > > Status of this Memo > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Drafts > as reference material or to cite them other than as "work in > progress". > > To learn the current status of any Internet-Draft, please check the > "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow > Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > Abstract > > This Internet-Draft defines the recommended mapping for many > currently popular Job submission protocols to objects and > attributes the Job Monitoring MIB. > > > > > > > > > > > > > > > > > > Bergman [page 1] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > TABLE OF CONTENTS > > 1.0 INTRODUCTION .....................................................2 > 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL ...........................3 > 2.1 jmJobSubmissionId Mapped to LPR/LPD ..............................4 > 2.2 jmJobIndex Mapped to LPR/LPD .....................................4 > 2.3 Other MIB Objects Mapped to LPR/LPD ..............................4 > 2.4 The Attribute Group Mapped to LPD ................................4 > 3.0 APPLETALK PROTOCOL ...............................................5 > 3.1 jmJobSubmissionId Mapped to AppleTalk ............................5 > 3.2 Other AppleTalk Mappings .........................................5 > 4.0 INTERNET PRINTING PROTOCOL (IPP) .................................5 > 4.1 jmJobSubmissionId Mapped to IPP ..................................6 > 4.2 jmJobIndex Mapped to IPP .........................................6 > 4.3 Other MIB Objects Mapped to IPP ..................................7 > 4.4 The Attribute Group Mapped to IPP ................................7 > 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) ...........................7 > 6.0 DOCUMENT PRINTING APPLICATION (DPA) ..............................8 > 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) ..........................8 > 7.1 jmJobSubmissionId Mapped to NDPS .................................8 > 7.2 jmJobIndex Mapped to NDPS ........................................8 > 7.3 Other MIB Objects Mapped to NDPS .................................8 > 7.4 The Attribute Group Mapped to NDPS ...............................8 > 8.0 PRINTER JOB LANGUAGE (PJL) .......................................9 > 8.1 jmJobSubmissionId Mapped to PJL ..................................9 > 8.2 jmJobIndex Mapped to PJL .........................................9 > 8.3 The Attribute Group Mapped to PJL ................................9 > 9.0 POSTSCRIPT ......................................................10 > 10.0 NETWARE PSERVER ................................................10 > 10.1 jmJobSubmissionId Mapped to PServer ............................10 > 10.2 jmJobIndex Mapped to PServer ...................................10 > 10.3 The Attribute Group Mapped to PServer ..........................10 > 11.0 NETWARE NPRINTER or RPRINTER ...................................11 > 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL ............................11 > 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) ........11 > 14.0 REFERENCES .....................................................11 > > > 1.0 INTRODUCTION > > The Job Monitoring MIB [JobMIB] is functional with any job submission Can we find a better word or phrase than "functional with" here? How about something like: The Job Monitoring MIB [JobMIB] is intended to be implemented in a device or server that supports any job submission protocol(s). > protocol. However, the information available and the method of > presentation varies significantly by job submission protocol. A common > method of mapping job submission information to the Job Monitoring MIB > is essential for interoperability of Job MIB agents and monitoring > applications. This document defines recommended mappings for most > popular job submission protocols to insure this compatibility. > > All mappings are unidirectional from the job submission protocol to the > MIB. It is assumed that support of the job submission protocol in the > printer implies that the reverse information flow is presently defined > and does not require interaction from the MIB. This mapping is not > defined in this document as it should be obvious. > > > Bergman [page 2] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > This document refers to system configurations that are defined in the > Job Monitoring MIB [JobMIB]. For those readers that are familiar with > the configuration descriptions, a short summary appears here. Please > see the Job MIB document for further details. > > Configuration 1: This is a simple peer-to-peer system which contains > only a client and a printer. The Job MIB agent is resident in > the printer. > > Configuration 2: This system contains a client, server, and a > printer. The Jib MIB agent is resident in the server. > > Configuration 3: This system, as in configuration 2, contains a > client, server, and a printer. In this case the Job MIB agent is > implemented within the printer. > > The most important object to be mapped is jmJobSubmissionId, since this > is the key for the user to locate a submitted job. Therefore, Add: or client > jmJobSubmissionId is specified for all job submission protocols defined > in this document. The remaining objects mapped include only those items > that have the equivalent information presented to the printer by the job > submission protocol. > > > 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL > > The LPR/LPD printing protocol [LPD] is used with BSD Unix systems in the > client-server-printer configuration. Usage of the Job Monitoring MIB > with LPR/LPD will most likely conform to Configuration 3, where the > monitor application or the server uses SNMP to obtain job information > from the printer. The client communicates with the Unix server using > the existing LPD protocol to obtain job information. > > The LPR/LPD protocol is also used in the Windows environment to > implement peer-to-peer printing, as shown in configuration 1. In this > case, SNMP is used by the client and/or the monitor application to > obtain the job information. > > One of the major problems of LPR/LPD is the large number of vendor > unique extensions currently used with the protocol and the resulting > compatibility issues between available implementations. To avoid these > issues, this mapping of LPR/LPD is restricted to the protocol as defined > by RFC 1179. > > The LPR/LPD protocol transfers print job data and control information in > separate files, known as the Data File and Control File respectively. Need a "," , > Most of the information concerning the print job is contained in the > Control File. In many LPD implementations, the Control File is > transferred following the Data File. Thus much of the information > concerning the job may not be available until the completion of the data > transmission. > > > > Bergman [page 3] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > 2.1 jmJobSubmissionId Mapped to LPR/LPD > > The LPR/LPD Receive Data File command contains a parameter which defines > the name of the data file. This name field is structured as follows: > > dfaXXX or daXXXX > > Where XXX or XXXX is the numeric job number assigned by the LPR/LPD > client submitting the print job. The recommended mapping of this name > field to jmJobSubmissionId is: > > octet 1: '9' > > octets 2-40: Contains the portion of the name field. If > the portion is less than 40 octets, the > left-most character in the string shall appear in octet > position 2. Otherwise, only the last 39 bytes shall be > included. Need to indicate that traliing SPACES are used for items shorter than 40. (The MIB describes the trailing spaces once up front.) Also this description is much different than (but equivalent to) what is in the Job Mon MIB. Do you think this is better, so we should change the MIB? The MIB description is: '9' octets 2-40: last 39 bytes of the host name with trailing SPACES that submitted the job to this server/device using a protocol, such as LPD [RFC-1179] which includes the host name in the job submission protocol. octets 41-48: 8-decimal-digit leading zero representation of the job id generated by the by the submitting server (configuration 3) or the client (configuration 1 and 2), such as in the LPD protocol. This format is reserved for clients. > > octets 41-48: `00000XXX' or `0000XXXX'. > > > 2.2 jmJobIndex Mapped to LPR/LPD > > The job index (jmJobIndex) is assigned by the SNMP job monitoring agent > and is independent of the XXX (or XXXX) index assigned by the LPR/LPD > client. This will allow the SNMP agent to track jobs received from > multiple sources. > > > 2.3 Other MIB Objects Mapped to LPR/LPD > > MIB Object | LPR/LPD Parameter > -----------------------+------------------------------------------------ > jmJobKOctetsRequested | Number of bytes as defined in the Data File > jmJobOwner | User Identification string in the Control File Need to identify which ASCII letter code field you mean in above. There are several. > > > 2.4 The Attribute Group Mapped to LPD > > Other attributes that are applicable, but not defined in this section > such as attributes that map to a vendor unique extension, may also be > included. > > MIB attribute | LPR/LPD information | Data type > ----------------------+---------------------------------+-------------- > serverAssignedJobName | Name of the data file (note 1) | Octet String I made the comment last meeting that this MIB attribute should be jobName(23), not serverAssignedJobName(22), but maybe you have changed your mind. Or the Job MIB needs some clarification for format 9? The serverAssignedJobName(22) is only for configuration 3, but LPD can be used with configurations 1 and 2 as well. > jobSourceChannelIndex | prtChannelIndex (note 2) | Integer > queueNameRequested | Queue name from the Data File | Octet String > fileName | Name of the source file (note 3)| Octet String > documentName | The document title name (note 3)| Octet String Need to identify which ASCII letter code field you mean in above. There are several. > > > > Bergman [page 4] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > Notes: > ------ > 1. See section 2.1 (jmJobSubmissionId). > 2. Included if the Printer MIB is also supported by the agent. > 3. The information is optional in the Control File. The attribute > should be included if present in the Control File. > > > 3.0 APPLETALK PROTOCOL > > AppleTalk was originally developed as a peer-to-peer network protocol, > as described in configuration 1, for use with Apple Macintosh computers. > Today, print spoolers are also available for use with Macintosh computer > networks that conform to configurations 2/3. In addition, printing with > the AppleTalk protocol is supported from both Windows NT servers and > Novell servers also per configurations 2/3. > > The AppleTalk protocol provides very little information that can be used > with the Job Monitoring MIB. The Macintosh print drivers are able to > provide information concerning the user and document name but imbed this > information in the PDL, which is typically PostScript. The preferred > jmJobSubmissionId is constructed from the information in the PostScript > file, as defined in section 9.0. > > > 3.1 jmJobSubmissionId Mapped to AppleTalk > > An alternative jmJobSubmissionId may be constructed from the Connection > Identifier contained in the AppleTalk Printer Access Protocol (PAP) > header. Since the Connection Id is not readily available in any of the > defined AppleTalk implementations, this approach may be of little > utility. > > octet 1: '?' ***** NEW TYPE CODE ???? ***** Everyone agree to add this format? > > octets 2-40: Contains the AppleTalk printer name, with the first > character of the name in octet 2. (AppleTalk printer > names are a maximum of 31 characters.) > > octets 41-48: `00000XXX', where `XXX' is the decimal representation > of the Connection Id. > > > 3.2 Other AppleTalk Mappings > > No other Job MIB objects or parameters can be derived from information > available in the AppleTalk headers > > > 4.0 INTERNET PRINTING PROTOCOL (IPP) > > The Internet Printing Protocol [IPP] supports printing using any one of > the three possible configurations. For configuration 2, the mapping > > > Bergman [page 5] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > defined herein is performed on a server. Otherwise, the mapping is > performed on an agent within the printer. > > 4.1 jmJobSubmissionId Mapped to IPP > > IPP contains a rich set of parameters which allow several methods of > creating the jmJobSubmissionId object. The preferred method is to use > the IPP job-uri attribute as follows: > > octet 1: '4' > > octets 2-40: Contains the IPP job-uri job template attribute. If > the job-uri is less than 40 octets, the left-most > character in the string shall appear in octet position > 2. Otherwise, only the last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. For all three formats, need to add a warning that the range of the IPP "job-id" attribute could exceed 8 characters, so implementors might want to limit the range of IPP "job-id" to not exceed 99999999. > > If the job-uri is not available to the agent, the job-name job template > attribute shall be used. > > octet 1: '?' ***** New format required ? (1 for clients) ***** Yes, '1' is for clients, but it is IPP clients who assign the "job-name", so change '?' to '1'. Or do we have some confusion about what is meant by reserved to clients vs. agents? > > octets 2-40: Contains the IPP job-name job template attribute. If > the job-name is less than 40 octets, the left-most > character in the string shall appear in octet position > 2. Otherwise, only the last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. > > If both the job-uri and the job-name are not available, the job- > originating-user job template attribute shall be used. > > octet 1: '4' I think this should be changed from '4' to '8' (which is also reserved to clients). > > octets 2-40: Contains the IPP job-originating-user job template > attribute. If the job-originating-user name is less > than 40 octets, the left-most character in the string > shall appear in octet position 2. Otherwise, only the > last 39 bytes shall be included. > > octets 41-48: Contains the job-id job template attribute. > > > 4.2 jmJobIndex Mapped to IPP > > The job index (jmJobIndex) assigned by the SNMP job monitoring agent may > be identical to the IPP job-id job template attribute if the agent is > receiving jobs only from a single server or client. If jobs are to be > received from multiple sources, jmJobIndex and job-id must be > independent. ISSUE: Need some discussion here. It would seem to me that an implementation that supports multiple protocols could assign job ids as the jobs come in in any protocol. The jobs that are visible via IPP, could either show all jobs or show only IPP jobs. There is no requirement in IPP that job-ids step by one. So there could be holes in the IPP job-id values, for the implementations that couldn't show jobs from other protocols as IPP jobs. Therefore, I disagree with the last sentence: > If jobs are to be > received from multiple sources, jmJobIndex and job-id must be > independent. If the jmJobIndex is not the same as the IPP job-id attribute, then we may need another jobsubmissionID format, so that a client that knows the IPP "job-id" can find the job. I had hoped that the jmJobIndex could always be the same as the IPP "job-id" so that we wouldn't have to add an extra submission id format in which the "job-id" (an integer) is the input. Though maybe any of the other three ids formats is good enough? > > > > > Bergman [page 6] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > 4.3 Other MIB Objects Mapped to IPP > > MIB Object | IPP Job template attribute > --------------------------+--------------------------------------------- > jmJobOwner | job-originating-user > jmJobKOctetsRequested | job-k-octets > jmJobKOctetsProcessed | job-k-octets-processed > jmJobImpressionsRequested | job-impressions > jmJobImpressionsProcessed | job-impressions-completed > jmJobStateReasons1 | job-state-reasons (note 1) > jmNumberOfInterveningJobs | number-of-intervening-jobs > > Notes: > ------ > 1. JobStateReasons is a bit map described in one object and three > attributes. The IPP condition may change one or more of the bits > in one or more of these Job MIB items. > > > 4.4 The Attribute Group Mapped to IPP > > The following mappings are required if the listed IPP job template > attribute is provided. > > MIB attribute | IPP job template attribute | Data type > ---------------------------+------------------------------+------------- > jobName | job-name | Octet String > documentFormat | document-format | Octet String > jobPriority | job-priority | Integer > jobHoldUntil | job-hold-until | Octet String > sides | sides | Integer Add a note that the mapping is 3 enum values to two integer values > finishing | finishings | Integer > printQualityRequested | print-quality | Integer > printerResolutionRequested | printer-resolution | Integer > jobCopiesRequested | copies | Integer > mediumRequested | media | Octet String > jobSubmissionTime | time-at-pending | Integer Changes to: time-at-submission > jobStartedProcessingTime | time-at-processing | Integer > jobCompletionTime | time-at-completed | Integer > sheetsRequested | job-media-sheets | Integer > jobURI | job-uri | Octet String > jobStateReasonsN | job-state-reasons (note 1) | Integer > physicalDevice | output-device-assigned | Octet String > sheetsCompleted | job-media-sheets-completed | Integer See latest ipp-jmp.doc .pdf that I'll post later today. > > Notes: > ------ > 1. JobStateReasons is a bit map described in one object and three > attributes. The IPP condition may change one or more of the bits > in one or more of these Job MIB items. > > > 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) > > > Bergman [page 7] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > > > 6.0 DOCUMENT PRINTING APPLICATION (DPA) I'll send this later this weekend in your format. > > > 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) > > Novell Distributed Print Services is a DPA based job submission protocol > that conforms to configuration 3. > > > 7.1 jmJobSubmissionId Mapped to NDPS > > NDPS supports the generation of a properly formatted jmJobSubmissionId > for use in the Job MIB. > > > 7.2 jmJobIndex Mapped to NDPS > > NDPS does not provide a value that can be mapped to jmJobIndex. > > > 7.3 Other MIB Objects Mapped to NDPS > > MIB Object | NDPS Parameter > -----------------------+------------------------------------------------ > jmJobOwner | > > > 7.4 The Attribute Group Mapped to NDPS > > The following mappings are required if the listed PJL attribute or > command option is provided. > > MIB attribute | NDPS parameter | Data type > ---------------------------+------------------------------+------------- > jobAccountName | > serverAssignedJobName | > jobName | > jobServiceTypes | > numberOfDocuments | > fileName | > documentName | > jobComment | > documentFormatIndex | > documentFormat | > jobPriority | > jobProcessAfterDateAndTime | > jobHoldUntil | > outputBin | > sides | > finishing | > printQualityRequested | > > > Bergman [page 8] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > printerResolutionRequested | > jobCopiesRequested | > mediumRequested | > jobSubmissionToServerTime | > jobSubmissionTime | > > > 8.0 PRINTER JOB LANGUAGE (PJL) > > PJL [PJL] has been developed by Hewlett-Packard to provide job control > information to the printer and status information to applications, > independent of the PDL. PJL is normally transferred using a traditional > job submission language such as LPR/LPD or NetWare PServer. > > > 8.1 jmJobSubmissionId Mapped to PJL > > PJL has defined the SUBMISSIONID option for the JOB command which > indicates a properly formatted jmJobSubmissionId for use in the Job MIB. > The PJL JOB command is presented at the start of a print job with > options that apply only the attached job. The syntax for this command > option is: > > @PJL JOB SUBMISSIONID = ` `id string' ' > > Driver software that implements this PJL command option must provide the > ` `id string' ' in one of the client version formats specified in the Job > MIB for jmJobSubmissionId. > > For drivers that are not able to create the SUBMISSIONID option, it is > recommended that jmJobSubmissionId format 0 be created by the agent > using the PJL attribute DocOwner or DocOwnerId. > > octet 1: '0' > > octets 2-40: Contains the string associated with DocOwner or > DocOwnerId. If the string is less than 40 octets, the > left-most character in the string shall appear in octet > position 2. Otherwise, only the last 39 bytes shall be > included. If DocOwner or DocOwnerId cannot be obtained, > this field shall be blank. > > octets 41-48: Contains the value of jmJobIndex associated with the > job. > > > 8.2 jmJobIndex Mapped to PJL > > PJL does not provide a value that can be mapped to jmJobIndex. > > > 8.3 The Attribute Group Mapped to PJL > > > > Bergman [page 9] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > The following mappings are required if the listed PJL attribute or > command option is provided. > > MIB attribute | PJL attribute or command option | Data type > ----------------------+----------------------------------+-------------- > jobOwner | DocOwner or DocOwnerId attribute | Octet String > serverAssignedJobName | DocName attribute or the command | Octet String > | @PJL JOB Name = ` `string' ' | Octet String > submittingServerName | SrcServerName attribute | Octet String > jobOriginatingHost | SrcPort attribute | Octet String > queueNameRequested | SrcQ attribute | Octet String > fileName | JobFName attribute | Octet String > jobComment | JobDesc attribute | Octet String > jobSubmissionTime | TimeSubmit attribute | Octet String > > > 9.0 POSTSCRIPT > > > 10.0 NETWARE PSERVER > > The NetWare PServer job submission protocol is implemented in a client- > server-printer system on the server to printer link as defined in > configuration 3. > > > 10.1 jmJobSubmissionId Mapped to PServer > > octet 1: '?' ***** New format req'd ??? ***** > > octets 2-40: Contains the Directory Path Name as recorded by the > Novell File Server in the queue directory. If the > string is less than 40 octets, the left-most character > in the string shall appear in octet position 2. > Otherwise, only the last 39 bytes shall be included. > > octets 41-48: `000XXXXX' The ASCII representation of the Job Number > as per the queue directory. > > > 10.2 jmJobIndex Mapped to PServer > > The job index (jmJobIndex) is assigned by the SNMP job monitoring agent > and is independent of the Job Number assigned by the NetWare File > Server. This will allow the SNMP agent to track jobs received from > multiple sources. > > > 10.3 The Attribute Group Mapped to PServer > > The following mappings are required if the listed PServer parameter is > provided in the Novell File Server queue directory. > > > > Bergman [page 10] > > > Job Submission Protocol Mapping Recommendations Oct 10, 1997 > > > > MIB attribute | PServer parameter | Data type > ---------------------------+-----------------------------+-------------- > jobOwner | Client Id Number | Integer > serverAssignedJobName | Job File Name | Octet String > queueNameRequested | Queue Id | Integer > physicalDevice | Server Id Number | Integer > jobComment | Job Description | Octet String > jobPriority | > jobProcessAfterDateAndTime | Target Execution Time | Octet String > jobHoldUntil | > jobCopiesRequested | Number of Copies | Integer > mediumRequested | Form Name | Octet String > jobSubmittedToServerTime | Job Entry Time | Octet String > > > 11.0 NETWARE NPRINTER or RPRINTER > > The NetWare NPrinter/RPrinter protocol was designed to transfer print > data from a Novell File Server to a printer attached directly to a local > port (e.g. parallel or serial) on a PC. NPrinter/RPrinter is an > extremely lightweight printing protocol. Consequently, no information > required by the Job Monitoring MIB is provided and a meaningful > jmJobSubmissionId cannot be generated. > > It is recommended that an additional job submission layer, such as PJL > or another vendor private protocol, be included on top of > NPrinter/RPrinter to provide the required information. The mapping > should then be performed according to the recommendations of the higher > layer submission protocol. > > > 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL > > > 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) > > > 14.0 REFERENCES > > [IPP] The Internet Printing Protocol RFC XXXX, Model RFC XXXX > > [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document. > > [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational > document. > > [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard > part number 5021-0328. > > [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document. > > > > > > Bergman [page 11] > > From harryl at us.ibm.com Sun Oct 26 21:16:54 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Boulder Weather Message-ID: <3.0.1.32.19971024142928.01117d50@garfield> I've had a few questions about the weather. Anyone trying to arrive Sat= urday probably had quite a difficult time. Two feet of snow fell in most part= s. Today (Sunday) is warm and sunny. Roads are clear. Forecast is high's in the = 50's, lows in the 20's all week. Should be a great week! Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Tue Oct 28 17:13:56 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> FWD: Std for testing MIB interoperability: I-D Message-ID: <3.0.1.32.19971028141356.01016560@garfield> Please send any comments back directly to the requester on this important IETF standard on MIB Interoperability Testing. Thanks, Tom >Return-Path: >X-Sender: fred@stilton.cisco.com >Date: Tue, 28 Oct 1997 07:20:43 PST >To: ABallardie@acm.org, John_Du@ccm.jf.intel.com, Robin_Iddon@3mail.3com.com, > S.Kille@isode.com, Scott-Isaacson@novell.com, abierman@cisco.com, > ansmith@extremenetworks.com, ansmith@ix.netcom.com, aprasad@cisco.com, > arun@cisco.com, bcoutts@casc.com, bernarda@microsoft.com, > bernst@softsw.ssw.com, bpenteco@boi.hp.com, bstewart@cisco.com, > buccic@ngc.com, bvroman@usr.com, bwagner@digprod.com, > cchung@tieo.saic.com, cheryl@empiretech.com, chrisw@iwl.com, > clouston@cisco.com, cochrane@ctron.com, cwk@onramp.net, cwk@verio.net, > daniele@zk3.dec.com, davef@newbridge.com, dhaskin@baynetworks.com, > dino@cisco.com, don@lexmark.com, dromasca@madge.com, > emking@lexmark.com, faye@3com.com, faye@baynetworks.com, > fayely@3com.com, fc@network.COM, fred@cisco.com, gbjones@mitre.org, > glenn@aic.co.jp, glennz@microsoft.com, gmalkin@baynetworks.com, > greddy@usr.com, greene@nexen.com, greene@ultranet.com, > groeck@cisco.com, gvm@att.com, harrie.hazewinkel@jrc.it, > harryl@us.ibm.com, hastings@cp10.es.xerox.com, hengstum@cs.utwente.nl, > james@newbridge.com (james watt), jaime@eng.paradyne.com, > jburruss@windata.com, jeff@redbacknetworks.com, > jeyai@future.futsoft.com, jh@lohi.dat.tele.fi, jjk@tiac.net, > jjohnson@cisco.com, jkm@underscore.com, jluciani@baynetworks.com, > joelgyllen@aol.com, johnf@hprnd.rose.hp.com, jweinstock@gic.gi.com, > jychu@watson.ibm.com, kaj@cc.bellcore.com, kashef@ctron.com, > kasten@ftp.com, kdegraaf@isd.3com.com, kdlee@vnet.ibm.com, > kellerman@nls.com, kennethw@vnet.ibm.com, kfrisa@fore.com, > khasin@BrocadeComm.COM, khasin@BrocadeComm.COM, kjones@baynetworks.com, > kzm@cisco.com, lahaye@ctron.com, levi@snmp.com, lpyoung@lexmark.com, > luciani@baynetworks.com, mbaugher@intel.com, mcmaster@cisco.com, > mike_noto@net.com, mspiegel@cisco.com, n.brownlee@auckland.ac.nz, > ned.freed@innosoft.com, noto@net.com, p.anderson@cablelabs.com, > pcalhoun@usr.com, pras@cs.uwtente.nl, rbergman@dpc.com, > remoore@us.ibm.com, rlsmith@nb.ppd.ti.com, robin_iddon@3mail.3com.com, > ross@routerware.com, rpresuhn@bmc.com, rpresuhn@peer.com, > rturner@sharplabs.com, rui.meneses@jrc.it, rwaterma@msn.com, > rwoundy@continental.com, saperia@networks.bgs.com, > sbush@ittc.ukans.edu, sbush@tisl.ukans.edu, schoenw@cs.utwente.nl, > scott_isaacson@novell.com, sgudur@bmc.com, snaudus@usrva.co, > sonishi@baynetworks.com, sroberts@farallon.com, sturm@emi-summit.com, > swillis@baynetworks.com, szilles@mv.us.adobe.com, > thalerd@eecs.umich.edu, tkuo@eos.ncsu.edu, waldbusser@ins.com, > waynet@netsuite.com, wedgeg@mcimail.com, wsawyer@lancity.com, > dperkins@scruznet.com >From: Fred Baker >Subject: Re: I-D ACTION:draft-iesg-odell-mibtest-00.txt >Cc: poised@tis.com, iesg@ietf.org > >Folks: > >If you are on the "to" line here, I found your email address in a MIB >internet draft. While you are certainly not the only folks I want to hear >from on this, I would be interested in your comments on the following >document. Let's use the POISED list for the discussion. Please feel free to >involve others whom you suspect would be interested. > >The question before the house is "what does it mean to test a MIB for >interoperability and completeness of implementation?". I would suggest that >you read the portion of RFC 2026 describing the requirements for Draft >Standard, which this is intended to be an implementation of. > >The IESG expects to open an extended last call momentarily, after we have >reviewed the document ourselves, and subsequent to that last call, to use >the document as guidance in the future, as a BCP. I am asking for your >early review so that if it's not going to be acceptable in its present >form, we can save the time of the larger community. > >Thanks. > > >At 9:47 AM -0500 10/28/97, Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the IETF Steering Group Working Group of the >>IETF. >> >> Title : MIB Interoperability Testing >> Author(s) : M. O''Dell >> Filename : draft-iesg-odell-mibtest-00.txt >> Pages : 4 >> Date : 27-Oct-97 >> >> This document specifies the IESG's interpretation of the Internet >> Standards Process for the progression of SNMP MIB specifications to >> the Draft Standard level of maturity. It discusses the rationale for >> this interpretation and details the testing which is used to satisfy >> the advancement criteria. >> >>Internet-Drafts are available by anonymous FTP. Login wih the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-iesg-odell-mibtest-00.txt". >>A URL for the Internet-Draft is: >>ftp://ds.internic.net/internet-drafts/draft-iesg-odell-mibtest-00.txt >> >>Internet-Drafts directories are located at: >> >> Africa: ftp.is.co.za >> >> Europe: ftp.nordu.net >> ftp.nis.garr.it >> >> Pacific Rim: munnari.oz.au >> >> US East Coast: ds.internic.net >> >> US West Coast: ftp.isi.edu >> >>Internet-Drafts are also available by mail. >> >>Send a message to: mailserv@ds.internic.net. In the body type: >> "FILE /internet-drafts/draft-iesg-odell-mibtest-00.txt". >> >>NOTE: The mail server at ds.internic.net can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>Content-Type: text/plain >>Content-ID: <19971027172016.I-D@ietf.org> >> >>[This attachment must be fetched by mail. >>Open the stationery below and send the resulting >>message to get the attachment.] >>Attachment converted: Internal:Get I-D ACTION-draft-iesg-odell (EuSn/CSOm) >>(00011ABD) >>Content-Type: Message/External-body; >> name="draft-iesg-odell-mibtest-00.txt"; >> site="ds.internic.net"; >> access-type="anon-ftp"; >> directory="internet-drafts" >> >>[This attachment must be fetched by ftp. >> Open the document below to ask your ftp client to fetch it.] >>Attachment converted: Internal:Get draft-iesg-odell-mibtest-00 (AURL/Arch) >>(00011ABE) >>Content-Type: text/plain >>Content-ID: <19971027172016.I-D@ietf.org> > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > "A beautiful idea has a much greater chance of being a correct idea > than an ugly one." > -- Roger Penrose, "The Emperor's New Mind", 1989 > > > > From cmanros at cp10.es.xerox.com Fri Oct 31 18:12:02 1997 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:00:11 2009 Subject: JMP> PING for Los Angeles Meeting December 1-5 Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield> Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From don at lexmark.com Mon Nov 3 16:02:50 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:11 2009 Subject: JMP> December Meeting in LA Message-ID: <199711032102.AA28468@interlock2.lexmark.com> Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, here's my first pass at a meeting schedule for the December meeting. Dec 1, 2 - 1394 Printing Dec 3 - IPP Dec 4 - SENSE Dec 5 - FIN I will issue a final agenda on or about November 24th. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From harryl at us.ibm.com Thu Nov 6 14:40:53 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB charter Message-ID: <199711032102.AA28468@interlock2.lexmark.com> Could someone please explain on what basis the Job MIB charter was reje= cted by the IETF? Is the IETF, in general, forcing all new MIB definitions to b= e informational, only? If not, why have they singled out the Job MIB for = this type of treatment? I am afraid that the IETF may have rejected the job MIB, out of hand, = because the Printer MIB's original charter prohibited working on Jobs, Fonts et= c... This was intentional, to limit our scope (AT THE TIME) so we could get = the base printer MIB done. If this is the case, then we and the IETF have fallen= into a trap that, inappropriately, resulted from these good intentions. I'm having a difficult time understanding why the Job MIB is not charte= red and would like an explanation. Harry Lewis - IBM Printing Systems = From chrisw at iwl.com Thu Nov 6 19:33:16 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB charter In-Reply-To: <5030300013781926000002L062*@MHS> Message-ID: On Thu, 6 Nov 1997, Harry Lewis wrote: > > I'm having a difficult time understanding why the Job MIB is not chartered and > would like an explanation. I went back through the email archives and found what I think was intended to be the definitive answer. See the email sent by Harald Alvestrand to the PWG mailing list that is dated 8/21/97. From harryl at us.ibm.com Thu Nov 6 20:20:36 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> ImpressionsCompleted Message-ID: We've stumbled across an area in the Job MIB that seems to be unduly confusing. This has to do with jmJobImpressionsRequested and Completed.= This seems to have crept in on the latest draft yet I didn't see revisi= on marks... or, I somehow missed them. Below, are the excerpts. The parts I have preceded with * are the issue= From harryl at us.ibm.com Fri Nov 7 09:57:47 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> ImpressionsCompleted Message-ID: Somehow, a couple messages I sent yesterday got truncated. This was one= of them. Here is a resend. Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/07/97= 07:49 AM --------------------------- Harry Lewis 11/06/97 06:13 PM To: jmp@pwg.org@internet cc: From: Harry Lewis/Boulder/IBM @ IBMUS Subject: ImpressionsCompleted We've stumbled across an area in the Job MIB that seems to be unduly confusing. This has to do with jmJobImpressionsRequested and Completed.= This seems to have crept in on the latest draft yet I didn't see revisi= on marks... or, I somehow missed them. Below, are the excerpts. The parts I have preceded with * are the issue= From jkm at underscore.com Fri Nov 7 10:43:34 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: ImpressionsCompleted In-Reply-To: Message-ID: Harry, It appears we may have some kind of bizarre problem on the PWG list server whereby your message gets truncated when being sent out to JMP list members. Besides resending your message to the JMP list, you also sent it to several individuals, including myself. I seem to have received the complete message in my personal copy, leading us to believe we have some problem on the PWG list server. We're working the issue now. Stay tuned. In the meantime, I am attaching my private copy of your message (as quoted text) to the list in the hopes that others can at least see this version. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Somehow, a couple messages I sent yesterday got truncated. This was one of > them. Here is a resend. > > Harry Lewis - IBM Printing Systems > > ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/07/97 07:49 AM > --------------------------- > > Harry Lewis > 11/06/97 06:13 PM > To: jmp@pwg.org@internet > cc: > From: Harry Lewis/Boulder/IBM @ IBMUS > Subject: ImpressionsCompleted > > We've stumbled across an area in the Job MIB that seems to be unduly > confusing. This has to do with jmJobImpressionsRequested and Completed. > This seems to have crept in on the latest draft yet I didn't see revision > marks... or, I somehow missed them. > > Below, are the excerpts. The parts I have preceded with * are the issue. > > jmJobImpressionsRequested OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total size in number of impressions of the document(s) > being requested by this job to produce. > *In computing this value, the server/device SHALL not include the > *multiplicative factors contributed by (1) the number of document > *copies, and (2) the number of job copies, independent of whether > *the device can process multiple copies of the job or document > *without making multiple passes over the job or document data and > *independent of whether the output is collated or not. Thus the > *server/device computation is independent of the implementation." > ::= { jmJobEntry 7 } > > jmJobImpressionsCompleted OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The current number of impressions completed for this job so > far. For printing devices, the impressions completed includes > interpreting, marking, and stacking the output. For other types > of job services, the number of impressions completed includes > the number of impressions processed. > > *For implementations where multiple copies are produced by the > *interpreter with only a single pass over the data, the final > *value SHALL be equal to the value of the > *jmJobImpressionsRequested object. For implementations where > *multiple copies are produced by the interpreter by processing > *the data for each copy, the final value SHALL be a multiple of > *the value of the jmJobImpressionsRequested object. > > NOTE - See the impressionsCompletedCurrentCopy and > pagesCompletedCurrentCopy attributes for attributes that are > reset on each document copy. > > NOTE - The jmJobImpressionsCompleted object can be used with the > jmJobImpressionsRequested object to provide an indication of the > relative progress of the job, provided that the multiplicative > factor is taken into account for some implementations of > multiple copies." > ::= { jmJobEntry 8 } > > I really don't have a problem with the wording associated with > jmJobImpressionsRequested, but have included it for background. The > issue is with the * words in jmJobImpressionsCompleted. > > We CANNOT have and either/or definition here. We must specify who > does the multiplication of impressions where there are copies involved. > > In our labs, we believe the only viable alternative for ImpressionsCompleted > is for the JobMIB agent to count every impression as it is stacked. So, if > there were 3 copies and jmJobImpressionsRequested was 5 (that means 5 > impressions per copy, by definition), then, if 2 copies has just completed, > the value for jmJobImpressionsCompleted would be 10. Our main reasons for > believing this are: > > 1. Two ways of counting something leads to confusion in the MIB > > 2. Counting completed impressions should have nothing to do with how > many squirrels are in the cage or which way or how hard they are > running to make impressions come out. > > 3. Even though the job MIB has "impressionsCompletedCurrentCopy(113)" > it does not distinguish between collated and uncollatted copies. > > 4. If the printer is handling uncollated copies, and the agent is behaving > such that the final value of jmJobImpressionsCompleted is expected to > equal jmJobImpressionsRequested (the "wrong" way), neither variable > (ImpressionsCompleted or ImpressionsCompletedCurrentCopy will "bump" > until at least one impression has stacked all copies. If the job was 3 > copies of a 5 impression job, the printer could stack 10 impressions, > then jam, abort or whatever and the accounting application would pick > up a final count of zero impressions completed. > > I suggest the * wording in jmJobImpressionsCompleted be replaced with > "Impressions SHALL be counted as they are completed such that the final > value is a multiple of the value of the jmJobImpressionsRequested object." > > Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Fri Nov 7 11:51:49 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB charter In-Reply-To: Message-ID: <3.0.1.32.19971107085149.015a5ca0@garfield> Chris, Here is the 8/21/97 mail to the PWG that I think you are referring to from Harald. Correct? At the end he says: >I've scheduled the Job MIB on my list of things to look at; let's hope >things get sorted out correctly! But I think that he hasn't. He also lists several reasons why he thinks the IESG wouldn't standardize things: >The IETF should, IMHO, NOT standardize things in the following cases: > 1. >- The proposal is not going to be used in or around the Internet 2. >- The proposal cannot be evaluated by IETF experts for lack of competence 3. >- The proposal cannot be modified if the IETF community thinks that it > needs modification 4. >- The proposal does not fit with IETF policy > >The last one is a flexible point again; some examples include requiring use of >patented or encumbered technology when freely available alternatives >exist, mandating use of cleartext passwords, standardizing very complex >protocols when simpler solutions solve most of the problem. >It's a judgment call. It would be helpful to know which of the above reasons applies to the Job Monitoring MIB [I've added numbers to them] Discussion about reason 1 (The proposal is not going to be used in or around the Internet): MIBs in general are still being standardized by the IETF, if they have to do with network management, i.e., with keeping the Internet (and intranets) running. The problem is that neither the Printer MIB nor the Job Monitoring MIB help with keeping the network itself running, they are MIBs involving the hosts at the end points. Same for the Host Resources MIB (which has been re-activiated because the Printer MIB needs it). However, the Printer MIB and the Host Resources MIB do seem to be still on the IETF standards track. Discussion about reason 2 (The proposal cannot be evaluated by IETF experts for lack of competence): David Perkins did a 5 hour detailed review. We incorporated all his suggestions, except for the one he felt was the most important one (split the attribute table into two tables, one for the integer values and one for the string values). We felt there was some value to have the two together in the same table, since there are a number of attributes that have both integer and string representations. Discussion about reason 3 (The proposal cannot be modified if the IETF community thinks that it needs modification): The JMP project has no problem with making any changes suggested by the IETF (except see reason 2). Discussion about reason 4 (The proposal does not fit with IETF policy): Perhaps the current policy is "no more application MIBs" and the Job Monitoring MIB is an application MIB? Tom At 16:33 11/06/1997 PST, Chris Wellens wrote: > > > > >On Thu, 6 Nov 1997, Harry Lewis wrote: > >> >> I'm having a difficult time understanding why the Job MIB is not chartered and >> would like an explanation. > >I went back through the email archives and found what I think >was intended to be the definitive answer. See the email >sent by Harald Alvestrand to the PWG mailing list that is dated >8/21/97. > > >Return-Path: >From: Harald.T.Alvestrand@uninett.no >To: JK Martin >Cc: pwg@pwg.org >Subject: Re: PWG> The Printer Working Group as its own standards body >Date: Thu, 21 Aug 1997 01:02:06 PDT >Sender: owner-pwg@pwg.org > >Jay, >good points. > >The relationship between the IETF and non-IETF groups has always been >worrisome; in some cases, we have seen things that looked as if someone >outside the IETF wanted to use the IETF as a tool to get the "community" >to endorse a position that couldn't be sold on its own merits, AND place >the IETF in a position where it couldn't insist on obvious weaknesses >in the protcol being repaired. >The discussions around Sun RPC and NFS focused around this issue; it is >also one of the things currently making the S/MIME debate so strident. > >In other cases, the IETF community knows that it does not add significant >value to the process of getting a standard done; the IETF is aggressively >uninterested in specifying the number of pins on serial plugs or the >precedence of operators in the C language, to name two instances, although >both efforts are obviously important to our user community. >Recent instances are our non-involvement in the SET payment protocol and >our closing down of work on HTML. >(This is of course a fluid point, since the set of people in the IETF >community, >and therefore its expertise, changes over time - after all, the IPP *is* >part of the IETF community.) > >The standards process is the process the IETF has that places a stamp >of approval on specifications. Obviously, we have to be careful what we >use it for. > >The IETF should, IMHO, NOT standardize things in the following cases: > >- The proposal is not going to be used in or around the Internet >- The proposal cannot be evaluated by IETF experts for lack of competence >- The proposal cannot be modified if the IETF community thinks that it > needs modification >- The proposal does not fit with IETF policy > >The last one is a flexible point again; some examples include requiring use of >patented or encumbered technology when freely available alternatives >exist, mandating use of cleartext passwords, standardizing very complex >protocols when simpler solutions solve most of the problem. >It's a judgment call. > >Since the bandwidth of those who have to do the judging (the IESG) is limited, >and since we know we're not infallible, we don't want this process to limit >publication of documents, even though we don't necessarily agree with them. > >Therefore, RFC publication, which has a reputation as a stable reference, >is available for non-IETF documents in "informational" form. We sometimes >ask for review of informationals, but only attempt to block publication of >them when we regard the content as misleading (such as labelling itself >"Internet Standard") or that publication would lead to confusion in the >community (such as having a fight about 2 approaches in a WG, and the >"loser" being published before the "standard"). > >I've scheduled the Job MIB on my list of things to look at; let's hope >things get sorted out correctly! >Regards, > > Harald T. Alvestrand > > > > > > From harryl at us.ibm.com Fri Nov 7 12:13:09 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB charter In-Reply-To: Message-ID: <3.0.1.32.19971107085149.015a5ca0@garfield> Chris, when I asked for an explanation of the status of the Job MIB charter, you pointed to a note from Harald Alvestrand (8/21/97). In his note (appended, below), Harald explains IETF philosophy, constraints, direction etc. which is very helpful. In summary, Harald tells us that the IETF, like any organization, must limit their scope to be effective - a concept with which I fully agree. You offer Harald's message as the definitive IETF response to the Job M= IB but, at the end of his note , Harald states "I've scheduled the Job MIB on my list of things to look at; let's hope= things get sorted out correctly!" Harald cited several reasons why a charter may be denied, including - The proposal is not going to be used in or around the Internet - The proposal cannot be evaluated by IETF experts for lack of competen= ce - The proposal cannot be modified if the IETF community thinks that it needs modification - The proposal does not fit with IETF policy These are not the only points Harald makes, there are others, such as bandwidth of the IETF advisors. If Harald doesn't have time to address the Job MIB, that's understandab= le. The IETF area directors certainly have as much reason to be "swamped" as the rest of us. And, I admit, to an area director, "Print Job MIB" may not seem as central an issue as "Web security". I can sympathize with the dynamics of the priority stack, here. But... then what are we to do? All I am asking for is an explanation of the current status of the Job = MIB charter and, if rejected, WHY. In helping the IETF make a determination, I think it must be pointed ou= t how the Job MIB relates to the Internet and other IETF standards activities= From harryl at us.ibm.com Fri Nov 7 12:22:11 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> IMPRESSIONS COMPLETE (again) Message-ID: <3.0.1.32.19971107085149.015a5ca0@garfield> I apologize, especially since this is a long message, but I'm re-sendin= g due to truncation problems. We've stumbled across an area in the Job MIB that seems to be unduly confusing. This has to do with jmJobImpressionsRequested and Completed.= This seems to have crept in on the latest draft yet I didn't see revisi= on marks... or, I somehow missed them. Below, are the excerpts. I've used * to highlight the issues. jmJobImpressionsRequested OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total size in number of impressions of the document(s) being requested by this job to produce. *In computing this value, the server/device SHALL not include t= he *multiplicative factors contributed by (1) the number of docume= nt *copies, and (2) the number of job copies, independent of wheth= er *the device can process multiple copies of the job or document *without making multiple passes over the job or document data a= nd *independent of whether the output is collated or not. Thus th= e *server/device computation is independent of the implementation= ." jmJobImpressionsCompleted OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other type= s of job services, the number of impressions completed includes the number of impressions processed. *For implementations where multiple copies are produced by the *interpreter with only a single pass over the data, the final *value SHALL be equal to the value of the *jmJobImpressionsRequested object. For implementations where *multiple copies are produced by the interpreter by processing *the data for each copy, the final value SHALL be a multiple of= *the value of the jmJobImpressionsRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with th= e jmJobImpressionsRequested object to provide an indication of th= e relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." I really don't have a problem with the wording associated with jmJobImpressionsRequested, but have included it for background. The issue is with the * words in jmJobImpressionsCompleted. We CANNOT have and either/or definition here. We must specify who does the multiplication of impressions where there are copies involved.= In our labs, we believe the only viable alternative for ImpressionsComp= leted is for the JobMIB agent to count every impression as it is stacked. So,= if there were 3 copies and jmJobImpressionsRequested was 5 (that means 5 impressions per copy, by definition), then, if 2 copies has just comple= ted, the value for jmJobImpressionsCompleted would be 10. Our main reasons f= or believing this are: 1. Two ways of counting something leads to confusion in the MIB 2. Counting completed impressions should have nothing to do with how many squirrels are in the cage or which way or how hard they are running to make impressions come out. 3. Even though the job MIB has "impressionsCompletedCurrentCopy(113)" it does not distinguish between collated and uncollatted copies. 4. If the printer is handling uncollated copies, and the agent is behav= ing such that the final value of jmJobImpressionsCompleted is expected t= o equal jmJobImpressionsRequested (the "wrong" way), neither variable (ImpressionsCompleted or ImpressionsCompletedCurrentCopy will "bump"= until at least one impression has stacked all copies. If the job was= 3 copies of a 5 impression job, the printer could stack 10 impressions= , then jam, abort or whatever and the accounting application would pic= k up a final count of zero impressions completed. I suggest the * wording in jmJobImpressionsCompleted be replaced with "Impressions SHALL be counted as they are completed such that the final= value is a multiple of the value of the jmJobImpressionsRequested obje= ct." Harry Lewis - IBM Printing Systems = From chrisw at iwl.com Fri Nov 7 12:17:49 1997 From: chrisw at iwl.com (Chris Wellens) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB charter In-Reply-To: <5030300013861249000002L092*@MHS> Message-ID: I believe it was shortly after Harald sent that message that he and Keith discussed it and sent private email to Lloyd and I that the answer was no. We then informed the group. I did not save a copy of the private email; I don't have the exact dates; I don't remember every single detail. I spent time digging up Harald's original message, because some one had stated that the rationale had not been put forward, and in fact, it had. I think the matter is closed. ----------------------------------------------------------------------------- --==--==--==- Chris Wellens President & CEO ==--==--==--= Email: chrisw@iwl.com Web: http://www.iwl.com/ --==--==--==- InterWorking Labs, Inc. 244 Santa Cruz Ave, Aptos, CA 95003 ==--==--==--= Tel: +1 408 685 3190 Fax: +1 408 662 9065 ----------------------------------------------------------------------------- From lpyoung at lexmark.com Fri Nov 7 12:41:34 1997 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:11 2009 Subject: JMP> JOB MIB Charter - Why? Message-ID: <199711071741.AA18620@interlock2.lexmark.com> I want to turn this discussion around 180 degrees. Why do you want to be chartered by the IETF? This is probably heresy coming from an IETF working group chairman but I really do not see any advantage for the JOB MIB to be chartered by the IETF. All that seems to matter is that an RFC number is attached to the JOB MIB which will happen by it being informational. I do not see the level (Informational, Proposed, Draft, etc.) that a MIB is at making any difference in whether a MIB is successful in the marketplace. Success in the marketplace is determined by a lot of factors more than merely whether the MIB is on an IETF Standards Track. Regards, Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C14L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From harryl at us.ibm.com Fri Nov 7 17:37:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Standard direction Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Appoligies to Harald and Chris. I found the concise IETF position I was= searching for. It was originally part of a PMP topic, which is why I ha= d difficulty back referencing. > With regard to the Job MIB, it seems clear that: > > - The IETF has no consensus position that it is a Good Thing to deplo= y > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the id= ea > that all users need MIB access; we do not want to bring this idea i= nto > that process, for fear of delaying it further. > > - The IETF has consensus that there is no need for all MIBs to be > Internet standards. Informational MIBs, or MIBs developed by other > organizations, are Good Things; the IETF can sometimes assist in th= eir > reviews, without necessarily taking responsibility. > > - Given the two positions above, we think that it's better for the > Job MIB to be submitted to the IETF as an external document and giv= en > Informational status as a protocol under PWG control. In Boulder, we discussed the fact that Experimental may carry more "wei= ght" than Informational. In Boulder, we felt we only had 2 weeks to resolve = this, which is why I brought it up. If we go strictly the Informational route= , we will register the Job MIB under the new PWG enterprise OID. Another thing I think this decision will force that we are really not addressing is the last bit of Harald's statement "as a protocol under = PWG control" Do we know exactly what this means? Harry Lewis - IBM Printing Systems = From jkm at underscore.com Fri Nov 7 18:15:47 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Standard direction In-Reply-To: Job MIB Standard direction> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Harry Lewis wrote: > Another thing I think this decision will force that we are really not > addressing is the last bit of Harald's statement "as a protocol under PWG > control" Do we know exactly what this means? > > Harry Lewis - IBM Printing Systems Doesn't this mean that the PWG advertises the protocol and retains all related documents in a publicly available repository, and that the PWG maintains authoritative control on the specifications? Are there other issues? Do you think the PWG is not currently able to do these things? If not, what must be done to make this happen, assuming the PWG desires to do this? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jkm at underscore.com Fri Nov 7 18:26:31 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> JOB MIB Charter - Why? In-Reply-To: JOB MIB Charter - Why?> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> [Given the general nature of this thread, I have also cc:'d the general PWG mailing list.] This statement will come as no surprise to those PWG folks who've been around for a while. Having a bonafide "IETF standard" seems to foster the perception that the standard is "real" and "genuine" in one or more ways, although I think everyone will be hard pressed to explain exactly why that is. IMHO, as long as a publicly available document repository exists for interested parties to extract related documents, a "standard" can be produced by anyone and used by anyone (assuming copyrights aren't a problem, of course). If a given industry decides to align itself towards delivering products based around a set of standards, it should not matter who or what produces that standard. Customers are interested in solutions, not standards. I know this sounds like Motherhood-and-Apple-Pie, but some folks seem to think otherwise, based on various postings on PWG mailing lists. I personally see no reason for the PWG's JMP effort to be sanctioned by the IETF. Instead, JMP should serve as the very first PWG-based standard published in the printer industry. What problems do people see with this position? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- lpyoung@lexmark.com wrote: > > I want to turn this discussion around 180 degrees. Why do you > want to be chartered by the IETF? This is probably heresy coming > from an IETF working group chairman but I really do not see any > advantage for the JOB MIB to be chartered by the IETF. All that > seems to matter is that an RFC number is attached to the JOB MIB > which will happen by it being informational. I do not see the > level (Informational, Proposed, Draft, etc.) that a MIB is at > making any difference in whether a MIB is successful in the > marketplace. Success in the marketplace is determined by a > lot of factors more than merely whether the MIB is on an > IETF Standards Track. > Regards, > Lloyd > ------------------------------------------------------------ > Lloyd Young Lexmark International, Inc. > Senior Program Manager Dept. C14L/Bldg. 035-3 > Strategic Alliances 740 New Circle Road NW > internet: lpyoung@lexmark.com Lexington, KY 40550 > Phone: (606) 232-5150 Fax: (606) 232-6740 From harryl at us.ibm.com Fri Nov 7 18:49:55 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> JMP Oct. MIns Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Will be posted .../jmp/jmp-1097.txt, pdf, meanwhile see attached (same)= Minutes of the Job MIB meeting in Boulder, CO October 31, 1997 Attendees Ron Bergman - DataProducts Carlos Cantu - IBM Dennis Carney - IBM Lee Farrell - Canon Jeff Haemer - QMS Tom Hastings - Xerox Scott Isaacson - Novell David Kellerman - Northlake Software Harry Lewis - IBM Printing Systems Jay Martin - Underscore Kathy Melton - IBM Ryan Nguyen - IBM Jerry Podojil - Genicom Stuart Rowley - Kyocera Yuyi Sacchi - Japan Computer Industry Jamsie Treppendahl - IBM 1. Ron Bergman (chair) reviewed editorial comments from the 10/27 e-mail - all were accepted 2. A list of recommendations, submitted by Tom Hastings was reviewed. - Tom recommended adding Job-state-message natural language attribut= e * Accepted - Tom recommended adding the choice of octet string vs. displaystring for jobCodedCharSet so either the IANA register printer MIB values can be used or the IANA MIME types can be used. *Dave Kellerman indicated choice would over unnecessarily burden the client application. Harry Lewis would like to stay with enums= if only 1 is chosen. Topic to be further discussed on mailing lis= t. - Tom recommended adding a natural language attribute for the job. *Tom will write up exact text and circulate on the mailing list. 3. Standards track vs. Informational. There is still consternation over the fact that the Job MIB charter nev= er seems to have evolved under the IETF. There is a view that our efforts should have been directed by the Management rather than Applications ar= ea, in which case the IETF may have looked more favorably on our MIB. It is= noted that the Printer MIB may actually be more widely deployed than an= y other MIB in the IETF! (many printers per one router). Part of the discussion related to the fate of the Printer MIB, also. Randy Turner indicated, during an earlier PMP discussion, that he would= still like to see the Printer and Job MIBs become IETF standards and fe= els that Experimental is a more appropriate and fruitful route than informa= tional. We need to get in touch with the Area Directors of both Management and Applications and have an IETF decision made. Two week deadline to resol= ve else submit as informational RFC. Also, find out what area is guiding t= he hrMIB, today, and who is heading that project. If we go the Informational route we will register the Job MIB under the= new PWG OID as follows: PWG OID =3D ... Private.Enterprises.1699 so the Job MIB will be ... Private.Enterprises.1699.1. The first assignment of the job mib will be ... Private Enterprises.1699.1.1 4. Mapping document. - LPR/LPD - Header of data file contains host name. Typically does get passed to controller. Used to create jmJobSubmissionID format 9. (See Ron's proposal). In peer-to-peer environments, the host name is typically derived from the client workstation. In client/server the host name is usually that of the server. - We decided to make jmJobSubmissionID format 9 ONLY apply to LPR - We added format A for Apple Talk. - The IPP jmJobSubmissionID format is derived directly from the printer URL. There are no other alternatives. By definition, because IPP is bidirectional, it benefits from having the jmJobIndex returned via IPP during submission. - IPDS - Harry will investigate possible mapping or changes to IPDS to support the Job MIB - NPDS - Provides jmJobSubmissionID. Does not map to jmJobIndex. - PJL - Implementation note. JobID table entry is likely to be created when the up front PJL has been parsed in well behaved, coordinated job submission systems. Harry Lewis - IBM Printing Systems = From WWagner at digprod.com Fri Nov 7 18:50:27 1997 From: WWagner at digprod.com (Wagner, William) Date: Wed May 6 14:00:11 2009 Subject: JMP> JOB MIB Charter - Why? Message-ID: <199711071741.AA18620@interlock2.lexmark.com> I agree with Jay's basic contention. I further suggest that this path would allow the industry to specify what is most reasonable for its products (avoiding imposition of inapplicable constraints). Further, my reading of Harald's message suggests that this is in fact just what he is suggesting, and is in keeping with the current IETF approach. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, November 07, 1997 6:27 PM > To: lpyoung@lexmark.com > Cc: jmp@pwg.org; Mailing List PWG > Subject: Re: JMP> JOB MIB Charter - Why? > > [Given the general nature of this thread, I have also cc:'d the > general PWG mailing list.] > > This statement will come as no surprise to those PWG folks who've > been around for a while. > > Having a bonafide "IETF standard" seems to foster the perception that > the standard is "real" and "genuine" in one or more ways, although I > think everyone will be hard pressed to explain exactly why that is. > > IMHO, as long as a publicly available document repository exists for > interested parties to extract related documents, a "standard" can > be produced by anyone and used by anyone (assuming copyrights aren't > a problem, of course). > > If a given industry decides to align itself towards delivering > products based around a set of standards, it should not matter > who or what produces that standard. > > Customers are interested in solutions, not standards. I know this > sounds like Motherhood-and-Apple-Pie, but some folks seem to think > otherwise, based on various postings on PWG mailing lists. > > I personally see no reason for the PWG's JMP effort to be sanctioned > by the IETF. Instead, JMP should serve as the very first PWG-based > standard published in the printer industry. > > What problems do people see with this position? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > lpyoung@lexmark.com wrote: > > > > I want to turn this discussion around 180 degrees. Why do you > > want to be chartered by the IETF? This is probably heresy coming > > from an IETF working group chairman but I really do not see any > > advantage for the JOB MIB to be chartered by the IETF. All that > > seems to matter is that an RFC number is attached to the JOB MIB > > which will happen by it being informational. I do not see the > > level (Informational, Proposed, Draft, etc.) that a MIB is at > > making any difference in whether a MIB is successful in the > > marketplace. Success in the marketplace is determined by a > > lot of factors more than merely whether the MIB is on an > > IETF Standards Track. > > Regards, > > Lloyd > > ------------------------------------------------------------ > > Lloyd Young Lexmark International, Inc. > > Senior Program Manager Dept. C14L/Bldg. 035-3 > > Strategic Alliances 740 New Circle Road NW > > internet: lpyoung@lexmark.com Lexington, KY 40550 > > Phone: (606) 232-5150 Fax: (606) 232-6740 From harryl at us.ibm.com Fri Nov 7 18:59:30 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Standard direction In-Reply-To: Job MIB Standard direction> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Jay, Yes, I believe the PWG is capable of this. I just don't think we = have ever stated it as such... >PWG advertises the protocol and retains >all related documents in a publicly available repository, and that >the PWG maintains authoritative control on the specifications? question. The rubber need to meet the road with JMP and probably FIN. Harry Lewis - IBM Printing Systems jkm@underscore.com on 11/07/97 04:27:58 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, rbergma@dpc.com @ internet, lpyoung@lexmark= .com @ internet, rturner@sharplabs.com @ internet, chrisw@iwl.com @ internet, Harald.T.Alvestrand@uninett.no @ internet Subject: Re: JMP> Job MIB Standard direction Harry Lewis wrote: > Another thing I think this decision will force that we are really not= > addressing is the last bit of Harald's statement "as a protocol unde= r PWG > control" Do we know exactly what this means? > > Harry Lewis - IBM Printing Systems Doesn't this mean that the PWG advertises the protocol and retains all related documents in a publicly available repository, and that the PWG maintains authoritative control on the specifications? Are there other issues? Do you think the PWG is not currently able to do these things? If not, what must be done to make this happen, assuming the PWG desires to do this? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- = From jkm at underscore.com Fri Nov 7 19:03:44 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> Formal PWG process for assigning PWG enterprise numbers Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Harry Lewis wrote in his posting of the Boulder minutes on the JMP list: > If we go the Informational route we will register the Job MIB under the new > PWG OID as follows: > > PWG OID = ... Private.Enterprises.1699 so the Job MIB will be > ... Private.Enterprises.1699.1. The first assignment > of the job mib will be > ... Private Enterprises.1699.1.1 As you know, we never got around to scheduling a meeting in Boulder having to do with the formal process of assigning OIDs to the new PWG enterprise tree. This discussion really belongs on the general PWG mailing list, the results of which can and should be used by the JMP project. I'm a bit confused by your posted text, thinking that part of it may be a typo. (That is, the comments seem a bit strange.) Notwithstanding, if I read you correctly, you're suggesting that the Job Monitoring MIB assume the ".1" position under the PWG tree. I tend to agree with this approach, that a particular project would be assigned a top-level number in the tree, assuming OID assignments are required by the project. (That is, just because a PWG project exists doesn't mean that a top-level OID is assigned to it; instead, only if the project *requires* such OIDs would the assignment be made.) Comments for the PWG at large? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From Harald.T.Alvestrand at uninett.no Sat Nov 8 03:54:57 1997 From: Harald.T.Alvestrand at uninett.no (Harald.T.Alvestrand@uninett.no) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB Standard direction In-Reply-To: Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Harry, The statement "under PWG control" means that if the PWG claims that the Job MIB version 2 is defined like this-and-this, the IETF won't protest. If the PWG were to do the same thing with a standards-track document, the IETF will insist that it ain't so until it's been approved by the IETF process. We've had several attempts at groups saying that they're "defining the next version of standard XXX", while not consulting the IETF. That is WRONG. Harald A From rbergma at dpc.com Mon Nov 10 11:06:01 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: PWG> Formal PWG process for assigning PWG enterprise numbers In-Reply-To: <3463AC60.69C60282@underscore.com> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> The assignment of projects which require the new PWG Enterprises OID was discussed in Boulder in the JMP meeting. The minutes do reflect the agreement in the meeting. I agree with Jay that comments from the PWG in general should be requested before this becomes official. I request that all comments be submitted by Friday, November 14th. One correction, the correct PWG Enterprises number is 2699. (I may have given the wrong number in the meeting. :-( Ron Bergman Dataproducts Corp. On Fri, 7 Nov 1997, Jay Martin wrote: > Harry Lewis wrote in his posting of the Boulder minutes on the > JMP list: > > > If we go the Informational route we will register the Job MIB under the new > > PWG OID as follows: > > > > PWG OID = ... Private.Enterprises.1699 so the Job MIB will be > > ... Private.Enterprises.1699.1. The first assignment > > of the job mib will be > > ... Private Enterprises.1699.1.1 > > As you know, we never got around to scheduling a meeting in Boulder > having to do with the formal process of assigning OIDs to the new > PWG enterprise tree. > > This discussion really belongs on the general PWG mailing list, > the results of which can and should be used by the JMP project. > > I'm a bit confused by your posted text, thinking that part of it > may be a typo. (That is, the comments seem a bit strange.) > > Notwithstanding, if I read you correctly, you're suggesting that the > Job Monitoring MIB assume the ".1" position under the PWG tree. I > tend to agree with this approach, that a particular project would be > assigned a top-level number in the tree, assuming OID assignments are > required by the project. (That is, just because a PWG project exists > doesn't mean that a top-level OID is assigned to it; instead, only > if the project *requires* such OIDs would the assignment be made.) > > Comments for the PWG at large? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From harryl at us.ibm.com Mon Nov 10 11:12:55 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Re: Job MIB Standard direction In-Reply-To: Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Harald, thank you for your comment. In general, the PWG places value on having it's work chartered by the IETF (when appropriate), and has placed a lot of emphasis on following IETF recommendations. The job MIB is a case in point. Nonetheless, we'r= e trying, now, to acclimate to your latest recommendations that the Job M= IB remain "Informational", and that, from the IETF perspective, is not a "Good Thing" (because it facilitates both client and administrative acc= ess via SNMP). Your recommendation to maintain the Job MIB under PWG control and clarification of what that means (ability to rev the specification without consulting the IETF) is probably one that we should see value in and take advantage of. Again, Thanks. Harry Lewis - IBM Printing Systems hta@dale.uninett.no on 11/08/97 03:33:43 PM Please respond to hta@dale.uninett.no @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet, rbergma@dpc.com @ internet, lpyoung@lexmark= .com @ internet, rturner@sharplabs.com @ internet, chrisw@iwl.com @ internet Subject: Re: Job MIB Standard direction Harry, The statement "under PWG control" means that if the PWG claims that the Job MIB version 2 is defined like this-and-this, the IETF won't protest. If the PWG were to do the same thing with a standards-track document, the IETF will insist that it ain't so until it's been approved by the IETF process. We've had several attempts at groups saying that they're "defining the next version of standard XXX", while not consulting the IETF. That is WRONG. Harald A = From rbergma at dpc.com Mon Nov 10 11:13:37 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB Standard direction In-Reply-To: <5030300013897684000002L042*@MHS> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> It seems that it is now clear to all the only possible direction for the Job MIB is to be submitted as a PWG standard and published as an IETF informational document. I have talked to Tom and he will modify the MIB document accordingly. I anyone has an objection to this approach, please comment now. (or forever hold your peace!) Ron Bergman Dataproducts Corp. On Fri, 7 Nov 1997, Harry Lewis wrote: > Jay, Yes, I believe the PWG is capable of this. I just don't think we have > ever stated it as such... > > >PWG advertises the protocol and retains > >all related documents in a publicly available repository, and that > >the PWG maintains authoritative control on the specifications? > > From time to time we've danced around the "is the PWG a real stds body" > question. The rubber > need to meet the road with JMP and probably FIN. > > Harry Lewis - IBM Printing Systems > > > > > > > jkm@underscore.com on 11/07/97 04:27:58 PM > Please respond to jkm@underscore.com @ internet > To: Harry Lewis/Boulder/IBM@ibmus > cc: jmp@pwg.org @ internet, rbergma@dpc.com @ internet, lpyoung@lexmark.com @ > internet, rturner@sharplabs.com @ internet, chrisw@iwl.com @ internet, > Harald.T.Alvestrand@uninett.no @ internet > Subject: Re: JMP> Job MIB Standard direction > > > Harry Lewis wrote: > > > Another thing I think this decision will force that we are really not > > addressing is the last bit of Harald's statement "as a protocol under PWG > > control" Do we know exactly what this means? > > > > Harry Lewis - IBM Printing Systems > > Doesn't this mean that the PWG advertises the protocol and retains > all related documents in a publicly available repository, and that > the PWG maintains authoritative control on the specifications? > > Are there other issues? Do you think the PWG is not currently able > to do these things? If not, what must be done to make this happen, > assuming the PWG desires to do this? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > > From harryl at us.ibm.com Mon Nov 10 11:42:42 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> PWG> Formal PWG process for assigning PWG enterprise numbers Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Tried to send Friday... don't see in archives, so must have been mail p= roblem. Again, sorry I exclude this from the minutes... but, below, is an overv= iew of the Boulder discussion... Harry Lewis - IBM Printing Systems ------- Forwarded by Harry Lewis/Boulder/IBM on 11/10/97 09:31 AM -----= - Harry Lewis 11/07/97 11:13 PM To: jkm@underscore.com@internet cc: pwg@pwg.org@internet, jmp@pwg.org@internet From: Harry Lewis/Boulder/IBM @ IBMUS Subject: PWG> Formal PWG process for assigning PWG enterprise numbers Jay, sorry if mixing notes with OIDs in the minutes was confusing. Unfortunately, my minutes, this month, are a fairly raw form of discussion captured from the meeting. >I'm a bit confused by your posted text, thinking that part of it >may be a typo. (That is, the comments seem a bit strange.) You go on to say... >Notwithstanding, if I read you correctly, you're suggesting that the >Job Monitoring MIB assume the ".1" position under the PWG tree. I >tend to agree with this approach, that a particular project would be >assigned a top-level number in the tree, assuming OID assignments are >required by the project. (That is, just because a PWG project exists >doesn't mean that a top-level OID is assigned to it; instead, only >if the project *requires* such OIDs would the assignment be made.) I should have included, in the minutes, that we discussed two alternati= ves. I proposed a structured registry under the PWG enterprise OID based (simply) on PWG projects. PRIVATE ENTERPRISE PWG JMP JOBMIB JMGROUP1 JMGROUP2 (etc) (ETC) FIN FINMIB FNGROUP1 FNGROUP2 (etc) (ETC) (etc) There didn't seem to be much favor over a flat registration of whatever= comes along. PRIVATE ENTERPRISE PWG JOBMIB JMGROUP1 JMGROUP2 (etc) FINMIB FNGROUP1 FNGROUP2 (etc) (ETC) (Note, it is not yet decided whether the Finisher MIB will stand alone or extend the Printer MIB, so FIN may have been a bad example). I suppose the topic is still open to e-mail discussion, if appropriate.= Harry Lewis = From jkm at underscore.com Mon Nov 10 11:44:38 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> PWG> Formal PWG process for assigning PWG enterprise numbers In-Reply-To: PWG> Formal PWG process for assigning PWG enterprise numbers> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Hmmm... I'm not so sure that it's best to subdivide the OID space based on the project *group* name. Rather, an OID subtree should be assigned to the specific *standard* being developed. Do you really think there is value in having a tree level for the specific group (for example, "JMP" or "FIN")? Seems like a waste of a tree level to me. Comments from others? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Tried to send Friday... don't see in archives, so must have been mail problem. > Again, sorry I exclude this from the minutes... but, below, is an overview of > the Boulder discussion... > > Harry Lewis - IBM Printing Systems > > ------- Forwarded by Harry Lewis/Boulder/IBM on 11/10/97 09:31 AM ------ > > Harry Lewis > 11/07/97 11:13 PM > To: jkm@underscore.com@internet > cc: pwg@pwg.org@internet, jmp@pwg.org@internet > From: Harry Lewis/Boulder/IBM @ IBMUS > Subject: PWG> Formal PWG process for assigning PWG enterprise numbers > > Jay, sorry if mixing notes with OIDs in the minutes was confusing. > Unfortunately, my minutes, this month, are a fairly raw form of > discussion captured from the meeting. > > >I'm a bit confused by your posted text, thinking that part of it > >may be a typo. (That is, the comments seem a bit strange.) > > You go on to say... > > >Notwithstanding, if I read you correctly, you're suggesting that the > >Job Monitoring MIB assume the ".1" position under the PWG tree. I > >tend to agree with this approach, that a particular project would be > >assigned a top-level number in the tree, assuming OID assignments are > >required by the project. (That is, just because a PWG project exists > >doesn't mean that a top-level OID is assigned to it; instead, only > >if the project *requires* such OIDs would the assignment be made.) > > I should have included, in the minutes, that we discussed two alternatives. > I proposed a structured registry under the PWG enterprise OID based > (simply) on PWG projects. > > PRIVATE > ENTERPRISE > PWG > JMP > JOBMIB > JMGROUP1 > JMGROUP2 > (etc) > (ETC) > FIN > FINMIB > FNGROUP1 > FNGROUP2 > (etc) > (ETC) > (etc) > > There didn't seem to be much favor over a flat registration of whatever > comes along. > > PRIVATE > ENTERPRISE > PWG > JOBMIB > JMGROUP1 > JMGROUP2 > (etc) > FINMIB > FNGROUP1 > FNGROUP2 > (etc) > (ETC) > > (Note, it is not yet decided whether the Finisher MIB will stand alone > or extend the Printer MIB, so FIN may have been a bad example). > > I suppose the topic is still open to e-mail discussion, if appropriate. > > Harry Lewis From rbergma at dpc.com Mon Nov 10 11:50:04 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> PWG> Formal PWG process for assigning PWG enterprise numbers In-Reply-To: <346739F6.3661FD31@underscore.com> Message-ID: <199711071741.AA18620@interlock2.lexmark.com> Jay, On Mon, 10 Nov 1997, Jay Martin wrote: > Hmmm... I'm not so sure that it's best to subdivide the OID space > based on the project *group* name. Rather, an OID subtree should > be assigned to the specific *standard* being developed. > The above was also the consensus of the group in Boulder and is the current plan, unless a better solution is suggested. Ron Bergman > Do you really think there is value in having a tree level for the > specific group (for example, "JMP" or "FIN")? Seems like a waste > of a tree level to me. > > Comments from others? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > Harry Lewis wrote: > > > > Tried to send Friday... don't see in archives, so must have been mail problem. > > Again, sorry I exclude this from the minutes... but, below, is an overview of > > the Boulder discussion... > > > > Harry Lewis - IBM Printing Systems > > > > ------- Forwarded by Harry Lewis/Boulder/IBM on 11/10/97 09:31 AM ------ > > > > Harry Lewis > > 11/07/97 11:13 PM > > To: jkm@underscore.com@internet > > cc: pwg@pwg.org@internet, jmp@pwg.org@internet > > From: Harry Lewis/Boulder/IBM @ IBMUS > > Subject: PWG> Formal PWG process for assigning PWG enterprise numbers > > > > Jay, sorry if mixing notes with OIDs in the minutes was confusing. > > Unfortunately, my minutes, this month, are a fairly raw form of > > discussion captured from the meeting. > > > > >I'm a bit confused by your posted text, thinking that part of it > > >may be a typo. (That is, the comments seem a bit strange.) > > > > You go on to say... > > > > >Notwithstanding, if I read you correctly, you're suggesting that the > > >Job Monitoring MIB assume the ".1" position under the PWG tree. I > > >tend to agree with this approach, that a particular project would be > > >assigned a top-level number in the tree, assuming OID assignments are > > >required by the project. (That is, just because a PWG project exists > > >doesn't mean that a top-level OID is assigned to it; instead, only > > >if the project *requires* such OIDs would the assignment be made.) > > > > I should have included, in the minutes, that we discussed two alternatives. > > I proposed a structured registry under the PWG enterprise OID based > > (simply) on PWG projects. > > > > PRIVATE > > ENTERPRISE > > PWG > > JMP > > JOBMIB > > JMGROUP1 > > JMGROUP2 > > (etc) > > (ETC) > > FIN > > FINMIB > > FNGROUP1 > > FNGROUP2 > > (etc) > > (ETC) > > (etc) > > > > There didn't seem to be much favor over a flat registration of whatever > > comes along. > > > > PRIVATE > > ENTERPRISE > > PWG > > JOBMIB > > JMGROUP1 > > JMGROUP2 > > (etc) > > FINMIB > > FNGROUP1 > > FNGROUP2 > > (etc) > > (ETC) > > > > (Note, it is not yet decided whether the Finisher MIB will stand alone > > or extend the Printer MIB, so FIN may have been a bad example). > > > > I suppose the topic is still open to e-mail discussion, if appropriate. > > > > Harry Lewis > From rbergma at dpc.com Mon Nov 10 12:01:11 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> New JMP MIB Mapping Specification Message-ID: <199711071741.AA18620@interlock2.lexmark.com> I have update the Job Mib Mapping document with the changes agreed in the Boulder meeting. I have also included the changes recommended in Tom Hastings memo of 24 Oct 1997, with the following exception: Tom recommended a note for the mapping of *sides* in IPP to indicate that 3 IPP enum values need to be mapped to 2 JMP integer values. IPP sides definition allows 3 values: 1) one-sided 2) two-sided-long-edge 3) two-sided-short-edge The JMP sides definition has two values: 1 (side) or 2 (sides). I do not feel that the recommended note is necessary. If anyone responds to this message that this mapping would be unclear without this note, I will add. The documents can be retrieved on the PWG FTP site as: ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01.DOC (no revision marks) ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01-REV.DOC (w/ revision marks) ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01.TXT Open issues: 1) Mapping information needs to be generated for IPDS. (There were several IBM representatives at the meeting in Boulder, and the consensus was IPDS should be included in the document.) ACTION: Harry Lewis will provide this information. 2) Mapping information needs to be generated for DPA or Print Exchange. ACTION: Tom Hastings will provide. 3) The NDPS mapping needs to be reviewed. Scott Isaacson provided a list of the JMP objects and attributes supported, but no information was provided as to the identification of the corresponding NDPS parameters. ACTION: Scott - Can this data be provided? 4) The PJL mapping needs to be reviewed. ACTION: Bob Pentecost, can you do a quick review? 5) I have added a mapping for PostScript. This needs to be reviewed. 6) A new jmJobSubmissionId format is required for PostScript. This is an agent generated format which uses the document name. 7) The mapping for PServer needs to be reviewed. There are three JMP attributes that do not a corresponding PServer parameter identified. ACTION: Scott - Can you review this section? 8) A new jmJobSubmissionId format is required for PServer. This is an agent generated format which uses the directory path name. 9) SMB mapping is needed. ACTION: Ron Bergman will provide. 10) TIP/SI mapping is needed. I will do a draft of the maaping and send the result to the mailing list for review. 11) The issue was raised in Boulder as to how jmJobSubmissionId is to be mapped if there are multiple *submission protocols* used in the transmission of the job, all which can generate a valid jmJobSubmissionId. I will send an email to get the discussion started on this subject. I would like to get as many of these issues resolved prior to the L.A. meeting. Please try to get as many of these action items resolved by November 21st. Ron Bergman Dataproducts Corp. From don at lexmark.com Mon Nov 10 18:08:57 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB - trials and tribulations Message-ID: <199711110244.AA09863@interlock2.lexmark.com> After much thought and reading of the mail, I personally have come to the conclusion that in the case of MIBs, operating under the IETF (even if it were possible) does not really buy us anything. Publishing the MIB as an informational RFC and making it available on the PWG servers as well as the IETF servers should meet the needs of the users of a MIB. That really raises the question of who are the customers of a MIB. In my mind, the end-user of a printer is not the customer of the MIB rather the printer manufacturers and the printer management utilities developers are really the customers. As an IT community, we all understand what is really going on and what is important - a widely implemented and functionally complete standard -- not one necessarily blessed by the IETF. Considering the membership of this group and the effort that has gone into the development of the Job MIB, I really believe we will have both. While there may be technically astute customers who may specify that a product they are going to buy must support specific standards, it is obvious to me that for Job management, if they chose to specify a standard, they can only specify our Job MIB -- there simply is no competing standard. Therefore, I strongly urge this group to discontinue its efforts to place the Job MIB in the IETF MIB OID space and simply utilize the enterprise space we have obtained for the PWG. We can learn from what the IETF has done, embracing the good points of the IETF process and improving on those that don't meet our needs. On a more technical note, I would suggest that we consider moving the Job MIB down one level in the OID space. I would prefer something like ..... 2699.1.1...... Job Mib ......2699.1.2...... Finisher MIB ...... 2699.2.1 ...... maybe IPP space? ...... 2699.3.1 ..... something else using OID space etc. Comments! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jkm at underscore.com Wed Nov 12 10:40:53 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB - trials and tribulations In-Reply-To: Job MIB - trials and tribulations> Message-ID: <199711110244.AA09863@interlock2.lexmark.com> Don, > After much thought and reading of the mail, I personally have come > to the conclusion that in the case of MIBs, operating under the IETF > (even if it were possible) does not really buy us anything. Note that, to date, there have been no objections whatsoever to the notion of having the PWG maintain its own standards. This is a good sign, I believe. > On a more technical note, I would suggest that we > consider moving the Job MIB down one level in the > OID space. I would prefer something like > > ..... 2699.1.1...... Job Mib > ......2699.1.2...... Finisher MIB > > ...... 2699.2.1 ...... maybe IPP space? > ...... 2699.3.1 ..... something else using OID space > > etc. What is your thinking here? I mean, what is the significance of putting JMP/FIN under ...2699.1 versus having IPP under .3, etc? Are you in some way suggesting a set of categories for the top-level OID (ie, .2699.1, .2699.2, etc)? This approach sounds good to me; it's just that I'm trying to figure out your plan here. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From don at lexmark.com Thu Nov 13 08:09:27 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB - trials and tribulations In-Reply-To: Job MIB - trials and tribulations> Message-ID: <199711131309.AA03519@interlock2.lexmark.com> JK Martin said: >> On a more technical note, I would suggest that we >> consider moving the Job MIB down one level in the >> OID space. I would prefer something like >> >> ..... 2699.1.1...... Job Mib >> ......2699.1.2...... Finisher MIB >> >> ...... 2699.2.1 ...... maybe IPP space? >> ...... 2699.3.1 ..... something else using OID space >> >> etc. > >What is your thinking here? I mean, what is the significance >of putting JMP/FIN under ...2699.1 versus having IPP under .3, >etc? Are you in some way suggesting a set of categories for >the top-level OID (ie, .2699.1, .2699.2, etc)? > >This approach sounds good to me; it's just that I'm trying to >figure out your plan here. My suggestion on the structure of the usage of our Enterprise number is to insure some kind of ordering and structure to our usage. I would prefer something like 2699 | +-------+------...--+ | | | | 1 2 3 n +---+ +---+ +---+ +----+ | | | | | | | | | JMP-+ | | | | | | | | | | FIN --+ | | | | | | | | etc ----+ | | | | | | | | | attributes--+ | | | | operations ---+ | | etc ------------+ This would allow us to put all the MIB work at one point (2699.1) and maybe all the IPP at another (2699.2) (maybe the need for IPP is non-existant but I use it as an example) and other "types" of objects at other places, properly grouped. I think this is a better structure than maybe: 2699 | +-------+------...--+ | | | | 1 2 3 n + +---+ + +----+ | | | | | JMP---+ | | | | | | | | attributes -+ | | | | | | operations -----+ | | | | FIN --------------+ | | etc -------------------+ Maybe its my obsessive/compulsive need for order and structure but that's my intent anyway. Does that explain it? Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jkm at underscore.com Thu Nov 13 11:37:12 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:11 2009 Subject: JMP> Structuring of the PWG enterprise OID tree Message-ID: <199711131309.AA03519@interlock2.lexmark.com> Don, Well, ok. I guess all we can derive from your explanation is that you want to put all MIBs under one subtree, and other "things" in other subtrees (eg, IPP under a separate top-level subtree). I guess that's ok...but I sure would like some idea of what the other "things" might be. Either way, your approach is certainly acceptable. If there are no substantive objections, we shall assume the approach described by Don (below). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > JK Martin said: > > >> On a more technical note, I would suggest that we > >> consider moving the Job MIB down one level in the > >> OID space. I would prefer something like > >> > >> ..... 2699.1.1...... Job Mib > >> ......2699.1.2...... Finisher MIB > >> > >> ...... 2699.2.1 ...... maybe IPP space? > >> ...... 2699.3.1 ..... something else using OID space > >> > >> etc. > > > >What is your thinking here? I mean, what is the significance > >of putting JMP/FIN under ...2699.1 versus having IPP under .3, > >etc? Are you in some way suggesting a set of categories for > >the top-level OID (ie, .2699.1, .2699.2, etc)? > > > >This approach sounds good to me; it's just that I'm trying to > >figure out your plan here. > > My suggestion on the structure of the usage of our > Enterprise number is to insure some kind of ordering > and structure to our usage. I would prefer something > like > > 2699 > | > +-------+------...--+ > | | | | > 1 2 3 n > +---+ +---+ +---+ +----+ > | | | | | | | | | > JMP-+ | | | | | > | | | | | > FIN --+ | | | | > | | | | > etc ----+ | | | > | | | > | | | > attributes--+ | | > | | > operations ---+ | > | > etc ------------+ > > This would allow us to put all the MIB work at one point > (2699.1) and maybe all the IPP at another (2699.2) (maybe > the need for IPP is non-existant but I use it as an example) > and other "types" of objects at other places, properly grouped. > I think this is a better structure than maybe: > > 2699 > | > +-------+------...--+ > | | | | > 1 2 3 n > + +---+ + +----+ > | | | | | > JMP---+ | | | | > | | | | > attributes -+ | | | > | | | > operations -----+ | | > | | > FIN --------------+ | > | > etc -------------------+ > > Maybe its my obsessive/compulsive need for order and structure > but that's my intent anyway. > > Does that explain it? > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From hastings at cp10.es.xerox.com Thu Nov 13 19:23:37 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Addition of natural language attributes to JMP to align with Message-ID: <3.0.1.32.19971113162337.00f62620@garfield> I've posted my action item to propose to the DL the addition of charset and natural language attributes to the Job Monitoring MIB to align with IPP that is now in WG Final Call. The files are in: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds-black.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds-red.pdf The .doc is MS-WORD with revision marks The .txt is plain text The two .pdf files are with red and black revision marks from the 0.86 version, dated 9/19/97. Please send comments by Wed, Nov 19, so I can republish the MIB. Silence will be assumed to be agreement. Thanks, Tom I've attached the .txt version here: Subj: Addition of natural language attributes to JMP to align with IPP From: Tom Hastings Date: 11/13/97 File: jmp-i18n-adds.doc Here is my action item to propose to the DL the addition of charset and natural language attributes to the Job Monitoring MIB to align with IPP that is now in WG Final Call. SUMMARY I've abandoned the idea to add the charset name as an alternative to the charset enum from the Printer MIB (see reasons below). So the only additions are two attributes to identify the natural language, one for the processingMessage(6) (that often comes from the interpreter) and the other for the text attributes that came from the job submitter (JmJobStringTC). Here are the detailed proposals: 1. At the JMP meeting I had proposed also allowing the IANA registered charset name to be allowed as an alternative representation for the jobCodedCharSet(7) attribute. But I'm withdrawing that proposal for the following reasons: a) Unlike all other attributes, the management application has to recognize and support the value of the jobCodedCharSet(7) attribute. Otherwise, the management application cannot process or display the text string attributes that it gets from the MIB that were submitted with the job. As David points out, management applications would have to recognize and support both the charset enum and the charset name identifications in order to determine the charset that the agent was using for a particular job. b) Implementations of the Job Monitoring MIB are very likely to also be doing the Printer MIB which uses the charset enums registered with IANA, not the charset names. IPP implementations that don't do the Printer MIB, are likely to be servers so it is easier for them to identify charset with both the charset names (as in IPP) and the charset enum representations. c) The Service Location Protocol (SLP), RFC 2165, June 1997, uses the charset enums, instead of the charset names. d) Each charset registered by IANA has only one enum value, but many charset names. IPP solved this ambiguity in the charset names, by requiring the names that are labeled "(MIME preferred name)". However, using enum values is more likely to be unique and unambiguous. 2. Add to the end of section 3.5.1, "Text generated by the server or device" as a new paragraph: The text message for the processingMessage(6) attribute is generated by the server/device. The natural language for the processingMessage(6) attribute is identified by the processingMessageNaturalLanguageTag(7) attribute. The processingMessageNaturalLanguageTag(7) attribute value SHALL conform to the language tag mechanism specified in RFC 1766 [RFC-1766]. Each attribute value is the same as the IPP [IPP-MOD] naturalLanguage attribute syntax. RFC 1766 specifies that a US-ASCII string consisting of the natural language followed by an optional country field. Both fields use the same two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], respectively, that are used in the Printer MIB for identifying language and country. Though RFC 1766 requires that the values be case-insensitive US-ASCII, this MIB specification requires all lower case to simplify comparing by management applications. Examples of the values of the processingMessageNaturalLanguageTag(7) attribute include: 'en' for English 'en-us' for US English 'fr' for French 'de' for German 3. Add to the end of section 3.5.2, "Text supplied by the job submitter" as a new paragraph: The natural language for all attributes represented by the textual-convention JmJobStringTC SHALL be identified by the jobNaturalLanguageTag(8) attribute. The jobNaturalLanguageTag(8) attribute value SHALL have the same syntax and semantics as the processingMessageNaturalLanguageTag(7) attribute, except that the jobNaturalLanguageTag(8) attribute identifies the natural language of attributes supplied by the job submitter instead of the natural language of the processingMessage(6) attribute. See Section 3.5.1. 4. Add the following textual convention: JmNaturalLanguageTagTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An IETF RFC 1766-compliant 'language tag', with zero or more sub-tags that identify a natural language. While RFC 1766 specifies that the US-ASCII values are case-insensitive, this MIB specification requires that all characters SHALL be lower case in order to simplify comparing by management applications." REFERENCE "See section 3.5.1, entitled: 'Text generated by the server or device' and section 3.5.2, entitled: 'Text supplied by the job submitter'." SYNTAX OCTET STRING (SIZE (0..63)) 5. Make the following modifications to the processingMessage attribute: processingMessage(6), JmUTF8StringTC(SIZE(0..63)) OCTETS: MULTI-ROW: A coded character set message that is generated by the server or device during the processing of the job as a simple form of processing log to show progress and any problems. The natural language of each value is specified by the corresponding processingMessageNaturalLanguageTag(7) value. There is no restriction for the same message occurring in multiple rows. 6. Add the following attribute: processingMessageNaturalLanguageTag(7), OCTET STRING(SIZE(2..63)) OCTETS: MULTI-ROW: The natural language of the corresponding processingMessage(6) attribute. See section 3.5.1, entitled 'Text generated by the server or device'. If the agent does not know the natural language of the job processing message, the agent SHALL either (1) return a zero length string value for the processingMessageNaturalLanguageTag(7) attribute or (2) not return the processingMessageNaturalLanguageTag(7) attribute for the job. There is no restriction for the same tag occurring in multiple rows. 7. Make the following changes to the jobCodedCharSet attribute: jobCodedCharSet(8), CodedCharSet INTEGER: The MIBenum identifier of the coded character set that the agent is using to represent coded character set objects and attributes of type 'JmJobStringTC'. These coded character set objects and attributes are either: (1) supplied by the job submitting client or (2) defaulted by the server or device when omitted by the job submitting client. The agent SHALL represent these objects and attributes in the MIB either (1) in the coded character set as they were submitted or (2) MAY convert the coded character set to another coded character set or encoding scheme as identified by the jobCodedCharSet attribute. See section 3.5.2, entitled: 'Text supplied by the job submitter'. These MIBenum values are assigned by IANA [IANA-charsets] when the coded character sets are registered. The coded character set SHALL be one of the ones registered with IANA [IANA] and the enum value uses the CodedCharSet textual-convention from the Printer MIB. See the JmJobStringTC textual-convention. If the agent does not know what coded character set was used by the job submitting client, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job. 8. Add the following attribute: jobNaturalLanguageTag(9), OCTET STRING(SIZE(2..63)) OCTETS: The natural language of the job attributes supplied by the job submitter or defaulted by the server or device for the job, i.e., all objects and attributes represented by the 'JmJobStringTC' textual-convention, such as jobName, mediumRequested, etc. See Section 3.5.2, entitled 'Text supplied by the job submitter'. If the agent does not know what natural language was used by the job submitting client, the agent SHALL either (1) return a zero length string value for the jobNaturalLanguageTag(9) attribute or (2) not return the jobNaturalLanguageTag(9) attribute for the job. 9. Add to References section: [RFC-1766] Avelstrand H., "Tags for the Identification of Languages", RFC 1766, March 1995. [ISO-639] ISO 639:1988 (E/F) - Code for Representation of names of languages - The International Organization for Standardization, 1st edition, 1988. [ISO-3166] ISO 3166:1988 (E/F) - Codes for representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15." From rbergma at dpc.com Thu Nov 13 21:38:51 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB - trials and tribulations In-Reply-To: <199711131309.AA03519@interlock2.lexmark.com> Message-ID: <3.0.1.32.19971113162337.00f62620@garfield> Don, I have no strong objection to your proposal, other than it requires an additional OID on top of the 15 or so already present. (So what difference does one more number make ;-) When I proposed the flat project oriented model in Boulder, I did not envision using OIDs for anything other than MIBs. The experience with IPP certainly hinted that OIDs, and more correctly ASN.1 encoding, are old technology. (But as we know, old things have a way of coming back in style.) If the consenus is that OIDs have a good probably of being used for other than MIBs I would support your proposal. On the other hand the Job and Finisher MIBs may be the only consumer of this OID space. Can anyone suggest any real requirements for "maybe IPP" and "something else"? Or is this not worth any further discussion, and just accept Don's proposed format? Ron Bergman Dataproducts Corp. On Thu, 13 Nov 1997 don@lexmark.com wrote: > > JK Martin said: > > >> On a more technical note, I would suggest that we > >> consider moving the Job MIB down one level in the > >> OID space. I would prefer something like > >> > >> ..... 2699.1.1...... Job Mib > >> ......2699.1.2...... Finisher MIB > >> > >> ...... 2699.2.1 ...... maybe IPP space? > >> ...... 2699.3.1 ..... something else using OID space > >> > >> etc. > > > >What is your thinking here? I mean, what is the significance > >of putting JMP/FIN under ...2699.1 versus having IPP under .3, > >etc? Are you in some way suggesting a set of categories for > >the top-level OID (ie, .2699.1, .2699.2, etc)? > > > >This approach sounds good to me; it's just that I'm trying to > >figure out your plan here. > > My suggestion on the structure of the usage of our > Enterprise number is to insure some kind of ordering > and structure to our usage. I would prefer something > like > > 2699 > | > +-------+------...--+ > | | | | > 1 2 3 n > +---+ +---+ +---+ +----+ > | | | | | | | | | > JMP-+ | | | | | > | | | | | > FIN --+ | | | | > | | | | > etc ----+ | | | > | | | > | | | > attributes--+ | | > | | > operations ---+ | > | > etc ------------+ > > > This would allow us to put all the MIB work at one point > (2699.1) and maybe all the IPP at another (2699.2) (maybe > the need for IPP is non-existant but I use it as an example) > and other "types" of objects at other places, properly grouped. > I think this is a better structure than maybe: > > > 2699 > | > +-------+------...--+ > | | | | > 1 2 3 n > + +---+ + +----+ > | | | | | > JMP---+ | | | | > | | | | > attributes -+ | | | > | | | > operations -----+ | | > | | > FIN --------------+ | > | > etc -------------------+ > > > > Maybe its my obsessive/compulsive need for order and structure > but that's my intent anyway. > > Does that explain it? > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > > From don at lexmark.com Fri Nov 14 12:59:14 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB - trials and tribulations In-Reply-To: Job MIB - trials and tribulations> Message-ID: <199711141759.AA18643@interlock2.lexmark.com> Harry Lewis said: >I will just reiterate my proposal which bases the hierarchy on PWG projects... >given that these tend to "foster" separate standards... > >..... 2699.1.1...... Job Mib >..... 2699.1.2 ..... Future Job Mib extensions >..... 2699.2.1 ..... Finisher Mib >..... 2699.2.2 ..... Finisher Mib extensions >..... 2699.3.1 ..... Hey, how about... Printer Mib >..... 2699.3.2 ..... Printer MIB extensions >..... 2699.3.2 ..... Printer MIB extensions >..... 2699.4.1 ..... IPP Operations (as suggested by someone, below) >..... 2699.4.2 ..... IPP Attributes > >What about a space for registering things like type-2 enums etc.? > >I don't feel real strongly about this proposal... I think just about any >structure will have pro's and con's. In Harry's format, I would really prefer the following which tends to group like things together, IMHO. If we add some other MIB later on, it would fall under the MIB sub-tree as opposed to after IPP and the Internet Finishing Protocol or whatever else happens before that new MIB. ......2699.1........ MIBS ..... 2699.1.1.1...... Job Mib ..... 2699.1.1.2 ..... Future Job Mib extensions ..... 2699.1.2.1 ..... Finisher Mib ..... 2699.1.2.2 ..... Finisher Mib extensions ..... 2699.1.3.1 ..... Hey, how about... Printer Mib ..... 2699.1.3.2 ..... Printer MIB extensions ..... 2699.1.3.2 ..... Printer MIB extensions ......2699.2....... IPP ..... 2699.2.1 ..... IPP Operations (as suggested by someone, below) ..... 2699.2.2 ..... IPP Attributes ......2699.3....... Something else To be consistant, we might even want to do something like: ......2699.1........ MIBS ..... 2699.1.1.1...... Job Mib ..... 2699.1.1.2 ..... Future Job Mib extensions ..... 2699.1.2.1 ..... Finisher Mib ..... 2699.1.2.2 ..... Finisher Mib extensions ..... 2699.1.3.1 ..... Hey, how about... Printer Mib ..... 2699.1.3.2 ..... Printer MIB extensions ..... 2699.1.3.2 ..... Printer MIB extensions ......2699.2........ PROTOCOLS ......2699.2.1...... IPP ..... 2699.2.1.1 ..... IPP Operations (as suggested by someone, below) ..... 2699.2.1.2 ..... IPP Attributes ......2699.2.2....... Some Other Protocol ......2699.3........ SOMETHING_ELSE_BESIDES_MIBS_AND_PROTOCOLS but I won't get hung up on that. I think insuring all the MIBs are in the same sub-tree is probably sufficient. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Fri Nov 14 15:51:10 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: PWG> Re: JMP> Job MIB - trials and tribulations In-Reply-To: <199711141759.AA18643@interlock2.lexmark.com> Message-ID: <3.0.1.32.19971114125110.00cca430@garfield> Could someone write down the entire path for OIDs that will be needed for the Job Mon MIB? How many octets long is it? Is the length a problem? By the way, I don't see any use of OIDs for IPP at the moment. We don't have an OID attribute syntax. We are using keywords for the same purpose. There are the following possible examples for the PWG assigning OIDs for use with: a. ISO DPA attributes or values. Maybe even assiging attribute OIDs for use with the DPA Printer object that are the equivalent of Printer MIB objects. b. OIDs for use with other MIBs as object values, such as device types in HR MIB(?). On the other hand, the value immediately under the 2699 could be for whatever type. So with either scheme, we are not constrained with inventing new types of uses for OIDs as far as I can see. The advantage of the scheme agreed in Boulder, is that we don't need to have any more discussion about what other uses we might put OIDs to. We can just use them for whatever purpose when the need arises and just assign the next available arc which would be 2 after the Job Monitoring MIB uses 1. The advantage of Don's scheme is that like things are grouped together. But would it hurt if ...2699.1.xx was Job MIB, ...2699.2.xx was for some non-MIB thing, and xxx2699.3.xx was for another PWG MIB? Even SNMP MIB walks would just skip over any holes that had been used for non-MIB things. So I'm in favor of the original proposal as being shorter, simpler, and easier to agree to. Tom At 09:59 11/14/1997 PST, don@lexmark.com wrote: > >Harry Lewis said: > >>I will just reiterate my proposal which bases the hierarchy on PWG >projects... >>given that these tend to "foster" separate standards... >> >>..... 2699.1.1...... Job Mib >>..... 2699.1.2 ..... Future Job Mib extensions >>..... 2699.2.1 ..... Finisher Mib >>..... 2699.2.2 ..... Finisher Mib extensions >>..... 2699.3.1 ..... Hey, how about... Printer Mib >>..... 2699.3.2 ..... Printer MIB extensions >>..... 2699.3.2 ..... Printer MIB extensions >>..... 2699.4.1 ..... IPP Operations (as suggested by someone, below) >>..... 2699.4.2 ..... IPP Attributes >> >>What about a space for registering things like type-2 enums etc.? >> >>I don't feel real strongly about this proposal... I think just about any >>structure will have pro's and con's. > >In Harry's format, I would really prefer the following which tends to group >like things together, IMHO. If we add some other MIB later on, it would >fall under the MIB sub-tree as opposed to after IPP and the Internet >Finishing Protocol or whatever else happens before that new MIB. >......2699.1........ MIBS >..... 2699.1.1.1...... Job Mib >..... 2699.1.1.2 ..... Future Job Mib extensions >..... 2699.1.2.1 ..... Finisher Mib >..... 2699.1.2.2 ..... Finisher Mib extensions >..... 2699.1.3.1 ..... Hey, how about... Printer Mib >..... 2699.1.3.2 ..... Printer MIB extensions >..... 2699.1.3.2 ..... Printer MIB extensions >......2699.2....... IPP >..... 2699.2.1 ..... IPP Operations (as suggested by someone, below) >..... 2699.2.2 ..... IPP Attributes >......2699.3....... Something else > >To be consistant, we might even want to do something like: > >......2699.1........ MIBS >..... 2699.1.1.1...... Job Mib >..... 2699.1.1.2 ..... Future Job Mib extensions >..... 2699.1.2.1 ..... Finisher Mib >..... 2699.1.2.2 ..... Finisher Mib extensions >..... 2699.1.3.1 ..... Hey, how about... Printer Mib >..... 2699.1.3.2 ..... Printer MIB extensions >..... 2699.1.3.2 ..... Printer MIB extensions >......2699.2........ PROTOCOLS >......2699.2.1...... IPP >..... 2699.2.1.1 ..... IPP Operations (as suggested by someone, below) >..... 2699.2.1.2 ..... IPP Attributes >......2699.2.2....... Some Other Protocol >......2699.3........ SOMETHING_ELSE_BESIDES_MIBS_AND_PROTOCOLS > >but I won't get hung up on that. I think insuring all the MIBs are in the >same >sub-tree is probably sufficient. > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Manager, Strategic Alliances and Standards * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > > From hastings at cp10.es.xerox.com Fri Nov 14 16:35:43 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> New JMP MIB Mapping Specification In-Reply-To: Message-ID: <3.0.1.32.19971114133543.00b9d2f0@garfield> All of the other mappings for IPP to JMP have the same attribute syntax with the exception of the "sides" attribute and the "job-state-reasons" attribute. We have a note for the "job-state-reasons" attribute explaining that IPP uses keywords and JMP uses bits. We should have the same kind of a note for "sides". In IPP the data type for "sides" is 'keyword' which is a us-ascii string. In JMP it is an 'integer' (not an enum). So I feel strongly that a note needs to be included to indicate this difference in syntax. If the issue is the size or complexity of the note, I offer the following alternative notes from simplest to more complex/detailed for Note 2: a. Simplest: 2. In JMP the sides attribute has the ingeter values '1' and '2' and three keyword values in IPP. b. More detailed: 2. In JMP the sides attribute has the integer value '1' or '2'. In IPP, the "sides" attribute has the three keyword values: 'one-sided', 'two-sided-long-edge', and 'two-sided-short-edge'. Tom At 09:01 11/10/1997 PST, Ron Bergman wrote: >I have update the Job Mib Mapping document with the changes agreed in >the Boulder meeting. I have also included the changes recommended in >Tom Hastings memo of 24 Oct 1997, with the following exception: > > Tom recommended a note for the mapping of *sides* in IPP to > indicate that 3 IPP enum values need to be mapped to 2 JMP integer > values. IPP sides definition allows 3 values: > > 1) one-sided > 2) two-sided-long-edge > 3) two-sided-short-edge > > The JMP sides definition has two values: 1 (side) or 2 (sides). > > I do not feel that the recommended note is necessary. If anyone > responds to this message that this mapping would be unclear without > this note, I will add. > >The documents can be retrieved on the PWG FTP site as: > > ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01.DOC (no revision marks) > ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01-REV.DOC (w/ revision marks) > ftp::/ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP01.TXT > >Open issues: > > 1) Mapping information needs to be generated for IPDS. (There were > several IBM representatives at the meeting in Boulder, and the > consensus was IPDS should be included in the document.) > ACTION: Harry Lewis will provide this information. > > 2) Mapping information needs to be generated for DPA or Print Exchange. > ACTION: Tom Hastings will provide. > > 3) The NDPS mapping needs to be reviewed. Scott Isaacson provided a > list of the JMP objects and attributes supported, but no information > was provided as to the identification of the corresponding NDPS > parameters. > ACTION: Scott - Can this data be provided? > > 4) The PJL mapping needs to be reviewed. > ACTION: Bob Pentecost, can you do a quick review? > > 5) I have added a mapping for PostScript. This needs to be reviewed. > > 6) A new jmJobSubmissionId format is required for PostScript. This is > an agent generated format which uses the document name. > > 7) The mapping for PServer needs to be reviewed. There are three JMP > attributes that do not a corresponding PServer parameter identified. > ACTION: Scott - Can you review this section? > > 8) A new jmJobSubmissionId format is required for PServer. This is > an agent generated format which uses the directory path name. > > 9) SMB mapping is needed. > ACTION: Ron Bergman will provide. > > 10) TIP/SI mapping is needed. I will do a draft of the maaping and > send the result to the mailing list for review. > > 11) The issue was raised in Boulder as to how jmJobSubmissionId is to > be mapped if there are multiple *submission protocols* used in the > transmission of the job, all which can generate a valid > jmJobSubmissionId. I will send an email to get the discussion > started on this subject. > >I would like to get as many of these issues resolved prior to the L.A. >meeting. Please try to get as many of these action items resolved by >November 21st. > > > Ron Bergman > Dataproducts Corp. > > > > > From hastings at cp10.es.xerox.com Fri Nov 14 17:48:23 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:11 2009 Subject: JMP> Some comments on the IPP part of the Mapping RFC Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> My comments are preceded with TH> about the previous line. 4.0 INTERNET PRINTING PROTOCOL (IPP) The Internet Printing Protocol [IPP] supports printing using any one of the three possible configurations. For configuration 2, the mapping defined herein is performed on a server. Otherwise, the mapping is performed on an agent TH> replace "a" with "an agent within the" to be like the next sentence. within the printer. 4.1 jmJobSubmissionId Mapped to IPP IPP contains a rich set of parameters which allow several methods of creating the jmJobSubmissionId object. To prevent interoperability problems, the preferred method is to use the IPP job-uri attribute as follows: octet 1: '4' octets 2-40: Contains the IPP job-uri job template attribute generated by the printer. (The job-uri is returned to the client by IPP.) If the job-uri is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: Contains the decimal representation of the job-id job template attribute. 4.2 jmJobIndex Mapped to IPP The job index (jmJobIndex) assigned by the SNMP job monitoring agent is returned to the client by IPP as the job-id job template attribute. TH> Change "template" to "decscrition" since job-id is a Description attr. (Since IPP does not require consecutively generated job-ids, the agent may receive job TH> add "s" to "job" from multiple clients and can assign jmJobIndex in an accending sequence TH> change "accending" to "ascending" independent of the submitting job client.) The IPP job-id must be restricted to the range of 1 to 99,999,999 (decimal) to allow the value to be properly represented in jmJobSubmissionId. 4.3 Other MIB Objects Mapped to IPP MIB Object | IPP Job template attribute TH> Delete "template", since these are not all Job Template attributes. --------------------------+--------------------------------------------- jmJobOwner | job-originating-user jmJobKOctetsRequested | job-k-octets jmJobKOctetsProcessed | job-k-octets-processed jmJobImpressionsRequested | job-impressions jmJobImpressionsProcessed | job-impressions-completed jmJobStateReasons1 | job-state-reasons (note 1) jmNumberOfInterveningJobs | number-of-intervening-jobs Notes: ------ 1. JobStateReasons is a bit map described in one object and three attributes. The IPP condition may change one or more of the bits in one or more of these Job MIB items. 4.4 The Attribute Group Mapped to IPP The following mappings are required if the listed IPP job template attribute is TH> Delete "template", since these are not all Job Template attributes. provided. MIB attribute | IPP job template attribute | Data type ---------------------------+------------------------------+------------- TH> Add the following: jobCodedCharSet | attributes-codeset (note 3) | Octet String TH> Add the following assuming that we agree: jobNaturalLanguage | attributes-natural-language | Octet String jobName | job-name | Octet String TH> Add the following line: numberOfDocuments | number-of-documents | Integer documentFormat | document-format | Octet String jobPriority | job-priority | Integer jobHoldUntil | job-hold-until | Octet String sides | sides | Integer TH> Add (note 2) in previous mail finishing | finishings | Integer printQualityRequested | print-quality | Integer printerResolutionRequested | printer-resolution | Integer jobCopiesRequested | copies | Integer mediumRequested | media | Octet String jobSubmissionTime | time-at-submission | Integer jobStartedProcessingTime | time-at-processing | Integer jobCompletionTime | time-at-completed | Integer sheetsRequested | job-media-sheets | Integer jobURI | job-uri | Octet String jobStateReasonsN | job-state-reasons (note 1) | Integer physicalDevice | output-device-assigned | Octet String sheetsCompleted | job-media-sheets-completed | Integer Notes: ------ 1. JobStateReasons is a bit map described in one object and three attributes. The IPP condition may change one or more of the bits in one or more of these Job MIB items. TH> Note 2 from previous e-mail about sides: TH> Add Note 3: 3. In JMP jobCodedCharSet is an enum from the Printer MIB and IANA registry. In IPP, attributes-charset is name (MIME prefered name) of the charset. From harryl at us.ibm.com Sat Nov 15 01:32:43 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Job MIB doesn't handle Uncollated Copies Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> This message could be long - suffice it to say that I hope this news wi= ll be received in the spirit of an "early warning" interoperability issue. The issue lies with the following Job MIB attributes: |sheetsCompletedCurrentCopy(152) |impressionsCompletedCurrentCopy attributes(113) |documentCopiesCompleted(93) |jobCopiesCompleted(91) The problem is that these attributes can accurately reflect a "Mopy" or internal collation, but are inadequate if used to describe uncollated copies (or externally collated... such as use of sequential output bins). With "Internal Collation", one copy is "worked on" at a time. That copy= is finished (jobCopiesCompleted) and the next is started, resetting "sheetsCompletedCurrentCopy" With "External Collation" (uncollated) multiple copies are "worked on" before any copy is completed. Thus, "sheetsCompletedCurrentCopy" has no meaning and "jobCopiesCompleted" jumps from initial to final value in one increment (not very useful). One possible reaction to the realization is to catagorize "External Collation" as uninteresting, or just a "larger" job. (I had this tendancy, initially). But, recall, IPP supports collated and uncollated copies. Also, as mentioned above, the uncollated case is the same (to the Job MIB agent) as sorting into multiple outputs. I have discussed this problem, at length, with my development team and also consulted with Tom Hastings (editor), briefly. Tom was receptive and helpful and contributed to the following proposal: Add the following attributes --- currentSheetNumber currentImpressionNumber currentCopyNumber currentDocumentNumber Replace these "completed" attributes with their new "current" counterpa= rts ------- sheetsCompletedCurrentCopy(152) impressionsCompletedCurrentCopy attributes(113) Decide whether or not to Keep these "completed" attributes ---- documentCopiesCompleted(93) jobCopiesCompleted(91) for accounting purposes. Note, the "completed" values ONLY make sense for collated copies and/or FINAL values on uncollated jobs. For this reason, we recommend adding a final additional attribute --- copyType (ENUM - Internal Collation External Collation) The value of the currentXxx attributes is 0 while the job is PENDING. The values increment to 1 as the first impression is produced. An abbreviated example (sheets and jobs, only) should help visualize. For example, assume a 3 impression job with a request for 3 copies. Uncollated 3/3 (copyType =3D External Collation) -------------- sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 1 2 3 1 3 4 2 1 5 2 2 6 2 3 7 3 1 8 3 2 9 3 3 Collated 3/3 (copyType =3D Internal Collation) ------------ sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 2 1 3 3 1 4 1 2 5 2 2 6 3 2 7 1 3 8 2 3 9 3 3 The issue of whether or not to keep attributes documentCopiesCompleted(93) jobCopiesCompleted(91) could be resolved by specifying that the final value of currentCopyNumber currentDocumentNumber *is* the completed value and the attribute maintains this value for the remainig life of the entry. I did not show an example using currentDocumentNumber because this is for high end implementations that collate documents within jobs. Nonetheless, the same problem (solution) exists. Harry Lewis = From rbergma at dpc.com Mon Nov 17 11:33:56 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:11 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> One of the issues discussed in Boulder was how to map jmJobSubmissionId when there are multiple possibilities in the protocol. This is similar to the situation previously discussed relative to PJL with nested headers. Here it is possible for the client to include a PJL header with a submission id and then a server to also include another PJL header with a job submission id in front of the client header. In this case, the agreement was to use the last submission id encountered in parsing the job, since this would contain the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is within one layer, it is not applicable when the information is contained in different protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the following rules. First, these are the possible combinations from the submission protocols mapped. Combinations with a (?) are possible but may have a low probably. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement. 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) 2. PJL or PostScript will define jmJobSubmissionId when transmitted with NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat questionable as the mapping information from Scott Isaacson is vague. Scott, will information to generate jmJobSubmissionId always be available?) 4. TIP/SI should be used for combinations 9, 18, and 28. (Lloyd or Don, does this seem accurate?) 5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, using the SUBMISSIONID option. 6. PostScript should be used for combinations 10, 11, 15, and 17 if the information can be imbedded and extracted from the PostScript comments. DPA (PrintXchange) should provide sufficient information so that it would always provide jmJobSubmissionId. (No mapping is currently available.) Any comments? Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Mon Nov 17 17:25:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:11 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, thanks for trying to tackle this difficult topic. I have read your= recommendations and I'm not sure I understand how they relate to the pr= oblem. For example, when you say >1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and = > 22) I'm left wondering HOW. Are you suggesting we change the "always take the last jmJobSubmissionI= D encountered" rule to "use jmJobSubmissionID provided by xyz in case A, czy in case B, etc"...? I'm not saying this would be wrong, just it's a major departure and order of magnitude more complex for the Job MIB agent than the current rule. Harry Lewis jmp-owner@pwg.org on 11/17/97 09:44:45 AM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: Subject: JMP> Proposed Rules for jmJobSubmissionId One of the issues discussed in Boulder was how to map jmJobSubmissionId= when there are multiple possibilities in the protocol. This is similar to t= he situation previously discussed relative to PJL with nested headers. He= re it is possible for the client to include a PJL header with a submission id= and then a server to also include another PJL header with a job submission = id in front of the client header. In this case, the agreement was to use the= last submission id encountered in parsing the job, since this would contain = the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is= within one layer, it is not applicable when the information is contained in di= fferent protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the foll= owing rules. First, these are the possible combinations from the submission protocol= s mapped. Combinations with a (?) are possible but may have a low probab= ly. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement.= 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22= ) 2. PJL or PostScript will define jmJobSubmissionId when transmitted wit= h NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPr= inter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewh= at questionable as the mapping information from Scott Isaacson is vague= From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Mon Nov 17 20:07:23 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:rbergma@dpc.com at CSERVE Date: 11/17/97 11:41 AM One of the issues discussed in Boulder was how to map jmJobSubmissionId when there are multiple possibilities in the protocol. This is similar to the situation previously discussed relative to PJL with nested headers. Here it is possible for the client to include a PJL header with a submission id and then a server to also include another PJL header with a job submission id in front of the client header. In this case, the agreement was to use the last submission id encountered in parsing the job, since this would contain the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is within one layer, it is not applicable when the information is contained in different protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the following rules. First, these are the possible combinations from the submission protocols mapped. Combinations with a (?) are possible but may have a low probably. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement. 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) 2. PJL or PostScript will define jmJobSubmissionId when transmitted with NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat questionable as the mapping information from Scott Isaacson is vague. Scott, will information to generate jmJobSubmissionId always be available?) 4. TIP/SI should be used for combinations 9, 18, and 28. (Lloyd or Don, does this seem accurate?) 5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, using the SUBMISSIONID option. 6. PostScript should be used for combinations 10, 11, 15, and 17 if the information can be imbedded and extracted from the PostScript comments. DPA (PrintXchange) should provide sufficient information so that it would always provide jmJobSubmissionId. (No mapping is currently available.) Any comments? Ron Bergman Dataproducts Corp. From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Mon Nov 17 20:07:23 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:rbergma@dpc.com at CSERVE Date: 11/17/97 11:41 AM One of the issues discussed in Boulder was how to map jmJobSubmissionId when there are multiple possibilities in the protocol. This is similar to the situation previously discussed relative to PJL with nested headers. Here it is possible for the client to include a PJL header with a submission id and then a server to also include another PJL header with a job submission id in front of the client header. In this case, the agreement was to use the last submission id encountered in parsing the job, since this would contain the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is within one layer, it is not applicable when the information is contained in different protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the following rules. First, these are the possible combinations from the submission protocols mapped. Combinations with a (?) are possible but may have a low probably. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement. 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) 2. PJL or PostScript will define jmJobSubmissionId when transmitted with NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat questionable as the mapping information from Scott Isaacson is vague. Scott, will information to generate jmJobSubmissionId always be available?) 4. TIP/SI should be used for combinations 9, 18, and 28. (Lloyd or Don, does this seem accurate?) 5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, using the SUBMISSIONID option. 6. PostScript should be used for combinations 10, 11, 15, and 17 if the information can be imbedded and extracted from the PostScript comments. DPA (PrintXchange) should provide sufficient information so that it would always provide jmJobSubmissionId. (No mapping is currently available.) Any comments? Ron Bergman Dataproducts Corp. From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Mon Nov 17 20:07:23 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:rbergma@dpc.com at CSERVE Date: 11/17/97 11:41 AM One of the issues discussed in Boulder was how to map jmJobSubmissionId when there are multiple possibilities in the protocol. This is similar to the situation previously discussed relative to PJL with nested headers. Here it is possible for the client to include a PJL header with a submission id and then a server to also include another PJL header with a job submission id in front of the client header. In this case, the agreement was to use the last submission id encountered in parsing the job, since this would contain the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is within one layer, it is not applicable when the information is contained in different protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the following rules. First, these are the possible combinations from the submission protocols mapped. Combinations with a (?) are possible but may have a low probably. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement. 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) 2. PJL or PostScript will define jmJobSubmissionId when transmitted with NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat questionable as the mapping information from Scott Isaacson is vague. Scott, will information to generate jmJobSubmissionId always be available?) 4. TIP/SI should be used for combinations 9, 18, and 28. (Lloyd or Don, does this seem accurate?) 5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, using the SUBMISSIONID option. 6. PostScript should be used for combinations 10, 11, 15, and 17 if the information can be imbedded and extracted from the PostScript comments. DPA (PrintXchange) should provide sufficient information so that it would always provide jmJobSubmissionId. (No mapping is currently available.) Any comments? Ron Bergman Dataproducts Corp. From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Mon Nov 17 20:08:16 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:rbergma@dpc.com at CSERVE Date: 11/17/97 11:41 AM One of the issues discussed in Boulder was how to map jmJobSubmissionId when there are multiple possibilities in the protocol. This is similar to the situation previously discussed relative to PJL with nested headers. Here it is possible for the client to include a PJL header with a submission id and then a server to also include another PJL header with a job submission id in front of the client header. In this case, the agreement was to use the last submission id encountered in parsing the job, since this would contain the information closest to the client. As agreed in Boulder, although this rule works well when the nesting is within one layer, it is not applicable when the information is contained in different protocol layers. To attempt to get a handle on this situation, I have formulated the following analysis of the problem and developed the following rules. First, these are the possible combinations from the submission protocols mapped. Combinations with a (?) are possible but may have a low probably. 1) LPR/LPD with PJL 2) AppleTalk with PJL (?) 3) IPP with PJL 4) DPA with PJL (?) 5) NDPS with PJL 6) PServer with PJL 7) NPrinter/RPrinter with PJL 8) SMB with PJL 9) TIP/SI with PJL 10) LPR/LPD with PostScript 11) AppleTalk with PostScript 12) IPP with PostScript 13) DPA with PostScript 14) NDPS with PostScript 15) PServer with PostScript 16) NPrinter/RPrinter with PostScript 17) SMB with PostScript 18) TIP/SI with PostScript 19) PJL with PostScript 20) LPR/LPD with PJL and PostScript 21) AppleTalk with PJL and PostScript (?) 22) IPP with PJL and PostScript 23) DPA with PJL and PostScript (?) 24) NDPS with PJL and PostScript 25) PServer with PJL and PostScript 26) NPrinter/RPrinter with PJL and PostScript 27) SMB with PJL and PostScript 28) TIP/SI with PJL and PostScript Some rules are immediately obvious and should have little disagreement. 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) 2. PJL or PostScript will define jmJobSubmissionId when transmitted with NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter cannot define jmJobSubmissionId.) (Covers 7 and 16) New rules must be created for the remaining combinations. 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat questionable as the mapping information from Scott Isaacson is vague. Scott, will information to generate jmJobSubmissionId always be available?) 4. TIP/SI should be used for combinations 9, 18, and 28. (Lloyd or Don, does this seem accurate?) 5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, using the SUBMISSIONID option. 6. PostScript should be used for combinations 10, 11, 15, and 17 if the information can be imbedded and extracted from the PostScript comments. DPA (PrintXchange) should provide sufficient information so that it would always provide jmJobSubmissionId. (No mapping is currently available.) Any comments? Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Tue Nov 18 10:58:02 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Stuart, are you suggesting that, in an NDPS environment (for example), = BOTH a "driver spawned" job monitoring client application (like DocWise) AND a= NOS provided monitoring paradigm (NDPS) will be in operation at the same ti= me on the same job? Why would the end-user want 2 ways to monitor the print j= ob? Part of the decision to use "last encountered" jmJobSubmissionID was to= keep the agent simple, yes, but this decision was also based on the premise = that only one "tightly coupled" monitoring application need be in control. T= his is not to say "out of band" applications can't still monitor - just not in= the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex map= ping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convince= d there is a practical use for this. Could someone offer a high level diagram o= f a practical system where the client is getting job progress information f= rom two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based o= n the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so= simple or straight forward after all. I can see the possibility of an application that works closely with the= driver, such as HP's DocWise, using the driver created jmJobSubmissionI= d for job monitoring. It is clearly undesirable for something downstream= , such as NDPS, to then stomp on the jmJobSubmissionId created by the dri= ver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se= ems to be a more straight forward solution. I know the consensus was to no= t re-open this, but maybe others are having second thoughts. Can someone= refresh my memory on the negatives of allowing multiple jmJobSubmission= Ids? Stuart Rowley Kyocera Electronics, Inc. = From rbergma at mailgate.dpc.com Tue Nov 18 11:22:00 1997 From: rbergma at mailgate.dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Job MIB doesn't handle Uncollated Copies In-Reply-To: <5030300014519198000002L082*@MHS> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, I do believe that Tom's proposed change solves the issue that you presented. Since this looks like an easy change to incorporate, I proposed that this be accepted. Ron Bergman Dataproducts Corp. On Sat, 15 Nov 1997, Harry Lewis wrote: > This message could be long - suffice it to say that I hope this news will be > received in the spirit of an "early warning" interoperability issue. > > The issue lies with the following Job MIB attributes: > > |sheetsCompletedCurrentCopy(152) > |impressionsCompletedCurrentCopy attributes(113) > |documentCopiesCompleted(93) > |jobCopiesCompleted(91) > > The problem is that these attributes can accurately reflect a "Mopy" > or internal collation, but are inadequate if used to describe > uncollated copies (or externally collated... such as use of > sequential output bins). > > With "Internal Collation", one copy is "worked on" at a time. That copy > is finished (jobCopiesCompleted) and the next is started, resetting > "sheetsCompletedCurrentCopy" > > With "External Collation" (uncollated) multiple copies are "worked on" > before any copy is completed. Thus, "sheetsCompletedCurrentCopy" has > no meaning and "jobCopiesCompleted" jumps from initial to final value > in one increment (not very useful). > > One possible reaction to the realization is to catagorize "External > Collation" as uninteresting, or just a "larger" job. (I had this > tendancy, initially). But, recall, IPP supports collated and > uncollated copies. Also, as mentioned above, the uncollated case is > the same (to the Job MIB agent) as sorting into multiple outputs. > > I have discussed this problem, at length, with my development team and > also consulted with Tom Hastings (editor), briefly. Tom was receptive > and helpful and contributed to the following proposal: > > Add the following attributes > --- > currentSheetNumber > currentImpressionNumber > currentCopyNumber > currentDocumentNumber > > Replace these "completed" attributes with their new "current" counterparts > ------- > sheetsCompletedCurrentCopy(152) > impressionsCompletedCurrentCopy attributes(113) > > Decide whether or not to Keep these "completed" attributes > ---- > documentCopiesCompleted(93) > jobCopiesCompleted(91) > > for accounting purposes. Note, the "completed" values ONLY make > sense for collated copies and/or FINAL values on uncollated jobs. > For this reason, we recommend adding a final additional attribute > --- > copyType (ENUM - Internal Collation > External Collation) > > The value of the currentXxx attributes is 0 while the job is > PENDING. The values increment to 1 as the first impression is > produced. An abbreviated example (sheets and jobs, only) should > help visualize. For example, assume a 3 impression job with a > request for 3 copies. > > Uncollated 3/3 (copyType = External Collation) > -------------- > > sheetsCompleted currentSheetNumber currentCopyNumber > --------------- ------------------ ----------------- > 1 1 1 > 2 1 2 > 3 1 3 > 4 2 1 > 5 2 2 > 6 2 3 > 7 3 1 > 8 3 2 > 9 3 3 > > > Collated 3/3 (copyType = Internal Collation) > ------------ > > sheetsCompleted currentSheetNumber currentCopyNumber > --------------- ------------------ ----------------- > 1 1 1 > 2 2 1 > 3 3 1 > 4 1 2 > 5 2 2 > 6 3 2 > 7 1 3 > 8 2 3 > 9 3 3 > > The issue of whether or not to keep attributes > > documentCopiesCompleted(93) > jobCopiesCompleted(91) > > could be resolved by specifying that the final value of > > currentCopyNumber > currentDocumentNumber > > *is* the completed value and the attribute maintains this value > for the remainig life of the entry. > > I did not show an example using currentDocumentNumber because this > is for high end implementations that collate documents within jobs. > Nonetheless, the same problem (solution) exists. > > Harry Lewis > From rbergma at avalon.dpc.com Tue Nov 18 11:57:52 1997 From: rbergma at avalon.dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: <5030300014651378000002L082*@MHS> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, If I recall correctly, the discussion in Boulder concluded that the last jmJobSubmissionId encountered was not always the proper rule. The situation is muddled primarily due to our attempts to generate a proper jmJobSubmissionId using existing job submission protocols without a change to these protocols. For example, if a job is submitted using IPP with a PJL header on the data stream, the "last encountered" rule requires that the PJL header information override the IPP information. If the proper information (i.e. @PJL JOB SUBMISSIONID = "id string") is not included in the PJL header, a less than optimal jmJobSubmissionId will be generated. In this case, the IPP information should be used and the PJL information should be ignored. My analysis, which I did not explain, assumed that no information to generate jmJobSubmissionId was included beyond what is currently presented in the protocol. Maybe an easier rule is to use the last "recommended information format" encountered and only use an "alternative information format" if a "recommend information format" is not required. The Mapping document would then indicate for each submission protocol one or both of these formats. Is this less complex? Comments please! Ron Bergman Dataproducts Corp. On Mon, 17 Nov 1997, Harry Lewis wrote: > Ron, thanks for trying to tackle this difficult topic. I have read your > recommendations and I'm not sure I understand how they relate to the problem. > For example, when you say > > >1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and > > 22) > > I'm left wondering HOW. > > Are you suggesting we change the "always take the last jmJobSubmissionID > encountered" rule to "use jmJobSubmissionID provided by xyz in case A, > czy in case B, etc"...? > > I'm not saying this would be wrong, just it's a major departure and > order of magnitude more complex for the Job MIB agent than the current > rule. > > Harry Lewis > > > > > jmp-owner@pwg.org on 11/17/97 09:44:45 AM > Please respond to jmp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet > cc: > Subject: JMP> Proposed Rules for jmJobSubmissionId > > > > One of the issues discussed in Boulder was how to map jmJobSubmissionId when > there are multiple possibilities in the protocol. This is similar to the > situation previously discussed relative to PJL with nested headers. Here it > is possible for the client to include a PJL header with a submission id and > then a server to also include another PJL header with a job submission id in > front of the client header. In this case, the agreement was to use the last > submission id encountered in parsing the job, since this would contain the > information closest to the client. > > As agreed in Boulder, although this rule works well when the nesting is within > one layer, it is not applicable when the information is contained in different > protocol layers. To attempt to get a handle on this situation, I have > formulated the following analysis of the problem and developed the following > rules. > > First, these are the possible combinations from the submission protocols > mapped. Combinations with a (?) are possible but may have a low probably. > > 1) LPR/LPD with PJL > 2) AppleTalk with PJL (?) > 3) IPP with PJL > 4) DPA with PJL (?) > 5) NDPS with PJL > 6) PServer with PJL > 7) NPrinter/RPrinter with PJL > 8) SMB with PJL > 9) TIP/SI with PJL > > 10) LPR/LPD with PostScript > 11) AppleTalk with PostScript > 12) IPP with PostScript > 13) DPA with PostScript > 14) NDPS with PostScript > 15) PServer with PostScript > 16) NPrinter/RPrinter with PostScript > 17) SMB with PostScript > 18) TIP/SI with PostScript > > 19) PJL with PostScript > 20) LPR/LPD with PJL and PostScript > 21) AppleTalk with PJL and PostScript (?) > 22) IPP with PJL and PostScript > 23) DPA with PJL and PostScript (?) > 24) NDPS with PJL and PostScript > 25) PServer with PJL and PostScript > 26) NPrinter/RPrinter with PJL and PostScript > 27) SMB with PJL and PostScript > 28) TIP/SI with PJL and PostScript > > Some rules are immediately obvious and should have little disagreement. > > 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and 22) > > 2. PJL or PostScript will define jmJobSubmissionId when transmitted with > NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPrinter > cannot define jmJobSubmissionId.) (Covers 7 and 16) > > New rules must be created for the remaining combinations. > > 3. NDPS should be used for combinations 5, 14, and 24. (This is somewhat > questionable as the mapping information from Scott Isaacson is vague From harryl at us.ibm.com Tue Nov 18 13:09:43 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Ron, in your example, >For example, if a job is submitted using IPP with a PJL header on the = >data stream, the "last encountered" rule requires that the PJL header >information override the IPP information. If the proper information >= (i.e. @PJL JOB SUBMISSIONID =3D "id string") is not included in the PJL >head= er, a less than optimal jmJobSubmissionId will be generated. In >this case, the I= PP information should be used and the PJL information >should be ignored. Why is there a jmJobSubmissionID in the PJL header? It's not like anyon= e is putting these headers on, today. So I'm perplexed about trying to solve= a problem we don't have... that is just because we can imagine nested jmJobSubmissionIDs we need to somehow fix the problem. Since IPP can pr= ovide monitoring capability for the client, why would someone implement an in= tegrated driver/monitoring app that relies on both IPP and the Job MIB to report= TO THE SAME CLIENT? I'm trying to get at exactly what problem we're trying to solve, here a= nd is it really a problem. >Maybe an easier rule is to use the last "recommended information forma= t" >encountered and only use an "alternative information format" if a >"recommend information format" is not required. The Mapping document >would then indicate for each submission protocol one or both of these >formats. Is this less complex? While the mapping you provided is very helpful in understanding what combinations of PDL and submission protocol we may encounter, I'd rathe= r NOT go the "recommended information format" route. I think this REALLY complic= ates things. Now, the agent behavior must be tailored, for each job, dependi= ng on how the job was received. I agree the topic of nested jmJobSubmissionIDs surfaced as the main top= ic, in Boulder, which seems unresolved (or misunderstood). I'd like to underst= and the system's in which this perceived problem is real, however. Then, if we = need to make a change, I would probably favor having the agent map multiple jmJobSubmissionID's to a single jmJobIndex. I believe this is cleaner a= nd more useful if the situation ever does occur. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 10:02:59 AM To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Harry, If I recall correctly, the discussion in Boulder concluded that the las= t jmJobSubmissionId encountered was not always the proper rule. The situation is muddled primarily due to our attempts to generate a proper= jmJobSubmissionId using existing job submission protocols without a cha= nge to these protocols. For example, if a job is submitted using IPP with a PJL header on the d= ata stream, the "last encountered" rule requires that the PJL header information override the IPP information. If the proper information (i= .e. @PJL JOB SUBMISSIONID =3D "id string") is not included in the PJL heade= r, a less than optimal jmJobSubmissionId will be generated. In this case, t= he IPP information should be used and the PJL information should be ignore= d. My analysis, which I did not explain, assumed that no information to generate jmJobSubmissionId was included beyond what is currently presen= ted in the protocol. Maybe an easier rule is to use the last "recommended information format= " encountered and only use an "alternative information format" if a "recommend information format" is not required. The Mapping document would then indicate for each submission protocol one or both of these formats. Is this less complex? Comments please! Ron Bergman Dataproducts Corp. On Mon, 17 Nov 1997, Harry Lewis wrote: > Ron, thanks for trying to tackle this difficult topic. I have read yo= ur > recommendations and I'm not sure I understand how they relate to the = problem. > For example, when you say > > >1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and= > > 22) > > I'm left wondering HOW. > > Are you suggesting we change the "always take the last jmJobSubmissio= nID > encountered" rule to "use jmJobSubmissionID provided by xyz in case A= , > czy in case B, etc"...? > > I'm not saying this would be wrong, just it's a major departure and > order of magnitude more complex for the Job MIB agent than the curren= t > rule. > > Harry Lewis > > > > > jmp-owner@pwg.org on 11/17/97 09:44:45 AM > Please respond to jmp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet > cc: > Subject: JMP> Proposed Rules for jmJobSubmissionId > > > > One of the issues discussed in Boulder was how to map jmJobSubmission= Id when > there are multiple possibilities in the protocol. This is similar to= the > situation previously discussed relative to PJL with nested headers. = Here it > is possible for the client to include a PJL header with a submission = id and > then a server to also include another PJL header with a job submissio= n id in > front of the client header. In this case, the agreement was to use t= he last > submission id encountered in parsing the job, since this would contai= n the > information closest to the client. > > As agreed in Boulder, although this rule works well when the nesting = is within > one layer, it is not applicable when the information is contained in = different > protocol layers. To attempt to get a handle on this situation, I hav= e > formulated the following analysis of the problem and developed the fo= llowing > rules. > > First, these are the possible combinations from the submission protoc= ols > mapped. Combinations with a (?) are possible but may have a low prob= ably. > > 1) LPR/LPD with PJL > 2) AppleTalk with PJL (?) > 3) IPP with PJL > 4) DPA with PJL (?) > 5) NDPS with PJL > 6) PServer with PJL > 7) NPrinter/RPrinter with PJL > 8) SMB with PJL > 9) TIP/SI with PJL > > 10) LPR/LPD with PostScript > 11) AppleTalk with PostScript > 12) IPP with PostScript > 13) DPA with PostScript > 14) NDPS with PostScript > 15) PServer with PostScript > 16) NPrinter/RPrinter with PostScript > 17) SMB with PostScript > 18) TIP/SI with PostScript > > 19) PJL with PostScript > 20) LPR/LPD with PJL and PostScript > 21) AppleTalk with PJL and PostScript (?) > 22) IPP with PJL and PostScript > 23) DPA with PJL and PostScript (?) > 24) NDPS with PJL and PostScript > 25) PServer with PJL and PostScript > 26) NPrinter/RPrinter with PJL and PostScript > 27) SMB with PJL and PostScript > 28) TIP/SI with PJL and PostScript > > Some rules are immediately obvious and should have little disagreemen= t. > > 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and = 22) > > 2. PJL or PostScript will define jmJobSubmissionId when transmitted w= ith > NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/R= Printer > cannot define jmJobSubmissionId.) (Covers 7 and 16) > > New rules must be created for the remaining combinations. > > 3. NDPS should be used for combinations 5, 14, and 24. (This is some= what > questionable as the mapping information from Scott Isaacson is vag= ue = From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Tue Nov 18 14:18:30 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Yes, I think both the NDPS client app and a DocWise-like application could be trying to provide job monitoring information to the user. Why would a user want both? They probably wouldn't, but they may prefer the monitoring provided by NDPS over that provided by the DocWise-like app. However, in our scenario, the NDPS supplied jmJobSubmissionId would have been overridden by the driver supplied jmJobSubmissionID. I don't think this scenario is far-fetched. In this example there are essentially two in-band monitoring apps. DocWise-like apps would exist for product differentiation or to provide job monitoring in environments which would not otherwise provide it. NDPS or other similar component would provide job monitoring because a DocWise-like app may not be in use. We now have a mib design where these apps will collide unless they use some complicated method to avoid it. If they collide, then the user's choices for a preferred job monitoring method would have been limited. This doesn't seem like a good thing. Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 10:52 AM Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Tue Nov 18 14:18:58 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Yes, I think both the NDPS client app and a DocWise-like application could be trying to provide job monitoring information to the user. Why would a user want both? They probably wouldn't, but they may prefer the monitoring provided by NDPS over that provided by the DocWise-like app. However, in our scenario, the NDPS supplied jmJobSubmissionId would have been overridden by the driver supplied jmJobSubmissionID. I don't think this scenario is far-fetched. In this example there are essentially two in-band monitoring apps. DocWise-like apps would exist for product differentiation or to provide job monitoring in environments which would not otherwise provide it. NDPS or other similar component would provide job monitoring because a DocWise-like app may not be in use. We now have a mib design where these apps will collide unless they use some complicated method to avoid it. If they collide, then the user's choices for a preferred job monitoring method would have been limited. This doesn't seem like a good thing. Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 10:52 AM Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. From jkm at underscore.com Tue Nov 18 14:36:23 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> This is a multi-part message in MIME format. --------------9294E64BCFD47B6DAE217715 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there > is a practical use for this. Could someone offer a high level diagram of a > practical system where the client is getting job progress information from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------9294E64BCFD47B6DAE217715 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA23693; Tue, 18 Nov 1997 10:54:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09864; Tue, 18 Nov 1997 10:54:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 10:53:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09807 for jmp-outgoing; Tue, 18 Nov 1997 10:52:32 -0500 (EST) From: Harry Lewis To: , Cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <5030300014719821000002L012*@MHS> Date: Tue, 18 Nov 1997 10:58:02 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: jmp-owner@pwg.org Content-Type: text/plain; charset=iso-8859-1 Stuart, are you suggesting that, in an NDPS environment (for example), = BOTH a "driver spawned" job monitoring client application (like DocWise) AND a= NOS provided monitoring paradigm (NDPS) will be in operation at the same ti= me on the same job? Why would the end-user want 2 ways to monitor the print j= ob? Part of the decision to use "last encountered" jmJobSubmissionID was to= keep the agent simple, yes, but this decision was also based on the premise = that only one "tightly coupled" monitoring application need be in control. T= his is not to say "out of band" applications can't still monitor - just not in= the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex map= ping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convince= d there is a practical use for this. Could someone offer a high level diagram o= f a practical system where the client is getting job progress information f= rom two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based o= n the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so= simple or straight forward after all. I can see the possibility of an application that works closely with the= driver, such as HP's DocWise, using the driver created jmJobSubmissionI= d for job monitoring. It is clearly undesirable for something downstream= , such as NDPS, to then stomp on the jmJobSubmissionId created by the dri= ver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se= ems to be a more straight forward solution. I know the consensus was to no= t re-open this, but maybe others are having second thoughts. Can someone= refresh my memory on the negatives of allowing multiple jmJobSubmission= Ids? Stuart Rowley Kyocera Electronics, Inc. = --------------9294E64BCFD47B6DAE217715-- From harryl at us.ibm.com Tue Nov 18 16:40:34 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stu= art's "Applet vs. NDPS" example... isn't the user going to feel like there is= an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monit= oring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client mon= itoring is favored over server back channel, then the fact that legacy LPR subm= ission results in a jmJobSubmissionID which is later replaced by the one found= in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ i= nternet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -----------------------------------------------------------------------= --------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convin= ced there > is a practical use for this. Could someone offer a high level diagram= of a > practical system where the client is getting job progress information= from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- Stuart, are you suggesting that, in an NDPS environment (for example), = BOTH a "driver spawned" job monitoring client application (like DocWise) AND a= NOS provided monitoring paradigm (NDPS) will be in operation at the same ti= me on the same job? Why would the end-user want 2 ways to monitor the print j= ob? Part of the decision to use "last encountered" jmJobSubmissionID was to= keep the agent simple, yes, but this decision was also based on the premise = that only one "tightly coupled" monitoring application need be in control. T= his is not to say "out of band" applications can't still monitor - just not in= the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex map= ping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convince= d there is a practical use for this. Could someone offer a high level diagram o= f a practical system where the client is getting job progress information f= rom two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based o= n the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so= simple or straight forward after all. I can see the possibility of an application that works closely with the= driver, such as HP's DocWise, using the driver created jmJobSubmissionI= d for job monitoring. It is clearly undesirable for something downstream= , such as NDPS, to then stomp on the jmJobSubmissionId created by the dri= ver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se= ems to be a more straight forward solution. I know the consensus was to no= t re-open this, but maybe others are having second thoughts. Can someone= refresh my memory on the negatives of allowing multiple jmJobSubmission= Ids? Stuart Rowley Kyocera Electronics, Inc. -----------------------------------------------------------------------= --------- = From jkm at underscore.com Tue Nov 18 16:42:23 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> This is a multi-part message in MIME format. --------------9791DEBD129EDC602A63C50F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Harry, I wouldn't expect a user operates more than one job monitoring application at a time. Furthermore, I would expect the user to invoke a monitoring application "closest" to the start of the job submission process stream (ie, on the local platform on which the job was originally submitted). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------9791DEBD129EDC602A63C50F Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id QAA10025 for ; Tue, 18 Nov 1997 16:35:04 -0500 (EST) Received: from US.IBM.COM (d03lms03.boulder.ibm.com [9.99.80.13]) by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id RAA06634; Tue, 18 Nov 1997 17:31:34 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300014752019; Tue, 18 Nov 1997 16:40:34 -0500 From: Harry Lewis To: , , , Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <5030300014752019000002L092*@MHS> Date: Tue, 18 Nov 1997 16:40:34 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stu= art's "Applet vs. NDPS" example... isn't the user going to feel like there is= an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monit= oring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client mon= itoring is favored over server back channel, then the fact that legacy LPR subm= ission results in a jmJobSubmissionID which is later replaced by the one found= in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ i= nternet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -----------------------------------------------------------------------= --------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convin= ced there > is a practical use for this. Could someone offer a high level diagram= of a > practical system where the client is getting job progress information= from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- Stuart, are you suggesting that, in an NDPS environment (for example), = BOTH a "driver spawned" job monitoring client application (like DocWise) AND a= NOS provided monitoring paradigm (NDPS) will be in operation at the same ti= me on the same job? Why would the end-user want 2 ways to monitor the print j= ob? Part of the decision to use "last encountered" jmJobSubmissionID was to= keep the agent simple, yes, but this decision was also based on the premise = that only one "tightly coupled" monitoring application need be in control. T= his is not to say "out of band" applications can't still monitor - just not in= the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex map= ping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convince= d there is a practical use for this. Could someone offer a high level diagram o= f a practical system where the client is getting job progress information f= rom two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based o= n the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so= simple or straight forward after all. I can see the possibility of an application that works closely with the= driver, such as HP's DocWise, using the driver created jmJobSubmissionI= d for job monitoring. It is clearly undesirable for something downstream= , such as NDPS, to then stomp on the jmJobSubmissionId created by the dri= ver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se= ems to be a more straight forward solution. I know the consensus was to no= t re-open this, but maybe others are having second thoughts. Can someone= refresh my memory on the negatives of allowing multiple jmJobSubmission= Ids? Stuart Rowley Kyocera Electronics, Inc. -----------------------------------------------------------------------= --------- = --------------9791DEBD129EDC602A63C50F-- From harryl at us.ibm.com Tue Nov 18 17:11:11 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Thanks, Jay... >I wouldn't expect a user operates more than one job monitoring >application at a time. Furthermore, I would expect the user >to invoke a monitoring application "closest" to the start of >the job submission process stream (ie, on the local platform >on which the job was originally submitted). I thought I was going nuts there for a while... Given your assertion (and mine)... then let's re-examine said problem. = Closest to submission means last encountered by Job MIB agent. This was the ba= sis behind the rule... "always take the last jmJobSubmissionID". The only modification I would make to your statement (above) is that there may be configurations where the NOS provides native job monitorin= g (NDPS) or a "3rd party" application (UNIX print server/monitor/notification) i= s in effect... in which case "upstream" monitoring should be disabled. Maybe= this is the real sticky point? Harry Lewis - IBM Printing Systems jkm@underscore.com on 11/18/97 02:56:02 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -----------------------------------------------------------------------= --------- Harry, I wouldn't expect a user operates more than one job monitoring application at a time. Furthermore, I would expect the user to invoke a monitoring application "closest" to the start of the job submission process stream (ie, on the local platform on which the job was originally submitted). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stu= art's "Applet vs. NDPS" example... isn't the user going to feel like there is= an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monit= oring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client mon= itoring is favored over server back channel, then the fact that legacy LPR subm= ission results in a jmJobSubmissionID which is later replaced by the one found= in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ i= nternet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -----------------------------------------------------------------------= --------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convin= ced there > is a practical use for this. Could someone offer a high level diagram= of a > practical system where the client is getting job progress information= from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- Stuart, are you suggesting that, in an NDPS environment (for example), = BOTH a "driver spawned" job monitoring client application (like DocWise) AND a= NOS provided monitoring paradigm (NDPS) will be in operation at the same ti= me on the same job? Why would the end-user want 2 ways to monitor the print j= ob? Part of the decision to use "last encountered" jmJobSubmissionID was to= keep the agent simple, yes, but this decision was also based on the premise = that only one "tightly coupled" monitoring application need be in control. T= his is not to say "out of band" applications can't still monitor - just not in= the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex map= ping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convince= d there is a practical use for this. Could someone offer a high level diagram o= f a practical system where the client is getting job progress information f= rom two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based o= n the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so= simple or straight forward after all. I can see the possibility of an application that works closely with the= driver, such as HP's DocWise, using the driver created jmJobSubmissionI= d for job monitoring. It is clearly undesirable for something downstream= , such as NDPS, to then stomp on the jmJobSubmissionId created by the dri= ver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se= ems to be a more straight forward solution. I know the consensus was to no= t re-open this, but maybe others are having second thoughts. Can someone= refresh my memory on the negatives of allowing multiple jmJobSubmission= Ids? Stuart Rowley Kyocera Electronics, Inc. -----------------------------------------------------------------------= --------- -----------------------------------------------------------------------= --------- = From jkm at underscore.com Tue Nov 18 17:13:52 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, > Given your assertion (and mine)... then let's re-examine said problem. Closest > to submission means last encountered by Job MIB agent. This was the basis > behind the rule... "always take the last > jmJobSubmissionID". Hmmm...we may be out of sync here. How many Job MIB agents are involved here? It's very hard to tell. All I am saying is that the monitoring app would likely be launched on the submitting platform, and would therefore have the original job id as the target for its searches for *whatever* agent(s) are contacted by the app. Wouldn't you agree that it would be very, VERY difficult for a monitoring app on the local (ie, submitting) platform to know the job id (much less the job id *format*) of the _last_ component in the printing system process? > The only modification I would make to your statement (above) is that > there may be configurations where the NOS provides native job monitoring (NDPS) > or a "3rd party" application (UNIX print server/monitor/notification) is in > effect... in which case "upstream" monitoring should be disabled. Maybe this is > the real sticky point? Sure, I guess it could be a sticky point. Yes, one could run multiple monitoring apps that look for different types of job ids. But I would expect that no one would want to do this. After all, the Number One reason why the Job MIB will be so useful is to answer that everlasting Holy Grail question: "Is it time for me to get up from my desk to go fetch my completed job(s)?" It seems natural (to me, anyway) that the user is most likely to use a single monitoring app, one that is integrated with the local platform to the maximum possible extent. Do others have differing views? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at us.ibm.com Tue Nov 18 17:56:11 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Herein lies one of our major problems, I'm sure... >Wouldn't you agree that it would be very, VERY difficult for >a monitoring app on the local (ie, submitting) platform to >know the job id (much less the job id *format*) of the _last_ >component in the printing system process? Yes, I would agree, but this is not the interpretation I have had, or h= ave tried to put forth. I searched the Job MIB draft for the language but c= ould not find it. The rule should be... the Job MIB agent always uses the last encountere= d jmJobSubmissionID (in fact, we recommended this rule for ANY potentiall= y nested attribute... it's probably in the doc somewhere but I just couldn't fin= d it). The interpretation you are using it that the agent should use the jmJobSubmissionID assigned by the last component in the printing system= ! A major difference in how we are viewing things, there! With my interpretation, there would be no need for the local monitoring= app to try and determine the ID supplied by a downstream component. If the loc= al app is monitoring and has applied the ID, this should be the final ID encou= ntered and all's well. If the local app is not monitoring (or any component, f= or that matter), it should not explicitly tag the job with an ID. Sure, legacy submission vehicles (LPR/LPD), and/or IPP, will end up "causing" an ID = to be established according to a particular format. So the problem really onl= y raises it's head if you go Client (off) --- LPR (legacy, on by default) --- LP= R or IPP (ditto - and want's to be THE monitor). But, this isn't even a problem = because the printer only sees one final form of submission ... it doesn't creat= e a jmJobSubmissionID for every intermediate form of legacy submission. So = there should only be one jmJobSubmissionID created due to the submission vehi= cle which either is or is not (in this case) overridden by the datastream. I'm not saying multiple entries isn't an elegant solution... I'm just s= till trying to flesh out the problem. Harry Lewis - IBM Printing Systems jkm@underscore.com on 11/18/97 03:16:03 PM To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Harry, > Given your assertion (and mine)... then let's re-examine said problem= . Closest > to submission means last encountered by Job MIB agent. This was the = basis > behind the rule... "always take the last > jmJobSubmissionID". Hmmm...we may be out of sync here. How many Job MIB agents are involved here? It's very hard to tell. All I am saying is that the monitoring app would likely be launched on the submitting platform, and would therefore have the original job id as the target for its searches for *whatever* agent(s) are contacted by the app. Wouldn't you agree that it would be very, VERY difficult for a monitoring app on the local (ie, submitting) platform to know the job id (much less the job id *format*) of the _last_ component in the printing system process? > The only modification I would make to your statement (above) is that > there may be configurations where the NOS provides native job monitor= ing (NDPS) > or a "3rd party" application (UNIX print server/monitor/notification)= is in > effect... in which case "upstream" monitoring should be disabled. May= be this is > the real sticky point? Sure, I guess it could be a sticky point. Yes, one could run multiple monitoring apps that look for different types of job ids. But I would expect that no one would want to do this. After all, the Number One reason why the Job MIB will be so useful is to answer that everlasting Holy Grail question: "Is it time for me to get up from my desk to go fetch my completed job(s)?" It seems natural (to me, anyway) that the user is most likely to use a single monitoring app, one that is integrated with the local platform to the maximum possible extent. Do others have differing views? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- = From jkm at underscore.com Tue Nov 18 18:28:09 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> This is a multi-part message in MIME format. --------------A7B3A36EF8F20FBB0A9DD068 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Umm...I think I'm getting really lost and confused here. Perhaps this subject would be best handled (at least initially) via a telecon? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------A7B3A36EF8F20FBB0A9DD068 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id RAA10349 for ; Tue, 18 Nov 1997 17:51:05 -0500 (EST) Received: from US.IBM.COM (d03lms03.boulder.ibm.com [9.99.80.13]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with SMTP id RAA30924; Tue, 18 Nov 1997 17:49:39 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300014759712; Tue, 18 Nov 1997 17:56:11 -0500 Priority: Urgent From: Harry Lewis To: , Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <5030300014759712000002L022*@MHS> Date: Tue, 18 Nov 1997 17:56:11 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Herein lies one of our major problems, I'm sure... >Wouldn't you agree that it would be very, VERY difficult for >a monitoring app on the local (ie, submitting) platform to >know the job id (much less the job id *format*) of the _last_ >component in the printing system process? Yes, I would agree, but this is not the interpretation I have had, or h= ave tried to put forth. I searched the Job MIB draft for the language but c= ould not find it. The rule should be... the Job MIB agent always uses the last encountere= d jmJobSubmissionID (in fact, we recommended this rule for ANY potentiall= y nested attribute... it's probably in the doc somewhere but I just couldn't fin= d it). The interpretation you are using it that the agent should use the jmJobSubmissionID assigned by the last component in the printing system= ! A major difference in how we are viewing things, there! With my interpretation, there would be no need for the local monitoring= app to try and determine the ID supplied by a downstream component. If the loc= al app is monitoring and has applied the ID, this should be the final ID encou= ntered and all's well. If the local app is not monitoring (or any component, f= or that matter), it should not explicitly tag the job with an ID. Sure, legacy submission vehicles (LPR/LPD), and/or IPP, will end up "causing" an ID = to be established according to a particular format. So the problem really onl= y raises it's head if you go Client (off) --- LPR (legacy, on by default) --- LP= R or IPP (ditto - and want's to be THE monitor). But, this isn't even a problem = because the printer only sees one final form of submission ... it doesn't creat= e a jmJobSubmissionID for every intermediate form of legacy submission. So = there should only be one jmJobSubmissionID created due to the submission vehi= cle which either is or is not (in this case) overridden by the datastream. I'm not saying multiple entries isn't an elegant solution... I'm just s= till trying to flesh out the problem. Harry Lewis - IBM Printing Systems jkm@underscore.com on 11/18/97 03:16:03 PM To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Harry, > Given your assertion (and mine)... then let's re-examine said problem= . Closest > to submission means last encountered by Job MIB agent. This was the = basis > behind the rule... "always take the last > jmJobSubmissionID". Hmmm...we may be out of sync here. How many Job MIB agents are involved here? It's very hard to tell. All I am saying is that the monitoring app would likely be launched on the submitting platform, and would therefore have the original job id as the target for its searches for *whatever* agent(s) are contacted by the app. Wouldn't you agree that it would be very, VERY difficult for a monitoring app on the local (ie, submitting) platform to know the job id (much less the job id *format*) of the _last_ component in the printing system process? > The only modification I would make to your statement (above) is that > there may be configurations where the NOS provides native job monitor= ing (NDPS) > or a "3rd party" application (UNIX print server/monitor/notification)= is in > effect... in which case "upstream" monitoring should be disabled. May= be this is > the real sticky point? Sure, I guess it could be a sticky point. Yes, one could run multiple monitoring apps that look for different types of job ids. But I would expect that no one would want to do this. After all, the Number One reason why the Job MIB will be so useful is to answer that everlasting Holy Grail question: "Is it time for me to get up from my desk to go fetch my completed job(s)?" It seems natural (to me, anyway) that the user is most likely to use a single monitoring app, one that is integrated with the local platform to the maximum possible extent. Do others have differing views? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 4:35 PM Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stuart's "Applet vs. NDPS" example... isn't the user going to feel like there is an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monitoring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client monitoring is favored over server back channel, then the fact that legacy LPR submission results in a jmJobSubmissionID which is later replaced by the one found in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ internet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -------------------------------------------------------------------------------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there > is a practical use for this. Could someone offer a high level diagram of a > practical system where the client is getting job progress information from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -------------------------------------------------------------------------------- Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. -------------------------------------------------------------------------------- From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Tue Nov 18 18:38:32 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Of course the user isn't going to want information from both monitoring apps, but they likely will not know that the driver is inserting a jmJobSubmissionID. When they use their NDPS/Unix monitoring component and it can't find the job, are they going to slap their forehead and suddenly realize they must turn off "Insert Job Submission ID" in their driver? If we can say that client monitoring is ALWAYS favored over server back channel, then our current design (last ID encountered) is ok. I would assume that Novell and others would not be happy with this decision, but we are not hearing from them. The current design works ok for the client monitoring/driver folks (which I represent) but I'm not sure it is the best overall solution for the user. Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 4:35 PM Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stuart's "Applet vs. NDPS" example... isn't the user going to feel like there is an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monitoring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client monitoring is favored over server back channel, then the fact that legacy LPR submission results in a jmJobSubmissionID which is later replaced by the one found in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ internet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -------------------------------------------------------------------------------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there > is a practical use for this. Could someone offer a high level diagram of a > practical system where the client is getting job progress information from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -------------------------------------------------------------------------------- Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. -------------------------------------------------------------------------------- From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Tue Nov 18 18:38:33 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Of course the user isn't going to want information from both monitoring apps, but they likely will not know that the driver is inserting a jmJobSubmissionID. When they use their NDPS/Unix monitoring component and it can't find the job, are they going to slap their forehead and suddenly realize they must turn off "Insert Job Submission ID" in their driver? If we can say that client monitoring is ALWAYS favored over server back channel, then our current design (last ID encountered) is ok. I would assume that Novell and others would not be happy with this decision, but we are not hearing from them. The current design works ok for the client monitoring/driver folks (which I represent) but I'm not sure it is the best overall solution for the user. Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 4:35 PM Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stuart's "Applet vs. NDPS" example... isn't the user going to feel like there is an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monitoring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client monitoring is favored over server back channel, then the fact that legacy LPR submission results in a jmJobSubmissionID which is later replaced by the one found in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ internet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -------------------------------------------------------------------------------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there > is a practical use for this. Could someone offer a high level diagram of a > practical system where the client is getting job progress information from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -------------------------------------------------------------------------------- Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. -------------------------------------------------------------------------------- From Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com Tue Nov 18 18:40:02 1997 From: Stuart_Rowley at KEI-CA.CCMAIL.compuserve.com (Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Of course the user isn't going to want information from both monitoring apps, but they likely will not know that the driver is inserting a jmJobSubmissionID. When they use their NDPS/Unix monitoring component and it can't find the job, are they going to slap their forehead and suddenly realize they must turn off "Insert Job Submission ID" in their driver? If we can say that client monitoring is ALWAYS favored over server back channel, then our current design (last ID encountered) is ok. I would assume that Novell and others would not be happy with this decision, but we are not hearing from them. The current design works ok for the client monitoring/driver folks (which I represent) but I'm not sure it is the best overall solution for the user. Stuart Rowley Kyocera Electronics, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Author: INTERNET:harryl@us.ibm.com at CSERVE Date: 11/18/97 4:35 PM Yes, I consider this topic (appropriately) re-opened (along with the collated/un-collated topic). Without repeating your example (attached, below)... and referencing Stuart's "Applet vs. NDPS" example... isn't the user going to feel like there is an echo in the room? Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) Page 2 (applet)... Page 2...(UNIX/NDPS) etc. I'd be quick to turn SOMETHING off in that environment! If client monitoring is turned off then it should not be wrapping jmJobSubmissionID with the job. If client monitoring is favored over server back channel, then the fact that legacy LPR submission results in a jmJobSubmissionID which is later replaced by the one found in the job (the LAST one encountered by the agent)... is no problem. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/18/97 12:40:30 PM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ internet, Harry Lewis/Boulder/IBM@ibmus Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -------------------------------------------------------------------------------- I believe we must reopen the issue of nested job ids and how to handle them. I realize that this topic was consciously shelved a while back, but further subsequent digging has resulted in the need to readdress and handle this issue. It appears that Stuart Rowley has also recognized the need to rethink this topic. Harry Lewis wrote in response to Stuart: > I don't strongly object to moving to a design where multiple > jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there > is a practical use for this. Could someone offer a high level diagram of a > practical system where the client is getting job progress information from two > sources, simultaneously? I don't think the operating requirements is such that a job monitoring application is monitoring progress from two sources. Rather, the application is "told" to monitor job ID "XYZ", but the application has no idea that (potentially) several intermediate servers are involved in the complete job submission and delivery process. And this scenario (ie, one or more intermediate servers) is the real problem here. Here is a real-world scenario we frequently encounter in enterprise environments: 1) A Windows user submits a job to the native Windows printing system; the PC has been configured to automatically launch a "print job monitor" application, where the application is instructed to monitor job "XYZ", where "XYZ" is the *Windows* job id. 2) The user's PC is configured to route all print jobs to a Unix (or NetWare, or other non-Windows) server using an appropriate spooling protocol, such as (gasp) LPD/LPR. 3) The printing system on the Unix server uses printer-specific driver software to deliver the print job to the target printer using an appropriate (and potentially proprietary) delivery mechanism. In this scenario there are at least two (if not three) different job ids created by the time the paper starts rolling out of the printer. Yet, the PC-based monitor application only knows about the first (original) job id. What can we do about this problem? Some quick options: 1) Force the monitoring application to know about all possible job ids that may be subsequently created as the job moves thru the printing system. This means the app must "learn" about all other job ids, or at least job id *patterns* that might be used to derive the relationship of subsequent job ids with the original job id. 2) Extend the Job MIB to allow for a parallel set of job id "aliases" for any given job. As a job moves thru the printing system, the current "handler" (job transfer agent, if you will) assigns an appropriate job id, then adds the previously assigned job id as an "alias" for the job. The monitoring app can then search for the target job in both the primary job id list or the list of aliases for each job. 3) Do nothing about this problem, declaring that job monitoring using the Job MIB is only useful in very simple printing systems. My quick opinions on each of these options: 1) This approach is very, very messy, and probably won't work for diverse environments in which several server types are used within a single environment (ie, Unix *and* NetWare, etc). 2) A good approach, IMHO, that can be fairly easily solved, given that we have already devised clever ways to attach variable lists of information with any given job. 3) This approach would disappoint us greatly, needless to say... Given the work done to date by Ira and Tom, it's not hard to imagine that they can come up with some wonderfully elegant approach to providing multiple job ids in the Job MIB, one that can be designed in the very near future. (Right, guys?? ;-) Again, we at Underscore strongly encourage the JMP group to address this problem now so that simple, effective and accurate job monitoring applications can be delivered to the marketplace independent of the underlying platform. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -------------------------------------------------------------------------------- Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a "driver spawned" job monitoring client application (like DocWise) AND a NOS provided monitoring paradigm (NDPS) will be in operation at the same time on the same job? Why would the end-user want 2 ways to monitor the print job? Part of the decision to use "last encountered" jmJobSubmissionID was to keep the agent simple, yes, but this decision was also based on the premise that only one "tightly coupled" monitoring application need be in control. This is not to say "out of band" applications can't still monitor - just not in the "pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping table. I don't strongly object to moving to a design where multiple jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there is a practical use for this. Could someone offer a high level diagram of a practical system where the client is getting job progress information from two sources, simultaneously? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/17/97 06:15:16 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet cc: Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Ron, I am increasingly uncomfortable with the agreement to use the last submission id encountered. I believe the original decision was based on the idea that it was the simplest solution, but your write-up on the Proposed Rules for jmJobSubmissionId shows that this solution is not so simple or straight forward after all. I can see the possibility of an application that works closely with the driver, such as HP's DocWise, using the driver created jmJobSubmissionId for job monitoring. It is clearly undesirable for something downstream, such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems to be a more straight forward solution. I know the consensus was to not re-open this, but maybe others are having second thoughts. Can someone refresh my memory on the negatives of allowing multiple jmJobSubmissionIds? Stuart Rowley Kyocera Electronics, Inc. -------------------------------------------------------------------------------- From harryl at us.ibm.com Tue Nov 18 20:04:20 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Proposed Rules for jmJobSubmissionId In-Reply-To: Proposed Rules for jmJobSubmissionId> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Stuart, >Of course the user isn't going to want information from both >monitoring apps, but they likely will not know that the driver >is inserting a jmJobSubmissionID. When they use their >NDPS/Unix monitoring component and it can't find the job, >are they going to slap their forehead and suddenly realize >they must turn off "Insert Job Submission ID" in their driver? what we're really talking about, here, is coexistence of drivers with p= rint platforms. If the only option for coexistence is "plug and pray", then I agree with your assessment. = It is my experience, however, in the Windows and OS/2 environments, the drive= r and monitor are separate elements and it should be the monitor portion of t= he system which is adding the ID, not always the "driver". If a driver is= submitting through a UNIX server rather than an NT port monitor, then t= here should be no ID coming from the (let's say - Windows) "driver". Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Tue Nov 18 20:08:47 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conference call needed Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> I agree we need a conf call to discuss A. nested jmJobSubmissionIDs B. Collated/Un-collated copies I propose tomorrow (Wednesday) 9-10am MST (8am west coast; 11am east co= ast). I will try to figure out how to originate such a call. Please ping. Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/18/97= 05:52 PM --------------------------- jmp-owner@pwg.org on 11/18/97 04:45:09 PM Please respond to jmp-owner@pwg.org @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org @ internet Subject: Re: JMP> Proposed Rules for jmJobSubmissionId This is a multi-part message in MIME format. -----------------------------------------------------------------------= --------- Umm...I think I'm getting really lost and confused here. Perhaps this subject would be best handled (at least initially) via a telecon? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- Herein lies one of our major problems, I'm sure... >Wouldn't you agree that it would be very, VERY difficult for >a monitoring app on the local (ie, submitting) platform to >know the job id (much less the job id *format*) of the _last_ >component in the printing system process? Yes, I would agree, but this is not the interpretation I have had, or h= ave tried to put forth. I searched the Job MIB draft for the language but c= ould not find it. The rule should be... the Job MIB agent always uses the last encountere= d jmJobSubmissionID (in fact, we recommended this rule for ANY potentiall= y nested attribute... it's probably in the doc somewhere but I just couldn't fin= d it). The interpretation you are using it that the agent should use the jmJobSubmissionID assigned by the last component in the printing system= ! A major difference in how we are viewing things, there! With my interpretation, there would be no need for the local monitoring= app to try and determine the ID supplied by a downstream component. If the loc= al app is monitoring and has applied the ID, this should be the final ID encou= ntered and all's well. If the local app is not monitoring (or any component, f= or that matter), it should not explicitly tag the job with an ID. Sure, legacy submission vehicles (LPR/LPD), and/or IPP, will end up "causing" an ID = to be established according to a particular format. So the problem really onl= y raises it's head if you go Client (off) --- LPR (legacy, on by default) --- LP= R or IPP (ditto - and want's to be THE monitor). But, this isn't even a problem = because the printer only sees one final form of submission ... it doesn't creat= e a jmJobSubmissionID for every intermediate form of legacy submission. So = there should only be one jmJobSubmissionID created due to the submission vehi= cle which either is or is not (in this case) overridden by the datastream. I'm not saying multiple entries isn't an elegant solution... I'm just s= till trying to flesh out the problem. Harry Lewis - IBM Printing Systems jkm@underscore.com on 11/18/97 03:16:03 PM To: Harry Lewis/Boulder/IBM@ibmus cc: jmp@pwg.org Subject: Re: JMP> Proposed Rules for jmJobSubmissionId Harry, > Given your assertion (and mine)... then let's re-examine said problem= . Closest > to submission means last encountered by Job MIB agent. This was the = basis > behind the rule... "always take the last > jmJobSubmissionID". Hmmm...we may be out of sync here. How many Job MIB agents are involved here? It's very hard to tell. All I am saying is that the monitoring app would likely be launched on the submitting platform, and would therefore have the original job id as the target for its searches for *whatever* agent(s) are contacted by the app. Wouldn't you agree that it would be very, VERY difficult for a monitoring app on the local (ie, submitting) platform to know the job id (much less the job id *format*) of the _last_ component in the printing system process? > The only modification I would make to your statement (above) is that > there may be configurations where the NOS provides native job monitor= ing (NDPS) > or a "3rd party" application (UNIX print server/monitor/notification)= is in > effect... in which case "upstream" monitoring should be disabled. May= be this is > the real sticky point? Sure, I guess it could be a sticky point. Yes, one could run multiple monitoring apps that look for different types of job ids. But I would expect that no one would want to do this. After all, the Number One reason why the Job MIB will be so useful is to answer that everlasting Holy Grail question: "Is it time for me to get up from my desk to go fetch my completed job(s)?" It seems natural (to me, anyway) that the user is most likely to use a single monitoring app, one that is integrated with the local platform to the maximum possible extent. Do others have differing views? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- -----------------------------------------------------------------------= --------- = From jkm at underscore.com Tue Nov 18 20:19:19 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: JMP Conference call needed In-Reply-To: Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> (Sorry, but I didn't know if public ping replies were requested.) I'll be available for the call. Please post the calling info once you make the arrangements! ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > I agree we need a conf call to discuss > > A. nested jmJobSubmissionIDs > B. Collated/Un-collated copies > > I propose tomorrow (Wednesday) 9-10am MST (8am west coast; 11am east coast). I > will try to figure out how to originate such a call. Please ping. > > Harry Lewis - IBM Printing Systems > > ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/18/97 05:52 PM > --------------------------- > > jmp-owner@pwg.org on 11/18/97 04:45:09 PM > Please respond to jmp-owner@pwg.org @ internet > To: Harry Lewis/Boulder/IBM@ibmus > cc: jmp@pwg.org @ internet > Subject: Re: JMP> Proposed Rules for jmJobSubmissionId > > This is a multi-part message in MIME format. > -------------------------------------------------------------------------------- > Umm...I think I'm getting really lost and confused here. > > Perhaps this subject would be best handled (at least initially) > via a telecon? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From rbergma at mailgate.dpc.com Tue Nov 18 21:29:22 1997 From: rbergma at mailgate.dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: JMP Conference call needed In-Reply-To: <5030300014770508000002L082*@MHS> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, I will be able to participate. (But the limit has to 1 hour due to a conflict with other meetings.) Ron Bergman On Tue, 18 Nov 1997, Harry Lewis wrote: > I agree we need a conf call to discuss > > A. nested jmJobSubmissionIDs > B. Collated/Un-collated copies > > I propose tomorrow (Wednesday) 9-10am MST (8am west coast; 11am east coast). I > will try to figure out how to originate such a call. Please ping. > > Harry Lewis - IBM Printing Systems > > > ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/18/97 05:52 PM > --------------------------- > > > jmp-owner@pwg.org on 11/18/97 04:45:09 PM > Please respond to jmp-owner@pwg.org @ internet > To: Harry Lewis/Boulder/IBM@ibmus > cc: jmp@pwg.org @ internet > Subject: Re: JMP> Proposed Rules for jmJobSubmissionId > > > This is a multi-part message in MIME format. > -------------------------------------------------------------------------------- > Umm...I think I'm getting really lost and confused here. > > Perhaps this subject would be best handled (at least initially) > via a telecon? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > -------------------------------------------------------------------------------- > Herein lies one of our major problems, I'm sure... > > >Wouldn't you agree that it would be very, VERY difficult for > >a monitoring app on the local (ie, submitting) platform to > >know the job id (much less the job id *format*) of the _last_ > >component in the printing system process? > > Yes, I would agree, but this is not the interpretation I have had, or have > tried to put forth. I searched the Job MIB draft for the language but could not > find it. > > The rule should be... the Job MIB agent always uses the last encountered > jmJobSubmissionID (in fact, we recommended this rule for ANY potentially nested > attribute... it's probably in the doc somewhere but I just couldn't find it). > The interpretation you are using it that the agent should use the > jmJobSubmissionID assigned by the last component in the printing system! A > major difference in how we are viewing things, there! > > With my interpretation, there would be no need for the local monitoring app to > try and determine the ID supplied by a downstream component. If the local app > is monitoring and has applied the ID, this should be the final ID encountered > and all's well. If the local app is not monitoring (or any component, for that > matter), it should not explicitly tag the job with an ID. Sure, legacy > submission vehicles (LPR/LPD), and/or IPP, will end up "causing" an ID to be > established according to a particular format. So the problem really only raises > it's head if you go Client (off) --- LPR (legacy, on by default) --- LPR or IPP > (ditto - and want's to be THE monitor). But, this isn't even a problem because > the printer only sees one final form of submission ... it doesn't create a > jmJobSubmissionID for every intermediate form of legacy submission. So there > should only be one jmJobSubmissionID created due to the submission vehicle > which either is or is not (in this case) overridden by the datastream. > > I'm not saying multiple entries isn't an elegant solution... I'm just still > trying to flesh out the problem. > > Harry Lewis - IBM Printing Systems > > > > > jkm@underscore.com on 11/18/97 03:16:03 PM > To: Harry Lewis/Boulder/IBM@ibmus > cc: jmp@pwg.org > Subject: Re: JMP> Proposed Rules for jmJobSubmissionId > > > Harry, > > > Given your assertion (and mine)... then let's re-examine said problem. Closest > > to submission means last encountered by Job MIB agent. This was the basis > > behind the rule... "always take the last > > jmJobSubmissionID". > > Hmmm...we may be out of sync here. How many Job MIB agents are > involved here? It's very hard to tell. All I am saying is that > the monitoring app would likely be launched on the submitting > platform, and would therefore have the original job id as the > target for its searches for *whatever* agent(s) are contacted > by the app. > > Wouldn't you agree that it would be very, VERY difficult for > a monitoring app on the local (ie, submitting) platform to > know the job id (much less the job id *format*) of the _last_ > component in the printing system process? > > > > The only modification I would make to your statement (above) is that > > there may be configurations where the NOS provides native job monitoring > (NDPS) > > or a "3rd party" application (UNIX print server/monitor/notification) is in > > effect... in which case "upstream" monitoring should be disabled. Maybe this > is > > the real sticky point? > > Sure, I guess it could be a sticky point. Yes, one could run > multiple monitoring apps that look for different types of job ids. > But I would expect that no one would want to do this. > > After all, the Number One reason why the Job MIB will be so useful > is to answer that everlasting Holy Grail question: > > "Is it time for me to get up from my desk to go > fetch my completed job(s)?" > > It seems natural (to me, anyway) that the user is most likely to > use a single monitoring app, one that is integrated with the local > platform to the maximum possible extent. > > Do others have differing views? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > > > -------------------------------------------------------------------------------- > > > > From harryl at us.ibm.com Wed Nov 19 10:43:16 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Job MIB conf call number Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Sorry for getting this number out so close to the wire 1-800-610-8663 code 404308. TODAY - 9am mst!!!!!!! Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Wed Nov 19 18:59:22 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conf Call - revisited Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> I'm setting up a call tomorrow (Firday) Noon-2 MST (2-4 wayEast; 11-1 w= ayWest). Number is 1-888-687-2860 pass code is 404724 Topics: 1. nested JmJobSubId 2. collatted / uncollated I have 8 lines (we had 6 participants today). Hope you can be there!!! Harry Lewis - IBM Printing Systems = From jkm at underscore.com Thu Nov 20 10:52:33 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> URGENT: Job MIB telecon is TODAY (Thursday), not tomorrow (Friday) Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Turns out that Harry misstated the date of the follow-up Job MIB telecon. It is TODAY (Thursday), not tomorrow (Friday). Here is the calling information as previously posted by Harry: > Number is 1-888-687-2860 > pass code is 404724 > > Topics: 1. nested JmJobSubId > 2. collatted / uncollated > > I have 8 lines (we had 6 participants today). Hope you can be there!!! ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at us.ibm.com Thu Nov 20 11:21:07 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Job MIB doesn't handle Uncollated Copies In-Reply-To: Job MIB doesn't handle Uncollated Copies> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> So much for working late to try and catch the early worm. My server cru= nched this mail last night. Sorry... here it is. Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/20/97= 09:08 AM --------------------------- Harry Lewis 11/19/97 10:23 PM To: jmp@pwg.org @ Internet cc: From: Harry Lewis/Boulder/IBM @ IBMUS Subject: Re: JMP> Job MIB doesn't handle Uncollated Copies There hasn't been a whole lot of discussion regarding my proposal (belo= w) other than Ron indicating he believes it should be accepted. I would like to modify it slightly, in a manner which I believe better accomplishes the goal of distinguishing between collated and uncollated= copies yet results in fewer changes to the Mib. To put it as simply as I can, I propose to add currentCopyNumber currentDocumentNumber copyType and to keep sheetsCompletedCurrentCopy impressionsCompletedCurrentCopy documentCopiesCompleted jobCopiesCompleted The example flows the same as before: For a 3 impression job with a request for 3 copies. Uncollated 3/3 (copyType =3D External Collation) -------------- sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber --------------- -------------------------- ----------------- 1 1 1 2 1 2 3 1 3 4 2 1 5 2 2 6 2 3 7 3 1 8 3 2 9 3 3 Collated 3/3 (copyType =3D Internal Collation) ------------ sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber --------------- -------------------------- ----------------- 1 1 1 2 2 1 3 3 1 4 1 2 5 2 2 6 3 2 7 1 3 8 2 3 9 3 3 The reason for the change from currentSheetNumber and currentImpressonN= umber is that there may be several sheets in the paper path, (different) impress= ions may be ripping and printing at the same time etc. It's very hard to say whi= ch is the "currentImpression" or "currentSheet" but easier to say which is th= e current copy. It is easy to say which sheet has just completed (stacked= ). Note that, while drivers should protect from this, it is theoretically = possible to mix collated and uncollated copies (try it with your favorite printe= r... it's fun!). At this point, attributes like current copy really break do= wn. We feel, rather then try and define even more attributes to handle this pathological case we should just say behavior of the MIB, at this point= , is device specific. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 11/14/97 11:31:38 PM To: jmp@pwg.org cc: hastings@cp10.es.xerox.com, rbergma@dpc.com, bpenteco@boi.hp.com, jkm@underscore.com Subject: JMP> Job MIB doesn't handle Uncollated Copies This message could be long - suffice it to say that I hope this news wi= ll be received in the spirit of an "early warning" interoperability issue. The issue lies with the following Job MIB attributes: |sheetsCompletedCurrentCopy(152) |impressionsCompletedCurrentCopy attributes(113) |documentCopiesCompleted(93) |jobCopiesCompleted(91) The problem is that these attributes can accurately reflect a "Mopy" or internal collation, but are inadequate if used to describe uncollated copies (or externally collated... such as use of sequential output bins). With "Internal Collation", one copy is "worked on" at a time. That copy= is finished (jobCopiesCompleted) and the next is started, resetting "sheetsCompletedCurrentCopy" With "External Collation" (uncollated) multiple copies are "worked on" before any copy is completed. Thus, "sheetsCompletedCurrentCopy" has no meaning and "jobCopiesCompleted" jumps from initial to final value in one increment (not very useful). One possible reaction to the realization is to catagorize "External Collation" as uninteresting, or just a "larger" job. (I had this tendancy, initially). But, recall, IPP supports collated and uncollated copies. Also, as mentioned above, the uncollated case is the same (to the Job MIB agent) as sorting into multiple outputs. I have discussed this problem, at length, with my development team and also consulted with Tom Hastings (editor), briefly. Tom was receptive and helpful and contributed to the following proposal: Add the following attributes --- currentSheetNumber currentImpressionNumber currentCopyNumber currentDocumentNumber Replace these "completed" attributes with their new "current" counterpa= rts ------- sheetsCompletedCurrentCopy(152) impressionsCompletedCurrentCopy attributes(113) Decide whether or not to Keep these "completed" attributes ---- documentCopiesCompleted(93) jobCopiesCompleted(91) for accounting purposes. Note, the "completed" values ONLY make sense for collated copies and/or FINAL values on uncollated jobs. For this reason, we recommend adding a final additional attribute --- copyType (ENUM - Internal Collation External Collation) The value of the currentXxx attributes is 0 while the job is PENDING. The values increment to 1 as the first impression is produced. An abbreviated example (sheets and jobs, only) should help visualize. For example, assume a 3 impression job with a request for 3 copies. Uncollated 3/3 (copyType =3D External Collation) -------------- sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 1 2 3 1 3 4 2 1 5 2 2 6 2 3 7 3 1 8 3 2 9 3 3 Collated 3/3 (copyType =3D Internal Collation) ------------ sheetsCompleted currentSheetNumber currentCopyNumber --------------- ------------------ ----------------- 1 1 1 2 2 1 3 3 1 4 1 2 5 2 2 6 3 2 7 1 3 8 2 3 9 3 3 The issue of whether or not to keep attributes documentCopiesCompleted(93) jobCopiesCompleted(91) could be resolved by specifying that the final value of currentCopyNumber currentDocumentNumber *is* the completed value and the attribute maintains this value for the remainig life of the entry. I did not show an example using currentDocumentNumber because this is for high end implementations that collate documents within jobs. Nonetheless, the same problem (solution) exists. Harry Lewis = From harryl at us.ibm.com Thu Nov 20 11:24:43 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conference Call Minutes 11/19//97 Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> SOrry - ANOTHER crunched message I had tried to send late last night so= all could review prior to call. Also I really goofed on my conf call messag= e. The Call is TODAY TODAY TODAY!!! at noon-2 MST. Number is 1-888-687-2860 pass code is 404724 Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/20/97= 09:11 AM --------------------------- Harry Lewis 11/19/97 10:53 PM To: jmp@pwg.org@internet cc: From: Harry Lewis/Boulder/IBM @ IBMUS Subject: JMP Conference Call Minutes 11/19//97 We had a 1 hour conference call. Dialed in were, Ron Bergman Tom Hastings Harry Lewis Jay Martin Ira McDonald Bill Wagner Topic of discussion was nested jmJobSubmissionID's. Everyone agrees tha= t the solution is to have the agent map multiple jmJobSubmissionIDs to one jmJobIndex. There is little or no agreement regarding what the real (vs= From harryl at us.ibm.com Thu Nov 20 12:26:36 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Collated/Uncollated Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> I tried to send this a couple times... appoligize if older versions cat= ch up later. There hasn't been a whole lot of discussion regarding my proposal (belo= w) other than Ron indicating he believes it should be accepted. I would like to modify it slightly, in a manner which I believe better accomplishes the goal of distinguishing between collated and uncollated= copies yet results in fewer changes to the Mib. To put it as simply as I can, I propose to add currentCopyNumber currentDocumentNumber copyType and to keep sheetsCompletedCurrentCopy impressionsCompletedCurrentCopy documentCopiesCompleted jobCopiesCompleted The example flows the same as before: For a 3 impression job with a request for 3 copies. Uncollated 3/3 (copyType =3D External Collation) -------------- sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber --------------- -------------------------- ----------------- 1 1 1 2 1 2 3 1 3 4 2 1 5 2 2 6 2 3 7 3 1 8 3 2 9 3 3 Collated 3/3 (copyType =3D Internal Collation) ------------ sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber --------------- -------------------------- ----------------- 1 1 1 2 2 1 3 3 1 4 1 2 5 2 2 6 3 2 7 1 3 8 2 3 9 3 3 The reason for the change from currentSheetNumber and currentImpressonN= umber is that there may be several sheets in the paper path, (different) impress= ions may be ripping and printing at the same time etc. It's very hard to say whi= ch is the "currentImpression" or "currentSheet" but easier to say which is th= e current copy. It is easy to say which sheet has just completed (stacked= ). Note that, while drivers should protect from this, it is theoretically = possible to mix collated and uncollated copies (try it with your favorite printe= r... it's fun!). At this point, attributes like current copy really break do= wn. We feel, rather then try and define even more attributes to handle this pathological case we should just say behavior of the MIB, at this point= , is device specific. Harry Lewis = From harryl at us.ibm.com Thu Nov 20 13:27:23 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Noon Agenda Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Again, I apologize for mixing up the initial invite to this call. The c= all is TODAY at noon-2 MST. Agenda 1. Impressions Requested / Completed. Proposal to rename jmJobImpressionsRequested to jmJobImpressionsRequest= edPerCopy so it fits the description in an unambiguous manner. Proposal to fix the method of counting for jmJobImpressionsCompleted to= "Impressions SHALL be counted as they are completed such that the final= value is a multiple, based on the number of copies, of the value of the jmJobImpressionsRequestedPerCopy attribute". This in place of two metho= ds which depend on how collated copies are produced (rip once or rip many). See Harry's e-mail IMPRESSIONS COMPLETED 11/7. 2. Collated vs. Uncollated copy, sheet and document tracking. Proposal to add currentCopyNumber, currentDocumentNumber, copyType to f= acilitate tracking of both collated and uncollated forms of copy (although not simultaneously). See Harry's e-mail of late "Job MIB doesn't handle Uncollated Copies". 3. Nested jmJobSubmissionID's Follow-on from yesterday. Harry Lewis - IBM Printing Systems = From rbergma at dpc.com Thu Nov 20 11:14:51 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conf Call - revisited In-Reply-To: <5030300014855795000002L052*@MHS> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, I have a conflict with the time scheduled and will not be able to participate in the call. A quick comment for the discussion: My goal in drafting the Mapping document was to provide guidance in creating jmJobSubmissionId without any changes to current job submission protocols. I now propose that this is incorrect. I believe that this corresponds to what you have been stating for quite some time. jmJobSubmissionIds should only be generated when there is a coupled Job Monitoring application that requires its use. Therefore, a Job Monitoring agent for the printer should only generate jmJobSubmissionId when explicitly required by the Job Monitoring Ap. This requires the agent to only develop jmJobSubmissionIds when properly formatted within the job. This reduces the problem I originally formulated, but there still is the issue of multiple submission ids. Unless an alternate solution can be developed, I am in favor of allowing multiple jmJobSubmissionIds to be created for the same job. Ron Bergman Dataproducts Corp. On Wed, 19 Nov 1997, Harry Lewis wrote: > I'm setting up a call tomorrow (Firday) Noon-2 MST (2-4 wayEast; 11-1 wayWest). > > Number is 1-888-687-2860 > pass code is 404724 > > Topics: 1. nested JmJobSubId > 2. collatted / uncollated > > I have 8 lines (we had 6 participants today). Hope you can be there!!! > > Harry Lewis - IBM Printing Systems > From jkm at underscore.com Thu Nov 20 13:44:32 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Collated/Uncollated In-Reply-To: Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> I haven't done due diligence on your proposal, Harry, but I believe the proposal is acceptable as presented. It's also pretty apparent (or should be to most folks by now!) that you are not proposing "theoretical" additions; instead, these proposals are the direct result of IBM's current product development surrounding the proposed Job MIB. Real world needs always out-weigh those proposals submitted in the vein of "just in case someone needs it"... ;-) Ron (Mr. Chairman): would a "deadline for objections" be possible so that Harry et al can get a better handle on planning? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > I tried to send this a couple times... appoligize if older versions catch up > later. > > There hasn't been a whole lot of discussion regarding my proposal (below) other > than Ron indicating he believes it should be accepted. > > I would like to modify it slightly, in a manner which I believe better > accomplishes the goal of distinguishing between collated and uncollated copies > yet results in fewer changes to the Mib. > > To put it as simply as I can, I propose to add > > currentCopyNumber > currentDocumentNumber > copyType > > and to keep > > sheetsCompletedCurrentCopy > impressionsCompletedCurrentCopy > documentCopiesCompleted > jobCopiesCompleted > > The example flows the same as before: > > For a 3 impression job with a request for 3 copies. > > Uncollated 3/3 (copyType = External Collation) > -------------- > > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber > --------------- -------------------------- ----------------- > 1 1 1 > 2 1 2 > 3 1 3 > 4 2 1 > 5 2 2 > 6 2 3 > 7 3 1 > 8 3 2 > 9 3 3 > > Collated 3/3 (copyType = Internal Collation) > ------------ > > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber > --------------- -------------------------- ----------------- > 1 1 1 > 2 2 1 > 3 3 1 > 4 1 2 > 5 2 2 > 6 3 2 > 7 1 3 > 8 2 3 > 9 3 3 > > The reason for the change from currentSheetNumber and currentImpressonNumber is > that there may be several sheets in the paper path, (different) impressions may > be ripping and printing at the same time etc. It's very hard to say which is > the "currentImpression" or "currentSheet" but easier to say which is the > current copy. It is easy to say which sheet has just completed (stacked). > > Note that, while drivers should protect from this, it is theoretically possible > to mix collated and uncollated copies (try it with your favorite printer... > it's fun!). At this point, attributes like current copy really break down. We > feel, rather then try and define even more attributes to handle this > pathological case we should just say behavior of the MIB, at this point, is > device specific. > > Harry Lewis From rbergma at dpc.com Thu Nov 20 13:48:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Collated/Uncollated In-Reply-To: <34748510.E407040C@underscore.com> Message-ID: <3.0.1.32.19971114144823.00ccde60@garfield> Harry, Jay, et al, Harry has posted the original request quite some time ago and I have not seen any objections. The new proposal is "close enough" to the original that I doubt that it will raise any objections. Unless a comment is received by the end of this week, the proposal is declared accepted!! Ron On Thu, 20 Nov 1997, Jay Martin wrote: > I haven't done due diligence on your proposal, Harry, but I believe > the proposal is acceptable as presented. It's also pretty apparent > (or should be to most folks by now!) that you are not proposing > "theoretical" additions; instead, these proposals are the direct > result of IBM's current product development surrounding the proposed > Job MIB. > > Real world needs always out-weigh those proposals submitted in the > vein of "just in case someone needs it"... ;-) > > Ron (Mr. Chairman): would a "deadline for objections" be possible > so that Harry et al can get a better handle on planning? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > Harry Lewis wrote: > > > > I tried to send this a couple times... appoligize if older versions catch up > > later. > > > > There hasn't been a whole lot of discussion regarding my proposal (below) other > > than Ron indicating he believes it should be accepted. > > > > I would like to modify it slightly, in a manner which I believe better > > accomplishes the goal of distinguishing between collated and uncollated copies > > yet results in fewer changes to the Mib. > > > > To put it as simply as I can, I propose to add > > > > currentCopyNumber > > currentDocumentNumber > > copyType > > > > and to keep > > > > sheetsCompletedCurrentCopy > > impressionsCompletedCurrentCopy > > documentCopiesCompleted > > jobCopiesCompleted > > > > The example flows the same as before: > > > > For a 3 impression job with a request for 3 copies. > > > > Uncollated 3/3 (copyType = External Collation) > > -------------- > > > > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber > > --------------- -------------------------- ----------------- > > 1 1 1 > > 2 1 2 > > 3 1 3 > > 4 2 1 > > 5 2 2 > > 6 2 3 > > 7 3 1 > > 8 3 2 > > 9 3 3 > > > > Collated 3/3 (copyType = Internal Collation) > > ------------ > > > > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber > > --------------- -------------------------- ----------------- > > 1 1 1 > > 2 2 1 > > 3 3 1 > > 4 1 2 > > 5 2 2 > > 6 3 2 > > 7 1 3 > > 8 2 3 > > 9 3 3 > > > > The reason for the change from currentSheetNumber and currentImpressonNumber is > > that there may be several sheets in the paper path, (different) impressions may > > be ripping and printing at the same time etc. It's very hard to say which is > > the "currentImpression" or "currentSheet" but easier to say which is the > > current copy. It is easy to say which sheet has just completed (stacked). > > > > Note that, while drivers should protect from this, it is theoretically possible > > to mix collated and uncollated copies (try it with your favorite printer... > > it's fun!). At this point, attributes like current copy really break down. We > > feel, rather then try and define even more attributes to handle this > > pathological case we should just say behavior of the MIB, at this point, is > > device specific. > > > > Harry Lewis > From lstein at fapo.com Thu Nov 20 15:26:58 1997 From: lstein at fapo.com (Larry Stein) Date: Wed May 6 14:00:12 2009 Subject: JMP> January Meeting Notice Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From jkm at underscore.com Thu Nov 20 15:29:13 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conf Call - revisited In-Reply-To: JMP Conf Call - revisited> Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Ron, > jmJobSubmissionIds should only be generated when there is a coupled Job > Monitoring application that requires its use. Therefore, a Job Monitoring > agent for the printer should only generate jmJobSubmissionId when > explicitly required by the Job Monitoring Ap. This requires the agent to > only develop jmJobSubmissionIds when properly formatted within the job. It's too bad you couldn't make the second telecon. Others in that call also believed that "driver-like" software (ie, components that package and deliver a job to the next element in the printing system chain) would OF COURSE be intimately tied to the Job MIB. Dave Kellerman and I showed how this wasn't necessarily true, citing existing real-world implementations in the field today. Upon hearing our explanation, the others in the call seemed to understand and agree with us. If anyone on the list (who wasn't on the telecon today) needs more info, then I'll take the (substantial) time to document the situation and post it to the list. However, I'd prefer to wait until the upcoming Los Angeles meeting so that we can talk face-to-face and draw diagrams, etc. > This reduces the problem I originally formulated, but there still is the > issue of multiple submission ids. Unless an alternate solution can be > developed, I am in favor of allowing multiple jmJobSubmissionIds to be > created for the same job. Everyone on the telecon today agreed that, despite our somewhat differing views on "expected implementations", the solution as proposed by Harry certainly appears to satisfy everyone's needs without substantial heartburn. Harry's solution can be summarized as: Multiple jmJobSubmissionId values can exist for a single job, but all of them reference a single jmJobIndex. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From rbergma at dpc.com Thu Nov 20 17:06:53 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Conf Call - revisited In-Reply-To: <34749D99.6D9FB9EE@underscore.com> Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Jay, Thanks for the update. If you have time, maybe a short summary regarding the position presented by yourself and Dave? (But if you don't have the time I can wait for the LA meeting.) Thanks again, Ron On Thu, 20 Nov 1997, Jay Martin wrote: > Ron, > > > jmJobSubmissionIds should only be generated when there is a coupled Job > > Monitoring application that requires its use. Therefore, a Job Monitoring > > agent for the printer should only generate jmJobSubmissionId when > > explicitly required by the Job Monitoring Ap. This requires the agent to > > only develop jmJobSubmissionIds when properly formatted within the job. > > It's too bad you couldn't make the second telecon. Others in > that call also believed that "driver-like" software (ie, components > that package and deliver a job to the next element in the printing > system chain) would OF COURSE be intimately tied to the Job MIB. > > Dave Kellerman and I showed how this wasn't necessarily true, citing > existing real-world implementations in the field today. Upon hearing > our explanation, the others in the call seemed to understand and > agree with us. > > If anyone on the list (who wasn't on the telecon today) needs more > info, then I'll take the (substantial) time to document the situation > and post it to the list. However, I'd prefer to wait until the > upcoming Los Angeles meeting so that we can talk face-to-face and > draw diagrams, etc. > > > > This reduces the problem I originally formulated, but there still is the > > issue of multiple submission ids. Unless an alternate solution can be > > developed, I am in favor of allowing multiple jmJobSubmissionIds to be > > created for the same job. > > Everyone on the telecon today agreed that, despite our somewhat > differing views on "expected implementations", the solution as > proposed by Harry certainly appears to satisfy everyone's needs > without substantial heartburn. > > Harry's solution can be summarized as: Multiple jmJobSubmissionId > values can exist for a single job, but all of them reference a > single jmJobIndex. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From harryl at us.ibm.com Thu Nov 20 18:35:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> JPM conference call minutes Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Today's call was from noon-1:30 MST. Dialed in were Tom Hastings David Kellerman Harry Lewis Jay Martin Brian Peavey Bob Pentecost 1. Nested jmJobSubmissionID's This discussion is so bogged down in the fundamental use and topology o= f print job monitoring in both tightly integrated and distributed environments,= that it is very difficult to visualize without props. Because the discussion ce= nters around the heart of the uses of the Job MIB it is considered valuable e= nough to warrant some time at the next JMP meeting, in LA. Ron Bergman (chair) w= ill be asked to schedule some time on the agenda. Those who want to contribute= to the discussion should be prepared to sketch their system design or otherwis= e present their ideas in a way that others will easily grasp their meanin= g. Meanwhile, to move on from this issue, it has been agreed that, should = multiple jmJobSubmissionID's ever become a problem, the way to address the issue= is to allow multiple jmJobSubmissionID's to point to one jmJobIndex in the jo= bID table. Tom will draft this change to the Job MIB and make the change av= ailable for review prior to LA. 2. ImpressionsRequested - ImpressionsCompleted - It was agreed that jmJobImpressionsRequested pertains to the number = of impressions which would be found in ONE copy. The name will be changed = to jmJobImpressionsRequestedPerJob. - It was observed that it was probably an editorial slip to suggest tha= t ImpressionsCompleted be counted one way for "rip once" copies and anoth= er way for "rip many" copies. The definition will be simplified and clarified = to indicate that jmJobImpressionsCompleted is a count of impressions as th= e sheet they are on stacks. - It was observed that ImpressionsInterprted definitely COULD be counte= d differently depending on the number of times the job is ripped if copie= s are involved. Three alternatives were discussed. a. Deprecate the jmJobImpressionsInterpreted attribute. b. Define a copyType (as part of a new attributed to be added for number 3, below) that distinguishes between collated - rip once and collated - rip many. c. Expect applications to determine on the fly which copy production method is in effect by realizing, if the impressionsInterpreted attribute exceeds the value of impressionsRequestedPerCopy it must be "rip-many". These options to be discussed via e-mail. 3. Collated / Uncollated It was agreed that there is a problem here. The current attribute defin= itions cannot handle uncollated copies because impressionsCompletedCurrentCopy= has no meaning. Harry's latest proposal was reviewed and accepted among this g= roup of participants. That is... Add currentCopyNumber currentDocumentNumber copyType See examples in Harry's previous mail for full details. Tom to include = in Job MIB and make available for review prior to LA. It was agreed that, if collated and uncollated copy requests are mixed = within a single job, the Job MIB becomes in-deterministic and we will not attemp= t to specify behavior. Also, it was observed that uncollated and collation to a series of outp= ut bins are equivalent in terms of how sheets and impressions exit the printer.= Thus the proposed copyType names are InternalCollation (.i.e "Mopy") and ExternalCollation (uncollated or collation to multiple outputs). The next planned meeting on these topics is in LA. Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Thu Nov 20 20:41:23 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> JPM conference call minutes - correction Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> I need to make a correction to the minutes... 2. ImpressionsRequested - ImpressionsCompleted - It was agreed that jmJobImpressionsRequested pertains to the number = of impressions which would be found in ONE copy. The name will be changed = to jmJobImpressionsRequestedPerJob. The last line should be jmJobImpressionsRequestedPerCopy! Also, Tom has since fleshed out the entire example including DOCUMENT copies and concludes that one additional copyType is necessary. So the copyType proposal is copyType (enum) 1 Other 2 Unknown 3 External Collation 4 Internal Collation with Collated Documents 5 Internal Collation with un-Collated Documents. The rule is, if there is one copy or one document then copyType =3D 4. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis ---- jmp-owner@pwg.org on 11/20/97 04:34:30 PM Please respond to jmp-owner@pwg.org @ internet To: JMP@pwg.org @ internet cc: jkm@underscore.com @ internet, hastings@cp10.es.xerox.com @ interne= t, bpenteco@boi.hp.com @ internet, kellerman@nls.com @ internet, rbergma@d= pc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ internet Subject: JMP> JPM conference call minutes Today's call was from noon-1:30 MST. Dialed in were Tom Hastings David Kellerman Harry Lewis Jay Martin Brian Peavey Bob Pentecost 1. Nested jmJobSubmissionID's This discussion is so bogged down in the fundamental use and topology o= f print job monitoring in both tightly integrated and distributed environments,= that it is very difficult to visualize without props. Because the discussion ce= nters around the heart of the uses of the Job MIB it is considered valuable e= nough to warrant some time at the next JMP meeting, in LA. Ron Bergman (chair) w= ill be asked to schedule some time on the agenda. Those who want to contribute= to the discussion should be prepared to sketch their system design or otherwis= e present their ideas in a way that others will easily grasp their meanin= g. Meanwhile, to move on from this issue, it has been agreed that, should = multiple jmJobSubmissionID's ever become a problem, the way to address the issue= is to allow multiple jmJobSubmissionID's to point to one jmJobIndex in the jo= bID table. Tom will draft this change to the Job MIB and make the change av= ailable for review prior to LA. 2. ImpressionsRequested - ImpressionsCompleted - It was agreed that jmJobImpressionsRequested pertains to the number = of impressions which would be found in ONE copy. The name will be changed = to jmJobImpressionsRequestedPerJob. - It was observed that it was probably an editorial slip to suggest tha= t ImpressionsCompleted be counted one way for "rip once" copies and anoth= er way for "rip many" copies. The definition will be simplified and clarified = to indicate that jmJobImpressionsCompleted is a count of impressions as th= e sheet they are on stacks. - It was observed that ImpressionsInterprted definitely COULD be counte= d differently depending on the number of times the job is ripped if copie= s are involved. Three alternatives were discussed. a. Deprecate the jmJobImpressionsInterpreted attribute. b. Define a copyType (as part of a new attributed to be added for number 3, below) that distinguishes between collated - rip once and collated - rip many. c. Expect applications to determine on the fly which copy production method is in effect by realizing, if the impressionsInterpreted attribute exceeds the value of impressionsRequestedPerCopy it must be "rip-many". These options to be discussed via e-mail. 3. Collated / Uncollated It was agreed that there is a problem here. The current attribute defin= itions cannot handle uncollated copies because impressionsCompletedCurrentCopy= has no meaning. Harry's latest proposal was reviewed and accepted among this g= roup of participants. That is... Add currentCopyNumber currentDocumentNumber copyType See examples in Harry's previous mail for full details. Tom to include = in Job MIB and make available for review prior to LA. It was agreed that, if collated and uncollated copy requests are mixed = within a single job, the Job MIB becomes in-deterministic and we will not attemp= t to specify behavior. Also, it was observed that uncollated and collation to a series of outp= ut bins are equivalent in terms of how sheets and impressions exit the printer.= Thus the proposed copyType names are InternalCollation (.i.e "Mopy") and ExternalCollation (uncollated or collation to multiple outputs). The next planned meeting on these topics is in LA. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Thu Nov 20 19:29:22 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Collated/Uncollated In-Reply-To: Message-ID: <3.0.1.32.19971120162922.00f00940@garfield> I agree with Harry's proposal, but want to build on it by handling IPP where there can be multiple documents per job. First a nit. The examples show sheetsCompleted. They should show impressionsCompleted. The examples are only true for single sided printing, correct? So I've changed them below and abbreviated as Impres. As discussed on the telecon and agreed in principle by Harry, we would need one more attribute called currentDocumentNumber. It goes from 0 before any processing takes place to n when the nth document in the job submission is taking place. If a job as documents A and B, whenever A is being processed, the currentDocumentNumber is 1, and when B is being processed, the currentDocumentNumber is 2. If an implementation only supports one document jobs, this attribute NEED NOT be implemented when implementing the others. IPP has collated documents within a job and uncollated documents within a job. If a job has documents A and B, and wants n copies, collated documents come out: A, B, A, B, .... and uncollated documents come out: A, A, ..., B, B, ... So the examples become: The example flows the same as before: For a 3 impression job with a request for 3 copies and two documents. Uncollated 3/3 (copyType = External Sheet Collation - either by a physical) -------------- output bin collator or uncollated - so user does by hand and 'separate-document-uncollated-copies' is assumed) ImpresCompleted ImpresCompleted CurrentCopy currentCopyNumber currentDocumentNumber --------------- ----------- ----------------- --------------------- 1 1 1 1 2 1 2 1 3 1 3 1 4 2 1 1 5 2 2 1 6 2 3 1 7 3 1 1 8 3 2 1 9 3 3 1 10 1 1 2 11 1 2 2 12 1 3 2 13 2 1 2 14 2 2 2 15 2 3 2 16 3 1 2 17 3 2 2 18 3 3 2 Collated 3/3 (copyType = Internal Collation - Mopier ------------ and 'separate-document-uncollated-copies') ImpressCompleted ImpresCompleted CurrentCopy currentCopyNumber currentDocumentNumber --------------- ----------- ----------------- --------------------- 1 1 1 1 2 2 1 1 3 3 1 1 4 1 2 1 5 2 2 1 6 3 2 1 7 1 3 1 8 2 3 1 9 3 3 1 10 1 1 2 11 2 1 2 12 3 1 2 13 1 2 2 14 2 2 2 15 3 2 2 16 1 3 2 17 2 3 2 18 3 3 2 Collated 3/3 (copyType = Internal Collation - Mopier ------------ and 'separate-document-collated-copies') ImpresCompleted ImpresCompleted CurrentCopy currentCopyNumber currentDocumentNumber --------------- ----------- ----------------- --------------------- 1 1 1 1 2 2 1 1 3 3 1 1 4 1 1 2 5 2 1 2 6 3 1 2 7 1 2 1 8 2 2 1 9 3 2 1 10 1 2 2 11 2 2 2 12 3 2 2 13 1 3 1 14 2 3 1 15 3 3 1 16 1 3 2 17 2 3 2 18 3 3 2 It seems that it isn't possible to do External Collation with 'separate-document-collated-copies'. We also need to divide the copyType Internal Collation enum into two enums: Internal Collation with 'separate-document-collated-copies' Internal Collation with 'separate-document-uncollated-copies' The two are the same for one document jobs and one document implemetnations, so we need to pick the value to use for the simple case of one document jobs. We also need to pick some good names, since we are overloading the term "collation" to mean sheets within a copy and documents within a job. Tom At 10:48 11/20/1997 PST, Ron Bergman wrote: >Harry, Jay, et al, > >Harry has posted the original request quite some time ago and I have not >seen any objections. The new proposal is "close enough" to the original >that I doubt that it will raise any objections. > >Unless a comment is received by the end of this week, the proposal is >declared accepted!! > > > Ron > > >On Thu, 20 Nov 1997, Jay Martin wrote: > >> I haven't done due diligence on your proposal, Harry, but I believe >> the proposal is acceptable as presented. It's also pretty apparent >> (or should be to most folks by now!) that you are not proposing >> "theoretical" additions; instead, these proposals are the direct >> result of IBM's current product development surrounding the proposed >> Job MIB. >> >> Real world needs always out-weigh those proposals submitted in the >> vein of "just in case someone needs it"... ;-) >> >> Ron (Mr. Chairman): would a "deadline for objections" be possible >> so that Harry et al can get a better handle on planning? >> >> ...jay >> >> ---------------------------------------------------------------------- >> -- JK Martin | Email: jkm@underscore.com -- >> -- Underscore, Inc. | Voice: (603) 889-7000 -- >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >> ---------------------------------------------------------------------- >> >> >> Harry Lewis wrote: >> > >> > I tried to send this a couple times... appoligize if older versions catch up >> > later. >> > >> > There hasn't been a whole lot of discussion regarding my proposal (below) other >> > than Ron indicating he believes it should be accepted. >> > >> > I would like to modify it slightly, in a manner which I believe better >> > accomplishes the goal of distinguishing between collated and uncollated copies >> > yet results in fewer changes to the Mib. >> > >> > To put it as simply as I can, I propose to add >> > >> > currentCopyNumber >> > currentDocumentNumber >> > copyType >> > >> > and to keep >> > >> > sheetsCompletedCurrentCopy >> > impressionsCompletedCurrentCopy >> > documentCopiesCompleted >> > jobCopiesCompleted >> > >> > The example flows the same as before: >> > >> > For a 3 impression job with a request for 3 copies. >> > >> > Uncollated 3/3 (copyType = External Collation) >> > -------------- >> > >> > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber >> > --------------- -------------------------- ----------------- >> > 1 1 1 >> > 2 1 2 >> > 3 1 3 >> > 4 2 1 >> > 5 2 2 >> > 6 2 3 >> > 7 3 1 >> > 8 3 2 >> > 9 3 3 >> > >> > Collated 3/3 (copyType = Internal Collation) >> > ------------ >> > >> > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber >> > --------------- -------------------------- ----------------- >> > 1 1 1 >> > 2 2 1 >> > 3 3 1 >> > 4 1 2 >> > 5 2 2 >> > 6 3 2 >> > 7 1 3 >> > 8 2 3 >> > 9 3 3 >> > >> > The reason for the change from currentSheetNumber and currentImpressonNumber is >> > that there may be several sheets in the paper path, (different) impressions may >> > be ripping and printing at the same time etc. It's very hard to say which is >> > the "currentImpression" or "currentSheet" but easier to say which is the >> > current copy. It is easy to say which sheet has just completed (stacked). >> > >> > Note that, while drivers should protect from this, it is theoretically possible >> > to mix collated and uncollated copies (try it with your favorite printer... >> > it's fun!). At this point, attributes like current copy really break down. We >> > feel, rather then try and define even more attributes to handle this >> > pathological case we should just say behavior of the MIB, at this point, is >> > device specific. >> > >> > Harry Lewis >> > > > From jkm at underscore.com Fri Nov 21 09:56:21 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: JPM conference call minutes In-Reply-To: Message-ID: <3.0.1.32.19971120162922.00f00940@garfield> > - It was observed that ImpressionsInterprted definitely COULD be counted > differently depending on the number of times the job is ripped if copies are > involved. Three alternatives were discussed. > > a. Deprecate the jmJobImpressionsInterpreted attribute. Hopefully this is just a nit (ie, no debate), but I don't think we want to _deprecate_ any object that we want to remove from the Job MIB draft. Instead, we simply want to _remove_ that object. Deprecation should only be pertinent in future versions of the MIB, after the initial draft is finalized and published. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From rbergma at dpc.com Mon Nov 24 11:23:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> Addition of natural language attributes to JMP to align with IPP In-Reply-To: <3.0.1.32.19971113162337.00f62620@garfield> Message-ID: <3.0.1.32.19971120162922.00f00940@garfield> Tom, I known this is late, but better late than never? Your proposal is very good, with some minor changes. See my comments preceded by RB>>. Although this change probably falls into the "just in case someone needs it", we might as well incorporate this since the work is complete. Since there have been no other comments posted regarding this change, I believe that it has been accepted by the group. Ron Bergman Dataproducts Corp. On Thu, 13 Nov 1997, Tom Hastings wrote: > I've posted my action item to propose to the DL the addition of charset and > natural language attributes to the Job Monitoring MIB to align with IPP > that is now in WG Final Call. The files are in: > **** snip...snip > Here are the detailed proposals: > **** snip...snip > 2. Add to the end of section 3.5.1, "Text generated by the server or > device" as a new paragraph: > > The text message for the processingMessage(6) attribute is generated by the > server/device. RB>> I found the above sentence to be somewhat confusing primarily due to RB>> the multiple occurrences of "message". I suggest rewording to: RB>> "The text contained in the processingMessage(6) attribute is RB>> generated by the server/device." The natural language for the processingMessage(6) attribute > is identified by the processingMessageNaturalLanguageTag(7) attribute. The > processingMessageNaturalLanguageTag(7) attribute value SHALL conform to the > language tag mechanism specified in RFC 1766 [RFC-1766]. Each attribute > value is the same as the IPP [IPP-MOD] naturalLanguage attribute syntax. > RFC 1766 specifies that a US-ASCII string consisting of the natural > language followed by an optional country field. Both fields use the same > two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], > respectively, that are used in the Printer MIB for identifying language and > country. RB>> The follow test is repeated, see item 4. Though RFC 1766 requires that the values be case-insensitive > US-ASCII, this MIB specification requires all lower case to simplify > comparing by management applications. > Examples of the values of the processingMessageNaturalLanguageTag(7) > attribute include: > > 'en' for English > 'en-us' for US English > 'fr' for French > 'de' for German > > **** snip...snip > > 4. Add the following textual convention: > > JmNaturalLanguageTagTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An IETF RFC 1766-compliant 'language tag', with zero or more sub-tags that > identify a natural language. RB>> The following line is repeated from the text that is proposed for RB>> section 3.5.1. While RFC 1766 specifies that the US-ASCII > values are case-insensitive, this MIB specification requires that all > characters SHALL be lower case in order to simplify comparing by management > applications." > REFERENCE > "See section 3.5.1, entitled: 'Text generated by the server or device' and > section 3.5.2, entitled: 'Text supplied by the job submitter'." > SYNTAX OCTET STRING (SIZE (0..63)) > > **** snip...snip From don at lexmark.com Mon Nov 24 15:59:11 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:12 2009 Subject: JMP> LA Schedule Message-ID: <199711242107.AA29754@interlock2.lexmark.com> Given that Jay will not be able to attend the LA meeting, the following is the schedule for the week. Changes are only to Thursday and Friday. Mon/Tues 1394 Printing Wednesday IPP Thursday Finisher MIB Friday Job MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Tue Nov 25 16:49:50 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> New version of Job Monitoring MIB (V0.87) available: Tues 12/2 Message-ID: <3.0.1.32.19971125134950.01097e40@garfield> I'll post with revision marks. I'll also bring revision marked and clean versions on paper Wednesday AM to the IPP meeting, 12/3 so you can all review for Friday, 12/5, JMP meeting. Sorry not to have it out this week, but IPP WG Final Call and Thanksgiving are keeping me from finishing. Things to be included from the e-mail list: 1. Make a PWG standard 2. New PWG OIDs 3. Natural Language support including Ron's editorial comments 4. New Monitoring for collated/uncollated implementations 5. Fixing ImpressionsCompleted 6. Any new Job Submission IDs Anything else? Thanks, Tom From imcdonal at eso.mc.xerox.com Tue Nov 25 21:30:57 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:12 2009 Subject: JMP> New version of Job Monitoring MIB (V0.87) available: Tues 12/2 In-Reply-To: New version of Job Monitoring MIB (V0.87) available: Tues 12/2> Message-ID: <9711260230.AA04758@snorkel.eso.mc.xerox.com> Hi Tom, Something else - you speculated in an IPP Telecon (last week) that the way to handle very long URLs (in the Job Monitoring MIB) from IPP was to have them 'segment' into max-length (63 octets??) fragments in the attribute table. Do JMP Working Group members want this behaviour? Truncation of URLs is particularly ugly. Also what about very long strings (like descriptions) from IPP? Same behavior? Cheers, - Ira McDonald (outside consultant at Xerox) 716-442-0609 ---------------------------- Return-Path: Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA04661; Tue, 25 Nov 97 16:58:41 EST Received: from alpha.xerox.com by zombi.eso.mc.xerox.com (4.1/SMI-4.1) id AA00782; Tue, 25 Nov 97 16:53:49 EST Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52240(5)>; Tue, 25 Nov 1997 13:53:53 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07329 for ; Tue, 25 Nov 1997 16:50:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 16:48:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07187 for jmp-outgoing; Tue, 25 Nov 1997 16:46:24 -0500 (EST) Message-Id: <3.0.1.32.19971125134950.01097e40@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Nov 1997 13:49:50 PST To: jmp@pwg.org From: Tom Hastings Subject: JMP> New version of Job Monitoring MIB (V0.87) available: Tues 12/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Status: R I'll post with revision marks. I'll also bring revision marked and clean versions on paper Wednesday AM to the IPP meeting, 12/3 so you can all review for Friday, 12/5, JMP meeting. Sorry not to have it out this week, but IPP WG Final Call and Thanksgiving are keeping me from finishing. Things to be included from the e-mail list: 1. Make a PWG standard 2. New PWG OIDs 3. Natural Language support including Ron's editorial comments 4. New Monitoring for collated/uncollated implementations 5. Fixing ImpressionsCompleted 6. Any new Job Submission IDs Anything else? Thanks, Tom From harryl at us.ibm.com Tue Dec 2 14:23:29 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Further Clarifications on counting Message-ID: <9711260230.AA04758@snorkel.eso.mc.xerox.com> There is ambiguity in our definition of attributes like impressionsCompletedCurrentCopy and currentCopyNumber in terms of how t= o synchronize them. Basically, the first is a trailing edge function, the= second is leading edge. This results in undefined states between the last impr= ession of a copy and the first impression of the next copy. I would like to rename currentCopyNumber to sheetCompleteCopyNumber and= make sure the definition clearly points out that all "currentCopy" attribute= s trigger off the SAME event, which is basically a sheet stacking. The sheetCompleteCopyNumber should start with a value of -1 or -2 to indica= te it has no meaning until at least one sheet has stacked. When the sheet sta= cks then the values impressionsCompletedCurrentCopy =3D 2 and sheetCompleteCopyN= umber =3D 1 make sense. The sheetCompleteCopyNumber should always refer to the copy= number of the last sheet stacked and never point forward to some future copy w= hich is being worked on. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Tue Dec 2 14:45:44 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> Structuring of the PWG enterprise OID tree In-Reply-To: <346B2CB8.3F825C7@underscore.com> Message-ID: <3.0.1.32.19971202114544.00ea91e0@garfield> I started to edit the Job Monitoring MIB with the PWG standard OIDs as proposed, even though I preferred Harry's flat OID approach. However, when discussing how to write it in SNMP ASN.1 with Ira, we realized that maybe the PWG ought to distinguish between PWG experimental OIDs and PWG standard OIDs, just like with the IETF MIBs. So we propose the following: Under iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) we have separate trees for PWG experimental and PWG standard: pwg(2699) pwgstandard(1) jobmon(1) pwg(2699) pwgexperimental(2) jobmon(1) Our current jobmon MIB is so near to becoming a PWG standard that we don't need this distinction. We haven't changed an OID during the last six months of drafts. However, just to be safe, I'm going to publish the next draft using the pwgexperimental(2) arc. Then if we decide that the above OID scheme isn't any good, we can change it. Experimental OIDs are free to be changed from draft to draft, but standard ones are not. The idea of pwgstandard OIDs is that the OIDs never change after being published, just like the IETF. (Adding new OIDs can be done to standards, that is NOT changing published OIDs). We also propose NOT to asign arc to PWG projects, but to actual PWG needs, in this case the jobmon mib. Thus a project can get one or more arcs assigned, depending on its needs. Also OIDs can be assigned for non-MIB purposes as well. Another advantage to this approach, is that we don't need to decide now what categories we might want in the future. Ok? Tom At 08:37 11/13/1997 PST, Jay Martin wrote: >Don, > >Well, ok. I guess all we can derive from your explanation is that >you want to put all MIBs under one subtree, and other "things" in >other subtrees (eg, IPP under a separate top-level subtree). > >I guess that's ok...but I sure would like some idea of what the >other "things" might be. Either way, your approach is certainly >acceptable. > >If there are no substantive objections, we shall assume the >approach described by Don (below). > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > >don@lexmark.com wrote: >> >> JK Martin said: >> >> >> On a more technical note, I would suggest that we >> >> consider moving the Job MIB down one level in the >> >> OID space. I would prefer something like >> >> >> >> ..... 2699.1.1...... Job Mib >> >> ......2699.1.2...... Finisher MIB >> >> >> >> ...... 2699.2.1 ...... maybe IPP space? >> >> ...... 2699.3.1 ..... something else using OID space >> >> >> >> etc. >> > >> >What is your thinking here? I mean, what is the significance >> >of putting JMP/FIN under ...2699.1 versus having IPP under .3, >> >etc? Are you in some way suggesting a set of categories for >> >the top-level OID (ie, .2699.1, .2699.2, etc)? >> > >> >This approach sounds good to me; it's just that I'm trying to >> >figure out your plan here. >> >> My suggestion on the structure of the usage of our >> Enterprise number is to insure some kind of ordering >> and structure to our usage. I would prefer something >> like >> >> 2699 >> | >> +-------+------...--+ >> | | | | >> 1 2 3 n >> +---+ +---+ +---+ +----+ >> | | | | | | | | | >> JMP-+ | | | | | >> | | | | | >> FIN --+ | | | | >> | | | | >> etc ----+ | | | >> | | | >> | | | >> attributes--+ | | >> | | >> operations ---+ | >> | >> etc ------------+ >> >> This would allow us to put all the MIB work at one point >> (2699.1) and maybe all the IPP at another (2699.2) (maybe >> the need for IPP is non-existant but I use it as an example) >> and other "types" of objects at other places, properly grouped. >> I think this is a better structure than maybe: >> >> 2699 >> | >> +-------+------...--+ >> | | | | >> 1 2 3 n >> + +---+ + +----+ >> | | | | | >> JMP---+ | | | | >> | | | | >> attributes -+ | | | >> | | | >> operations -----+ | | >> | | >> FIN --------------+ | >> | >> etc -------------------+ >> >> Maybe its my obsessive/compulsive need for order and structure >> but that's my intent anyway. >> >> Does that explain it? >> >> Don >> >> ********************************************** >> * Don Wright don@lexmark.com * >> * Manager, Strategic Alliances and Standards * >> * Lexmark International * >> * 740 New Circle Rd * >> * Lexington, Ky 40550 * >> * 606-232-4808 (phone) 606-232-6740 (fax) * >> ********************************************** > > From hastings at cp10.es.xerox.com Tue Dec 2 15:38:10 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Further Clarifications on counting In-Reply-To: <5030300015651646000002L062*@MHS> Message-ID: <3.0.1.32.19971202123810.00eafdc0@garfield> At 11:23 12/02/1997 PST, Harry Lewis wrote: >There is ambiguity in our definition of attributes like >impressionsCompletedCurrentCopy and currentCopyNumber in terms of how to >synchronize them. Basically, the first is a trailing edge function, the second >is leading edge. This results in undefined states between the last impression >of a copy and the first impression of the next copy. In other words, if the currentCopyNumber advanced as the device starts to work on the next copy, but the impressionsCompletedCurrentCopy remained at the number of impressions in that copy, it would look like the new copy had done a whole bunch of impressions at once. So both attributes need to be changed on the same event as you point out. > >I would like to rename currentCopyNumber to sheetCompleteCopyNumber and make >sure the definition clearly points out that all "currentCopy" attributes >trigger off the SAME event, which is basically a sheet stacking. The >sheetCompleteCopyNumber should start with a value of -1 or -2 to indicate it >has no meaning until at least one sheet has stacked. When the sheet stacks then >the values impressionsCompletedCurrentCopy = 2 and sheetCompleteCopyNumber = 1 >make sense. The sheetCompleteCopyNumber should always refer to the copy number >of the last sheet stacked and never point forward to some future copy which is >being worked on. Sounds good. How about changing the name from currentCopyNumber to stackedCopyNumber, instead of sheetCompleteCopyNumber? Also, why can't the value of stackedCopyNumber be 0 before the first sheet of the first copy is stacked, instead of -1 or -2? So the possible values for each are through time: stackedCopyNumber impressionsCompletedCurrentCopy 0 0 1 1 1 2 1 3 2 1 2 2 2 3 The last values stay that way until the job is deleted. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Tue Dec 2 15:54:32 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree In-Reply-To: Structuring of the PWG enterprise OID tree> Message-ID: <3.0.1.32.19971202123810.00eafdc0@garfield> Tom, I like your idea for experimental and standard. My only question i= s what triggers a standard registration and when do we expect this for the Job= MIB? Harry Lewis ----- Forwarded by Harry Lewis ------ owner-pwg@pwg.org on 12/02/97 12:54:27 PM Please respond to owner-pwg@pwg.org @ internet To: don@lexmark.com @ internet, jkm@underscore.com @ internet cc: JMP@pwg.org @ internet, pwg@pwg.org @ internet Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree I started to edit the Job Monitoring MIB with the PWG standard OIDs as proposed, even though I preferred Harry's flat OID approach. However, when discussing how to write it in SNMP ASN.1 with Ira, we realized that maybe the PWG ought to distinguish between PWG experimental OIDs and PWG standard OIDs, just like with the IETF MIBs. So we propose the following: Under iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) we have separate trees for PWG experimental and PWG standard: pwg(2699) pwgstandard(1) jobmon(1) pwg(2699) pwgexperimental(2) jobmon(1) Our current jobmon MIB is so near to becoming a PWG standard that we don't need this distinction. We haven't changed an OID during the last six months of drafts. However, just to be safe, I'm going to publish the next draft using the pwgexperimental(2) arc. Then if we decide that the above OID scheme isn't any good, we can change it. Experimental OIDs are free to be changed from draft to draft, but standard ones are not. The idea of pwgstandard OIDs is that the OIDs never change after being published, just like the IETF. (Adding new OIDs can be done to standards, that is NOT changing published OIDs). We also propose NOT to asign arc to PWG projects, but to actual PWG needs, in this case the jobmon mib. Thus a project can get one or more arcs assigned, depending on its needs. Also OIDs can be assigned for non-MIB purposes as well. Another advantage to this approach, is that we don't need to decide now what categories we might want in the future. Ok? Tom = From harryl at us.ibm.com Tue Dec 2 16:15:55 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Re: Further Clarifications on counting In-Reply-To: Message-ID: <3.0.1.32.19971202123810.00eafdc0@garfield> Tom, I agree with your name recommendation... >>How about changing the name from currentCopyNumber to stackedCopyNumb= er, instead of sheetCompleteCopyNumber? ... as long as no one gets the impression that it can only represent th= e number of STACKED (i.e. completed) copies. The name is less important than the= definition and I like your name because it is shorter. We could even us= e a name like copyCounter and just define it carefully. You had another question... >>Also, why can't the value of stackedCopyNumber be 0 before the first sheet of the first copy is stacked, instead of -1 or -2? It could be zero. We thought a - integer was more in keeping with the w= ay we've done things in the past that basically have no valid value. Maybe Ira c= an help us here. Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 12/02/97= 01:51 PM --------------------------- hastings@cp10.es.xerox.com on 12/02/97 01:45:32 PM Please respond to hastings@cp10.es.xerox.com @ internet To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: rbergma@dpc.com @ internet Subject: Re: Further Clarifications on counting At 11:23 12/02/1997 PST, Harry Lewis wrote: >There is ambiguity in our definition of attributes like >impressionsCompletedCurrentCopy and currentCopyNumber in terms of how = to >synchronize them. Basically, the first is a trailing edge function, th= e second >is leading edge. This results in undefined states between the last imp= ression >of a copy and the first impression of the next copy. In other words, if the currentCopyNumber advanced as the device starts to work on the next copy, but the impressionsCompletedCurrentCopy remai= ned at the number of impressions in that copy, it would look like the new c= opy had done a whole bunch of impressions at once. So both attributes need to be changed on the same event as you point ou= t. > >I would like to rename currentCopyNumber to sheetCompleteCopyNumber an= d make >sure the definition clearly points out that all "currentCopy" attribut= es >trigger off the SAME event, which is basically a sheet stacking. The >sheetCompleteCopyNumber should start with a value of -1 or -2 to indic= ate it >has no meaning until at least one sheet has stacked. When the sheet st= acks then >the values impressionsCompletedCurrentCopy =3D 2 and sheetCompleteCopy= Number =3D 1 >make sense. The sheetCompleteCopyNumber should always refer to the cop= y number >of the last sheet stacked and never point forward to some future copy which is >being worked on. Sounds good. How about changing the name from currentCopyNumber to stackedCopyNumber= , instead of sheetCompleteCopyNumber? Also, why can't the value of stackedCopyNumber be 0 before the first sheet of the first copy is stacked, instead of -1 or -2? So the possible values for each are through time: stackedCopyNumber impressionsCompletedCurrentCopy 0 0 1 1 1 2 1 3 2 1 2 2 2 3 The last values stay that way until the job is deleted. > >Harry Lewis - IBM Printing Systems > > = From jkm at underscore.com Tue Dec 2 17:43:19 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:12 2009 Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree In-Reply-To: Re: JMP> Structuring of the PWG enterprise OID tree> Message-ID: <3.0.1.32.19971202123810.00eafdc0@garfield> Tom, I, too, tend to like your proposal. However, instead of: > pwg(2699) pwgstandard(1) jobmon(1) > pwg(2699) pwgexperimental(2) jobmon(1) How about more simple words, such as: pwg(2699) standard(1) jobmon(1) pwg(2699) experimental(2) jobmon(1) That is, there is no real value in having the "pwg" prefix. The more I think of it, though, I don't think we need to have an explicit "standard" tree. Instead--just like the IETF--we have an "experimental" subtree, but all other trees at that level represent "standard" assignments. This means we end up with (for example): pwg(2699) jobmon(1) pwg(2699) experimental(2) jobmon(1) Btw, I also agree with you that it is quite unnecessary to put the Job MIB under an "experimental" tree at this point. Let's just assign the final, "standard" tree and be done with it. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Tom, I like your idea for experimental and standard. My only question is what > triggers a standard registration and when do we expect this for the Job MIB? > > Harry Lewis > > ----- Forwarded by Harry Lewis ------ > > owner-pwg@pwg.org on 12/02/97 12:54:27 PM > Please respond to owner-pwg@pwg.org @ internet > To: don@lexmark.com @ internet, jkm@underscore.com @ internet > cc: JMP@pwg.org @ internet, pwg@pwg.org @ internet > Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree > > I started to edit the Job Monitoring MIB with the PWG standard OIDs > as proposed, even though I preferred Harry's flat OID approach. > > However, when discussing how to write it in SNMP ASN.1 with Ira, > we realized that maybe the PWG ought to distinguish between > PWG experimental OIDs and PWG standard OIDs, just like with the > IETF MIBs. > > So we propose the following: > > Under iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) > > we have separate trees for PWG experimental and PWG standard: > > pwg(2699) pwgstandard(1) jobmon(1) > pwg(2699) pwgexperimental(2) jobmon(1) > > Our current jobmon MIB is so near to becoming a PWG standard that > we don't need this distinction. We haven't changed an OID during the > last six months of drafts. However, just to be safe, I'm going to > publish the next draft using the pwgexperimental(2) arc. Then if we > decide that the above OID scheme isn't any good, we can change it. > Experimental OIDs are free to be changed from draft to draft, but > standard ones are not. > > The idea of pwgstandard OIDs is that the OIDs never change after being > published, just like the IETF. (Adding new OIDs can be done to > standards, that is NOT changing published OIDs). > > We also propose NOT to asign arc to PWG projects, but to actual PWG > needs, in this case the jobmon mib. Thus a project can get one or > more arcs assigned, depending on its needs. Also OIDs can be assigned > for non-MIB purposes as well. > > Another advantage to this approach, is that we don't need to decide > now what categories we might want in the future. > > Ok? > > Tom From harryl at us.ibm.com Tue Dec 2 19:07:20 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree In-Reply-To: Re: JMP> Structuring of the PWG enterprise OID tree> Message-ID: <3.0.1.32.19971202123810.00eafdc0@garfield> I agree with Jay's improvements on Tom's proposal. I also feel we are f= ar enough along with the Job MIB to skip Experimental. In all, however, I = think we need to lay down a process for going from Experimental to Standard incl= uding any last call, bakeoff, internet informational RFC and subsequent IETF timelines etc. I am very interested in getting to the point of a standa= rd job mib. I don't want to loose sight of the fact that this is our opportuni= ty to establish a viable process for the new PWG standards body ! Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 12/02/97= 04:47 PM --------------------------- jkm@underscore.com on 12/02/97 03:44:39 PM Please respond to jkm@underscore.com @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: JMP@pwg.org @ internet, pwg@pwg.org @ internet, hastings@cp10.es.xe= rox.com @ internet Subject: Re: PWG> Re: JMP> Structuring of the PWG enterprise OID tree Tom, I, too, tend to like your proposal. However, instead of: > pwg(2699) pwgstandard(1) jobmon(1) > pwg(2699) pwgexperimental(2) jobmon(1) How about more simple words, such as: pwg(2699) standard(1) jobmon(1) pwg(2699) experimental(2) jobmon(1) That is, there is no real value in having the "pwg" prefix. The more I think of it, though, I don't think we need to have an explicit "standard" tree. Instead--just like the IETF--we have an "experimental" subtree, but all other trees at that level represent "standard" assignments. This means we end up with (for example): pwg(2699) jobmon(1) pwg(2699) experimental(2) jobmon(1) Btw, I also agree with you that it is quite unnecessary to put the Job MIB under an "experimental" tree at this point. Let's just assign the final, "standard" tree and be done with it. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Tom, I like your idea for experimental and standard. My only question= is what > triggers a standard registration and when do we expect this for the J= ob MIB? > > Harry Lewis > > ----- Forwarded by Harry Lewis ------ > > owner-pwg@pwg.org on 12/02/97 12:54:27 PM > Please respond to owner-pwg@pwg.org @ internet > To: don@lexmark.com @ internet, jkm@underscore.com @ internet > cc: JMP@pwg.org @ internet, pwg@pwg.org @ internet > Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree > > I started to edit the Job Monitoring MIB with the PWG standard OIDs > as proposed, even though I preferred Harry's flat OID approach. > > However, when discussing how to write it in SNMP ASN.1 with Ira, > we realized that maybe the PWG ought to distinguish between > PWG experimental OIDs and PWG standard OIDs, just like with the > IETF MIBs. > > So we propose the following: > > Under iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) > > we have separate trees for PWG experimental and PWG standard: > > pwg(2699) pwgstandard(1) jobmon(1) > pwg(2699) pwgexperimental(2) jobmon(1) > > Our current jobmon MIB is so near to becoming a PWG standard that > we don't need this distinction. We haven't changed an OID during the= > last six months of drafts. However, just to be safe, I'm going to > publish the next draft using the pwgexperimental(2) arc. Then if we > decide that the above OID scheme isn't any good, we can change it. > Experimental OIDs are free to be changed from draft to draft, but > standard ones are not. > > The idea of pwgstandard OIDs is that the OIDs never change after bein= g > published, just like the IETF. (Adding new OIDs can be done to > standards, that is NOT changing published OIDs). > > We also propose NOT to asign arc to PWG projects, but to actual PWG > needs, in this case the jobmon mib. Thus a project can get one or > more arcs assigned, depending on its needs. Also OIDs can be assigne= d > for non-MIB purposes as well. > > Another advantage to this approach, is that we don't need to decide > now what categories we might want in the future. > > Ok? > > Tom = From imcdonal at eso.mc.xerox.com Wed Dec 3 15:15:09 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:12 2009 Subject: JMP> Structuring of the PWG enterprise OID tree In-Reply-To: Structuring of the PWG enterprise OID tree> Message-ID: <9712032015.AA06362@snorkel.eso.mc.xerox.com> Reference: Re: JMP> Structuring of the PWG enterprise OID tree Hi folks, Wednesday (3 December 1997) Jay kind of distorted the form of the Internet OID tree. Note that all IETF standards track projects start out at 'experimental' (which is 'internet 3') and then move over (at Proposed Standard stage) to 'mgmt' (which is 'internet 2'). The space is NOT flat under 'internet' (which is 'iso(1) org(3) dod(6) 1'). Some 'internet' branches (see RFC 1902): directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } security OBJECT IDENTIFIER ::= { internet 5 } I suggest that we avoid using the arc 'experimental' in the PWG tree, to avoid confusion with the full OID 'experimental' in the Internet tree. I still recommend that the Job Mon MIB module OIDs be: enterprises pwg(2699) pwgstandard(1) jobmon(1) enterprises pwg(2699) pwgexperimental(2) jobmon(1) I also recommend that the next draft be 'pwgexperimental(2) jobmon(1)', because the dust hasn't settled yet in the IESG on IPP and alignment with the PWG Job Mon MIB v1.0 is highly desirable. Cheers, - Ira McDonald From hastings at cp10.es.xerox.com Fri Dec 5 03:15:57 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> IETF Job Monitoring MIB to ISO DPA mapping section Message-ID: <3.0.1.32.19971205001557.00f3b920@garfield> I've posted the mapping from JMP to DPA for our PWG RFC mapping document: ftp://ftp.pwg.org/pub/pwg/jmp/protomap/jmpmap01-dpa.doc .pdf I've also embedded the .txt in this message. Tom 6.0 DOCUMENT PRINTING APPLICATION (DPA) The ISO 10175 Document Printing Application [DPA] supports printing using any one of the three possible configurations. For configuration 2, the mapping defined herein is performed on a server. Otherwise, the mapping is performed on an agent within the printer. 6.1 jmJobSubmissionId Mapped to DPA DPA contains a rich set of parameters which allow several methods of creating the jmJobSubmissionId object. To prevent interoperability problems, the preferred method is to use the DPA job-originating-user attribute as follows: octet 1: '0' octets 2-40: Contains the DPA job-owner attribute supplied by the submitter. If the job-owner is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: Contains an 8-digit sequential decimal number. 6.2 jmJobIndex Mapped to DPA The job index (jmJobIndex) assigned by the SNMP job monitoring agent is returned to the client by DPA as a decimal digit string as the value of the DPA job-identifer attribute. (Since DPA does not require consecutively generated job-identifiers, the agent may receive jobs from multiple clients and can assign the jmJobIndex in an accending sequence independent of the submitting job client.) The DPA job-identifier must be restricted to the range of 1 to 99,999,999 (decimal) to allow the value to be properly represented in jmJobSubmissionId. 6.3 Other MIB Objects Mapped to DPA MIB Object | DPA Job attribute --------------------------+--------------------------------------------- jmJobOwner | job-owner jmJobKOctetsRequested | total-job-octets (note 1) jmJobKOctetsProcessed | job-octets-completed (note 1) jmJobImpressionsRequested | job-impression-count jmJobImpressionsProcessed | impressions-completed jmJobStateReasons1 | job-state-reasons (note 2) jmNumberOfInterveningJobs | intervening-jobs Notes: ------ 1. jmJobKOctetsRequested and jmJobKOctetsProcessed is in K octets while the DPA job-total-octets and job-octets-completed is in octets and is 63-bits of significance. 2. JobStateReasons is a bit map described in one object and three attributes. The DPA condition may change one or more of the bits in one or more of these Job MIB items. Also the DPA job-state-reasons is a multi-valued attribute with each value being an OBJECT IDENTIFIER (OID). 6.4 The Attribute Group Mapped to DPA The following mappings are required if the listed DPA job attribute is provided. MIB attribute | DPA job attribute |IPP Data type ---------------------------+------------------------------+------------- jobCodedCharSet | every attribute is tagged | Octet String jobNaturalLanguage | - | Octet String jobName | job-name | Octet String documentFormat | document-format | Octet String jobPriority | job-priority | Integer jobHoldUntil | job-print-after (note 3) | Octet String sides | sides (note 4) | Integer finishing | job-finishing, finishing | Integer printQualityRequested | print-quality | Integer printerResolutionRequested | default-printer-resolution | Integer (note 5) jobCopiesRequested | job-copies-requested | Integer mediumRequested | page-media-select, | Octet String default-medium jobSubmissionTime | submission-time (note 6) | Integer jobStartedProcessingTime | started-printing-time (note 6) Integer jobCompletionTime | completion-time (note 6) | Integer sheetsRequested | job-media-sheet-count | Integer jobURI | - | Octet String jobStateReasonsN | job-state-reasons (note 2) | Integer physicalDevice | printers-assigned | Octet String sheetsCompleted | job-media-sheets-completed | Integer Notes: ------ 3. jobHoldUntil is a keyword value of the time period, while DPA job-print-after is a date/time value. 4. The Job MIB sides attribute is an integer '1' or '2' while the DPA sides attribute has one of six OID values that includes plex. 5. printerResolutionRequested has x and y resolution and is intended to override the resolution instruction in the document, if any, while the DPA default-printer-resolution is the same in x and y and only takes effect if the document does not contain a resolution instruction 6. IPP times are the number of seconds since boot time, while DPA times are a date/time. From harryl at us.ibm.com Sat Dec 6 12:37:22 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> LA Minutes Message-ID: <3.0.1.32.19971205001557.00f3b920@garfield> I'm in the process of uploading FIN and JMP minutes. They will be at ftp://pwg.org/pub/pwg/fin/minutes/fin-1297.pdf or ...jmp/jmp-1097.pdf. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Tue Dec 9 18:28:40 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> Job Monitoring MIB, V0.87, available Message-ID: <3.0.1.32.19971209152840.01154100@garfield> I've uploaded the V0.87 version of the Job Monitoring MIB that we reviewed at the meeting, Dec 5, in LA: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mibr.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mibr.pdf (red revision marks) I've not converted it to plain text and compiled it. Done in version V0.87 distributed at the meeting: 1. use the new PWG OIDs 2. add natural language support like IPP 3. add/fix monitoring collated/uncollated implementations [see issues] 4. fix impressions completed, 5. allows multiple Job Submission Id entries to point to the same jmJobIndex entry Not done: 1. The changes agreed to at the December 5 meeting. 2. and add any new Job Submission Ids 3. make the document a PWG draft standard that will be sent as an Internet-Draft that will become an IETF Informational RFC I'll be producing the updated version this week with the changes agreed to at the meeting. Tom From harryl at us.ibm.com Wed Dec 10 17:25:10 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Addition of natural language attributes to JMP to a In-Reply-To: Addition of natural language attributes to JMP to a> Message-ID: <3.0.1.32.19971209152840.01154100@garfield> Tom, one quick question about the natural lang tag we added. I want to = assure these only apply to "back channel" information. Comments passed by the = device or server... but always on the return path with respect to the printer = job... never passed in with the job. If this is not true, then we have a probl= em with legacy PDLs like PJL, PCL, Postscript etc, which might pass a comment b= ut give no clue what the natural language is. Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Wed Dec 10 18:20:24 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> LA minutes correction Message-ID: <3.0.1.32.19971209152840.01154100@garfield> I noticed the following error in my minutes... >1. jobURI is not multi-row to accommodate URL's longer than 64 octets = via concatenation, if necessary. Should read "jobURI is NOW multi-row to accomodate... Harry Lewis - IBM Printing Systems O = From rbergma at dpc.com Wed Dec 10 21:12:40 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Mapping RFC Posted, From LA Meeting Message-ID: <3.0.1.32.19971209152840.01154100@garfield> I finally loaded the Job Submission Protocol Mapping RFC that was distributed and discussed in the LA meeting. The URLs... ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP02.TXT (.DOC) The DOC version has the revisions marked. I plan to update this document with the changes agreed in LA and will try to post next week. Ron Bergman Dataproducts Corp. From lstein at fapo.com Fri Dec 12 10:48:28 1997 From: lstein at fapo.com (Larry Stein) Date: Wed May 6 14:00:12 2009 Subject: JMP> January Meeting Notice Message-ID: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From hastings at cp10.es.xerox.com Fri Dec 12 13:17:23 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> JMP Mapping RFC Posted, From LA Meeting [I added .pdf] Message-ID: <3.0.1.32.19971212101723.009874a0@garfield> I added jmpmap02-rev.pdf with line numbers and red revision marks. Tom >Date: Wed, 10 Dec 1997 18:12:40 PST >From: Ron Bergman >To: jmp@pwg.org >Subject: JMP> JMP Mapping RFC Posted, From LA Meeting >X-X-Sender: rbergma@newmai.dpc.com >Sender: jmp-owner@pwg.org > >I finally loaded the Job Submission Protocol Mapping RFC that was >distributed and discussed in the LA meeting. The URLs... > > ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP02.TXT (.DOC) > >The DOC version has the revisions marked. > >I plan to update this document with the changes agreed in LA and will try >to post next week. > > Ron Bergman > Dataproducts Corp. > > > > From ACaruso at channels.mc.xerox.com Fri Dec 12 15:37:53 1997 From: ACaruso at channels.mc.xerox.com (Caruso, Angelo) Date: Wed May 6 14:00:12 2009 Subject: JMP> RE: Ambiguity in XCMI & PWG Job Mon: fullColorImpressionsComplete Message-ID: <3.0.1.32.19971212101723.009874a0@garfield> Tom, There's no ambiguity in my mind. You increment exactly one of the three counters ([monochrome]impressionsCompleted, fullColorImpressionsCompleted, or highlightColorImpressionsCompleted) for each SIDE completed. If the side requires 3 or more colorants to produce the impression then it's Full Color, black plus one other colorant would be Highlight color, and a side that uses only black would cause the monochrome counter to increment. To display job progress to a user you need to sum all three of these counters. For example, if you produce a duplex sheet with full process color graphics on the front side and black text on the back side, then you would increment fullColorImpressionsCompleted when the front side was completed and [monochrome]impressionsCompleted when the back was complete. Since the descriptions of these attributes were changed to say "For printing, the impressions completed includes interpreting, marking, and stacking the output", then this implies to me that both counters would be incremented simultaneously when this completed duplex sheet was delivered to the output. Is there something else I'm missing here? Obviously these objects do not provide detailed colorant use information for each page. To do so would require objects to count the actual amount of each colorant transferred to each side. So as a compromise, we proposed these two new objects (which complement the previously existing [monochrome]impressionsCompleted counter) to provide enough information for an accounting application to bill at different rates for monochrome, highlight color, and full color impressions within a job. Thanks, Angelo > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Friday, December 12, 1997 11:26 AM > To: Angelo_Caruso@wb.xerox.com > Cc: XCMI Editors only > Subject: Ambiguity in XCMI & PWG Job Mon: > fullColorImpressionsCompleted(1 > > URGENT: > > The current definition of fullColorImpressionsCompleted(114) and > highlightColorImpressionsCompleted(115) is: > > fullColorImpressionsCompleted(114), Integer32(-2..2147483647) > INTEGER: The number of full color impressions completed by the device > for > this job so far. For printing, the impressions completed includes > interpreting, marking, and stacking the output. For other types of > job > services, the number of impressions completed includes the number of > impressions processed. Full color impressions are typically defined as > those requiring 3 or more colorants, but this MAY vary by > implementation. > > highlightColorImpressionsCompleted(115), > Integer32(-2..2147483647) > INTEGER: The number of highlight color impressions completed by the > device > for this job so far. For printing, the impressions completed includes > interpreting, marking, and stacking the output. For other types of > job > services, the number of impressions completed includes the number of > impressions processed. Highlight color impressions are typically > defined > as those requiring black plus one other colorant, but this MAY vary by > implementation. > > > Suppose you have a 4 color process that makes four passes through the > marker > for each side, does this attribute count by 1 for each pass or does > it still > count just the number of sides? > > The advantage of counting the number of color passes is that something > > counts for each pass which can be shown to a user. Also accounting > may > want to charge for each color pass. Conceivably, there might be a > variable > number of passes, depending on the colors demanded by each image? > > The advantage of only counting once per side, is that you can then > compare > the number of impressions for the job with the number of > fullColorImpressionsCompleted and determine the percentage of color > impressions in the job. Also this definition seems to be more in > keeping > with the > concept of "stacking" the media mentioned in the definition. > > Since Xerox proposed this attribute, what did we have in mind? > > Thanks, > Tom From hastings at cp10.es.xerox.com Fri Dec 12 13:01:32 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:12 2009 Subject: JMP> Addition of natural language attributes to JMP to a In-Reply-To: <5030300015944756000002L062*@MHS> Message-ID: <3.0.1.32.19971212100132.00984d00@garfield> We added two natural language tags: 1. processingMessagNaturalLanguageTag(7) which is the only "back channel" text string attribute (at the moment) that is likely to have a natural language associated with it. For an implementation that does not support the processingMessage(6) attribute, this attribute is not implemented either. 2. jobNaturalLanguageTag(9) which is the natural language submitted by the submitter. For those protocols that don't have this capability or where the submitter does not supply the natural language, the agent should either not return this attribute or return a zero length string as the description says. For an implementation that does not support any protocols, like IPP, where the job submitter supplies a natural langauge, I would assume that the implementation would not implement this attribute at all (as with any attribute). Here are the two definitions. Any suggestions for further clarifying them? Tom processingMessageNaturalLanguageTag(7), OCTET STRING(SIZE(0..63)) OCTETS: MULTI-ROW: The natural language of the corresponding processingMessage(6) attribute value. See section 3.6.1, entitled 'Text generated by the server or device'. If the agent does not know the natural language of the job processing message, the agent SHALL either (1) return a zero length string value for the processingMessageNaturalLanguageTag(7) attribute or (2) not return the processingMessageNaturalLanguageTag(7) attribute for the job. There is no restriction for the same tag occurring in multiple rows, since when this attribute is implemented, it SHOULD have a value row for each corresponding processingMessage(6) attribute value row. jobNaturalLanguageTag(9), OCTET STRING(SIZE(0..63)) OCTETS: The natural language of the job attributes supplied by the job submitter or defaulted by the server or device for the job, i.e., all objects and attributes represented by the 'JmJobStringTC' textual-convention, such as jobName, mediumRequested, etc. See Section 3.6.2, entitled 'Text supplied by the job submitter'. If the agent does not know what natural language was used by the job submitting client, the agent SHALL either (1) return a zero length string value for the jobNaturalLanguageTag(9) attribute or (2) not return jobNaturalLanguageTag(9) attribute for the job. 1. Not return this attribute At 14:25 12/10/1997 PST, Harry Lewis wrote: >Tom, one quick question about the natural lang tag we added. I want to assure >these only apply to "back channel" information. Comments passed by the device >or server... but always on the return path with respect to the printer job... >never passed in with the job. If this is not true, then we have a problem with >legacy PDLs like PJL, PCL, Postscript etc, which might pass a comment but give >no clue what the natural language is. > >Harry Lewis - IBM Printing Systems > > From harryl at us.ibm.com Fri Dec 12 21:02:21 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:12 2009 Subject: JMP> Inconsistency with REQUESTED attributes Message-ID: <3.0.1.32.19971212100132.00984d00@garfield> I think we have a consistency problem with attributes job-impressions a= nd job-media-sheets. The inconsistency exists in both JMP and IPP. Most at= tributes that reflect a REQUESTED value are based on the "unit" of one copy of t= he job. For instance, job-impressions (requested) is specifically PER COPY. She= ets, however, for some reason, is defined to pertain to all the sheets in al= l the copies in the job. There seems to be no good reason for this and I requ= est that we adjust sheets back to a unit base like other attributes. If an appli= cation wants to calculate load they can multiply sheets by copies... like with= any other requested attribute. Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Tue Dec 16 12:22:11 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Re: Inconsistency with REQUESTED attributes [I don't think its In-Reply-To: Message-ID: <3.0.1.32.19971216092211.00cc5c70@garfield> Harry, I thought of a why this inconsistency is a useful feature for IPP. (The inconsistency is that k octets and impressions requested don't take account of the number of copies while media requested does. See Harry's attached mail). In IPP the job-k-octets, job-impressions, and job-media-sheets have corresponding Printer attributes: job-k-octets-supported, job-impressions-supported, and job-media-sheets-supported. These three xxx-supported attributes have an integer range value which is a lower bound and an upper bound on the allowed values for the job-k-octets, job-impressions, and job-media-sheets job attributes. This allows the system administrator some control over preventing too small or two large jobs from being accepted. By making job-media-sheets, include copies, but job-k-octets and job-impressions, not include copies, the system administrator is able to limit the size of documents and the size of jobs. So he/she can say, no more that 100 sheets (whether one- or two-sided and no matter how many copies) will be accepted. Thus controlling cost of media. Also not less than n, for a high volume printer. Then he/she can limit the size of the document(s), independent of the number of copies, by picking the value for job-k-octets-supported and job-impressions-supported (which correspond to the Job MIB jmJobKOctetsPerCopyRequested and jmJobImpressionsPerCopyRequested objects). So I think we have a good reason to be different between K octets/impressions requested versus media requested. And happily, both IPP and Job Mon have this same difference, so lets keep IPP and Job Mon as they are and in agreement with each other (since we are trying to forward both documents as I-Ds to the IESG this week to become standard track and informational RFC, respectively). Ok? Tom >From: Harry Lewis >To: , >Subject: IPP> Inconsistency with REQUESTED attributes >Date: Fri, 12 Dec 1997 18:02:21 PST >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id SAA23815 > >I think we have a consistency problem with attributes job-impressions and >job-media-sheets. The inconsistency exists in both JMP and IPP. Most attributes >that reflect a REQUESTED value are based on the "unit" of one copy of the job. >For instance, job-impressions (requested) is specifically PER COPY. Sheets, >however, for some reason, is defined to pertain to all the sheets in all the >copies in the job. There seems to be no good reason for this and I request that >we adjust sheets back to a unit base like other attributes. If an application >wants to calculate load they can multiply sheets by copies... like with any >other requested attribute. > >Harry Lewis - IBM Printing Systems > > From hastings at cp10.es.xerox.com Tue Dec 16 17:36:57 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Ambiguity in In-Reply-To: <7BFEEB88B1C0D011BCD400A0C93EEA4A2052C3@US0111-CH-MS1> Message-ID: <3.0.1.32.19971216143657.00b547e0@garfield> Angelo, You've come up with a third interpretation of the impressionsCompleted, fullColorImpressionsCompleted and highlightColorImpressionsCompleted! I'm proposing the interpretation based on our discussion at the Dec 5 JMP meeting (which you did not have the benefit of attending). PEOPLE, PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU OBJECT TO MY CLARIFICATIONS. AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS AGREEMENT. I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK AS WE AGREED AT THE JMP MEETING. First, here is the definition of the term "impression" that we came up with at the meeting (please review the text too, since it was only the ideas that we agreed to at the meeting): Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". The three interpretations of these three attributes are: 1. Does impressionsCompleted increment or not when a highlight or full color impression is made? The current above definition of impressions suggests that it does, since an impressions is the passing of one side of the media past the marker whether color or not. 2. Does the fullColorImpressionsCompleted count once for each side of a full color impression or once for each color pass past the side of a medium? For example, if I had a 16-page document that had 10 black and white pages, 5 highlight color pages, and 1 full 4-color page, (number-up=1, sides=1), would the counts at the end of my job be: highlightColor fullColor impressionsCompleted ImpressionsCompleted ImpressionsCompleted 1. 16 5 1 2. 16 5 20 3. 10 5 1 4. 10 5 20 I suggest that it is interpretation 1 that we are agreeing to and I'll clarify the fullColorImpressionsCompleted, by adding the phrase, "independent of the number of colors or color passes" to the end of the first sentence, yielding: The number of full color impressions completed by the device for this job so far independent of the number of colors or color passes. I'll also add the parenthetical remake to the impressionsCompleted "(monochome, highlight color, and full color)" to the first sentence, since it is clear from the definition of impression that it includes all, yielding: The total number of impressions (monochome, highlight color, and full color) completed for this job so far. Ok? AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE CLARIFICATION. Thanks, Tom The current definitions of impressionsCompleted, highlightColorImpressionsCompleted, and fullColorImpressionsCompleted are: OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with the jmJobImpressionsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." REFERENCE "See the definition of the term "impression" in Section 2 and the counting example in Section 3.4 entitled 'Monitoring Job Progress'." DEFVAL { 0 } -- default is no octets ::= { jmJobEntry 8 } fullColorImpressionsCompleted(114), Integer32(-2..2147483647) INTEGER: The number of full color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Full color impressions are typically defined as those requiring 3 or more colorants, but this MAY vary by implementation. highlightColorImpressionsCompleted(115), Integer32(-2..2147483647) INTEGER: The number of highlight color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Highlight color impressions are typically defined as those requiring black plus one other colorant, but this MAY vary by implementation. At 12:37 12/12/1997 PST, Caruso, Angelo wrote: >Tom, > >There's no ambiguity in my mind. You increment exactly one of the three >counters ([monochrome]impressionsCompleted, >fullColorImpressionsCompleted, or highlightColorImpressionsCompleted) >for each SIDE completed. If the side requires 3 or more colorants to >produce the impression then it's Full Color, black plus one other >colorant would be Highlight color, and a side that uses only black would >cause the monochrome counter to increment. To display job progress to a >user you need to sum all three of these counters. The advantage to saying that impressionsCompleted, counts black/white, highlight color, and full color, is that an application only need to look at one attribute if it doesn't care about the distinction of b/w, highlight and full color. Also the device might not implement the other two, so it is easier for an application to just look at the one attribute if that is all it is interested in. Ok? > >For example, if you produce a duplex sheet with full process color >graphics on the front side and black text on the back side, then you >would increment fullColorImpressionsCompleted when the front side was >completed and [monochrome]impressionsCompleted when the back was >complete. Since the descriptions of these attributes were changed to say >"For printing, the impressions completed includes interpreting, marking, >and stacking the output", then this implies to me that both counters >would be incremented simultaneously when this completed duplex sheet was >delivered to the output. So with my suggested resolution, the fullColorImpressionsCompleted would count by 1 and the impressionsCompleted would count by 2 in your example. > >Is there something else I'm missing here? > >Obviously these objects do not provide detailed colorant use information >for each page. To do so would require objects to count the actual amount >of each colorant transferred to each side. So as a compromise, we >proposed these two new objects (which complement the previously existing >[monochrome]impressionsCompleted counter) to provide enough information >for an accounting application to bill at different rates for monochrome, >highlight color, and full color impressions within a job. I think that the accounting program can still bill correctly with impressionsCompleted counting highlight and fullColor as well as monochrome. It can substract out the monochrome, if it wants to, or build in the charge for color to be less that the correct charge for coloer by the amount charged for monochrome and avoid subtracting. > >Thanks, >Angelo > >> -----Original Message----- >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] >> Sent: Friday, December 12, 1997 11:26 AM >> To: Angelo_Caruso@wb.xerox.com >> Cc: XCMI Editors only >> Subject: Ambiguity in XCMI & PWG Job Mon: >> fullColorImpressionsCompleted(1 >> >> URGENT: >> >> The current definition of fullColorImpressionsCompleted(114) and >> highlightColorImpressionsCompleted(115) is: >> >> fullColorImpressionsCompleted(114), Integer32(-2..2147483647) >> INTEGER: The number of full color impressions completed by the device >> for >> this job so far. For printing, the impressions completed includes >> interpreting, marking, and stacking the output. For other types of >> job >> services, the number of impressions completed includes the number of >> impressions processed. Full color impressions are typically defined as >> those requiring 3 or more colorants, but this MAY vary by >> implementation. >> >> highlightColorImpressionsCompleted(115), >> Integer32(-2..2147483647) >> INTEGER: The number of highlight color impressions completed by the >> device >> for this job so far. For printing, the impressions completed includes >> interpreting, marking, and stacking the output. For other types of >> job >> services, the number of impressions completed includes the number of >> impressions processed. Highlight color impressions are typically >> defined >> as those requiring black plus one other colorant, but this MAY vary by >> implementation. >> >> >> Suppose you have a 4 color process that makes four passes through the >> marker >> for each side, does this attribute count by 1 for each pass or does >> it still >> count just the number of sides? >> >> The advantage of counting the number of color passes is that something >> >> counts for each pass which can be shown to a user. Also accounting >> may >> want to charge for each color pass. Conceivably, there might be a >> variable >> number of passes, depending on the colors demanded by each image? >> >> The advantage of only counting once per side, is that you can then >> compare >> the number of impressions for the job with the number of >> fullColorImpressionsCompleted and determine the percentage of color >> impressions in the job. Also this definition seems to be more in >> keeping >> with the >> concept of "stacking" the media mentioned in the definition. >> >> Since Xerox proposed this attribute, what did we have in mind? >> >> Thanks, >> Tom > > From Angelo.Caruso at usa.xerox.com Wed Dec 17 10:18:33 1997 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo ) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: URGENT: Ambiguity in impressions|fullColor|highlighColorCompp Message-ID: <3.0.1.32.19971216143657.00b547e0@garfield> Tom, The only difference I see between my interpretation and yours is that I thought "impressionCompleted" was for monochrome only. But, I guess this doesn't make sense because then fullColor and highlightColor would need to be mandatory for color capable devices. So, impressionsCompleted should include monochrome, highlight color, and full color pages. This also makes life easier on applications that just want to report progress because they only have to look at one counter. Your proposed definition of impressions is great except for the sentence "If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass." I disagree with this. Why should the odd side count as an impression if it is not marked? And which impressions counters would you increment for the unmarked odd side? Some engine architectures require that the sheet pass through the marker twice even though the sheet only gets marked on one side. This seems like a rather arbitrary and unfair policy, especially from the customer's point of view. With this policy, if I printed 100 copies of a 5 page duplex document, I would pay for 600 impressions even though I only made 500 impressions. Thanks, Angelo -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] Sent: Tuesday, December 16, 1997 5:37 PM To: jmp@pwg.org; Caruso, Angelo Cc: XCMI Editors only Subject: URGENT: Ambiguity in impressions|fullColor|highlighColorComppleteddefns Angelo, You've come up with a third interpretation of the impressionsCompleted, fullColorImpressionsCompleted and highlightColorImpressionsCompleted! I'm proposing the interpretation based on our discussion at the Dec 5 JMP meeting (which you did not have the benefit of attending). PEOPLE, PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU OBJECT TO MY CLARIFICATIONS. AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS AGREEMENT. I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK AS WE AGREED AT THE JMP MEETING. First, here is the definition of the term "impression" that we came up with at the meeting (please review the text too, since it was only the ideas that we agreed to at the meeting): Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". The three interpretations of these three attributes are: 1. Does impressionsCompleted increment or not when a highlight or full color impression is made? The current above definition of impressions suggests that it does, since an impressions is the passing of one side of the media past the marker whether color or not. 2. Does the fullColorImpressionsCompleted count once for each side of a full color impression or once for each color pass past the side of a medium? For example, if I had a 16-page document that had 10 black and white pages, 5 highlight color pages, and 1 full 4-color page, (number-up=1, sides=1), would the counts at the end of my job be: highlightColor fullColor impressionsCompleted ImpressionsCompleted ImpressionsCompleted 1. 16 5 1 2. 16 5 20 3. 10 5 1 4. 10 5 20 I suggest that it is interpretation 1 that we are agreeing to and I'll clarify the fullColorImpressionsCompleted, by adding the phrase, "independent of the number of colors or color passes" to the end of the first sentence, yielding: The number of full color impressions completed by the device for this job so far independent of the number of colors or color passes. I'll also add the parenthetical remake to the impressionsCompleted "(monochome, highlight color, and full color)" to the first sentence, since it is clear from the definition of impression that it includes all, yielding: The total number of impressions (monochome, highlight color, and full color) completed for this job so far. Ok? AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE CLARIFICATION. Thanks, Tom The current definitions of impressionsCompleted, highlightColorImpressionsCompleted, and fullColorImpressionsCompleted are: OBJECT-TYPE SYNTAX Integer32(-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with the jmJobImpressionsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." REFERENCE "See the definition of the term "impression" in Section 2 and the counting example in Section 3.4 entitled 'Monitoring Job Progress'." DEFVAL { 0 } -- default is no octets ::= { jmJobEntry 8 } fullColorImpressionsCompleted(114), Integer32(-2..2147483647) INTEGER: The number of full color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Full color impressions are typically defined as those requiring 3 or more colorants, but this MAY vary by implementation. highlightColorImpressionsCompleted(115), Integer32(-2..2147483647) INTEGER: The number of highlight color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Highlight color impressions are typically defined as those requiring black plus one other colorant, but this MAY vary by implementation. At 12:37 12/12/1997 PST, Caruso, Angelo wrote: >Tom, > >There's no ambiguity in my mind. You increment exactly one of the three >counters ([monochrome]impressionsCompleted, >fullColorImpressionsCompleted, or highlightColorImpressionsCompleted) >for each SIDE completed. If the side requires 3 or more colorants to >produce the impression then it's Full Color, black plus one other >colorant would be Highlight color, and a side that uses only black would >cause the monochrome counter to increment. To display job progress to a >user you need to sum all three of these counters. The advantage to saying that impressionsCompleted, counts black/white, highlight color, and full color, is that an application only need to look at one attribute if it doesn't care about the distinction of b/w, highlight and full color. Also the device might not implement the other two, so it is easier for an application to just look at the one attribute if that is all it is interested in. Ok? > >For example, if you produce a duplex sheet with full process color >graphics on the front side and black text on the back side, then you >would increment fullColorImpressionsCompleted when the front side was >completed and [monochrome]impressionsCompleted when the back was >complete. Since the descriptions of these attributes were changed to say >"For printing, the impressions completed includes interpreting, marking, >and stacking the output", then this implies to me that both counters >would be incremented simultaneously when this completed duplex sheet was >delivered to the output. So with my suggested resolution, the fullColorImpressionsCompleted would count by 1 and the impressionsCompleted would count by 2 in your example. > >Is there something else I'm missing here? > >Obviously these objects do not provide detailed colorant use information >for each page. To do so would require objects to count the actual amount >of each colorant transferred to each side. So as a compromise, we >proposed these two new objects (which complement the previously existing >[monochrome]impressionsCompleted counter) to provide enough information >for an accounting application to bill at different rates for monochrome, >highlight color, and full color impressions within a job. I think that the accounting program can still bill correctly with impressionsCompleted counting highlight and fullColor as well as monochrome. It can substract out the monochrome, if it wants to, or build in the charge for color to be less that the correct charge for coloer by the amount charged for monochrome and avoid subtracting. > >Thanks, >Angelo > >> -----Original Message----- >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] >> Sent: Friday, December 12, 1997 11:26 AM >> To: Angelo_Caruso@wb.xerox.com >> Cc: XCMI Editors only >> Subject: Ambiguity in XCMI & PWG Job Mon: >> fullColorImpressionsCompleted(1 >> >> URGENT: >> >> The current definition of fullColorImpressionsCompleted(114) and >> highlightColorImpressionsCompleted(115) is: >> >> fullColorImpressionsCompleted(114), Integer32(-2..2147483647) >> INTEGER: The number of full color impressions completed by the device >> for >> this job so far. For printing, the impressions completed includes >> interpreting, marking, and stacking the output. For other types of >> job >> services, the number of impressions completed includes the number of >> impressions processed. Full color impressions are typically defined as >> those requiring 3 or more colorants, but this MAY vary by >> implementation. >> >> highlightColorImpressionsCompleted(115), >> Integer32(-2..2147483647) >> INTEGER: The number of highlight color impressions completed by the >> device >> for this job so far. For printing, the impressions completed includes >> interpreting, marking, and stacking the output. For other types of >> job >> services, the number of impressions completed includes the number of >> impressions processed. Highlight color impressions are typically >> defined >> as those requiring black plus one other colorant, but this MAY vary by >> implementation. >> >> >> Suppose you have a 4 color process that makes four passes through the >> marker >> for each side, does this attribute count by 1 for each pass or does >> it still >> count just the number of sides? >> >> The advantage of counting the number of color passes is that something >> >> counts for each pass which can be shown to a user. Also accounting >> may >> want to charge for each color pass. Conceivably, there might be a >> variable >> number of passes, depending on the colors demanded by each image? >> >> The advantage of only counting once per side, is that you can then >> compare >> the number of impressions for the job with the number of >> fullColorImpressionsCompleted and determine the percentage of color >> impressions in the job. Also this definition seems to be more in >> keeping >> with the >> concept of "stacking" the media mentioned in the definition. >> >> Since Xerox proposed this attribute, what did we have in mind? >> >> Thanks, >> Tom > > From hastings at cp10.es.xerox.com Wed Dec 17 16:03:48 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Should impressions include blank last page back sides In-Reply-To: Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> At the JMP meeting on 12/5, we agreed that the definitions of impressions would count the number of times a media side goes past the marker, even if there are no marks made. I think we agreed to that, becasue impressions is supposed to count after the sheet is stacked, so that the sheet counter doesn't know whether the back side of the last page (documents with an odd number of pages), was marked or not, so we said that it SHALL count. Howver, for an accounting application, the customers may get pretty unhappy with having to pay for the final side they didn't use, as Angelo points out, when their document has an odd number of pages. URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: So how about RECOMMENDING (but not requiring) that the number of impressions for two-sided printing not include counting both sides of sheets marked on only one side. It may be that the interpreter has to be involved in counting impressions, rather than the sheet counter in the stacker or maybe the implementation only worries about the last sheet and so there is just an internal status bit that says whether a document has an odd number or an even number of sides in order to know whether to count the last sheet as 1 or 2 impressions. I suggest changing the sentence in the definition of impression: If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. to: If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. BTW, the current definition of "impression" in the IPP Model is: 12.2.15 impressions An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. So it seems that the IPP Job Model is in agreement with the following recommendation for the Job Mon MIB: The full definition of the term impressions (as sent yesterday) is for the Job Monitoring MIB: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". I propose to soften that definition to: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY OBJECTIONS, I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. Thanks, Tom At 07:18 12/17/1997 PST, Caruso, Angelo wrote: >Tom, > snip... >Your proposed definition of impressions is great except for the sentence >"If a two-sided document has an odd number of pages, the last sheet >still counts as two impressions, if that sheet makes two passes through >the marker or the marker marks on both sides of a sheet in a single >pass." I disagree with this. Why should the odd side count as an >impression if it is not marked? And which impressions counters would you >increment for the unmarked odd side? Some engine architectures require >that the sheet pass through the marker twice even though the sheet only >gets marked on one side. This seems like a rather arbitrary and unfair >policy, especially from the customer's point of view. With this policy, >if I printed 100 copies of a 5 page duplex document, I would pay for 600 >impressions even though I only made 500 impressions. > >Thanks, >Angelo > > > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Tuesday, December 16, 1997 5:37 PM > To: jmp@pwg.org; Caruso, Angelo > Cc: XCMI Editors only > Subject: URGENT: Ambiguity in >impressions|fullColor|highlighColorComppleteddefns > > Angelo, > > You've come up with a third interpretation of the >impressionsCompleted, > fullColorImpressionsCompleted and >highlightColorImpressionsCompleted! > > > I'm proposing the interpretation based on our discussion at the > Dec 5 JMP meeting (which you did not have the benefit of >attending). > > > PEOPLE, > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU >OBJECT TO > MY CLARIFICATIONS. > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS >AGREEMENT. > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK >AS WE > AGREED AT THE JMP MEETING. > > First, here is the definition of the term "impression" that we > came up with at the meeting (please review the text too, since >it was only > the ideas that we agreed to at the meeting): > > Impression: For a print job, an impression is the passage of >the entire > side of a sheet by the marker, whether or not any marks are made >and > independent of the number of passes that the side makes past the >marker. > Thus a four pass color process counts as a single impression. >One-sided > processing involves one impression per sheet. Two-sided >processing > involves two impressions per sheet. If a two-sided document has >an odd > number of pages, the last sheet still counts as two impressions, >if that > sheet makes two passes through the marker or the marker marks on >both sides > of a sheet in a single pass. Two-up printing is the placement >of two > logical pages on one side of a sheet and so is still a single >impression. > See "page" and "sheet". > > The three interpretations of these three attributes are: > > 1. Does impressionsCompleted increment or not when a highlight >or full color > impression is made? The current above definition of impressions >suggests > that it does, since an impressions is the passing of one side of >the > media past the marker whether color or not. > > 2. Does the fullColorImpressionsCompleted count once for each >side of > a full color impression or once for each color pass past the >side of > a medium? > > For example, if I had a 16-page document that had 10 black and >white pages, > 5 highlight color pages, and 1 full 4-color page, (number-up=1, >sides=1), > would the counts at the end of my job be: > > highlightColor fullColor > impressionsCompleted ImpressionsCompleted >ImpressionsCompleted > > 1. 16 5 1 > 2. 16 5 20 > 3. 10 5 1 > 4. 10 5 20 > > I suggest that it is interpretation 1 that we are agreeing to >and I'll clarify > the fullColorImpressionsCompleted, by adding the phrase, >"independent > of the number of colors or color passes" to the end of the first > sentence, yielding: > > The number of full color impressions completed by the device for >this job > so far independent of the number of colors or color passes. > > I'll also add the parenthetical remake to the >impressionsCompleted > "(monochome, highlight color, and full color)" to the first >sentence, > since it is clear from the definition of impression that it >includes > all, yielding: > > The total number of impressions (monochome, highlight color, and >full > color) completed for this job so far. > > Ok? > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE >CLARIFICATION. > > Thanks, > Tom > > The current definitions of impressionsCompleted, > highlightColorImpressionsCompleted, and >fullColorImpressionsCompleted are: > > OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of impressions completed for this job so far. >For > printing devices, the impressions completed includes >interpreting, marking, > and stacking the output. For other types of job services, the >number of > impressions completed includes the number of impressions >processed. > > NOTE - See the impressionsCompletedCurrentCopy and > pagesCompletedCurrentCopy attributes for attributes that are >reset on each > document copy. > > NOTE - The jmJobImpressionsCompleted object can be used with the > jmJobImpressionsPerCopyRequested object to provide an indication >of the > relative progress of the job, provided that the multiplicative >factor is > taken into account for some implementations of multiple copies." > REFERENCE > "See the definition of the term "impression" in Section 2 and >the counting > example in Section 3.4 entitled 'Monitoring Job Progress'." > DEFVAL { 0 } -- default is no octets > ::= { jmJobEntry 8 } > > fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > INTEGER: The number of full color impressions completed by the >device for > this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Full color impressions are typically >defined as > those requiring 3 or more colorants, but this MAY vary by >implementation. > > highlightColorImpressionsCompleted(115), >Integer32(-2..2147483647) > INTEGER: The number of highlight color impressions completed by >the device > for this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Highlight color impressions are >typically defined > as those requiring black plus one other colorant, but this MAY >vary by > implementation. > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > >Tom, > > > >There's no ambiguity in my mind. You increment exactly one of >the three > >counters ([monochrome]impressionsCompleted, > >fullColorImpressionsCompleted, or >highlightColorImpressionsCompleted) > >for each SIDE completed. If the side requires 3 or more >colorants to > >produce the impression then it's Full Color, black plus one >other > >colorant would be Highlight color, and a side that uses only >black would > >cause the monochrome counter to increment. To display job >progress to a > >user you need to sum all three of these counters. > > The advantage to saying that impressionsCompleted, counts >black/white, > highlight color, and full color, is that an application only >need to > look at one attribute if it doesn't care about the distinction >of b/w, > highlight and full color. Also the device might not implement > the other two, so it is easier for an application to just look >at the > one attribute if that is all it is interested in. Ok? > > > > >For example, if you produce a duplex sheet with full process >color > >graphics on the front side and black text on the back side, >then you > >would increment fullColorImpressionsCompleted when the front >side was > >completed and [monochrome]impressionsCompleted when the back >was > >complete. Since the descriptions of these attributes were >changed to say > >"For printing, the impressions completed includes interpreting, >marking, > >and stacking the output", then this implies to me that both >counters > >would be incremented simultaneously when this completed duplex >sheet was > >delivered to the output. > > So with my suggested resolution, the >fullColorImpressionsCompleted > would count by 1 and the impressionsCompleted would count by 2 >in > your example. > > > > >Is there something else I'm missing here? > > > >Obviously these objects do not provide detailed colorant use >information > >for each page. To do so would require objects to count the >actual amount > >of each colorant transferred to each side. So as a compromise, >we > >proposed these two new objects (which complement the previously >existing > >[monochrome]impressionsCompleted counter) to provide enough >information > >for an accounting application to bill at different rates for >monochrome, > >highlight color, and full color impressions within a job. > > I think that the accounting program can still bill correctly >with > impressionsCompleted counting highlight and fullColor as well as >monochrome. > It can substract out the monochrome, if it wants to, or build in >the > charge for color to be less that the correct charge for coloer >by the amount > charged for monochrome and avoid subtracting. > > > > >Thanks, > >Angelo > > > >> -----Original Message----- > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > >> Sent: Friday, December 12, 1997 11:26 AM > >> To: Angelo_Caruso@wb.xerox.com > >> Cc: XCMI Editors only > >> Subject: Ambiguity in XCMI & PWG Job Mon: > >> fullColorImpressionsCompleted(1 > >> > >> URGENT: > >> > >> The current definition of fullColorImpressionsCompleted(114) >and > >> highlightColorImpressionsCompleted(115) is: > >> > >> fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > >> INTEGER: The number of full color impressions completed by >the device > >> for > >> this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Full color impressions are typically >defined as > >> those requiring 3 or more colorants, but this MAY vary by > >> implementation. > >> > >> highlightColorImpressionsCompleted(115), > >> Integer32(-2..2147483647) > >> INTEGER: The number of highlight color impressions completed >by the > >> device > >> for this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Highlight color impressions are >typically > >> defined > >> as those requiring black plus one other colorant, but this >MAY vary by > >> implementation. > >> > >> > >> Suppose you have a 4 color process that makes four passes >through the > >> marker > >> for each side, does this attribute count by 1 for each pass >or does > >> it still > >> count just the number of sides? > >> > >> The advantage of counting the number of color passes is that >something > >> > >> counts for each pass which can be shown to a user. Also >accounting > >> may > >> want to charge for each color pass. Conceivably, there might >be a > >> variable > >> number of passes, depending on the colors demanded by each >image? > >> > >> The advantage of only counting once per side, is that you can >then > >> compare > >> the number of impressions for the job with the number of > >> fullColorImpressionsCompleted and determine the percentage of >color > >> impressions in the job. Also this definition seems to be >more in > >> keeping > >> with the > >> concept of "stacking" the media mentioned in the definition. > >> > >> Since Xerox proposed this attribute, what did we have in >mind? > >> > >> Thanks, > >> Tom > > > > > > From jkm at underscore.com Wed Dec 17 23:50:05 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Should impressions include blank last page back sides In-Reply-To: URGENT: Should impressions include blank last page back sides> Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> Sorry, but I must agree with Angelo Caruso with the position that most folks are going to be pretty upset if they are charged for blanks sides of sheets. Can't say that I like that idea at all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From WWagner at digprod.com Thu Dec 18 11:44:14 1997 From: WWagner at digprod.com (Wagner, William) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank last p In-Reply-To: Re: JMP> URGENT: Should impressions include blank last p> Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> This was discussed in great detail at the LA meeting. If one agrees that the MIB is to provide information on what the printer does, which may not necessarily agree with what the rate structures may or may not be at a particular place at a particular time, then I think the contention that sending a sheet side through transfer and fixing steps constitutes making an impression. The question of how much colorant is put on that page is a separate one. If it is a single period, a fully colored page or a blank page, colorant use is a different characteristic from impression, and one which could be instrumented. In most page printers, the information that a page has no marking is not readily available. The page goes though the same processes, takes pretty much the same time and the same wear and tear on the mechanism. I suggest that, unless the printer has a way of separately ejecting such sheet sides, from a printer point of view, treating a blank side differently is an artificial distinction. The point may be moot. I am told that commercial duplication houses charge by the sheet, with perhaps a different sheet rate for duplex (but no distinction for blank sides). A large in-house reports person told me that there are no blank pages; there is a header or footer, a page number, or a "This page intentionally left blank" message. I suggest that a measure of importance from those actually concerned with the accounting be obtained before the MIB imposes the derivation of another parameter on the printer. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Wednesday, December 17, 1997 11:50 PM > To: Tom Hastings > Cc: jmp@pwg.org; ipp@pwg.org > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > last page back sides or not? > > Sorry, but I must agree with Angelo Caruso with the position > that most folks are going to be pretty upset if they are > charged for blanks sides of sheets. Can't say that I like > that idea at all. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From WWagner at digprod.com Thu Dec 18 11:50:43 1997 From: WWagner at digprod.com (Wagner, William) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: IPP> URGENT: Should impressions include blank last page back Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> Tom, I suggest that making it optional (should) is undesirable since it merely adds to the confusion. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Wednesday, December 17, 1997 4:04 PM > To: jmp@pwg.org > Cc: ipp@pwg.org; szilles@Adobe.COM > Subject: IPP> URGENT: Should impressions include blank last page > back sides or not? > > At the JMP meeting on 12/5, we agreed that the definitions of > impressions would count the number of times a media side goes past > the marker, even if there are no marks made. > > I think we agreed to that, becasue impressions is supposed to count > after the sheet is stacked, so that the sheet counter doesn't know > whether > the back side of the last page (documents with an odd number of > pages), > was marked or not, so we said that it SHALL count. > > Howver, for an accounting application, the customers may get pretty > unhappy with having to pay for the final side they didn't use, as > Angelo points out, when their document has an odd number of pages. > > URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. > HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: > > So how about RECOMMENDING (but not requiring) that the number of > impressions > for two-sided printing not include counting both sides of sheets > marked on > only one side. It may be that the interpreter has to be involved in > counting impressions, rather than the sheet counter in the stacker or > maybe > the implementation only worries about the last sheet and so there is > just > an internal status bit that says whether a document has an odd number > or an > even number of sides in order to know whether to count the last sheet > as 1 > or 2 impressions. > > I suggest changing the sentence in the definition of impression: > > If a two-sided document has an odd number of pages, the last sheet > still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > > > to: > > If a two-sided document has some sheets that only have marks on one > side > (such as on the last sheet of a document with an odd-number of > impressions), those sheets SHOULD count as one impression, instead of > two, > even if that sheet makes two passes through the marker. > > BTW, the current definition of "impression" in the IPP Model is: > > 12.2.15 impressions > > An "impression" is the image (possibly many print-stream pages in > different > configurations) imposed onto a single media page. > > So it seems that the IPP Job Model is in agreement with the following > recommendation for the Job Mon MIB: > > > The full definition of the term impressions (as sent yesterday) is > for the Job Monitoring MIB: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an > odd > number of pages, the last sheet still counts as two impressions, if > that > sheet makes two passes through the marker or the marker marks on both > sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single > impression. > See "page" and "sheet". > > > I propose to soften that definition to: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has some > sheets that only have marks on one side (such as on the last sheet of > a > document with an odd-number of impressions), those sheets SHOULD count > as > one impression, instead of two, even if that sheet makes two passes > through > the marker. Two-up printing is the placement of two logical pages on > one > side of a sheet and so is still a single impression. See "page" and > "sheet". > > > PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY > OBJECTIONS, > I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. > > Thanks, > Tom > > > > At 07:18 12/17/1997 PST, Caruso, Angelo wrote: > >Tom, > > > snip... > > >Your proposed definition of impressions is great except for the > sentence > >"If a two-sided document has an odd number of pages, the last sheet > >still counts as two impressions, if that sheet makes two passes > through > >the marker or the marker marks on both sides of a sheet in a single > >pass." I disagree with this. Why should the odd side count as an > >impression if it is not marked? And which impressions counters would > you > >increment for the unmarked odd side? Some engine architectures > require > >that the sheet pass through the marker twice even though the sheet > only > >gets marked on one side. This seems like a rather arbitrary and > unfair > >policy, especially from the customer's point of view. With this > policy, > >if I printed 100 copies of a 5 page duplex document, I would pay for > 600 > >impressions even though I only made 500 impressions. > > > >Thanks, > >Angelo > > > > > > > > -----Original Message----- > > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > Sent: Tuesday, December 16, 1997 5:37 PM > > To: jmp@pwg.org; Caruso, Angelo > > Cc: XCMI Editors only > > Subject: URGENT: Ambiguity in > >impressions|fullColor|highlighColorComppleteddefns > > > > Angelo, > > > > You've come up with a third interpretation of the > >impressionsCompleted, > > fullColorImpressionsCompleted and > >highlightColorImpressionsCompleted! > > > > > > I'm proposing the interpretation based on our discussion at the > > Dec 5 JMP meeting (which you did not have the benefit of > >attending). > > > > > > PEOPLE, > > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU > >OBJECT TO > > MY CLARIFICATIONS. > > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS > >AGREEMENT. > > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK > >AS WE > > AGREED AT THE JMP MEETING. > > > > First, here is the definition of the term "impression" that we > > came up with at the meeting (please review the text too, since > >it was only > > the ideas that we agreed to at the meeting): > > > > Impression: For a print job, an impression is the passage of > >the entire > > side of a sheet by the marker, whether or not any marks are made > >and > > independent of the number of passes that the side makes past the > >marker. > > Thus a four pass color process counts as a single impression. > >One-sided > > processing involves one impression per sheet. Two-sided > >processing > > involves two impressions per sheet. If a two-sided document has > >an odd > > number of pages, the last sheet still counts as two impressions, > >if that > > sheet makes two passes through the marker or the marker marks on > >both sides > > of a sheet in a single pass. Two-up printing is the placement > >of two > > logical pages on one side of a sheet and so is still a single > >impression. > > See "page" and "sheet". > > > > The three interpretations of these three attributes are: > > > > 1. Does impressionsCompleted increment or not when a highlight > >or full color > > impression is made? The current above definition of impressions > >suggests > > that it does, since an impressions is the passing of one side of > >the > > media past the marker whether color or not. > > > > 2. Does the fullColorImpressionsCompleted count once for each > >side of > > a full color impression or once for each color pass past the > >side of > > a medium? > > > > For example, if I had a 16-page document that had 10 black and > >white pages, > > 5 highlight color pages, and 1 full 4-color page, (number-up=1, > >sides=1), > > would the counts at the end of my job be: > > > > highlightColor fullColor > > impressionsCompleted ImpressionsCompleted > >ImpressionsCompleted > > > > 1. 16 5 1 > > 2. 16 5 20 > > 3. 10 5 1 > > 4. 10 5 20 > > > > I suggest that it is interpretation 1 that we are agreeing to > >and I'll clarify > > the fullColorImpressionsCompleted, by adding the phrase, > >"independent > > of the number of colors or color passes" to the end of the first > > sentence, yielding: > > > > The number of full color impressions completed by the device for > >this job > > so far independent of the number of colors or color passes. > > > > I'll also add the parenthetical remake to the > >impressionsCompleted > > "(monochome, highlight color, and full color)" to the first > >sentence, > > since it is clear from the definition of impression that it > >includes > > all, yielding: > > > > The total number of impressions (monochome, highlight color, and > >full > > color) completed for this job so far. > > > > Ok? > > > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE > >CLARIFICATION. > > > > Thanks, > > Tom > > > > The current definitions of impressionsCompleted, > > highlightColorImpressionsCompleted, and > >fullColorImpressionsCompleted are: > > > > OBJECT-TYPE > > SYNTAX Integer32(-2..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The total number of impressions completed for this job so far. > >For > > printing devices, the impressions completed includes > >interpreting, marking, > > and stacking the output. For other types of job services, the > >number of > > impressions completed includes the number of impressions > >processed. > > > > NOTE - See the impressionsCompletedCurrentCopy and > > pagesCompletedCurrentCopy attributes for attributes that are > >reset on each > > document copy. > > > > NOTE - The jmJobImpressionsCompleted object can be used with the > > jmJobImpressionsPerCopyRequested object to provide an indication > >of the > > relative progress of the job, provided that the multiplicative > >factor is > > taken into account for some implementations of multiple copies." > > REFERENCE > > "See the definition of the term "impression" in Section 2 and > >the counting > > example in Section 3.4 entitled 'Monitoring Job Progress'." > > DEFVAL { 0 } -- default is no octets > > ::= { jmJobEntry 8 } > > > > fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > INTEGER: The number of full color impressions completed by the > >device for > > this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Full color impressions are typically > >defined as > > those requiring 3 or more colorants, but this MAY vary by > >implementation. > > > > highlightColorImpressionsCompleted(115), > >Integer32(-2..2147483647) > > INTEGER: The number of highlight color impressions completed by > >the device > > for this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Highlight color impressions are > >typically defined > > as those requiring black plus one other colorant, but this MAY > >vary by > > implementation. > > > > > > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > > >Tom, > > > > > >There's no ambiguity in my mind. You increment exactly one of > >the three > > >counters ([monochrome]impressionsCompleted, > > >fullColorImpressionsCompleted, or > >highlightColorImpressionsCompleted) > > >for each SIDE completed. If the side requires 3 or more > >colorants to > > >produce the impression then it's Full Color, black plus one > >other > > >colorant would be Highlight color, and a side that uses only > >black would > > >cause the monochrome counter to increment. To display job > >progress to a > > >user you need to sum all three of these counters. > > > > The advantage to saying that impressionsCompleted, counts > >black/white, > > highlight color, and full color, is that an application only > >need to > > look at one attribute if it doesn't care about the distinction > >of b/w, > > highlight and full color. Also the device might not implement > > the other two, so it is easier for an application to just look > >at the > > one attribute if that is all it is interested in. Ok? > > > > > > > >For example, if you produce a duplex sheet with full process > >color > > >graphics on the front side and black text on the back side, > >then you > > >would increment fullColorImpressionsCompleted when the front > >side was > > >completed and [monochrome]impressionsCompleted when the back > >was > > >complete. Since the descriptions of these attributes were > >changed to say > > >"For printing, the impressions completed includes interpreting, > >marking, > > >and stacking the output", then this implies to me that both > >counters > > >would be incremented simultaneously when this completed duplex > >sheet was > > >delivered to the output. > > > > So with my suggested resolution, the > >fullColorImpressionsCompleted > > would count by 1 and the impressionsCompleted would count by 2 > >in > > your example. > > > > > > > >Is there something else I'm missing here? > > > > > >Obviously these objects do not provide detailed colorant use > >information > > >for each page. To do so would require objects to count the > >actual amount > > >of each colorant transferred to each side. So as a compromise, > >we > > >proposed these two new objects (which complement the previously > >existing > > >[monochrome]impressionsCompleted counter) to provide enough > >information > > >for an accounting application to bill at different rates for > >monochrome, > > >highlight color, and full color impressions within a job. > > > > I think that the accounting program can still bill correctly > >with > > impressionsCompleted counting highlight and fullColor as well as > >monochrome. > > It can substract out the monochrome, if it wants to, or build in > >the > > charge for color to be less that the correct charge for coloer > >by the amount > > charged for monochrome and avoid subtracting. > > > > > > > >Thanks, > > >Angelo > > > > > >> -----Original Message----- > > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > >> Sent: Friday, December 12, 1997 11:26 AM > > >> To: Angelo_Caruso@wb.xerox.com > > >> Cc: XCMI Editors only > > >> Subject: Ambiguity in XCMI & PWG Job Mon: > > >> fullColorImpressionsCompleted(1 > > >> > > >> URGENT: > > >> > > >> The current definition of fullColorImpressionsCompleted(114) > >and > > >> highlightColorImpressionsCompleted(115) is: > > >> > > >> fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > >> INTEGER: The number of full color impressions completed by > >the device > > >> for > > >> this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Full color impressions are typically > >defined as > > >> those requiring 3 or more colorants, but this MAY vary by > > >> implementation. > > >> > > >> highlightColorImpressionsCompleted(115), > > >> Integer32(-2..2147483647) > > >> INTEGER: The number of highlight color impressions completed > >by the > > >> device > > >> for this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Highlight color impressions are > >typically > > >> defined > > >> as those requiring black plus one other colorant, but this > >MAY vary by > > >> implementation. > > >> > > >> > > >> Suppose you have a 4 color process that makes four passes > >through the > > >> marker > > >> for each side, does this attribute count by 1 for each pass > >or does > > >> it still > > >> count just the number of sides? > > >> > > >> The advantage of counting the number of color passes is that > >something > > >> > > >> counts for each pass which can be shown to a user. Also > >accounting > > >> may > > >> want to charge for each color pass. Conceivably, there might > >be a > > >> variable > > >> number of passes, depending on the colors demanded by each > >image? > > >> > > >> The advantage of only counting once per side, is that you can > >then > > >> compare > > >> the number of impressions for the job with the number of > > >> fullColorImpressionsCompleted and determine the percentage of > >color > > >> impressions in the job. Also this definition seems to be > >more in > > >> keeping > > >> with the > > >> concept of "stacking" the media mentioned in the definition. > > >> > > >> Since Xerox proposed this attribute, what did we have in > >mind? > > >> > > >> Thanks, > > >> Tom > > > > > > > > > > From rbergma at dpc.com Thu Dec 18 20:31:39 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Ambiguity in impressions|fullColor|highlighColorComppleted defns In-Reply-To: <3.0.1.32.19971216143657.00b547e0@garfield> Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> Tom, I agree with your interpretation. I have not found any other responses so I would guess no one else objects. If Angelo agrees, then it is closed. Have you heard from Angelo? Ron Bergman Dataproducts Corp. On Tue, 16 Dec 1997, Tom Hastings wrote: > Angelo, > > You've come up with a third interpretation of the impressionsCompleted, > fullColorImpressionsCompleted and highlightColorImpressionsCompleted! > > > I'm proposing the interpretation based on our discussion at the > Dec 5 JMP meeting (which you did not have the benefit of attending). > > > PEOPLE, > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU OBJECT TO > MY CLARIFICATIONS. > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS AGREEMENT. > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK AS WE > AGREED AT THE JMP MEETING. > > First, here is the definition of the term "impression" that we > came up with at the meeting (please review the text too, since it was only > the ideas that we agreed to at the meeting): > > Impression: For a print job, an impression is the passage of the entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the marker. > Thus a four pass color process counts as a single impression. One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an odd > number of pages, the last sheet still counts as two impressions, if that > sheet makes two passes through the marker or the marker marks on both sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single impression. > See "page" and "sheet". > > The three interpretations of these three attributes are: > > 1. Does impressionsCompleted increment or not when a highlight or full color > impression is made? The current above definition of impressions suggests > that it does, since an impressions is the passing of one side of the > media past the marker whether color or not. > > 2. Does the fullColorImpressionsCompleted count once for each side of > a full color impression or once for each color pass past the side of > a medium? > > For example, if I had a 16-page document that had 10 black and white pages, > 5 highlight color pages, and 1 full 4-color page, (number-up=1, sides=1), > would the counts at the end of my job be: > > highlightColor fullColor > impressionsCompleted ImpressionsCompleted ImpressionsCompleted > > 1. 16 5 1 > 2. 16 5 20 > 3. 10 5 1 > 4. 10 5 20 > > I suggest that it is interpretation 1 that we are agreeing to and I'll clarify > the fullColorImpressionsCompleted, by adding the phrase, "independent > of the number of colors or color passes" to the end of the first > sentence, yielding: > > The number of full color impressions completed by the device for this job > so far independent of the number of colors or color passes. > > I'll also add the parenthetical remake to the impressionsCompleted > "(monochome, highlight color, and full color)" to the first sentence, > since it is clear from the definition of impression that it includes > all, yielding: > > The total number of impressions (monochome, highlight color, and full > color) completed for this job so far. > > Ok? > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE CLARIFICATION. > > Thanks, > Tom > > The current definitions of impressionsCompleted, > highlightColorImpressionsCompleted, and fullColorImpressionsCompleted are: > > OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of impressions completed for this job so far. For > printing devices, the impressions completed includes interpreting, marking, > and stacking the output. For other types of job services, the number of > impressions completed includes the number of impressions processed. > > NOTE - See the impressionsCompletedCurrentCopy and > pagesCompletedCurrentCopy attributes for attributes that are reset on each > document copy. > > NOTE - The jmJobImpressionsCompleted object can be used with the > jmJobImpressionsPerCopyRequested object to provide an indication of the > relative progress of the job, provided that the multiplicative factor is > taken into account for some implementations of multiple copies." > REFERENCE > "See the definition of the term "impression" in Section 2 and the counting > example in Section 3.4 entitled 'Monitoring Job Progress'." > DEFVAL { 0 } -- default is no octets > ::= { jmJobEntry 8 } > > fullColorImpressionsCompleted(114), Integer32(-2..2147483647) > INTEGER: The number of full color impressions completed by the device for > this job so far. For printing, the impressions completed includes > interpreting, marking, and stacking the output. For other types of job > services, the number of impressions completed includes the number of > impressions processed. Full color impressions are typically defined as > those requiring 3 or more colorants, but this MAY vary by implementation. > > highlightColorImpressionsCompleted(115), Integer32(-2..2147483647) > INTEGER: The number of highlight color impressions completed by the device > for this job so far. For printing, the impressions completed includes > interpreting, marking, and stacking the output. For other types of job > services, the number of impressions completed includes the number of > impressions processed. Highlight color impressions are typically defined > as those requiring black plus one other colorant, but this MAY vary by > implementation. > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > >Tom, > > > >There's no ambiguity in my mind. You increment exactly one of the three > >counters ([monochrome]impressionsCompleted, > >fullColorImpressionsCompleted, or highlightColorImpressionsCompleted) > >for each SIDE completed. If the side requires 3 or more colorants to > >produce the impression then it's Full Color, black plus one other > >colorant would be Highlight color, and a side that uses only black would > >cause the monochrome counter to increment. To display job progress to a > >user you need to sum all three of these counters. > > The advantage to saying that impressionsCompleted, counts black/white, > highlight color, and full color, is that an application only need to > look at one attribute if it doesn't care about the distinction of b/w, > highlight and full color. Also the device might not implement > the other two, so it is easier for an application to just look at the > one attribute if that is all it is interested in. Ok? > > > > >For example, if you produce a duplex sheet with full process color > >graphics on the front side and black text on the back side, then you > >would increment fullColorImpressionsCompleted when the front side was > >completed and [monochrome]impressionsCompleted when the back was > >complete. Since the descriptions of these attributes were changed to say > >"For printing, the impressions completed includes interpreting, marking, > >and stacking the output", then this implies to me that both counters > >would be incremented simultaneously when this completed duplex sheet was > >delivered to the output. > > So with my suggested resolution, the fullColorImpressionsCompleted > would count by 1 and the impressionsCompleted would count by 2 in > your example. > > > > >Is there something else I'm missing here? > > > >Obviously these objects do not provide detailed colorant use information > >for each page. To do so would require objects to count the actual amount > >of each colorant transferred to each side. So as a compromise, we > >proposed these two new objects (which complement the previously existing > >[monochrome]impressionsCompleted counter) to provide enough information > >for an accounting application to bill at different rates for monochrome, > >highlight color, and full color impressions within a job. > > I think that the accounting program can still bill correctly with > impressionsCompleted counting highlight and fullColor as well as monochrome. > It can substract out the monochrome, if it wants to, or build in the > charge for color to be less that the correct charge for coloer by the amount > charged for monochrome and avoid subtracting. > > > > >Thanks, > >Angelo > > > >> -----Original Message----- > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > >> Sent: Friday, December 12, 1997 11:26 AM > >> To: Angelo_Caruso@wb.xerox.com > >> Cc: XCMI Editors only > >> Subject: Ambiguity in XCMI & PWG Job Mon: > >> fullColorImpressionsCompleted(1 > >> > >> URGENT: > >> > >> The current definition of fullColorImpressionsCompleted(114) and > >> highlightColorImpressionsCompleted(115) is: > >> > >> fullColorImpressionsCompleted(114), Integer32(-2..2147483647) > >> INTEGER: The number of full color impressions completed by the device > >> for > >> this job so far. For printing, the impressions completed includes > >> interpreting, marking, and stacking the output. For other types of > >> job > >> services, the number of impressions completed includes the number of > >> impressions processed. Full color impressions are typically defined as > >> those requiring 3 or more colorants, but this MAY vary by > >> implementation. > >> > >> highlightColorImpressionsCompleted(115), > >> Integer32(-2..2147483647) > >> INTEGER: The number of highlight color impressions completed by the > >> device > >> for this job so far. For printing, the impressions completed includes > >> interpreting, marking, and stacking the output. For other types of > >> job > >> services, the number of impressions completed includes the number of > >> impressions processed. Highlight color impressions are typically > >> defined > >> as those requiring black plus one other colorant, but this MAY vary by > >> implementation. > >> > >> > >> Suppose you have a 4 color process that makes four passes through the > >> marker > >> for each side, does this attribute count by 1 for each pass or does > >> it still > >> count just the number of sides? > >> > >> The advantage of counting the number of color passes is that something > >> > >> counts for each pass which can be shown to a user. Also accounting > >> may > >> want to charge for each color pass. Conceivably, there might be a > >> variable > >> number of passes, depending on the colors demanded by each image? > >> > >> The advantage of only counting once per side, is that you can then > >> compare > >> the number of impressions for the job with the number of > >> fullColorImpressionsCompleted and determine the percentage of color > >> impressions in the job. Also this definition seems to be more in > >> keeping > >> with the > >> concept of "stacking" the media mentioned in the definition. > >> > >> Since Xerox proposed this attribute, what did we have in mind? > >> > >> Thanks, > >> Tom > > > > > From rbergma at dpc.com Thu Dec 18 21:03:29 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank last p age back sides or not? In-Reply-To: Message-ID: <3.0.1.32.19971217130348.00fd26d0@garfield> Tom, I agree with Bill on this issue, especially that "the point may be moot" Have you asked Kinkos how they charge in this situation? We should stick with the agreement per the LA meeting. Ron Bergman Dataproducts Corp. On Thu, 18 Dec 1997, Wagner, William wrote: > This was discussed in great detail at the LA meeting. If one agrees > that the MIB is to provide information on what the printer does, which > may not necessarily agree with what the rate structures may or may not > be at a particular place at a particular time, then I think the > contention that sending a sheet side through transfer and fixing steps > constitutes making an impression. The question of how much colorant is > put on that page is a separate one. If it is a single period, a fully > colored page or a blank page, colorant use is a different characteristic > from impression, and one which could be instrumented. > > In most page printers, the information that a page has no marking is not > readily available. The page goes though the same processes, takes pretty > much the same time and the same wear and tear on the mechanism. I > suggest that, unless the printer has a way of separately ejecting such > sheet sides, from a printer point of view, treating a blank side > differently is an artificial distinction. > > The point may be moot. I am told that commercial duplication houses > charge by the sheet, with perhaps a different sheet rate for duplex (but > no distinction for blank sides). A large in-house reports person told > me that there are no blank pages; there is a header or footer, a page > number, or a "This page intentionally left blank" message. > > I suggest that a measure of importance from those actually concerned > with the accounting be obtained before the MIB imposes the derivation of > another parameter on the printer. > > W. A. Wagner (Bill Wagner) > OSICOM/DPI > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Wednesday, December 17, 1997 11:50 PM > > To: Tom Hastings > > Cc: jmp@pwg.org; ipp@pwg.org > > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > > last page back sides or not? > > > > Sorry, but I must agree with Angelo Caruso with the position > > that most folks are going to be pretty upset if they are > > charged for blanks sides of sheets. Can't say that I like > > that idea at all. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > From david at spencer.com Thu Dec 18 22:16:52 1997 From: david at spencer.com (David R Spencer) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank In-Reply-To: Re: JMP> URGENT: Should impressions include blank> Message-ID: <3.0.1.32.19971218191652.00c56280@garfield> Bill, I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. Therefore, perhaps the sentence in the definition of impression: > If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. should be: If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. David R. Spencer Spencer & Associates Publishing, Ltd. Three Giffard Way, Melville, NY 11747-2310 david@spencer.com 1-516-367-6655 Fax:1-516-367-2878 http://www.spencer.com ______________________________________________________________________ >This was discussed in great detail at the LA meeting. If one agrees >that the MIB is to provide information on what the printer does, which >may not necessarily agree with what the rate structures may or may not >be at a particular place at a particular time, then I think the >contention that sending a sheet side through transfer and fixing steps >constitutes making an impression. The question of how much colorant is >put on that page is a separate one. If it is a single period, a fully >colored page or a blank page, colorant use is a different characteristic >from impression, and one which could be instrumented. > >In most page printers, the information that a page has no marking is not >readily available. The page goes though the same processes, takes pretty >much the same time and the same wear and tear on the mechanism. I >suggest that, unless the printer has a way of separately ejecting such >sheet sides, from a printer point of view, treating a blank side >differently is an artificial distinction. > >The point may be moot. I am told that commercial duplication houses >charge by the sheet, with perhaps a different sheet rate for duplex (but >no distinction for blank sides). A large in-house reports person told >me that there are no blank pages; there is a header or footer, a page >number, or a "This page intentionally left blank" message. > >I suggest that a measure of importance from those actually concerned >with the accounting be obtained before the MIB imposes the derivation of >another parameter on the printer. > >W. A. Wagner (Bill Wagner) >OSICOM/DPI > >> -----Original Message----- >> From: Jay Martin [SMTP:jkm@underscore.com] >> Sent: Wednesday, December 17, 1997 11:50 PM >> To: Tom Hastings >> Cc: jmp@pwg.org; ipp@pwg.org >> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >> last page back sides or not? >> >> Sorry, but I must agree with Angelo Caruso with the position >> that most folks are going to be pretty upset if they are >> charged for blanks sides of sheets. Can't say that I like >> that idea at all. >> >> ...jay >> >> ---------------------------------------------------------------------- >> -- JK Martin | Email: jkm@underscore.com -- >> -- Underscore, Inc. | Voice: (603) 889-7000 -- >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >> ---------------------------------------------------------------------- From hastings at cp10.es.xerox.com Thu Dec 18 22:30:18 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank In-Reply-To: Message-ID: <3.0.1.32.19971218193018.00ba51a0@garfield> At 18:03 12/18/1997 PST, Ron Bergman wrote: >Tom, > >I agree with Bill on this issue, especially that "the point may be moot" > >Have you asked Kinkos how they charge in this situation? I believe that Kinkos charges by the sheet for printing from a PC. For copying, they have a different rate for one versus two sided copying. So far, I have not run into a duplex printer at Kinkos, so I don't know whether they have a policy for two-sided printing. But if the printing charge is like the copying charge, this issue would be moot. > >We should stick with the agreement per the LA meeting. Then we may want to add a note that impressions is more for monitoring and sheets is for monitoring and accounting. Tom There is another comment on this issue that was sent only to the IPP DL suggesting a rather simple algorithm that only worries about the last sheet, not any other sheets, and only as a recommendation. Is that a good compromise? >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > From rbergma at dpc.com Fri Dec 19 11:45:03 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? In-Reply-To: <3.0.1.32.19971218193018.00ba51a0@garfield> Message-ID: <3.0.1.32.19971218193018.00ba51a0@garfield> Tom, On Thu, 18 Dec 1997, Tom Hastings wrote: > At 18:03 12/18/1997 PST, Ron Bergman wrote: > >Tom, > > > >I agree with Bill on this issue, especially that "the point may be moot" > > > >Have you asked Kinkos how they charge in this situation? > > I believe that Kinkos charges by the sheet for printing from a PC. > For copying, they have a different rate for one versus two sided > copying. So far, I have not run into a duplex printer at Kinkos, > so I don't know whether they have a policy for two-sided printing. > But if the printing charge is like the copying charge, this issue > would be moot. > > > > >We should stick with the agreement per the LA meeting. > > Then we may want to add a note that impressions is more for monitoring > and sheets is for monitoring and accounting. > Could you post a copy of the note to be added to the DL? > Tom > > > There is another comment on this issue that was sent only to the IPP DL > suggesting a rather simple algorithm that only worries about the last > sheet, not any other sheets, and only as a recommendation. Is that a good > compromise? > The proposed change sounds reasonable. > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant difference > between blank pages within a document and documents in a duplex job with an > odd number of pages causing the COMPLETELY blank back side of the last page > to be counted? Almost all page printers include an option for not printing > such completely blank pages, and I think the point about user concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of impression: > >> If a two-sided document has an odd number of pages, the last sheet still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > >should be: > >If a two-sided document has an odd number of pages and there are no marks > to be made on second side of the last sheet, the last sheet should count as > one impression, instead of two, even if that sheet makes two passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Fri Dec 19 12:40:23 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Proposed jobmon MIB note for impressions (that count blank In-Reply-To: Message-ID: <3.0.1.32.19971219094023.00c389b0@garfield> I am not proposing any change to IPP from the current definition of impression which the Model document has as: 12.2.5 impression An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. I am only proposing to add a warning note to the Job Monitoring MIB, since we have agreed that impressions include passes past the marker that don't make marks, on even the last sheet. I propose to add the following note to the definition of the term impressions (to which all attributes and objects contain a reference) that we have in the PWG Job Monitoring MIB: NOTE - Since impressions include blank sides, it is suggested that accounting application implementers consider charging for sheets, rather than impressions, possibly factoring in value of the sides attribute for possibly different charges for one versus two-sided printing, since some users may think that impressions don't include blank sides. Here is the definition that we agreed to in principle at the L.A. meeting and for which there still seems to be support from most respondents: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". If you have any objections to the note, please voice them today, since we are forwarding the Job Mon MIB as an Internet-Draft today. Thanks, Tom At 08:45 12/19/1997 PST, Ron Bergman wrote: >Tom, > >On Thu, 18 Dec 1997, Tom Hastings wrote: > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: >> >Tom, >> > >> >I agree with Bill on this issue, especially that "the point may be moot" >> > >> >Have you asked Kinkos how they charge in this situation? >> >> I believe that Kinkos charges by the sheet for printing from a PC. >> For copying, they have a different rate for one versus two sided >> copying. So far, I have not run into a duplex printer at Kinkos, >> so I don't know whether they have a policy for two-sided printing. >> But if the printing charge is like the copying charge, this issue >> would be moot. >> >> > >> >We should stick with the agreement per the LA meeting. >> >> Then we may want to add a note that impressions is more for monitoring >> and sheets is for monitoring and accounting. >> >Could you post a copy of the note to be added to the DL? > >> Tom >> >> >> There is another comment on this issue that was sent only to the IPP DL >> suggesting a rather simple algorithm that only worries about the last >> sheet, not any other sheets, and only as a recommendation. Is that a good >> compromise? >> >The proposed change sounds reasonable. > >> >X-Sender: spencerdr@vipmail.earthlink.net >> >Date: Thu, 18 Dec 1997 10:03:04 PST >> >To: "Wagner, William" >> >From: David R Spencer >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last >> > page back sides or not? >> >Cc: ipp@pwg.org >> >Sender: ipp-owner@pwg.org >> >X-MIME-Autoconverted: from quoted-printable to 8bit by >> garfield.cp10.es.xerox.com id LAA26719 >> > >> >Bill, >> > >> >I'm just monitoring the group, but isn't there a significant difference >> between blank pages within a document and documents in a duplex job with an >> odd number of pages causing the COMPLETELY blank back side of the last page >> to be counted? Almost all page printers include an option for not printing >> such completely blank pages, and I think the point about user concern is >> well taken. >> > >> >Therefore, perhaps the sentence in the definition of impression: >> >> If a two-sided document has an odd number of pages, the last sheet still >> counts as two impressions, if that sheet makes two passes through the >> marker or the marker marks on both sides of a sheet in a single pass. >> >should be: >> >If a two-sided document has an odd number of pages and there are no marks >> to be made on second side of the last sheet, the last sheet should count as >> one impression, instead of two, even if that sheet makes two passes through >> the marker. >> > >> >David R. Spencer >> > >> >Spencer & Associates Publishing, Ltd. >> >Three Giffard Way, Melville, NY 11747-2310 >> >david@spencer.com >> >1-516-367-6655 Fax:1-516-367-2878 >> >http://www.spencer.com > > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Fri Dec 19 15:36:47 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> Proposed jobmon MIB note for impressions (that count blank pages) In-Reply-To: <3.0.1.32.19971219094023.00c389b0@garfield> Message-ID: <3.0.1.32.19971219094023.00c389b0@garfield> Tom, I don't have any objections to your proposal. Ron Bergman Dataproducts Corp. On Fri, 19 Dec 1997, Tom Hastings wrote: > I am not proposing any change to IPP from the current definition > of impression which the Model document has as: > > 12.2.5 impression > > An "impression" is the image (possibly many print-stream pages in different > configurations) imposed onto a single media page. > > > > I am only proposing to add a warning note to the Job Monitoring MIB, > since we have agreed that impressions include passes past the marker > that don't make marks, on even the last sheet. > > I propose to add the following note to the definition of the > term impressions (to which all attributes and objects contain a reference) > that we have in the PWG Job Monitoring MIB: > > NOTE - Since impressions include blank sides, it is suggested that > accounting application implementers consider charging for sheets, rather > than impressions, possibly factoring in value of the sides attribute for > possibly different charges for one versus two-sided printing, since some > users may think that impressions don't include blank sides. > > > Here is the definition that we agreed to in principle at the L.A. meeting > and for which there still seems to be support from most respondents: > > Impression: For a print job, an impression is the passage of the entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the marker. > Thus a four pass color process counts as a single impression. One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an odd > number of pages, the last sheet still counts as two impressions, if that > sheet makes two passes through the marker or the marker marks on both sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single impression. > See "page" and "sheet". > > > If you have any objections to the note, please voice them today, > since we are forwarding the Job Mon MIB as an Internet-Draft today. > > Thanks, > Tom > > > At 08:45 12/19/1997 PST, Ron Bergman wrote: > >Tom, > > > >On Thu, 18 Dec 1997, Tom Hastings wrote: > > > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: > >> >Tom, > >> > > >> >I agree with Bill on this issue, especially that "the point may be moot" > >> > > >> >Have you asked Kinkos how they charge in this situation? > >> > >> I believe that Kinkos charges by the sheet for printing from a PC. > >> For copying, they have a different rate for one versus two sided > >> copying. So far, I have not run into a duplex printer at Kinkos, > >> so I don't know whether they have a policy for two-sided printing. > >> But if the printing charge is like the copying charge, this issue > >> would be moot. > >> > >> > > >> >We should stick with the agreement per the LA meeting. > >> > >> Then we may want to add a note that impressions is more for monitoring > >> and sheets is for monitoring and accounting. > >> > >Could you post a copy of the note to be added to the DL? > > > >> Tom > >> > >> > >> There is another comment on this issue that was sent only to the IPP DL > >> suggesting a rather simple algorithm that only worries about the last > >> sheet, not any other sheets, and only as a recommendation. Is that a good > >> compromise? > >> > >The proposed change sounds reasonable. > > > >> >X-Sender: spencerdr@vipmail.earthlink.net > >> >Date: Thu, 18 Dec 1997 10:03:04 PST > >> >To: "Wagner, William" > >> >From: David R Spencer > >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > >> > page back sides or not? > >> >Cc: ipp@pwg.org > >> >Sender: ipp-owner@pwg.org > >> >X-MIME-Autoconverted: from quoted-printable to 8bit by > >> garfield.cp10.es.xerox.com id LAA26719 > >> > > >> >Bill, > >> > > >> >I'm just monitoring the group, but isn't there a significant difference > >> between blank pages within a document and documents in a duplex job with an > >> odd number of pages causing the COMPLETELY blank back side of the last page > >> to be counted? Almost all page printers include an option for not printing > >> such completely blank pages, and I think the point about user concern is > >> well taken. > >> > > >> >Therefore, perhaps the sentence in the definition of impression: > >> >> If a two-sided document has an odd number of pages, the last sheet still > >> counts as two impressions, if that sheet makes two passes through the > >> marker or the marker marks on both sides of a sheet in a single pass. > >> >should be: > >> >If a two-sided document has an odd number of pages and there are no marks > >> to be made on second side of the last sheet, the last sheet should count as > >> one impression, instead of two, even if that sheet makes two passes through > >> the marker. > >> > > >> >David R. Spencer > >> > > >> >Spencer & Associates Publishing, Ltd. > >> >Three Giffard Way, Melville, NY 11747-2310 > >> >david@spencer.com > >> >1-516-367-6655 Fax:1-516-367-2878 > >> >http://www.spencer.com > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > > > From hastings at cp10.es.xerox.com Sat Dec 20 12:23:34 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Internet-Draft posted - but .txt has lost cross references! Message-ID: <3.0.1.32.19971220092334.00ca1c00@garfield> I finshed the edits that Ron and Harry found proof reading a week ago's version of the MIB. This was to be the Internet-Draft that was to be forwarded to the IESG for their four week review in order to become an informational RFC. After the cover sheet, its labeled V1 (IETF won't allow "." in the subject line). I edited all of the agreements from Harry's minutes from the L.A. meeting, 12/05/97. Unfortunately, I upgraded the file to WORD97 without making sure that I had the Distiller and the generic text driver on the same system. Having WORD97 down grade to WORD6 almost worked, except the generic text driver loses all of the cross references. Also the AttributeTypeTC definition is too big for the SMICng compiler; it bombs out! However, it does compile with the Epilogue and the MOSY compilers. So I didn't forward it as an Internet-Draft. The text file meets the IETF standards for line length and no special characters. The files are: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-word97.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-red.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-word97.doc The "rev" files are with revisions since the V0.86 version which was released after the 10/31 meeting. The changes are: 1. use the new PWG OIDs without the standard arc: ... enterprises pwg(2699) jobmon(1) 2. make the document a PWG draft standard that will be sent as an Internet-Draft that will become an IETF Informational RFC, including changing the IANA Considerations section not to use IANA 3. add natural language support like IPP 4. fix the issues with monitoring collated/uncollated implementations, adding the jobCollationType attribute 5. fix impressions completed, 6. allows multiple Job Submission Id entries to point to the same jmJobIndex entry 7. and add 3 new Job Submission Ids 8. sort the terminology alphabetically as requested 9. Clarify how JmJobStringTC can be used with client localized strings or keywords, like IPP. I'm off for two weeks and not near any place that has WORD97 and the generic text driver on the same system. I'm sorry that I didn't quite make it. Perhaps someone else can try, or wait until the first week in January. Tom From hastings at cp10.es.xerox.com Mon Dec 22 02:23:47 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted Message-ID: <3.0.1.32.19971221232347.00cb08b0@garfield> I finshed the edits that Ron and Harry found proof reading a week ago's version of the MIB and posted them on the PWG server. This was to be the Internet-Draft that was to be forwarded to the IESG for their four week review in order to become an informational RFC as the first PWG standard! Unfortunately, there are a few minor problems with the .txt version (extracting plain text from MS-WORD is still tricky business, especially when switching from WORD6 to WORD97), so I haven't actually forwarded the .txt form to the internet-drafts DL. I'll confer with Ron Bergman on Monday, to see if he still wants me to send the .txt file that I just posted as an Internet-Draft or wait until January 5, when I'm back in the office. See below for an explanation. Here is the introduction that Ron and I crafted: This specification defines an official Printer Working Group (PWG) [PWG] standard SNMP MIB for the monitoring of jobs on network printers. This specification is being published as an IETF Information Document for the convenience of the Internet community. In consultation with the IETF Application Area Directors, we concluded that it properly belongs as an Information document, because this MIB monitors a service node on the network, rather than a network node proper. After the cover sheet, its labeled V1 (IETF won't allow "." in the subject line). The .txt version doesn't have the cover sheet. I edited all of the agreements from Harry's minutes from the L.A. meeting, 12/05/97. There are still a few minor problems with the plain text version only. (The .doc and .pdf versions are fine): a. I was able to use my generic text driver at home where I also have WORD97 and which produced a proper .txt file with cross references. But I forgot to re-do the table of contents and index with the fixed pitch fonts, so the page numbers are off by 0 to 10 pages. b. Also the AttributeTypeTC definition is too big for the Sun version of the SMICng compiler I was using; it bombs out saying object too big! However, it does compile with the Epilogue and the MOSY compilers. c. Finally, the text file meets the IETF standards: - no special characters, except FF and LF. - line length, almost: there are 275 lines with 73 characters, instead of 72 Just another bug that MS-WORD 97 and/or the generic text driver have introduced. The files are: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-word97.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-red.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-word97.doc The .txt file is the one that was supposed to be sent as an Internet-Draft. The "rev" files are with revisions since the V0.86 version which was released after the 10/31 meeting. The changes are: 1. use the new PWG OIDs without the standard arc: ... enterprises pwg(2699) jobmon(1) 2. make the document an official PWG standard that will be sent as an Informational Internet-Draft that will become an IETF Informational RFC, including changing the IANA Considerations section not to use IANA, but to use PWG registration. 3. add natural language support like IPP, as distributed to the DL before the L.A. meeting: processingMessageNaturalLanguageTag(7) - language of processingMessage jobNaturalLanguageTag(9) - language of job strings 4. clarify that the processingMessage is intended to be for messages generated during processing of the job, such as from the interpreter, which is not the same as IPP "job-state-message" which is just a printable form of "job-state" and "job-state-reasons", and that IPP doesn't have an equivalent of processingMessage (because programs would want to parse to take action on the message from the interpreter). These were important clarifications from the IPP WG discussions. 5. fixed the issues with monitoring collated/uncollated implementations, adding the jobCollationType attribute as agreed at the L.A. meeting: JmJobCollationTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value is the type of job collation. Implementations that don't support multiple documents or don't support multiple copies SHALL NOT support the uncollatedDocuments(5) value." REFERENCE "This is a type 2 enumeration. See Section 3.7.1.2. See also Section 3.4, entitled 'Monitoring Job Progress'." SYNTAX INTEGER { other(1), unknown(2), uncollatedSheets(3), -- sheets within each document copy -- are not collated: 1 1 ..., 2 2 ..., collatedDocuments(4), -- internal collated sheets, -- documents: A, B, A, B, ... uncollatedDocuments(5) -- internal collated sheets, -- documents: A, A, ..., B, B, ... } 6. fix impressions completed, so it counts the number of sides stacked independent of how the intepreter produces multiple copies. 7. allows multiple Job Submission Id entries to point to the same jmJobIndex entry 8. added 3 new Job Submission Ids for: NetWare PServer ('B'), Server Message Block protocol (SMB) ('C'), Transport Independent Printer/System Interface (TIP/SI) ('D'). 9. sort the terminology alphabetically as requested 10. clarify how JmJobStringTC can be used with client localized strings or with keywords which are not localized (they are in US-ASCII, U.S. English), like IPP. Tom From imcdonal at eso.mc.xerox.com Mon Dec 22 10:01:20 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted In-Reply-To: RESEND: PWG Standard Job Monitoring MIB, V1, posted> Message-ID: <9712221501.AA17020@snorkel.eso.mc.xerox.com> Hi Tom, I commented out (as ASN.1 comments) the details of the attributes in the DESCRIPTION clause of JmAttributeTypeTC in this version of the Job Mon MIB and got a CLEAN compile with SMICng. I also got a small warning from Epilogue on the OID assignment statement in the MODULE-IDENTITY macro. I'll look at this more and experiment before commenting to the DL. Lastly, the posted text file has 275 lines that are 73 characters long (not all are trailing blanks). After using the SMICng 'mstrip' tool to extract the '.mib' file, there are still 164 lines that are 73 characters long. This does NOT meet the IETF rules for Internet-Drafts (or RFCs) and will need to be corrected in January. Thanks for all the good work, - Ira McDonald (outside consultant at Xerox) From rbergma at dpc.com Mon Dec 22 11:53:09 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> New Job MIB Mapping Document Message-ID: <9712221501.AA17020@snorkel.eso.mc.xerox.com> I have loaded the latest Job Monitoring MIB, Job Submission Protocol Mapping document as: ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP03.DOC (.TXT) (The TXT version does not have the proper page format. The DOC version can be viewed with or without revisions.) This version contains the changes agreed to in the December meeting plus 1. The DPA mapping provided by Tom Hastings. 2. I added an introductory paragraph for TIP/SI. 3. Scott Isaacson provided clairification regarding jobPriority for PServer. I have received the parameter information from Craig Whittle (thanks Craig!) and will incorporate this into the document by the first week in January. The only other open issue is the mapping for IPDS. Please review and provide any comments. If no comments are received, this document will not be discussed in Maui. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Dec 29 17:35:42 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted In-Reply-To: <9712221501.AA17020@snorkel.eso.mc.xerox.com> Message-ID: <3.0.1.32.19971229143542.010a8100@garfield> At 07:01 12/22/1997 PST, Ira Mcdonald x10962 wrote: >Hi Tom, > >I commented out (as ASN.1 comments) the details of the attributes >in the DESCRIPTION clause of JmAttributeTypeTC in this version >of the Job Mon MIB and got a CLEAN compile with SMICng. Looks like I should move all the DESCRIPTION of each of the attributes up front before the BEGIN into the section on attributes, since I got the same error with SMICng on my Sun workstation. Since I have the enum numbers duplicated in the description, the reader can still find each attribute easily by the number and the table of contents and index will refer to the moved section. By the way, did you have any difficulty removing the headers and footers from the .txt version with the MSTRING program distributed with SMICng on the PC? The version of mstring on the Sun was unable to strip the headers from the .txt version that I posted. My test compile was with a previous version that differed only in formatting. > >I also got a small warning from Epilogue on the OID assignment >statement in the MODULE-IDENTITY macro. I'll look at this >more and experiment before commenting to the DL. I got it too, but I figured it was some problem with the Epilogue compiler, but if you see a problem, let us know. > >Lastly, the posted text file has 275 lines that are 73 characters >long (not all are trailing blanks). After using the SMICng >'mstrip' tool to extract the '.mib' file, there are still 164 lines >that are 73 characters long. This does NOT meet the IETF rules >for Internet-Drafts (or RFCs) and will need to be corrected >in January. Yes, I discovered this too, so I need to make the right margin 1.4 inches wide, instead of 1.3 (left, top, and bottome = 0.0). It looks like MS-WORD now places the center of the character inside the margin, not the right edge of the character. Strange. > >Thanks for all the good work, >- Ira McDonald (outside consultant at Xerox) > > From imcdonal at eso.mc.xerox.com Mon Dec 29 20:26:16 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted In-Reply-To: RESEND: PWG Standard Job Monitoring MIB, V1, posted> Message-ID: <9712300126.AA18611@snorkel.eso.mc.xerox.com> Hi Tom, Per earlier comments from David Perkins, please do NOT move all the attribute descriptions up before the BEGIN statement. Just make them all into ASN.1 comment lines in place (with "--" in column 1), and remember to wrap a close-quote around the last line of the general DESCRIPTION clause (in '...AttributeTypeTC'). Otherwise, an 'mstrip' output will remove all the attribute descriptions (NOT good). No, I didn't have any trouble running 'mstrip' on your posted version. Also, I forgot to further pursue the Epilogue warning on the assignment in the MODULE-IDENTITY macro. I'll try to get back to this later this week or next week, as soon as I can. Cheers, - Ira --------------------------------- Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA18554; Mon, 29 Dec 97 17:45:19 EST Received: from norman.cp10.es.xerox.com by zombi (4.1/SMI-4.1) id AA26662; Mon, 29 Dec 97 17:40:10 EST Received: from garfield.cp10.es.xerox.com (garfield.cp10.es.xerox.com [13.240.104.48]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id OAA00115; Mon, 29 Dec 1997 14:38:57 -0800 (PST) Received: from dellxpi-11 (ppphastings [13.240.103.243]) by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id OAA09541; Mon, 29 Dec 1997 14:35:07 -0800 (PST) Message-Id: <3.0.1.32.19971229143542.010a8100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 29 Dec 1997 14:35:42 -0800 To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), jmp@pwg.org From: Tom Hastings Subject: Re: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted In-Reply-To: <9712221501.AA17020@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: R At 07:01 12/22/1997 PST, Ira Mcdonald x10962 wrote: >Hi Tom, > >I commented out (as ASN.1 comments) the details of the attributes >in the DESCRIPTION clause of JmAttributeTypeTC in this version >of the Job Mon MIB and got a CLEAN compile with SMICng. Looks like I should move all the DESCRIPTION of each of the attributes up front before the BEGIN into the section on attributes, since I got the same error with SMICng on my Sun workstation. Since I have the enum numbers duplicated in the description, the reader can still find each attribute easily by the number and the table of contents and index will refer to the moved section. By the way, did you have any difficulty removing the headers and footers from the .txt version with the MSTRING program distributed with SMICng on the PC? The version of mstring on the Sun was unable to strip the headers from the .txt version that I posted. My test compile was with a previous version that differed only in formatting. > >I also got a small warning from Epilogue on the OID assignment >statement in the MODULE-IDENTITY macro. I'll look at this >more and experiment before commenting to the DL. I got it too, but I figured it was some problem with the Epilogue compiler, but if you see a problem, let us know. > >Lastly, the posted text file has 275 lines that are 73 characters >long (not all are trailing blanks). After using the SMICng >'mstrip' tool to extract the '.mib' file, there are still 164 lines >that are 73 characters long. This does NOT meet the IETF rules >for Internet-Drafts (or RFCs) and will need to be corrected >in January. Yes, I discovered this too, so I need to make the right margin 1.4 inches wide, instead of 1.3 (left, top, and bottome = 0.0). It looks like MS-WORD now places the center of the character inside the margin, not the right edge of the character. Strange. > >Thanks for all the good work, >- Ira McDonald (outside consultant at Xerox) > > From imcdonal at eso.mc.xerox.com Mon Dec 29 20:43:27 1997 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Mon [Epilogue fixup] In-Reply-To: RESEND: PWG Standard Job Mon [Epilogue fixup]> Message-ID: <9712300143.AA18672@snorkel.eso.mc.xerox.com> Hi Tom, The Epilogue warning goes away if you rewrite the 'jobmonMIB MODULE-IDENTITY' assignment statement from ::= { enterprises pwg(2699) jobmon(1) } to ::= { enterprises pwg(2699) jobmonMIB(1) } Cheers, - Ira