Subject: JMP> Open Editorial Changes From Rev. 0.83

From: Ron Bergman <[email-masked]>
Date: Tue, 12 Aug 1997 17:46:17 -0700 (PDT)

Tom,

The following editorial corrections from revision 0.83 were not
incorporated into version 0.84.  Please comment if there is a
reason that these should not be incorporated.  I do not believe 
that any of the corrections change the intent of the document.

Problems from 0.83:

1. Section 2. Terminology and Job Model (page 14) states:

   "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."

   This text should be a part of the mapping document.  This additional
   example does not provide any additional help in understanding the
   subject paragraph.

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):

   "...interfaces to humans in human perceptible means, such as produces
    marks on paper, scans marks on paper to produce an electronic
    representations, or writes CD_ROMS..."

   The second two examples don't appear to be human perceptible.  I am
   not sure I understand the reason for including other than the first
   example.

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."

    Since this is a read only object do we need to define how it is
    configured?  We only need to describe the function.  Suggest:

        "Configuration of this parameter is implementation dependent."

5. For jmGeneralAttributePersistence (page #76) the above comment
   also applies.

6. In jmJobStateReasons1 (page #81), I find the following statement
   hard to disagree with, but why do we need to state this?

       "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."

    All this really states is that the value of an object must be valid.
    We do not have a similar statement for any other object.

7. Also in jmJobStateReasons1 (page #81), the next sentence:

        "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."

    I suggest it be reworded 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."

	Ron Bergman
	Dataproducts Corp.

---

From: JK Martin <[email-masked]>
Date: Thu, 21 Aug 1997 14:21:39 -0400 (EDT)

After very carefully reading Ron Bergman's message, I find myself
agreeing with Ron pretty much up and down the line.

Quick comments:

  - I like Ron's proposed wording in every single case; I find
    the Job MIB tends to read more like a legal contract than a
    useful specification.  Sorry, but the comments about "active voice"
    are just not all that useful, given that Ron's sentence is far
    cleaner and completely unambiguous.  (I mean, who cares that you
    call out the agent versus something else??  If a value is supposed
    to be 0, then IT IS ZERO, regardless of who sets it or receives it.)

  - Ron's insistence on moving certain examples to the "mapping section"
    of the document is also right on track.  I find the PCL "example" only
    marginally useful and not worth the many words used to describe it.

    If words exist in the main body of the spec, then the reader will be
    compelled to carefully read and evaluate them; if those words exist
    only to "clarify" a rather nitty point, then the reader grows quite
    weary and distracted.  This is Not Good.  Move all such stuff to the
    mapping section.

  - I found the interchange on "human perceptibility" to be totally bizarre.
    (At first I thought it was some kind of joke.)  Get rid of it!

    This is the Job MIB for heaven's sake, and not some treatise on a cure
    for cancer, or a discourse on human strife and suffering.  Keep it SIMPLE.

  - A FAQ is always, ALWAYS an excellent addition to any specification,
    and we should try to move things to the FAQ whenever possible, IMHO.
    I like Ron's suggestions in this area, and strongly suggest adopting
    his suggestions.

Ron had asked for opinions.  ;-)

I must say, however, to the JMP group at large:

I am totally appalled by this situation.  The MIB Editor is supposed to
maintain the document according to group consensus, and such consensus
is managed by the project chairperson, based on open dialog on the JMP
mailing list.  I thought everyone was aware of these "rules" of conduct
within the PWG (as "borrowed" from the essential rules of IETF working
groups).

The fact that the JMP MIB Editor made a number of unilateral decisions
on the document--and then posted the document without first responding
to Ron's editorial proposals--is TOTALLY unacceptable.  The fact that
Ron Bergman is the JMP Chairperson makes the situation even more
unacceptable, especially since Ron has done such a fine job in
eagle-eyeing the document all along.

I trust this kind of situation does not happen in the future, because
if it does, we'd be wise to appoint a new MIB Editor.  Yes, I realize
these are harsh words, but this is a completely UNACCEPTABLE situation
that should never have happened in the first place.

	...jay