Subject: RE: FIN> On reading the FIN draft

From: Paul Moore <[email-masked]>
Date: Fri, 19 Jun 1998 09:41:53 -0700

Let me explain why I raised the issue and they maybe you will understand
what I am talking about.

I am looking at attribute sets for printers. Rather than sit and think for
several weeks, the obvious thing to do is to look at the existing work done
by large groups of intelligent people who know this stuff inside out. So I
looked in TIPSI, here is a big set of attributes with their values and
meaning. Next I looked in 1759, aha - here are really detailed attributes
for paper trays, Oh and marking systems, and even cover panels - great. Next
I looked in the finisher MIB, great here is a REALLY detailed analysis of
punching and here is a detailed analysis for.. - but no - there are no more
detailed anaylses, only a scheme for recording them. So I have hit a
roadblock - where do I go to look for the attributes for, say , a perfect
binder. The FIN MIB requires that there be another document somewhere else -
the 'Perfect Binder Attribute Set for FIN MIB'

I have a practical problem - not a architectural one. 

What you should have done is to do FIN MIB part1 (staple, punch and general
status), then done part2 (Binders, sorters and inserters) then
part3(shredders, igniters and bleachers). Or even done a separate MIB for
each FIN sub-unit.

I think the criticism that we should have said this earlier is not
reasonable. Nobody can read all drafts at all stages of revision. 

> -----Original Message-----
> From:	Harry Lewis [SMTP:[email-masked]]
> Sent:	Friday, June 19, 1998 8:27 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; Paul Moore;
> [email-masked]; [email-masked]
> Subject:	Re: FIN> On reading the FIN draft
> 
> Criticism can be healthy... and your points of view are valid, although I
> must
> say I wish they had been more timely. There ARE other points of view which
> were
> obviously factored into the design.
> 
> >However, it is inappropriate behavior on the part of a standards body
> >to choose such a course, to go charging off into wild new territory,
> >without first at least clearly recognizing the problems that it entails
> >and clearly considering the alternatives. I don't think I ever saw that
> >done here.
> 
> I'll spare the counter-criticism... rather, I'd like to seek a show of
> hands
> how many people are aware of customers using generic web browsers to
> effectively manage print, printers or printer extensions (finishers).
> Please
> take a look (ESPECIALLY with the Job MIB) at the types of objects we are
> managing!
> 
> >I lacked the time and energy to raise the issue myself here.
> 
> Welcome to the club. Precisely why rehashing seems like a tiresome
> setback.
> Let's see... haven't we gone through this with IPP recently?
> 
> >Of course it is rather late to be raising this issue in connection with
> the
> >FIN or the JOB MIBs.  This issue was timely for those a year and two ago.
> 
> Thank You!
> 
> >But the point is still well taken.
> 
> OK. So what are you suggesting? What is the real issue NOW? I would like
> to see
> this discussion move to a more productive stage as opposed to a
> critical/defensive one. I'm hearing "We're gone too far with "SNMP"... So
> what's the antidote? Do we back up to a flat FIN MIB with sets of
> mandatory and
> optional attributes (this was ugly when we tried it!). Are we saying that
> some
> of our problems are just to complex to address with SNMP and the solution
> space
> should move to the SDP arena?  Do we just need a FIN MIB FAQ to help with
> the
> understanding? I'm open to suggestions and eager to find a direction with
> more
> consensus.
> 
> Please remember that there are significant numbers of PWG members who
> think the
> FIN MIB is fine... and worked quite hard to get it there. Please don't
> underestimate the effort and dedication even though the working group
> received
> less fame than (say) IPP.  Also note that any solution... SDP or
> whatever... is
> VERY likely to result in SIMILAR complexity... after all the problems will
> be
> the same... we just won't be able to look back and say... "well, THAT's
> not
> SNMP!"
> 
> Harry Lewis - IBM Printing Systems
> 
> 
> 
> [email-masked] on 06/18/98 11:14:00 PM
> Please respond to [email-masked]
> To: [email-masked]
> cc: [email-masked], [email-masked],
> [email-masked], Harry Lewis/Boulder/IBM@ibmus, [email-masked],
> [email-masked]
> Subject: Re: FIN> On reading the FIN draft
> 
> 
> I would like to echo Jay's statement, that Paul Moore has made an
> excellent
> point, and respond to Ron's question, "In what way does the use of
> attributes break SNMP?"
> 
> The complaint is not that "the use of attributes breaks SNMP."  The
> complaint is that the use of attributes like this is really not SNMP.  As
> Paul M. says, SNMP has a clear, central model for representing
> objects/attributes and values thereof, and this attributes table approach
> does not follow the SNMP model.  Instead, it uses SNMP as a mere framework
> or platform on top of which to build a significantly different attributes
> and values representational model.  And it does this without benefit of
> appropriate documentation or standards or infrastructure or technical
> support or tooling or diagnostics or any of the zillion things that are
> normally expected when a new standard data representational model is
> established.  (Does anybody have a MIB browser that will do a useful job
> of
> browsing attributes tables?  I'd be very surprised - albeit pleasantly
> so.)
> 
> It is conceivable that this attributes-table poor solution (poor because
> unsupported, as above) is the best available under the circumstances, that
> all the other available choices are worse.  However, it is inappropriate
> behavior on the part of a standards body to choose such a course, to go
> charging off into wild new territory, without first at least clearly
> recognizing the problems that it entails and clearly considering the
> alternatives.  I don't think I ever saw that done here.  I lacked the time
> and energy to raise the issue myself here.  Paul M. is now raising it.
> 
> Of course it is rather late to be raising this issue in connection with
> the
> FIN or the JOB MIBs.  This issue was timely for those a year and two ago.
> But the point is still well taken.
> 
> /Paul Gloger
> 
> 
> 
> 
> 
>

---

From: Ron Bergman <[email-masked]>
Date: Fri, 19 Jun 1998 17:36:46 -0700 (Pacific Daylight Time)

Paul,

Now I understand the specific issue you are having with the Finisher MIB.
(So with the religious issues aside we can discuss the problems that we
can actually solve;-)

We have tried to all the possible parameters (i.e. attributes) for each
finisher process.  As it turned out, the punch operation was the most
complex and thus the big (huge might be a better description) set of
attributes.  For the other operations we tried to also include all the
possible attributes.

In your example of binding, there are 8 enums in FinBindingTypeTC that
can be used to define the method of binding.  They are Tape, Plastic,
Velo, Perfect, Spiral, Adhesive, Comb, and Padding.  Other than the
position of the binding on the document, which should be defined in the
attribute table, there is little else that can be said about binding.  
(I forgot about color, which is specified in finSupplyColorantValue.)
Indeed there are other parameters that could be of interest in this case,
such as the width of the bind on the cover, but these are fixed for the
process and usually independent of the finisher device.  What else do you
need to know about binding?

If you do have time to review the document and can point to specifics or
even an area where additional information can be provided, we will bw more
than happy to resolve the issue.

BTW the latest Finisher MIB Document is dated June 11, 1998 and can be
found on the PWG FTP site under FIN/MIBS or FIN/SPECS (I forget which).

Hope this information helps.

	Ron Bergman
	Dataproducts Corp.