Subject: JMP> 4th Set of Comments on Version 0.83

From: Ron Bergman <[email-masked]>
Date: Mon, 28 Jul 1997 09:57:40 -0700 (PDT)

Some more editorial corrections to version 0.83.  (I have more comments and
will try to get the remainder published tonight.)

1. Section 3.3.4, first paragraph (page 24):

   Add to end of the paragraph:  "Attributes that allow duplicates are
   indicated in the appropriate attribute description."

   Then the last two paragraphs are no longer required.  (The first
   is a redundant example of an intensive attribute.)  The two 
   paragraphs to be deleted are:

   "As another example of an intensive attribute that can have multiple
    entries, if a document or job uses multiple types of media, there SHALL
    be only one row in the jmAttributeTable for each media type, not one row
    for each document that uses that medium type.

    On the other hand, if a job contains two documents of the same name,
    there can be separate rows for the documentName attribute with the same
    name, since a document name is an extensive attribute.  The
    specification indicates that the values NEED NOT be unique for such
    'MULTI-ROW: attributes'"

2. Section 3.3.5 (page 24), the following change is suggested.  ("that 
   submitted the job" seems to obvious to include.)

    Change: "(1) requested by the client (or intervening server) in the job 
    submission protocol that submitted the job..."

    To: "(1) requested by the client (or intervening server) in the job 
    submission protocol..."

3. section 3.6.1.2 (page 27), the following is confusing:

    "Those textual conventions that are labeled "[same enum values as IPP]"
    have the same enum values as the indicated IPP Job attribute.  When IPP
    registers additional values, those values shall be simultaneously
    registered by IANA for use with the Job Monitoring MIB textual-
    convention, so that the enum values stay in lock step between the IPP
    protocol and the Job Monitoring MIB."

   Proposed new wording:

    "For those textual conventions that have the same enum values as the 
    indicated IPP Job attribute, additional values shall be simultaneously
    registered by IANA for use with both IPP and the Job Monitoring MIB."

4. In the description for JmJobStateTC (page 40), there is a state "other".

        "other(1),
            The job state is not one of the defined states."

   I thought we had covered all possible states with the 7 primary plus the 
   JmJobStateReasons.  Why do we need other?  Did we not accomplish what was
   claimed?

5. In the description for JmAttributeTypeTC (page 43) the paragraph:

       "In the following descriptions of each attribute, the tags:
        'INTEGER:' or 'OCTETS:'  specify whether the value SHALL be
        represented in the jmAttributeValueAsInteger or the
        jmAttributeValueAsOctets object, or both, respectively."

   This information seems to be adequately presented in the previous 
   paragraphs and I recommend that it be deleted.

6. Also in the description for JmAttributeTypeTC (page 43) the paragraph:

       "The standard attribute types defined so far are:"

   This sounds like the MIB document is not final, I suggest:

       "The standard attribute types defined at the time of completion of
        this document:"

7. In the description for serverAssignedJobName (22) (page 45), the text
   "...that the agent is providing access to with this MIB." is obvious
   from the context and should be deleted.

More to come...

	Ron Bergman
	Dataproducts Corp.