Harry Lewis 1 Minutes of the PWG - JMP Seattle August, 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 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 . PJL - Roman-8 IPP - UTF-8 If PJL or IPP do not include the character set attribute, the agent is responsible for knowing which protocol submitted the job and assuming the above localizations. Other ISSUES Serial and Parallel Ports Chris Wellens had originated an issue regarding Job MIB use with Parallel and Serial ports. The Job MIB in no way restricts it's use to jobs coming over any specific port. In fact, the agent assigns the jmJobSubmissionID to any job, from any port, which appears to come from an unaware client. Tom Hastings and Bill Wagner will submit clarifications to the JMP e-mail and Harry Lewis will respond to Chris - making sure her concerns are understood and that she accepts our clarification. Job CANCEL state reasons Issue 115 - There was a simple attempt to clarify that, when a job is Canceled it should enter the CANCEL state with reason "Processing to stop point". This allows accounting applications to be aware that values, such as the number of impression stacked, could change as the cancel operation completes. This, however, led to the observation that Processing to stop point belongs to an optional group of job state reasons. We talked about using the reason "Printing" instead but, in the end, decided to move "Processing to Stopped Point" to the mandatory Reasons-1 group. Job state OTHER Job state OTHER was removed. Toner selections Toner economy vs. density. Is there a difference? Yes. IPP and JMP alignment IPP and JMP do not have identical text string sizes for similar or identical attributes. We should define a min and max 63...255. Also need to define agent behavior if text string is too large. Truncate left has the problem mentioned earlier with UTF-8 variable multi-byte characters. Truncate right (apparently the most favored at the meeting) looses the most granular part of the information (in a URL, for example). The agent could also reject the set and allow the client to adjust the text string length until it fits. Tom Hastings will put this question to the JMP and IPP mailing lists. Attributes and State Reasons which were added to IPP in Seattle should also be added to the Job MIB v0.85. 119 - new 32 bit IPP Job ID = jmJobIndex? Some feel it is not possible to insist because nics might assign the IPP ID prior to communicating with the controller. Some think this is possible. We will make a recommendation in the job MIB but it's not enforceable. Any other IPP/JMP differences? Put them on the wire ASAP. Number of rows Object 120 - Paul Moore requested an object which indicates the number of consecutive rows in a packed table. This would reduce network traffic by facilitating proper number of gets in a packet. etc. Due to the dynamic nature of the Job MIB tables (jobs being completed, canceled etc.) there was come confusion about Paul's request (Paul not able to attend this part of the meeting). Ron Bergman to talk with Paul. Request Paul articulate issue via e-mail if still wants to pursue. Platform Types Platform types attribute - Add WIN-98 to the list. Follow-on Activities We should pursue a "Mapping RFC" to map legacy protocols such as LPD, Netware, Appletalk, IPP, NDPS, PJL, Pserver, NPAP, IPDS etc. into the Job MIB. Interop testing, experience sharing - other follow through. Use FAQ process rather than change the Job MIB draft. Reissue the draft only as needed based on FAQ accumulation or severity. Nested job and character set decisions should be the first FAQ entries, even though they will result in draft changes. More elaborate clarifications can go into the FAQ. Harry Lewis will manage the FAQ. Tom's issues doc will stay as is and not be completely reiterated in the FAQ.