Job MIB Minutes - Atlanta - 9/19/97Harry Lewis 1 9/25/97 Attendees Ron Bergman - DataProducts Mabry Dozier - QMS Lee Farrell - Canon Tom Hastings - Xerox Scott Isaacson - Novell Rick Landau - Digital Equipment Harry Lewis - IBM Printing Systems Bob Pentecost - HP Yuyi Sacchi - Japan Computer Industry Bill Wagner - DPI/Osicom Lloyd Young - Lexmark Standards track vs. Individual Contribution. The IESG is telling us to submit the Job MIB as an individual contribution - Informational RFC (not Standards Track). This way, the MIB will undergo less rigorous examination by the IESG, consisting only of formatting and/or obvious contrary statements. The Job MIB would still get an RFC number. We would have a 4 week rather than 2 week "Last Call". However, there is question as to where, on the OID tree, the Job MIB would be registered. If it ends up registered under "Experimental", only, this could be detrimental to adoption of the Job MIB by industry participants. Experimental.54 is assigned to PWG. Experimental.54.104 was assigned by Steve Waldbusser to the Printer MIB. We have chosen Experimental.54.105 for the Job MIB, during it's development. Currently, this structure is not compatible with the SMICNG compiler, however. Tom working with Ira to correct this When IBM and CISCO publish SNA MIBs, today, these are informational, not standards track. Another example of Informational RFC is RFC1179 - which is informational. Job MIB and IPP The Job MIB will attempt to remain aligned with any new IPP Job attributes. Interoperability We will run our own interoperability testing, following the same basic rules as the IETF but we will be more at ease to make agreements regarding what needs to be changed, if anything. We will still focus on only fixing things which are found to be "broke" in the Job MIB, not continuously adding function unless we embark on a new Job MIB version. Schedule Version 0.86 by Friday, 9/26, then 2 weeks to review. Final version 0.88 by the end of October. Note that "Last Call" is for the world at large and should not be fraught with comments from our own workgroup. Issues/Changes The following issues were discussed and agreed: Cancel and Abort states will transition upon completion not initiation. Add jobURI as an attribute. 255 string. Note that, for singular devices, like an IPP printer device, this is likely to be generated on the fly, not stored repeatedly. Add new format for jmJobSubmissionID. Agent only. Last 39 octets of the job URL + jmJobIndex. Moved submissionInterrupted to jobStateReason-1 added jobCacneledAtDevice for "local" cancel. clarify canced by User vs. Operator. clarified that processingToStoppedState is intended for the Processing state, not Canceled or Aborted states, since they are completion states. clarified abortedBySystem to show that it may apply to the Processing, PendingHeld or Aborted states. moved ServiceOffline to JobStateReasons-1 IPP has 3 new jobStateReasons. JobInterpreting, JobQueued, JobTransforming. JobQueued (IPP). Note that this is same as JMP jobQueuedInDevice. There is also a problem with the IPP definition in that the name is Queued and the definition is queuing. Which is it? jobTransforming added to job state reason 2 or 3 jobInterpreting added to stateReasons-1. There was a proposal to delete jobTransferring but it was decided against because it could be viewed as a more abbreviated means of indicating incoming or outgoing data. As a result of Ron's LPD to JMP mapping, we added jmJobSubmissionID format-9 specifically for LPD. Octets 2-40 contain the host-name portion of the control file name field. Octets 41-48 contain the sequential number assigned by the submission protocol Job MIB Editorials Ron supplied a list of editorial changes which had been covered via the mailing list. Job MIB Mapping Ron Bergman presented a LPD mapping document and a general framework for mapping other submission protocols. Tom suggested that a convention be established to indicate whether attributes should map into Octets, Integer or both for the Attribute Table. Rick Landau recommended further reduction of the table. A table would be hard to do in the RFC text format, however. Perhaps a table posted on the PWG ftp site would be helpful. In LPD, the client assigns the job name, not the server. Ron modified his LPD mapping to reflect this. We added jmJobSubmissionID format-9 (see Issues/Changes, above) Other mappings which have been done: HP-PJL P-Server N-Printer NDPS These need to be incorporated into the overall mapping document. Assignments were given for further mappings. DPA mappings will be shown for actual implementations such as NDPS, PSM, PrintXchange, Dazel... As a group, we did not review each and every existing mapping, but we did discuss jmJobSubmission ID for every one we currently have mappings for. PJL - HP has added @PJL JobSubmissionID = PJL also has a job attribute which associates an owner with the document. If not using @PJL JobSubmissionID, then the agent can construct a Format-0 ID from the JobOwner. In general, for all mappings, if there is no job owner and no jmJobSubmissionID, the agent should just use blanks for the string N-Printer - There is nothing inherent in this protocol that facilitates job management via the job MIB. You can't get jobOwner. Can't get JobID 'cause there's only ever one job. But, jobs submitted via N-Printer can be wrapped in PJL. P-Server - job ID is supplied by the sever, not the client. This actually a P-Server spool ID and a control record available to the Q-Server. Job Owner is supplied by client. Bindery name or fully distinguished DNS name. NDPS - supports most jmJob attributes. Next Meeting The next meeting will be October 31 in Boulder. This meeting should be addressing editorial changes ONLY and issues related to the IESG and/or registration. Function is Frozen and the MIB should be complete and completely reviewed by then!