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.