Ok. I'll make the edits.
Tom
>-----Original Message-----
>From: Harry Lewis [mailto:harryl at us.ibm.com]
>Sent: Tuesday, October 13, 1998 14:47
>To: rbergma at dpc.com>Cc: jmp at pwg.org; hastings at cp10.es.xerox.com>Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
>>>I agree with Ron. My main concern is that we not disturb the
>actual operation
>of the MIB... this appears to be strictly a documentation
>issue. Since the IETF
>mentioned one such example, if we have found 4 similar I think
>it best to
>respond.
>>Harry Lewis - IBM Printing Systems
>>>>rbergma at dpc.com on 10/13/98 03:02:46 PM
>Please respond to rbergma at dpc.com>To: Harry Lewis/Boulder/IBM at ibmus>cc: hastings at cp10.es.xerox.com, jmp at pwg.org>Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
>>>Harry,
>>What I see in the MIB is four other TCs that, like JmAttributeTypeTC,
>contain very long, detailed specifications of each enumeration
>in the TC
>definition. The specification details should be removed from the MIB
>section. I don't want this to come back from the ADs as aonther fix.
>If it easy to fix, and I don't see why not, I prefer to do it
>now and be
>done with it.
>>Does this make the MIB harder to use? Maybe, maybe not. With all the
>cross references we have, I don'e see how it could be that much more
>difficult.
>>Any opinions?
>> Ron Bergman
> Dataproducts Corp.
>>>On Tue, 13 Oct 1998, Harry Lewis wrote:
>>> You were just recommending moving TC's to a consolidated place in the
>> document... right? I didn't see any problem with doing that.
>>>> Harry Lewis - IBM Printing Systems
>>>>>>>>jmp-owner at pwg.org on 10/13/98 09:07:33 AM
>> Please respond to jmp-owner at pwg.org>> To: hastings at cp10.es.xerox.com>> cc: jmp at pwg.org, Harry Lewis/Boulder/IBM at ibmus, rbergma at 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 changed.
>> 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 at dpc.com]
>> > >Sent: Thursday, October 08, 1998 13:46
>> > >To: Tom Hastings; Harry Lewis
>> > >Cc: jmp at 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 are 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 having
>> > 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 same
>> > version number for two different versions of the MIB. The
>minor version
>> > 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 MIB 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 incrementing
>> > the MIB module version number anyway.
>> >
>> > >
>> > >
>> > > Ron Bergman
>> > > Dataproducts Corp.
>> > >
>> > >
>> >
>>>>>>>>>>>>>>>