My main comment about attributes was saying that you have done a level shift
in the document. Most MIBS say - 'here is the set of attributes for object
set XXX'. FIN has said 'here are some of the attributes for finishers, plus
here is a way of adding other attributes that we havent thought about yet'.
You have defined a generic extensibiity mechanism - this is more properly
done in the core SNMP document set - not in an individual MIB.
I expected to read in the FIN MIB the definition of ALL attributes for
finishers - they are not there (So where are they?). Compare this to 1759.
> -----Original Message-----
> From: Harry Lewis [SMTP:harryl@us.ibm.com]
> Sent: Thursday, June 18, 1998 10:52 AM
> To: rbergma@dpc.com
> Cc: Paul Moore
> Subject: RE: FIN> On reading the FIN draft
>
> Ron - I got a bit behind... sorry I haven't jumped in... but your
> responses to
> Paul's concerns are excellent. Thanks. I too am glad that Paul has taken
> time
> to review our work.
>
> Paul has been a big advocate of SDP so he may be wishing we could hold up
> FIN
> until the PWG gets a more serious bead on SDP. We, of course, feel we have
> run
> the gamut and are wanting to close down and call the FIN MIB complete.
>
> I am also starting to see the great benefit a (modern) standard SDP would
> have
> so I share BOTH goals. I think we've had quite a bit of finisher expertise
> (especially Carlos from HP) helping define the FIN MIB and I'm comfortable
> that
> what we have is good. I sympathize with the discomfort someone feels when
> they
> first see the "attribute" based approach, but I can assure Paul, our Job
> MIB
> implementation is working flawlessly (well... we all like to exaggerate
> ;-) and
> developers had no problem with it. I guess Paul's point may be more of...
> "this
> ain't your grandfather's SNMP". Well, maybe not, but I don't think it is
> toxic
> or anything... If the comment is intended to help point out the benefit of
> focusing on a bona-fide SDP rather than "tricks with SNMP"... like I
> said...
> I'm beginning to convert.
>
> I don't think there is any reason to deter our efforts to complete the FIN
> MIB,
> however. Actually, the FIN MIB probably has a better chance of being
> widely
> adopted than does the Job MIB, at this point. I think the set of
> attributes we
> have should form the basis for a robust SDP Finisher section. SDP will
> want to
> consider all the attributes in IPP, Printer MIB and FIN MIB (I hope) as it
> develops.
>
> Harry Lewis - IBM Printing Systems
>
>
> ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/18/98
> 09:45 AM
> ---------------------------
>
>
> fin-owner@pwg.org on 06/18/98 09:40:18 AM
> Please respond to fin-owner@pwg.org
> To: paulmo@microsoft.com
> cc: fin@pwg.org
> Subject: RE: FIN> On reading the FIN draft
>
>
> Paul,
>
> More responses below.
>
>
> Ron Bergman
> Dataproducts Corp.
>
>
> On Tue, 16 Jun 1998, Paul Moore wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Ron Bergman [SMTP:rbergma@dpc.com]
> > > Sent: Tuesday, June 16, 1998 8:35 AM
> > > To: Paul Moore
> > > Cc: 'fin@pwg.org'
> > > Subject: Re: FIN> On reading the FIn draft
> > >
> > > Paul,
> > >
> > > Thank you for your inputs on our efforts to develop a Finisher MIB.
> It is
> > > nice to see some outside of the core developers of this standard
> actually
> > > look at the document.
> > >
> > > My responses are embedded in your original text below.
> > >
> > >
> > > Ron Bergman
> > > Dataproducts Corp.
> > >
> > >
> > > On Fri, 12 Jun 1998, Paul Moore wrote:
> > >
> > > > Several questions come to mind.
> > > >
> > > > 1. Is this intended as read-only?
> > > >
> > > > The intro suggests that it is for controlling as well. (1.1 Scope).
> I
> > > > dont see how this can work.
> > >
> > > As with most MIBs, it is primarily read-only. However, as in the
> Printer
> > > MIB, Finisher devices can be enabled or disabled. The MIB also allows
> > > some parameters that the agent may not be able to detect, such as
> > > capacities or media type, to be defined by an SNMP Manager. This is
> no
> > > more or no less than the control capability in the Printer MIB.
> > >
> > > >
> > > > 2. Doesnt the generic 'attributes' section merely punt the
> > > > standardization issue?
> > > >
> > > > SNMP already has methods for passing general attributes around (its
> > > > called OIDs and MIBS). We are now inventing another method. The
> whole
> > > > purpose of a MIB is to define the attribute set.
> > >
> > > The attributes method was developed during our work on the Job MIB as
> a
> > > means of providing a core set of mandatory objects and allow
> additional
> > > information to be provided for those exception cases. Since optional
> > > objects are considered *bad* in SNMP, this appeared to be a good
> > > compromise. The attributes method was review quite extensively by
> SNMP
> > > expert David Perkins with no negative comments. The Job MIB has also
> been
> > > reviewed by several other ADs and, again, no negative comments.
> > [Paul Moore] I am saying that you are defining an extension to
> > SNMP (a way of adding extra MIB entries without reving the MIB). This is
> > perfectly valid but should not be in a MIB, it should be in some SNMP v4
> or
> > SNMP extensions document. The purpose of a MIB is to define the set of
> > attributes associated with an entity - you have defined a way of
> defining
> > the set of attributes associated with an entity. Specifically I cannot
> read
> > the FIN MIB document and see the set of supported attributes (cf
> RFC1759). I
> > will have to find another document. This is a significant change.
>
> Attributes are in reality enums. I would say "special purpose" enums, but
> then all enums are "special purpose". SNMP is constantly using enums in
> new ways to present the desired information. Many SNMP aware individuals
> have examined the attributes as implemented in the Job MIB and no other
> negative comments have been voiced.
>
> I don't understand why you believe that a new version of SNMP would be
> required to allow attributes. In what way does the use of attributes
> break SNMP?
>
> Regarding your comment that you "..cannot read the FIN MIB document and
> see the set of supported attributes..", is this in reference to the
> Textual Conventions that are imported? If so these are found in the
> latest Printer MIB draft (update to RFC1759). Importing of TC's is common
> SNMP practice and, I agree, does make it difficult to read the document.
> You cannot do it without your entire SNMP library at hand.
>
> > > >
> > > > What this really shows is that MIBs are too chunky and cannot be
> > > > extended easily enough - so the group has ending up defining a way
> > > > of adding 'TBD'
> > >
> > > This is, to a degree, true. But if you look at the positive side, we
> have
> > > provided a useful enhancement to SNMP. We have significantly reduced
> the
> > > number of objects typically required to define a configuration.
> > >
> > > >
> > > > 3. Why have standard names for punching styles?
> > > >
> > > > Why not just explicitly state the hole sizes, shapes and placement?
> Are
> > > > these 'well-known' values - where is Latvian9punch and
> Morrocan21Hole?
> > > > :-)
> > >
> > > You can actually do either. We have tried to define the hole patterns
> for
> > > the common punch configurations. This means that in most cases the
> size,
> > > shapes and placements are defined using one enum. For "other"
> patterns,
> > > the attributes can be used to provide the definitions.
> > [Paul Moore] You did not answer the question. Why is it useful to
> > use punch style names? Who is the benificary? What is the intent? There
> > seems to be a LOT in the MIB (implict attributes, many tables, ..) just
> to
> > support this. I dont see the point. If its valuable why dont we have
> named
> > sets of other things (paper trays for example). Paper types are
> different,
> > they are 'well-known' to end users
> >
> Actually we have tried to define all finishing operations. Folding,
> stapling, binding, slitting, and wrapping all have a set of enums to
> define more detail regarding the possible configurations. It just so
> happens that punching is significantly more complex to define. We could
> have taken the simple approach and just said "punch-2-hole", but it was
> agreed that the additional information would be useful.
>
> > > >
> > > > 4. I like the way that it slides gracefully into the printer MIB
> model.
> > > > (section 3)
> > >
> > > Thank you for this comment. The group spent several meetings refining
> the
> > > model to achieve this result!
> > >
> > > >
> > > > 99. (personal peeve) The word 'insure' is used where you mean
> 'ensure'.
> > > >
> > >
> > > Glad you caught this! Little things like this seem to be hard to spot
> in
> > > a document. This will be corrected ASAP.
> > >
> >
>
>
>
>