..... 2699.1.1...... Job Mib
..... 2699.1.2 ..... Future Job Mib extensions
..... 2699.2.1 ..... Finisher Mib
..... 2699.2.2 ..... Finisher Mib extensions
..... 2699.3.1 ..... Hey, how about... Printer Mib
..... 2699.3.2 ..... Printer MIB extensions
..... 2699.3.2 ..... Printer MIB extensions
..... 2699.4.1 ..... IPP Operations (as suggested by someone, below)
..... 2699.4.2 ..... IPP Attributes
What about a space for registering things like type-2 enums etc.?
I don't feel real strongly about this proposal... I think just about an=
y
structure will have pro's and con's.
Harry Lewis - IBM Printing Systems
jmp-owner@pwg.org on 11/13/97 07:46:04 PM
Please respond to jmp-owner@pwg.org @ internet
To: don@lexmark.com @ internet
cc: JMP@pwg.org @ internet, pwg@pwg.org @ internet, jkm@underscore.com =
@
internet
Subject: Re: JMP> Job MIB - trials and tribulations
Don,
I have no strong objection to your proposal, other than it requires an
additional OID on top of the 15 or so already present. (So what
difference does one more number make ;-)
When I proposed the flat project oriented model in Boulder, I did not
envision using OIDs for anything other than MIBs. The experience with =
IPP
certainly hinted that OIDs, and more correctly ASN.1 encoding, are old
technology. (But as we know, old things have a way of coming back in
style.)
If the consenus is that OIDs have a good probably of being used for oth=
er
than MIBs I would support your proposal.
On the other hand the Job and Finisher MIBs may be the only consumer of=
this OID space.
Can anyone suggest any real requirements for "maybe IPP" and "something=
else"? Or is this not worth any further discussion, and just accept Do=
n's
proposed format?
Ron Bergman
Dataproducts Corp.
On Thu, 13 Nov 1997 don@lexmark.com wrote:
>
> JK Martin said:
>
> >> On a more technical note, I would suggest that we
> >> consider moving the Job MIB down one level in the
> >> OID space. I would prefer something like
> >>
> >> ..... 2699.1.1...... Job Mib
> >> ......2699.1.2...... Finisher MIB
> >>
> >> ...... 2699.2.1 ...... maybe IPP space?
> >> ...... 2699.3.1 ..... something else using OID space
> >>
> >> etc.
> >
> >What is your thinking here? I mean, what is the significance
> >of putting JMP/FIN under ...2699.1 versus having IPP under .3,
> >etc? Are you in some way suggesting a set of categories for
> >the top-level OID (ie, .2699.1, .2699.2, etc)?
> >
> >This approach sounds good to me; it's just that I'm trying to
> >figure out your plan here.
>
> My suggestion on the structure of the usage of our
> Enterprise number is to insure some kind of ordering
> and structure to our usage. I would prefer something
> like
>
> 2699
> |
> +-------+------...--+
> | | | |
> 1 2 3 n
> +---+ +---+ +---+ +----+
> | | | | | | | | |
> JMP-+ | | | | |
> | | | | |
> FIN --+ | | | |
> | | | |
> etc ----+ | | |
> | | |
> | | |
> attributes--+ | |
> | |
> operations ---+ |
> |
> etc ------------+
>
>
> This would allow us to put all the MIB work at one point
> (2699.1) and maybe all the IPP at another (2699.2) (maybe
> the need for IPP is non-existant but I use it as an example)
> and other "types" of objects at other places, properly grouped.
> I think this is a better structure than maybe:
>
>
> 2699
> |
> +-------+------...--+
> | | | |
> 1 2 3 n
> + +---+ + +----+
> | | | | |
> JMP---+ | | | |
> | | | |
> attributes -+ | | |
> | | |
> operations -----+ | |
> | |
> FIN --------------+ |
> |
> etc -------------------+
>
>
>
> Maybe its my obsessive/compulsive need for order and structure
> but that's my intent anyway.
>
> Does that explain it?
>
> Don
>
> **********************************************
> * Don Wright don@lexmark.com *
> * Manager, Strategic Alliances and Standards *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 606-232-4808 (phone) 606-232-6740 (fax) *
> **********************************************
>
>
>
=