Harry Lewis - IBM Printing Systems
jmp-owner@pwg.org on 10/13/98 09:07:33 AM
Please respond to jmp-owner@pwg.org
To: hastings@cp10.es.xerox.com
cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com
Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
Tom,
Since there have been no comments from others regarding the changes to =
the
TCs, I assume no one else cares. I have this feeling that this will be=
another issue with the IETF, so I believe it is best if we beat them to=
the draw. So, unless others support my position, keep it as is.
Concerning the version number change, your reply indicates that new
attributes and enums cannot be added unless the version number is chang=
ed.
This is clearly not true. So what other than the editorial changes and=
the addition of the two attributes makes this version 1.2?
Ron
On Mon, 12 Oct 1998, Hastings, Tom N wrote:
>
>
> >-----Original Message-----
> >From: Ron Bergman [mailto:rbergma@dpc.com]
> >Sent: Thursday, October 08, 1998 13:46
> >To: Tom Hastings; Harry Lewis
> >Cc: jmp@pwg.org
> >Subject: Review of Job Monitoring MIB of October 2, 1998
> >
> >
> >Tom,
> >
> >Your proposed changes look very good!
> >
> >I did notice that there are four other TCs that reflect the
> >same situation
> >as with JmAttributeTypeTC. They are:
> >
> > JmFinishingTypeTC
> > JmMediumTypeTC
> > JmJobSubmissionTypeTC
> > JmJobStateTC
> >
> >In the case of the first two, the definitions could be added
> >as comments
> >with the enums. For the second two, the specs should also be
> >moved out of
> >the MIB and into the text
> >
> >I will submit a proposal for these changes unless the other JMP
> >participants feel strongly that a change here is not required.
>
> I don't think we should bother. It wasn't commented on by the IESG. =
Moving
> the explanations out of the TC makes them a lot harder to use. The
> information is spread to two places. For attributes, because there a=
re so
> many, it makes sense to move them out.
>
> I think that they really objected to having -- in the middle of a
> DESCRIPTION clause (which I removed in doing 1.2.
>
> >Also the bit-mapped TCs are structured very different than
> >what is in the
> >current Printer MIB and the HR MIB. I suggest everyone look
> >at this and
> >indicate if we should revise.
> >
> > JmJobServiceTypesTC
> > JmJobStateReasonsTC
> > JmJobStateReasons2TC
> > JmJobStateReasons3TC
> > JmJobStateReasons4TC
>
> Since the IESG folks didn't comment on them, I think they are fine ha=
ving
> the bit assignments and the description of each bit as part of the
> DESCRIPTION clause. Also I think it is a lot clearer to show the bit=
-ness
> as hex in the description, then as the decimal equivalent.
>
> >
> >I see that you also changed this to v1.2 ( was v1 ). The editorial
> >changes should not affect the revision status, nor should the
> >addition of
> >the 2 new enums. So I prefer that the MIB remain at v1.
>
> Yikes! There would be a terrible confusion problem if we use the sam=
e
> version number for two different versions of the MIB. The minor vers=
ion
> number changes shows that some attributes have been added and/ or
> clarifications.
>
> If we don't have a different version number, how can you tell which M=
IB you
> have? (Of course, if the TCs were a separate file, then the MIB part=
could
> have kept the same version number. But suppose there had been some
> clarification text added to even the MIB part, then you wind up incre=
menting
> the MIB module version number anyway.
>
> >
> >
> > Ron Bergman
> > Dataproducts Corp.
> >
> >
>
=