From fin-archive Tue Jun 9 22:23:41 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA14005 for fin-outgoing; Tue, 9 Jun 1998 22:20:04 -0400 (EDT) Date: Tue, 9 Jun 1998 19:09:17 -0700 (Pacific Daylight Time) From: Ron Bergman To: fin@pwg.org Subject: FIN> MIBS to Compile Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO I have loaded two Finisher MIB files on the PWG server, 1. ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980609.mib 2. ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980609-modified.mib and also the new Printer MIB. 3. ftp://ftp.pwg.org/pub/pwg/fin/mibs/printer.mib The first Finisher MIB is per the current updated draft. The second contains two changes I had to make to compile with "NetPlus". The Printer MIB is required since there are references to the Textual Conventions in the Finisher MIB. Change 1: I had to provide an OBJECT IDENTIFIER definition for mib-2. Change 2: I had to change "printmib" to "finisherMIB" in the definitions for the four Finisher MIB groups. (e.g. finDevice OBJECT IDENTIFIER ::= { printmib 30 }) The MIB would compile without this change but crashed my PC when I tried to view. We need to try to compile the MIB with other available compiliers. If you have access to any other compilier please try and send the results to the DL. I am almost ready to send the latest draft to the server. Just one more change is required! It should be available by the end of the week. Ron Bergman Dataproducts Corp. From fin-archive Thu Jun 11 11:29:07 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08505 for fin-outgoing; Thu, 11 Jun 1998 11:27:28 -0400 (EDT) Date: Thu, 11 Jun 1998 08:16:05 -0700 (Pacific Daylight Time) From: Ron Bergman To: fin@pwg.org Subject: FIN> New Finisher MIB Document Available Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO I have placed an updated Finisher MIB document (the complete document, not just the MIB) on the PWG server at: ftp://ftp.pwg.org/pub/pwg/fin/mibs/FIN-MIB-980611.TXT ...DOC The .DOC version can be used to see the changes from the last version of the document. (You'll have to enable "show revisions" in WORD.) This draft includes all the changes discussed in Virginia plus the editorial changes required to make the MIB compile. The MIB portion of the document is identical to the MIB posted earlier this week. I have not submitted this as an Internet-Draft at this time. I will not submit until the week of June 22 in case any additional changes are required as the result of problems encountered with other compiliers. This should give everyone adequate time to review prior to the next meeting. Ron Bergman Dataproducts Corp. From fin-archive Fri Jun 12 17:34:24 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17850 for fin-outgoing; Fri, 12 Jun 1998 17:34:10 -0400 (EDT) Message-ID: From: Paul Moore To: "'fin@pwg.org'" Subject: FIN> On reading the FIn draft Date: Fri, 12 Jun 1998 14:33:54 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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. 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. 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' 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? :-) 4. I like the way that it slides gracefully into the printer MIB model. (section 3) 99. (personal peeve) The word 'insure' is used where you mean 'ensure'. From fin-archive Tue Jun 16 11:50:32 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11727 for fin-outgoing; Tue, 16 Jun 1998 11:46:55 -0400 (EDT) Date: Tue, 16 Jun 1998 08:35:25 -0700 (Pacific Daylight Time) From: Ron Bergman To: Paul Moore cc: "'fin@pwg.org'" Subject: Re: FIN> On reading the FIn draft In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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. > > 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. > > 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. From fin-archive Tue Jun 16 12:58:41 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13756 for fin-outgoing; Tue, 16 Jun 1998 12:46:09 -0400 (EDT) Message-ID: From: Paul Moore To: "'Ron Bergman'" Cc: "'fin@pwg.org'" Subject: RE: FIN> On reading the FIn draft Date: Tue, 16 Jun 1998 09:45:53 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: fin-owner@pwg.org Precedence: bulk Status: RO > -----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. > > > > 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 > > > > 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. > From fin-archive Thu Jun 18 11:38:36 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12828 for fin-outgoing; Thu, 18 Jun 1998 11:34:38 -0400 (EDT) Date: Thu, 18 Jun 1998 08:22:41 -0700 (Pacific Daylight Time) From: Ron Bergman To: Paul Moore cc: "'fin@pwg.org'" Subject: RE: FIN> On reading the FIN draft In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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. > > > From fin-archive Thu Jun 18 14:46:43 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13331 for fin-outgoing; Thu, 18 Jun 1998 14:45:40 -0400 (EDT) Message-ID: From: Paul Moore To: "'Harry Lewis'" , rbergma@dpc.com Cc: "'fin@pwg.org'" Subject: RE: FIN> On reading the FIN draft Date: Thu, 18 Jun 1998 11:45:18 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: fin-owner@pwg.org Precedence: bulk Status: RO I DO have the concern that we need to resolve the issues arounf SNMP vs IPP. 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. > > > > > > > > > From fin-archive Thu Jun 18 15:26:43 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13504 for fin-outgoing; Thu, 18 Jun 1998 15:25:52 -0400 (EDT) From: Harry Lewis To: Cc: , , Subject: RE: FIN> On reading the FIN draft Message-ID: <5030100021974395000002L052*@MHS> Date: Thu, 18 Jun 1998 15:23:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: fin-owner@pwg.org Precedence: bulk Status: RO Paul, don't forget that the IETF showed no interest in the Job MIB, thi= s allowed us to develop technology more well suited to our industry. We t= ook advantage of this position, but maintained close contact and review wit= h SNMP standards experts. The FIN MIB continues this approach even though it a= ctually augments RFC1759. Harry Lewis - IBM Printing Systems paulmo@microsoft.com on 06/18/98 12:51:11 PM Please respond to paulmo@microsoft.com To: rbergma@dpc.com, Harry Lewis/Boulder/IBM@ibmus cc: fin@pwg.org Subject: RE: FIN> On reading the FIN draft I DO have the concern that we need to resolve the issues arounf SNMP vs= IPP. 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 obj= ect 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 y= et'. You have defined a generic extensibiity mechanism - this is more proper= ly 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 17= 59. > -----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 ta= ken > time > to review our work. > > Paul has been a big advocate of SDP so he may be wishing we could hol= d 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= From fin-archive Thu Jun 18 15:36:43 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13637 for fin-outgoing; Thu, 18 Jun 1998 15:34:54 -0400 (EDT) Message-ID: <35896B8C.BD50321B@underscore.com> Date: Thu, 18 Jun 1998 15:33:32 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: paulmo@microsoft.com, fin@pwg.org Subject: Re: FIN> On reading the FIN draft References: <5030100021974395000002L052*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: fin-owner@pwg.org Precedence: bulk Status: RO Notwithstanding, Paul has made an excellent point, one that should be addressed without concern for the Job MIB's position in the IETF food chain. I tend to agree with Paul. I have similar concerns regarding the PWG's attempt to define standard ways of subscribing to Traps--this is a truly generic requirement for a very, very large audience, and not just the PWG's. If the PWG wants a "standard" mechanism that is genuinely usable by a large audience, then we should play the IETF game and get a new WG formed that draws from that audience. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Paul, don't forget that the IETF showed no interest in the Job MIB, this > allowed us to develop technology more well suited to our industry. We took > advantage of this position, but maintained close contact and review with SNMP > standards experts. The FIN MIB continues this approach even though it actually > augments RFC1759. > > Harry Lewis - IBM Printing Systems > > paulmo@microsoft.com on 06/18/98 12:51:11 PM > Please respond to paulmo@microsoft.com > To: rbergma@dpc.com, Harry Lewis/Boulder/IBM@ibmus > cc: fin@pwg.org > Subject: RE: FIN> On reading the FIN draft > > I DO have the concern that we need to resolve the issues arounf SNMP vs IPP. > > 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 From fin-archive Thu Jun 18 16:06:43 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13871 for fin-outgoing; Thu, 18 Jun 1998 16:05:56 -0400 (EDT) From: Harry Lewis To: Cc: , , Subject: Re: FIN> On reading the FIN draft Message-ID: <5030100021976676000002L062*@MHS> Date: Thu, 18 Jun 1998 16:03:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: fin-owner@pwg.org Precedence: bulk Status: RO With regard to trap registration... I agree. I think, if you've been fo= llowing the Notifications discussions in the PWG (which I'm sure YOU have ;-), = you'll find proposals to define PWG specific registration schemes "rejected" o= n the basis that SNMPv3 supplies most of what we need. As for "things we did = with the Job MIB"... remember, it was the IETF who turned their backs on us... t= his is strictly a PWG standard. Harry Lewis - IBM Printing Systems jkm@underscore.com on 06/18/98 01:39:09 PM Please respond to jkm@underscore.com To: Harry Lewis/Boulder/IBM@ibmus cc: fin@pwg.org, paulmo@microsoft.com Subject: Re: FIN> On reading the FIN draft Notwithstanding, Paul has made an excellent point, one that should be addressed without concern for the Job MIB's position in the IETF food chain. I tend to agree with Paul. I have similar concerns regarding the PWG's attempt to define standard ways of subscribing to Traps--this is a truly generic requirement for a very, very large audience, and not just the PWG's. If the PWG wants a "standard" mechanism that is genuinely usable by a large audience, then we should play the IETF game and get a new WG formed that draws from that audience. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Paul, don't forget that the IETF showed no interest in the Job MIB, t= his > allowed us to develop technology more well suited to our industry. We= took > advantage of this position, but maintained close contact and review w= ith SNMP > standards experts. The FIN MIB continues this approach even though it= actually > augments RFC1759. > > Harry Lewis - IBM Printing Systems > > paulmo@microsoft.com on 06/18/98 12:51:11 PM > Please respond to paulmo@microsoft.com > To: rbergma@dpc.com, Harry Lewis/Boulder/IBM@ibmus > cc: fin@pwg.org > Subject: RE: FIN> On reading the FIN draft > > I DO have the concern that we need to resolve the issues arounf SNMP = vs IPP. > > My main comment about attributes was saying that you have done a leve= l shift > in the document. Most MIBS say - 'here is the set of attributes for o= bject > 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 prop= erly > 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 fo= r > 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 h= old 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 comple= te = From fin-archive Thu Jun 18 16:41:43 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14091 for fin-outgoing; Thu, 18 Jun 1998 16:37:36 -0400 (EDT) Message-ID: <35897A18.9DAD1390@underscore.com> Date: Thu, 18 Jun 1998 16:35:36 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis , fin@pwg.org, sense@pwg.org Subject: Re: FIN> On reading the FIN draft References: <5030100021976676000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: fin-owner@pwg.org Precedence: bulk Status: RO Harry, > With regard to trap registration... I agree. I think, if you've been following > the Notifications discussions in the PWG (which I'm sure YOU have ;-), you'll > find proposals to define PWG specific registration schemes "rejected" on the > basis that SNMPv3 supplies most of what we need. As for "things we did with the > Job MIB"... remember, it was the IETF who turned their backs on us... this is > strictly a PWG standard. With all due respect, the fact that the Job MIB is not under the domain of the IETF has nothing to do with the concept of developing standard techniques in an open arena. I personally struggled with this concept while developing the SENSE technology. I knew all along that a system of inexpensive, light-weight, scalable event notification was of emminent utility around the world, across almost every type of distributed application. Hence, I was (and remain) quite shy about having the PWG declare its own notification system without regard for the needs of others. This is but one reason I put the brakes on the SENSE project--to wait and see if other proposals would emerge in a reasonable time frame. (I am now monitoring the WebDAV's ENP effort quite closely.) Just because the IETF declined to embrace the Job MIB shouldn't mean we have license to institute any kind of related technology we find interesting or useful. Give unto Caesar what is Caesar's, and all that rot... ;-) Please do understand, though, that I wholeheartedly encourage members of the PWG to band together and form a new IETF WG to address any IETF-related technology opportunity as a separate group. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From fin-archive Thu Jun 18 16:51:44 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14398 for fin-outgoing; Thu, 18 Jun 1998 16:50:51 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: FIN> On reading the FIN draft Message-ID: <5030100021979126000002L062*@MHS> Date: Thu, 18 Jun 1998 16:48:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: fin-owner@pwg.org Precedence: bulk Status: RO Jay - I'm not quite sure what we're talking about here. Generally, I ag= ree wholeheartedly with what you are saying. For Notifications, it is clear= that the PWG has shown a desire to investigate existing or emerging standard= s as the basis for a solution. Originally, Paul Moore had commented on the robus= t use of attributes in the FIN MIB... a scheme we adopted in development of the = JOB MIB to reduce the number of OIDs and avoid an approach which had proven les= s than useful with the Printer MIB (Mandatory/Optional). No-one core to the Jo= b MIB team and no-one having prototyped and/or implemented the Job MIB seems = to have any issues. Admittedly, someone reviewing this for the first time (as P= aul was in the FIN MIB) may wonder. I was only trying to help Paul at least und= erstand the CONTEXT... even if he decides to persist in his disagreement with t= he method. Harry Lewis - IBM Printing Systems jkm@underscore.com on 06/18/98 02:42:15 PM Please respond to jkm@underscore.com To: sense@pwg.org, fin@pwg.org, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: FIN> On reading the FIN draft Harry, > With regard to trap registration... I agree. I think, if you've been = following > the Notifications discussions in the PWG (which I'm sure YOU have ;-)= , you'll > find proposals to define PWG specific registration schemes "rejected"= on the > basis that SNMPv3 supplies most of what we need. As for "things we di= d with the > Job MIB"... remember, it was the IETF who turned their backs on us...= this is > strictly a PWG standard. With all due respect, the fact that the Job MIB is not under the domain of the IETF has nothing to do with the concept of developing standard techniques in an open arena. I personally struggled with this concept while developing the SENSE technology. I knew all along that a system of inexpensive, light-weight, scalable event notification was of emminent utility around the world, across almost every type of distributed application. Hence, I was (and remain) quite shy about having the PWG declare its own notification system without regard for the needs of others. This is but one reason I put the brakes on the SENSE project--to wait and see if other proposals would emerge in a reasonable time frame. (I am now monitoring the WebDAV's ENP effort quite closely.) Just because the IETF declined to embrace the Job MIB shouldn't mean we have license to institute any kind of related technology we find interesting or useful. Give unto Caesar what is Caesar's, and all that rot... ;-) Please do understand, though, that I wholeheartedly encourage members of the PWG to band together and form a new IETF WG to address any IETF-related technology opportunity as a separate group. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- = From fin-archive Fri Jun 19 01:11:49 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA16272 for fin-outgoing; Fri, 19 Jun 1998 01:08:26 -0400 (EDT) Message-Id: <3.0.1.16.19980618220517.3dbf8f98@mail2> X-Sender: pgloger@mail2 X-Mailer: Windows Eudora Pro Version 3.0.1 (16) Date: Thu, 18 Jun 1998 22:05:17 PDT To: fin@pwg.org From: Paul Gloger Subject: Re: FIN> On reading the FIN draft Cc: Jay Martin , Ron Bergman , Harry Lewis , Paul Moore , Tom Hastings , Paul_Gloger@cp10.es.xerox.com In-Reply-To: <35896B8C.BD50321B@underscore.com> References: <5030100021974395000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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 fin-archive Fri Jun 19 11:31:57 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA18304 for fin-outgoing; Fri, 19 Jun 1998 11:28:48 -0400 (EDT) From: Harry Lewis To: Cc: , , , , Subject: Re: FIN> On reading the FIN draft Message-ID: <5030100022026734000002L042*@MHS> Date: Fri, 19 Jun 1998 11:27:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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 wh= ich 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 entail= s >and clearly considering the alternatives. I don't think I ever saw tha= t >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). P= lease take a look (ESPECIALLY with the Job MIB) at the types of objects we ar= e managing! >I lacked the time and energy to raise the issue myself here. Welcome to the club. Precisely why rehashing seems like a tiresome setb= ack. 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 wit= h the >FIN or the JOB MIBs. This issue was timely for those a year and two a= go. Thank You! >But the point is still well taken. OK. So what are you suggesting? What is the real issue NOW? I would lik= e 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 manda= tory and optional attributes (this was ugly when we tried it!). Are we saying th= at some of our problems are just to complex to address with SNMP and the soluti= on space should move to the SDP arena? Do we just need a FIN MIB FAQ to help wi= th the understanding? I'm open to suggestions and eager to find a direction wi= th more consensus. Please remember that there are significant numbers of PWG members who t= hink 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 r= eceived less fame than (say) IPP. Also note that any solution... SDP or whatev= er... is VERY likely to result in SIMILAR complexity... after all the problems w= ill be the same... we just won't be able to look back and say... "well, THAT's= not SNMP!" Harry Lewis - IBM Printing Systems fin-owner@pwg.org on 06/18/98 11:14:00 PM Please respond to fin-owner@pwg.org To: fin@pwg.org cc: Paul_Gloger@cp10.es.xerox.com, hastings@cp10.es.xerox.com, paulmo@microsoft.com, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com, jkm@underscore.com Subject: Re: FIN> On reading the FIN draft I would like to echo Jay's statement, that Paul Moore has made an excel= lent 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 approa= ch does not follow the SNMP model. Instead, it uses SNMP as a mere framew= ork or platform on top of which to build a significantly different attribut= es 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 jo= b of browsing attributes tables? I'd be very surprised - albeit pleasantly = so.) It is conceivable that this attributes-table poor solution (poor becaus= e unsupported, as above) is the best available under the circumstances, t= hat all the other available choices are worse. However, it is inappropriat= e 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 t= ime 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 ag= o. But the point is still well taken. /Paul Gloger = From fin-archive Fri Jun 19 12:41:57 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18653 for fin-outgoing; Fri, 19 Jun 1998 12:38:13 -0400 (EDT) Message-ID: <358A93C6.2513B1FF@underscore.com> Date: Fri, 19 Jun 1998 12:37:26 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: fin@pwg.org, Paul_Gloger@cp10.es.xerox.com Subject: Re: FIN> On reading the FIN draft References: <5030100022026734000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: fin-owner@pwg.org Precedence: bulk Status: RO Harry, If nothing else, this thread serves as useful information to be used as a rough design guideline for future efforts, that's all. I don't think anyone is jumping up and down to get the FIN MIB substantially changed at this point. (Although Paul Moore might be... ;) One other thing. Please don't say that concerns weren't raised about this generic topic before, because they were. The designers of the Job MIB simply decided to ignore it, that's all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > 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 > > fin-owner@pwg.org on 06/18/98 11:14:00 PM > Please respond to fin-owner@pwg.org > To: fin@pwg.org > cc: Paul_Gloger@cp10.es.xerox.com, hastings@cp10.es.xerox.com, > paulmo@microsoft.com, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com, > jkm@underscore.com > 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 fin-archive Fri Jun 19 12:46:57 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18794 for fin-outgoing; Fri, 19 Jun 1998 12:42:05 -0400 (EDT) Message-ID: From: Paul Moore To: "'Harry Lewis'" , fin@pwg.org Cc: jkm@underscore.com, rbergma@dpc.com, hastings@cp10.es.xerox.com, Paul_Gloger@cp10.es.xerox.com Subject: RE: FIN> On reading the FIN draft Date: Fri, 19 Jun 1998 09:41:53 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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:harryl@us.ibm.com] > Sent: Friday, June 19, 1998 8:27 AM > To: fin@pwg.org > Cc: jkm@underscore.com; rbergma@dpc.com; Paul Moore; > hastings@cp10.es.xerox.com; Paul_Gloger@cp10.es.xerox.com > 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 > > > > fin-owner@pwg.org on 06/18/98 11:14:00 PM > Please respond to fin-owner@pwg.org > To: fin@pwg.org > cc: Paul_Gloger@cp10.es.xerox.com, hastings@cp10.es.xerox.com, > paulmo@microsoft.com, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com, > jkm@underscore.com > 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 fin-archive Fri Jun 19 20:52:01 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21590 for fin-outgoing; Fri, 19 Jun 1998 20:49:40 -0400 (EDT) Date: Fri, 19 Jun 1998 17:36:46 -0700 (Pacific Daylight Time) From: Ron Bergman To: Paul Moore cc: "'Harry Lewis'" , fin@pwg.org, jkm@underscore.com, Tom Hastings , Paul_Gloger@cp10.es.xerox.com Subject: RE: FIN> On reading the FIN draft In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO 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. On Fri, 19 Jun 1998, Paul Moore wrote: > 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. > From fin-archive Fri Jun 19 21:22:01 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21765 for fin-outgoing; Fri, 19 Jun 1998 21:17:50 -0400 (EDT) Message-ID: From: Paul Moore To: "'Ron Bergman'" Cc: "'Harry Lewis'" , fin@pwg.org, jkm@underscore.com, Tom Hastings , Paul_Gloger@cp10.es.xerox.com Subject: RE: FIN> On reading the FIN draft Date: Fri, 19 Jun 1998 18:17:38 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: fin-owner@pwg.org Precedence: bulk Status: RO So now I am found out - my example is bad because you do have binders in there. So let me ask you - what things are not included? Why do you not consider this to be a complete MIB? > -----Original Message----- > From: Ron Bergman [SMTP:rbergma@dpc.com] > Sent: Friday, June 19, 1998 5:37 PM > To: Paul Moore > Cc: 'Harry Lewis'; fin@pwg.org; jkm@underscore.com; Tom Hastings; > Paul_Gloger@cp10.es.xerox.com > Subject: RE: FIN> On reading the FIN draft > > 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. > > > On Fri, 19 Jun 1998, Paul Moore wrote: > > > 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. > > From fin-archive Mon Jun 22 11:27:39 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26022 for fin-outgoing; Mon, 22 Jun 1998 11:24:58 -0400 (EDT) Date: Mon, 22 Jun 1998 08:11:53 -0700 (Pacific Daylight Time) From: Ron Bergman To: Paul Moore cc: "'Harry Lewis'" , fin@pwg.org, jkm@underscore.com, Tom Hastings , Paul_Gloger@cp10.es.xerox.com Subject: RE: FIN> On reading the FIN draft In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO Paul, To my knowledge, we have full coverage on all finisher processes of interest. But keep in mind that group members developing this MIB are not finisher experts. We are basing our work on the previous efforts from LMO (Large Mailroom Operations) and DPA. As a positive note, the last several meetings have been attended by a finisher expert from HP who has provided significant inputs. The document has also been reviewed by finisher experts at Xerox. The next meeting will be attended by several more finisher experts from Duplo Corp. So, even though the core developers are not finisher experts, there should be enough outside expertise to ensure full coverage. Ron Bergman Dataproducts Corp. On Fri, 19 Jun 1998, Paul Moore wrote: > So now I am found out - my example is bad because you do have binders in > there. > > So let me ask you - what things are not included? Why do you not consider > this to be a complete MIB? > > > -----Original Message----- > > From: Ron Bergman [SMTP:rbergma@dpc.com] > > Sent: Friday, June 19, 1998 5:37 PM > > To: Paul Moore > > Cc: 'Harry Lewis'; fin@pwg.org; jkm@underscore.com; Tom Hastings; > > Paul_Gloger@cp10.es.xerox.com > > Subject: RE: FIN> On reading the FIN draft > > > > 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. > > > > > > On Fri, 19 Jun 1998, Paul Moore wrote: > > > > > 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. > > > > From fin-archive Tue Jun 23 10:52:54 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13398 for fin-outgoing; Tue, 23 Jun 1998 10:52:12 -0400 (EDT) Message-ID: <358FC0CC.2E1F88E2@underscore.com> Date: Tue, 23 Jun 1998 10:50:52 -0400 From: Jeff Schnitzer X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: fin@pwg.org, ipp@pwg.org, jmp@pwg.org, p1394@pwg.org, pmp@pwg.org, pwg@pwg.org, sdp@pwg.org, sense@pwg.org, upd@pwg.org Subject: FIN> Please ignore this test message. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: fin-owner@pwg.org Precedence: bulk Status: RO Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From fin-archive Mon Jun 29 18:15:27 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04259 for fin-outgoing; Mon, 29 Jun 1998 18:12:30 -0400 (EDT) Message-Id: <3.0.5.32.19980629151206.01b08400@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 15:12:06 PDT To: fin@pwg.org From: Tom Hastings Subject: FIN> Comments on the FIN MIB - will be forwarded when PWG server up Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO Typos: Section 5.5 Linked MULTI-ROW Values, 3rd and 4th lines both have "shape". Delete one of them. >X-Sender: hastings@garfield >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Thu, 25 Jun 1998 13:56:44 -0700 >To: rbergma@dpc.com, Harry Lewis >From: Tom Hastings >Subject: Comments on the FIN MIB - will be forwarded when PWG server up >Cc: imcdonal@eso.mc.xerox.com (Ira Mcdonald), hastings > >Ron and Harry, > >We just completed a company-wide review of the Finisher MIB. It stood up >well. > >Here are the comments: > >1. Fix the compile errors that Ira will send. > > >2. Add two attributes to allow the agent to indicate the fixed sequential >order of finishing, when there is an ordering. Then replace the >following sentence on page 11, just before 4.1: > > The Finisher MIB does not provide information regarding the order > that operations can be performed. > >with: > > The Finisher MIB permits an agent to describe the order that operations > can be performed. > >Add the two generic attributes: > > finPreviousFinishingOperation(19), Integer32 (0..65535) > INTEGER: Defines the finDeviceIndex of the previous finishing operation > for implementations in which the finishing operations are performed in > a prescribed order. Each finishing operation in the fixed seqence is > either performed or not performed according to the finishing instructions > submitted with the job. A value of 0 indicates that this finishing > operation is the first in a sequence. Finishing operations which are > not part of a fixed sequence SHALL not have this attribute. > > finNextFinishingOperation(20), Integer32 (0..65535) > INTEGER: Defines the finDeviceIndex of the next finishing operation > for implementations in which the finishing operations are performed in > a prescribed order. Each finishing operation in the fixed seqence is > either performed or not performed according to the finishing instructions > submitted with the job. A value of 0 indicates that this finishing > operation is the first in a sequence. Finishing operations which are > not part of a fixed sequence SHALL not have this attribute. > > >3. Figure 1 and 2: some people are having trouble distinguishing the edge >of the medium from all the other lines. How about using a distinguishing >character, such as # for all four edges of the medium? Still keep + for >the corners. > > >4. Need to clarify that the 'X' axis is always along the short >edge of the medium and the 'Y' axis is always along the long edge of the >medium, regardless of the orientation of the printer image or the direction >of feed. You might want to add an i.e. to the end of the second sentence of >Media Orienation on page 5, so that it would read: > >The 'X' and 'Y' axis, therefore, will always reference the medium as shown >in figure 1 and 2, i.e., with the 'X' axis always along the short edge and >the 'Y' axis always along the long edge. > > >5. Page 30, line 23, finSupplyEntry: there is a bug in the INDEX clause: > >Change finDeviceIndex to finSupplyIndex to go with the in-accessible >object. > > >6. Page 32, finSupplyColorantValue: the name is confusing, since the >Finisher isn't applying color. How about using the first words in the >defintion from the Printer MIB: "color name"? > >So change the name from finSupplyColorantValue to finSupplyColorName. > > >7. Change 40, delete finSuppplyMediaInputGroup from the MANDATORY-GROUPS >clause, since page 33 says its Conditionally Mandatory in the header. > > >8. ISSSU: The Finisher Device Attribute Group is listed in the >MANDATORY-GROUPS on page 40, which is fine. But need to say MANDATORY >on page 37 as well. > >I assume that making it MANDATORY is not much of a burden, since the table >doesn't need to contain any attributes, correct? > >Alternatively, we could make it CONDITIONALLY MANDATORY, but then we need >to write a condition on page 37 that makes the table MANDATORY, as is done >for the finSupplyMediaInput group/table. > >Thanks, >Tom > > > > > > > > From fin-archive Mon Jun 29 18:15:28 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04460 for fin-outgoing; Mon, 29 Jun 1998 18:13:53 -0400 (EDT) Message-Id: <3.0.5.32.19980629151334.01ae1d80@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 15:13:34 PDT To: fin@pwg.org From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962 by way of Tom Hastings ) Subject: FIN> Compile errors in the Finisher MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO Hi Ron and Harry, Below is the note I wrote up earlier today, when I thought the PWG server would be back up by now. But it isn't, so herewith some compiler fixups. Cheers, - Ira ---------------------------------------------------- Hi Ron Bergman and PWG folks, Thursday (25 June 1998) Below are the 'diff' files for the compile errors I fixed in the Printer MIB and Finisher MIB I got from Tom Hastings (they MAY vary slightly from those on the PWG server at present). Tom hadn't posted a '.mib' of the Finisher MIB on our Xerox server, so I made one with David Perkins' 'mstrip' utility (thus line numbers will vary from yours, no doubt). I commented the 'diff' files, to indicate the object or sequence clause in question. I used Epilogue Emissary 7.0 (1997) and SMICng 2.1 (1997) MIB compilers, both of which do a fine job of enforcing RFC 1902 rules. Cheers, - Ira McDonald High North 221 Ridge Ave Grand Marais, MI 49839 906-494-2434 (work) 906-494-2697 (home) ------------------------------------------------------------------------ ** Printer MIB - 06/11/98 version ** ==> added 'mib-2' import from RFC 1213 and uncommented RFC 1902 imports 4,5,c,4,6 < -- MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, TimeTicks, NOTIFICATION-TYPE, < -- OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI --- > mib-2 FROM RFC1213-MIB > MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, TimeTicks, NOTIFICATION-TYPE, > OBJECT-IDENTITY FROM SNMPv2-SMI ==> deleted illegal 'mib-2' definition prior to MODULE-IDENTITY 10,11,d,10 < mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } < ==> changed 'prtAlertIndex' to 'read-only' (from 'not-accessible'), ==> because it is a hard error in RFC 1902 and Epilogue Emissary 7.0 ==> to include a 'not-accessible' object in trap bindings 4035,c,4034 < MAX-ACCESS not-accessible --- > MAX-ACCESS read-only ==> added 'ptrAlertIndex' to 'prtAlertTableGroup' 4670,c,4669,4670 < OBJECTS { prtAlertCriticalEvents, prtAlertAllEvents, --- > OBJECTS { prtAlertIndex, > prtAlertCriticalEvents, prtAlertAllEvents, ==> commented out some text following the END statement 4702,4703,c,4702,4703 < Update the MIB references to SMIv2, and the conformance < statements. --- > -- Update the MIB references to SMIv2, and the conformance > -- statements. ------------------------------------------------------------------------ ** Finisher MIB - 06/11/98 version ** ==> added 'mib-2' import from RFC 1213 ==> removed unused 'experimental' import from RFC 1902 (SMIv2) 4,c,4,5 < MODULE-IDENTITY, OBJECT-TYPE, experimental, --- > mib-2 FROM RFC1213-MIB > MODULE-IDENTITY, OBJECT-TYPE, ==> removed unused 'prtOutputIndex' import from Printer MIB 12,c,13 < PrtCapacityUnitTC, prtOutputIndex, --- > PrtCapacityUnitTC, ==> removed unused 'prtMediaPathIndex' import from Printer MIB 14,c,15 < PrtMediaPathIndex, prtMIBConformance FROM Printer-MIB; --- > prtMIBConformance FROM Printer-MIB; ==> changed module ID from duplicate of Printer MIB to arbitrary arc 39,c,40 < ::= { mib-2 43 } --- > ::= { mib-2 9999 } ==> corrected case error in spelling of 'FinAttributeTypeTC' 69,c,70 < finAttributeTypeTC ::= TEXTUAL-CONVENTION --- > FinAttributeTypeTC ::= TEXTUAL-CONVENTION ==> corrected type of 'finDeviceCurrentCapacity' to 'Integer32' 468,c,469 < finDeviceCurrentCapacity OCTET STRING, --- > finDeviceCurrentCapacity Integer32, ==> corrected type of 'finDeviceAssociated Outputs' to 'OCTET STRING' 472,c,473 < finDeviceAssociatedOutputs Integer32, --- > finDeviceAssociatedOutputs OCTET STRING, ==> corrected typo in SYNTAX of 'finDeviceIndex' 478,c,479 < SYNTAX Integer32 ((0..65535) --- > SYNTAX Integer32 (0..65535) ==> corrected DEFVAL of 'finDevicePresentOnOff' to name NOT number 505,c,506 < DEFVAL { 5 } -- not present --- > DEFVAL { notPresent } ==> corrected typo in SYNTAX of 'finDeviceAssociatedMediaPaths' 552,c,553 < SYNTAX Octet String --- > SYNTAX OCTET STRING ==> corrected typo in SYNTAX of 'finDeviceAssociatedOutputs' 569,c,570 < SYNTAX Octet String --- > SYNTAX OCTET STRING ==> corrected typo in INDEX of 'finSupplyEntry' 636,c,637 < INDEX { hrDeviceIndex, finDeviceIndex } --- > INDEX { hrDeviceIndex, finSupplyIndex } ==> corrected illegal use of dashes in comment line ==> at end of figure above 'finSupplyColorantValue' 758,c,759 < -- ------- +-------------------+ ------- --- > -- _______ +___________________+ _______ ==> corrected SYNTAX of 'finSupplyMediaInputName' to ==> 'OCTET STRING' (consistent with Printer MIB) 939,c,940 < SYNTAX DisplayString (SIZE(0..63)) --- > SYNTAX OCTET STRING (SIZE(0..63)) ==> corrected SYNTAX of 'finSupplyMediaInputDescription' to ==> 'OCTET STRING' (consistent with Printer MIB) 949,c,950 < SYNTAX DisplayString (SIZE(0..255)) --- > SYNTAX OCTET STRING (SIZE(0..255)) ==> corrected SYNTAX of 'finSupplyMediaInputMediaType' to ==> corrected SYNTAX of 'finSupplyMediaInputDescription' to 1000,c,1001 < SYNTAX DisplayString (SIZE(0..63)) --- > SYNTAX OCTET STRING (SIZE(0..63)) ==> corrected SYNTAX of 'finDeviceAttributeValueAsInteger' ==> agree with DEFVAL 1079,c,1080 < SYNTAX Integer32 (-1..2147483647) --- > SYNTAX Integer32 (-2..2147483647) ==> corrected typo in DEFVAL of 'finDeviceAttributeValueAsOctets' 1113,c,1114 < DEFVAL { '' } -- empty string --- > DEFVAL { ''H } -- empty string ==> removed 'finDeviceIndex' (not-accessible) from OBJECTS clause of ==> 'finDeviceGroup' OBJECT-GROUP macro 1214,c,1215 < OBJECTS { finDeviceIndex, finDeviceType, finDevicePresentOnOff, --- > OBJECTS { finDeviceType, finDevicePresentOnOff, ==> removed 'finSupplyIndex' (not-accessible) from OBJECTS clause ==> and added 'finSupplyDeviceIndex' (read-only) to OBJECTS clause ==> of 'finSupplyGroup' OBJECT-GROUP macro 1225,c,1226 < OBJECTS { finSupplyIndex, finSupplyClass, finSupplyType, --- > OBJECTS { finSupplyDeviceIndex, finSupplyClass, finSupplyType, ==> removed 'finSupplyMediaInputDeviceType' (undefined) from OBJECTS clause ==> of 'finSupplyMediaInputGroup' OBJECT-GROUP macro 1234,c,1235 < OBJECTS { finSupplyMediaInputIndex, finSupplyMediaInputDeviceType, --- > OBJECTS { finSupplyMediaInputDeviceIndex, ==> corrected type in 'finSupplyMediaInputDimUnit' in OBJECTS clause ==> of 'finSupplyMediaInputGroup' OBJECT-GROUP macro 1236,c,1237 < finSupplyMediaInputDimType, --- > finSupplyMediaInputDimUnit, ==> removed 'finDeviceAttributeTypeIndex' (not-accessible) and ==> removed 'finDeviceAttributeInstanceIndex' (not-accessible) from ==> OBJECTS clause of 'finDeviceAttributeGroup' OBJECT-GROUP macro 1251,1252,c,1252 < OBJECTS { finDeviceAttributeTypeIndex, < finDeviceAttributeInstanceIndex, --- > OBJECTS { ------------------------------------------------------------------------ From fin-archive Mon Jun 29 20:55:24 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06353 for fin-outgoing; Mon, 29 Jun 1998 20:53:18 -0400 (EDT) Date: Mon, 29 Jun 1998 17:40:13 -0700 (Pacific Daylight Time) From: Ron Bergman To: fin@pwg.org cc: Harry Lewis , Tom Hastings , imcdonal@eso.mc.xerox.com Subject: FIN> New Finisher MIB Internet-Draft Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fin-owner@pwg.org Precedence: bulk Status: RO I have submitted the latest Finisher MIB document to the IETF to be posted as an internet-draft. The announcement should appear in the next day or so. The document also can be found at: ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing-03.txt I have also loaded a WORD file that contains revision marks for all the changes since the last internet-draft. (I could not create a PDF file today.) The WORD file is in the same directory as: draft-ietf-printmib-finishing-rev-03.doc And there is a MIB file that matches at: ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980629.mib These documents contain all the changes from the prevous posting plus, with the following exceptions, the changes suggested by Tom Hastings and Ira Mcdonald. 1. I added "(mandatory)" to the Finisher Device Attribute Group but I question whether it should really be "Conditionally Mandatory". As suggested by Tom, is it valid to have a table entry without any attributes? Or, if there are no attributes there should be no table? 2. I did not change the arc to { mib-2 9999 } as in Ira's differences. I believe that the problem observed by Ira could also be solved by appending the Finisher MIB to the Printer MIB and compiling both together. Ira: Did your complied result contain the correct OIDs with the Printer MIB arc? 3. Ira suggested that the syntax of the objects: finSupplyMediaInputName finSupplyMediaInputDescription finSupplyMediaInputMediaType be change from "DisplayString" to "OCTET STRING" to be consistent with the Printer MIB. Since it was previously discussed and agreed that these objects should be "DisplayString", I did not change. Unless we can resolve the above three issues via email, I would like to place these issues for discussion on the agenda for next week. Ron Bergman Dataproducts Corp. From fin-archive Tue Jun 30 16:55:38 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21352 for fin-outgoing; Tue, 30 Jun 1998 16:53:19 -0400 (EDT) Message-Id: <3.0.5.32.19980630131147.0093e100@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Jun 1998 13:11:47 PDT To: Ron Bergman From: Tom Hastings Subject: Re: FIN> New Finisher MIB Internet-Draft Cc: fin@pwg.org, Harry Lewis , imcdonal@eso.mc.xerox.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO At 17:40 6/29/98 PDT, Ron Bergman wrote: >I have submitted the latest Finisher MIB document to the IETF to be posted >as an internet-draft. The announcement should appear in the next day or >so. > >The document also can be found at: > >ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing -03.txt > >I have also loaded a WORD file that contains revision marks for all the >changes since the last internet-draft. (I could not create a PDF file today.) >The WORD file is in the same directory as: > >draft-ietf-printmib-finishing-rev-03.doc > >And there is a MIB file that matches at: > >ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980629.mib > > >These documents contain all the changes from the prevous posting plus, >with the following exceptions, the changes suggested by Tom Hastings and >Ira Mcdonald. > > 1. I added "(mandatory)" to the Finisher Device Attribute Group but I > question whether it should really be "Conditionally Mandatory". As > suggested by Tom, is it valid to have a table entry without any > attributes? Or, if there are no attributes there should be no table? Good question. > > 2. I did not change the arc to { mib-2 9999 } as in Ira's differences. > I believe that the problem observed by Ira could also be solved by > appending the Finisher MIB to the Printer MIB and compiling both > together. > > Ira: Did your complied result contain the correct OIDs with the > Printer MIB arc? > > 3. Ira suggested that the syntax of the objects: > > finSupplyMediaInputName > finSupplyMediaInputDescription > finSupplyMediaInputMediaType > > be change from "DisplayString" to "OCTET STRING" to be consistent > with the Printer MIB. Since it was previously discussed and agreed > that these objects should be "DisplayString", I did not change. I forget the discussion about keeping it as DisplayString. The problem with DisplayString, is that it MUST be US-ASCII. With OCTET STRING, it could be some other character set (and language). See the suggested clarifications that Ira and I proposed to reflect current implementations. By keeping it as DisplayString, then if we ever did agree to allowing other charsets for the Printer MIB, we couldn't for the Finisher MIB. > >Unless we can resolve the above three issues via email, I would like to >place these issues for discussion on the agenda for next week. > > > Ron Bergman > Dataproducts Corp. > > > > From fin-archive Tue Jun 30 19:10:38 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23126 for fin-outgoing; Tue, 30 Jun 1998 19:08:17 -0400 (EDT) Message-Id: <3.0.5.32.19980630153518.016e4ea0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Jun 1998 15:35:18 PDT To: Ron Bergman From: Tom Hastings Subject: Re: FIN> New Finisher MIB Internet-Draft Cc: fin@pwg.org, Harry Lewis , imcdonal@eso.mc.xerox.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO I've posted the .pdf files with line numbers: ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing- rev-03.pdf ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing- rev-03-rev.pdf The latter has revision marks turned on (they start over each page). -rw-r--r-- 1 pwg pwg 94049 Jun 30 00:06 draft-ietf-printmib-finishing-03.txt -rw-r--r-- 1 pwg pwg 160768 Jun 30 00:08 draft-ietf-printmib-finishing-rev-03.doc -rw-r--r-- 1 pwg pwg 86160 Jun 30 22:31 draft-ietf-printmib-finishing-rev-03.pdf -rw-r--r-- 1 pwg pwg 115794 Jun 30 22:31 draft-ietf-printmib-finishing-rev-03-rev.pdf Tom At 17:40 6/29/98 PDT, Ron Bergman wrote: >I have submitted the latest Finisher MIB document to the IETF to be posted >as an internet-draft. The announcement should appear in the next day or >so. > >The document also can be found at: > >ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing -03.txt > >I have also loaded a WORD file that contains revision marks for all the >changes since the last internet-draft. (I could not create a PDF file today.) >The WORD file is in the same directory as: > >draft-ietf-printmib-finishing-rev-03.doc > >And there is a MIB file that matches at: > >ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980629.mib > > >These documents contain all the changes from the prevous posting plus, >with the following exceptions, the changes suggested by Tom Hastings and >Ira Mcdonald. > > 1. I added "(mandatory)" to the Finisher Device Attribute Group but I > question whether it should really be "Conditionally Mandatory". As > suggested by Tom, is it valid to have a table entry without any > attributes? Or, if there are no attributes there should be no table? > > 2. I did not change the arc to { mib-2 9999 } as in Ira's differences. > I believe that the problem observed by Ira could also be solved by > appending the Finisher MIB to the Printer MIB and compiling both > together. > > Ira: Did your complied result contain the correct OIDs with the > Printer MIB arc? > > 3. Ira suggested that the syntax of the objects: > > finSupplyMediaInputName > finSupplyMediaInputDescription > finSupplyMediaInputMediaType > > be change from "DisplayString" to "OCTET STRING" to be consistent > with the Printer MIB. Since it was previously discussed and agreed > that these objects should be "DisplayString", I did not change. > >Unless we can resolve the above three issues via email, I would like to >place these issues for discussion on the agenda for next week. > > > Ron Bergman > Dataproducts Corp. > > > > From fin-archive Tue Jun 30 21:00:38 1998 Return-Path: fin-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23649 for fin-outgoing; Tue, 30 Jun 1998 20:55:58 -0400 (EDT) Message-Id: <3.0.5.32.19980630155952.0093e210@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Jun 1998 15:59:52 PDT To: fin@pwg.org From: Tom Hastings Subject: Re: FIN> New Finisher MIB Internet-Draft [more on the DisplayString issue] Cc: Ron Bergman , fin@pwg.org, Harry Lewis , imcdonal@eso.mc.xerox.com In-Reply-To: <3.0.5.32.19980630131147.0093e100@garfield> References: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: fin-owner@pwg.org Precedence: bulk Status: RO At 13:11 6/30/98 PDT, Tom Hastings wrote: snip... >> 3. Ira suggested that the syntax of the objects: >> >> finSupplyMediaInputName >> finSupplyMediaInputDescription >> finSupplyMediaInputMediaType >> >> be change from "DisplayString" to "OCTET STRING" to be consistent >> with the Printer MIB. Since it was previously discussed and agreed >> that these objects should be "DisplayString", I did not change. > >I forget the discussion about keeping it as DisplayString. The problem >with DisplayString, is that it MUST be US-ASCII. With OCTET STRING, >it could be some other character set (and language). See the suggested >clarifications that Ira and I proposed to reflect current implementations. > >By keeping it as DisplayString, then if we ever did agree to allowing other >charsets for the Printer MIB, we couldn't for the Finisher MIB. Further arguments for changing these three back to OCTET STRING to agree with the Printer MIB: We must change at least finSupplyMediaInputDescription back to OCTET STRING in order to agree with the semantics that we have written which require the data to be whatever the current localizaion is: The finSupplyMediaInputDescription is intended to be localized (as in the Printer MIB): finSupplyMediaInputDescription OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A free form text description of this input subunit in the localization specified by prtGeneralCurrentLocalization." ::= { finSupplyMediaInputEntry 11 } RFC 1902 says: 11.1.1. Mapping to the SYNTAX clause When mapping to the SYNTAX clause of the OBJECT-TYPE macro: snip... (6) An object with a character string syntax becomes either an OCTET STRING, or a DisplayString [3], depending on the repertoire of the character string. [3] is RFC 1903. Therefore, it cannot be DisplayString, which RFC 1903 restricts to US-ASCII: DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255)) I claim that we should change all three back to OCTET STRING to be consistent with the Printer MIB and to allow implementations to use other charsets for these three objects. We should only use DisplayString when the data is restricted to US-ASCII for some reason, such as the data is really keywords for programs, not arbitrary text for humans. Tom > >> >>Unless we can resolve the above three issues via email, I would like to >>place these issues for discussion on the agenda for next week. >> >> >> Ron Bergman >> Dataproducts Corp. >> >> >> >> > >