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.