Subject: IPP> MOD - FYI: RESEND: PWG Standard Job Monitoring MIB, V1, posted

From: Tom Hastings <[email-masked]>
Date: Mon, 22 Dec 1997 09:34:23 PST

For those IPP folks that are on neither the PWG list nor the JMP list,
we finished the PWG Job Monitoring MIB which has a lot of compatibility
with IPP, while also being useful for monitoring devices and servers
that supports any job submission protocol.

Tom

>X-Sender: hastings@garfield
>Date: Sun, 21 Dec 1997 23:23:47 PST
>To: [email-masked]
>From: Tom Hastings <[email-masked]>
>Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted
>Cc: [email-masked]
>Sender: [email-masked]
>
>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
>
>
>
>