By the way, I don't see any use of OIDs for IPP at the moment. We don't
have an OID attribute syntax. We are using keywords for the same purpose.
There are the following possible examples for the PWG assigning OIDs for
use with:
a. ISO DPA attributes or values. Maybe even assiging attribute OIDs for use
with the DPA Printer object that are the equivalent of Printer MIB objects.
b. OIDs for use with other MIBs as object values, such as device types in
HR MIB(?).
On the other hand, the value immediately under the 2699 could be for
whatever type.
So with either scheme, we are not constrained with inventing new types
of uses for OIDs as far as I can see.
The advantage of the scheme agreed in Boulder, is that we don't need
to have any more discussion about what other uses we might put OIDs to.
We can just use them for whatever purpose when the need arises and just
assign the next available arc which would be 2 after the Job Monitoring MIB
uses 1.
The advantage of Don's scheme is that like things are grouped together.
But would it hurt if ...2699.1.xx was Job MIB, ...2699.2.xx was for some
non-MIB thing, and xxx2699.3.xx was for another PWG MIB? Even SNMP
MIB walks would just skip over any holes that had been used for non-MIB
things.
So I'm in favor of the original proposal as being shorter, simpler,
and easier to agree to.
Tom
At 09:59 11/14/1997 PST, don@lexmark.com wrote:
>
>Harry Lewis said:
>
>>I will just reiterate my proposal which bases the hierarchy on PWG
>projects...
>>given that these tend to "foster" separate standards...
>>
>>..... 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 any
>>structure will have pro's and con's.
>
>In Harry's format, I would really prefer the following which tends to group
>like things together, IMHO. If we add some other MIB later on, it would
>fall under the MIB sub-tree as opposed to after IPP and the Internet
>Finishing Protocol or whatever else happens before that new MIB.
>......2699.1........ MIBS
>..... 2699.1.1.1...... Job Mib
>..... 2699.1.1.2 ..... Future Job Mib extensions
>..... 2699.1.2.1 ..... Finisher Mib
>..... 2699.1.2.2 ..... Finisher Mib extensions
>..... 2699.1.3.1 ..... Hey, how about... Printer Mib
>..... 2699.1.3.2 ..... Printer MIB extensions
>..... 2699.1.3.2 ..... Printer MIB extensions
>......2699.2....... IPP
>..... 2699.2.1 ..... IPP Operations (as suggested by someone, below)
>..... 2699.2.2 ..... IPP Attributes
>......2699.3....... Something else
>
>To be consistant, we might even want to do something like:
>
>......2699.1........ MIBS
>..... 2699.1.1.1...... Job Mib
>..... 2699.1.1.2 ..... Future Job Mib extensions
>..... 2699.1.2.1 ..... Finisher Mib
>..... 2699.1.2.2 ..... Finisher Mib extensions
>..... 2699.1.3.1 ..... Hey, how about... Printer Mib
>..... 2699.1.3.2 ..... Printer MIB extensions
>..... 2699.1.3.2 ..... Printer MIB extensions
>......2699.2........ PROTOCOLS
>......2699.2.1...... IPP
>..... 2699.2.1.1 ..... IPP Operations (as suggested by someone, below)
>..... 2699.2.1.2 ..... IPP Attributes
>......2699.2.2....... Some Other Protocol
>......2699.3........ SOMETHING_ELSE_BESIDES_MIBS_AND_PROTOCOLS
>
>but I won't get hung up on that. I think insuring all the MIBs are in the
>same
>sub-tree is probably sufficient.
>
>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) *
>**********************************************
>
>
>
>
>