From charles.a.adams at exgate.tek.com Mon Jan 4 10:34:59 1999 From: charles.a.adams at exgate.tek.com (charles.a.adams@exgate.tek.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <6B57A2A3212BD2119C2600805F6F1413011536FF@us-wv-m11.wv.tek.com> Name: Charles Adams Company: Tektronix, Inc ___ I support this proposed change ___ I reject this proposed change X I abstain from voting for the following reason: We have no opinion on this change. From imcdonal at sdsp.mc.xerox.com Mon Jan 4 11:24:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901041624.AA08040@appsrv1.sdsp.mc.xerox.com> Hi Folks, I vote in favor of this proposed update to the Job Mon MIB. Cheers, - Ira McDonald High North Inc 716-561-5667 From harryl at us.ibm.com Tue Jan 5 11:07:06 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F0.00588C85.00@d53mta05h.boulder.ibm.com> I may change my vote with further consideration but, at this time, I vote "against" based on the fact that continued changes at this point may adversely affect progress with the IETF. It was my understanding that we would take the job MIB as frozen last year to the IETF and make any additions to a future version. Name: Harry Lewis___________________________ Company: IBM_________________________ ___ I support this proposed change _x_ I reject this proposed change ___ I abstain from voting for the following reason: ___________________________________________________________ Harry Lewis - IBM Printing Systems harryl@us.ibm.com From imcdonal at sdsp.mc.xerox.com Tue Jan 5 19:52:04 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901060052.AA03421@appsrv1.sdsp.mc.xerox.com> Hi Harry, I understand your argument (too late, once again), but I think your logic is flawed. We aren't asking the IETF to adopt JMP MIB. We're just asking them to publish it as an Informational RFC. Unlike IPP (which is merely in serious trouble with the IETF), the JMP MIB has fallen entirely from IETF grace. Why do we care if we delay it for a short while to improve it? Also, I watched the same argument (too late, once again) be applied nineteen months ago to abandon work to fix the localisation contexts of all strings in the Printer MIB. And we all saw how quickly the Printer MIB v2 draft moved forward... - Ira McDonald High North Inc 716-461-5667 (w/ voice mail) From hastings at cp10.es.xerox.com Wed Jan 6 19:23:05 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C305@x-crt-es-ms1.cp10.es.xerox.com> >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Tuesday, December 22, 1998 07:42 >To: jmp@pwg.org >Subject: JMP> Ballot on Xerox Job MIB comments > > >I am requesting a formal ballot regarding the recent request >from Xerox to >expand the object jmSystemAttributeSupport to three objects. >Since this >is a very last minute change, it is very important that all who have >participated in this project review this change carefully. >Please return >the following ballot: > > > Name: _____Tom Hastings_______________________ > > Company: __Xerox______________________________ > > _x_ I support this proposed change > > ___ I reject this proposed change > > ___ I abstain from voting for the following reason: > > ___________________________________________________________ > > >Because the holidays will soon be here, I am setting the deadline to >January 13th. So we should have a final vote prior to the >Maui meeting. > >I encourage everyone to vote! > > > Ron Bergman > Dataproducts Corp. > > >---------- Forwarded message ---------- >Date: Mon, 14 Dec 1998 15:47:58 -0800 >From: "Hastings, Tom N" >To: jmp >Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call > >We held a Xerox-wide design review the proposed version 1.3 of >the PWG Job >Monitoring MIB that included a number of client-side >developers as well as >agent developers. We believe that the single bit array, >jmSystemAttributeSupport, indicating attribute support should >be replaced >with three bit arrays: >1) A bit array specifying which supported attributes can >contain meaningful >integer data. >2) A bit array specifying which supported attributes can >contain meaningful >string data. >3) A bit array specifying which supported attributes can have >more than one >integer or more than one string value. >There are two main areas of concern regarding the use of >"dictionary" or >attribute defining MIBs. First is the efficiency with which attribute >values can be requested and obtained from the device and second is the >ability to create generic management middleware that can be >reused when the >MIB is extended with additional attributes and can be used >with different >management applications that use different combinations of >attributes. Such >middleware obtains all of the attributes and keeps a local copy of the >attributes updated as the device runs. Any management application then >deals with the client-side local copy by calling the >client-side management >middleware for any combination of attributes which are >returned immediately >without querying the device. >Some items of note which should be considered in the following >discussion >are: >1) Most management applications must support SNMPv1 and SNMPv2 so that >relying on a getBulk type operation is not viable. >2) Most management applications support multiple SNMP protocol >stacks some >of which have quite small packet size limits such as 480 >octets so relying >on a maximum size of more than that is not viable. >One of the major concerns of many management applications is the >minimization of network traffic and a major factor in >determining the amount >of traffic is the number of strings to be retrieved. The >reason for this is >due to the fact that strings can be fairly long, up to 63 >octets. Couple >this with the limited packet size available and it is easily >seen that if a >large number of strings are to be retrieved then a large >number of packets >will be required. At most only 6 strings can be requested in a single >packet, else there is the risk of not all of the data fitting >in the packet. >This is because each string can be up to 63 octets and the OID for each >string can be around 15-20 octets, say around 80 as a maximum. > 484 divided >by 80 is 6 strings maximum. If only a single bit array is >used then both >the integer and string values will have to be requested for all of the >supported attributes. Since most of the string values will be NULL this >results in a large number of packets with unnecessary data (the null >strings). With an indicator of which attributes can actually >have valid >string data then only those attributes need to be requested >and the number >of needed packets can be optimized. This same argument >applies to integers >as well, although, to a lesser degree since 24 or so integers can be >requested in a single packet. >Being able to request this information from the device rather >than encoding >it directly into management application middleware makes the >application >middleware more robust, generic and re-usable. Encoding the >information >directly into the application middleware that an application >needs means >that the middleware can not be used with any application. It >also means >that if new attributes are added to a MIB then the application >middleware >will have to be modified to accommodate them. Neither of >these situations >is desirable from a software design and product deployment >point-of-view. >Adding the bit array that indicates which attributes might >have more than >one value and which ones cannot, means that the management >application knows >which values should be retrieved with several GetNext >operations in order to >pick up all the values and which only need one direct Get. While the >specification indicates which attribute MAY have multiple values, many >implementations MAY only actually implement one value. For >example, the >number of fileName or documentName attribute values per job >MAY only have a >single value for many implementations that only support one >document per >job, though multiple values are allowed. The same for >mediumRequested, etc. >So the third bit array indicates which attributes could have >more than one >value for that implementation. >Having these three bit arrays also allows management >middleware to obtain >attribute extensions from a device that were registered after >the management >middleware was shipped. Only the management application needs >updating that >wants to take advantage of the newly registered attributes. >Since these bit arrays are all read-only and never change >while the device >operates, they are very low cost in implementation and can be >put into ROM. >While we share the group's concern about "creeping elegance" >and "mission >creep" and want to see the PWG Job Monitoring MIB approved, we >believe that >these three bit arrays are the end. There does not seem to be >any other >support information about an implementation that could be >added to the new >System Group. So we believe that this addition would be the end. >We have produced complete compilable alternatives to V1.3 and >stored them in >a sub-directory of the usual place: >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array s/jmp.dic >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.mib >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.txt >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib-rev >.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib-rev >.pdf > > >Here are the relevant changes: > > >In Section 3.3.8 Attribute Specification update the paragraphs >on the bit >array support: > >A management application can determine which attributes are supported >and whether the integer and/or the octet string values are supported >with meaningful value by querying the jmSystemAttrIntegerSupport and >jmSystemAttrOctetsSupport objects, respectively. Management >applications can also determine which supported attributes might >support more than one integer value or more than one octet string value >by querying jmSystemAttrMultiRowSupport. > >These support bits are indicated in hex for each range in the line >starting with "support bits starting:". Note: these objects permit a >management application to determine the degree of support, even when >there are no jobs present in the system. They also permit management >middleware to fetch all attribute values for all jobs, including future >extensions, and keep them updated for one or more management >applications at the same time. > > >Replace the jmSystemAttributeSupport bit array object with the >following >three bit array objects: > >jmSystemAttrIntegerSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which attributes of the MIB this > implementation supports with meaningful integer values. > > The value of this object is a sparse bit array in which bit n > is a 1 if attribute n is supported with the > jmAttributeValueAsInteger object with meaningful values, where > n is the value of the enumerated attribute type in the > JmAttributeTypeTC used in jmAttributeTypeIndex (and the > jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). > Bit n MUST be 0 (or beyond the end of the returned bit array), > if attribute n is not supported or is always returned with a '- > 1'(other) or '-2'(unknown) value. > > The high order bit of the first octet in this octet string > corresponds to an attribute type of 0 (reserved), i.e., the bit > string uses the Big Endian numbering convention. Compare with > the BITS data type in SMIv2 [SMIv2-SMI] which has the same > format but requires contiguous enumerated bits. Trailing > octets in the octet string that contain only zero bits MUST NOT > be returned. > > Note: private attributes cannot be represented in this bit > array because their enum values are in the range 2**30 to > 2**31-1. See section 3.3.8. > > Example: An implementation supporting the attributes: > jobStateReasons2(3), jobStateReasons3(4), and jobName(23) > would return a one-octet string value of { '18'H }, since > jobName is an octet string value, not an integer value. > > This object helps a management application determine which > attributes with meaningful integer values MAY be present on > jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 3 } > > > >jmSystemAttrOctetsSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which attributes of the MIB this > implementation supports with meaningful octet string values. > > The format and semantics of this object is the same as > jmSystemAttrIntegerSupport, except that bit n indicates that > attribute n supports the jmAttributeValueAsOctets object with > meaningful values, instead of the jmAttributeValueAsInteger > object. Bit n MUST be 0 (or beyond the end of the returned bit > array), if attribute n is not supported or is always returned > as a zero-length octet string value. > > If an implementation supports both jmAttributeValueAsInteger > and jmAttributeValueAsOctets with meaningful values for > attribute n, bit n MUST appear in both bit array objects with a > 1 value. > > Example: An implementation supporting the attributes: > jobStateReasons2(3), jobStateReasons3(4), and jobName(23) > would return a three-octet string value of { '000001'H }, since > jobStateReasons2 and jobStateReasons3 are integer values, not > octet string values. > > This object helps a management application determine which > attributes with meaningful octet string values MAY be present > on jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 4 } > > >jmSystemAttrMultiRowSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which MULTI-ROW attributes of the MIB > this implementation supports with multiple integer values > and/or multiple octet string values. > > The format of this object is the same as the > jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport > objects. Bit n MUST be 1, if attribute n is actually supported > with more than one integer and/or more than one octet string > value. Bit n MUST be 0 (or beyond the end of the returned bit > array), if attribute n is not supported, is always returned as > a single integer value, or as a single octet string value. For > every bit n that is a 1 in this bit array, there MUST be a > corresponding 1 for bit n in either jmSystemAttrIntegerSupport, > jmSystemAttrOctetsSupport, or both. > > Example: Consider an implementation supporting: > (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW > integer attributes > (b) the jobName(23) SINGLE-ROW octet string attribute > (c) more than one integer value for the mediumRequested(170) > and mediumConsumed(171) MULTI-ROW attributes AND > (d) more than one octet string value for the fileName(34), > documentName(35), and mediumConsumed(171) MULTI-ROW attributes > (e) no octet string values for mediumRequested(170). > Such an implementation would return: > jmSystemAttrIntegerSupport 22 octets: > { '18000000 00000000 00000000 00000000 00000000 0030'H } > jmSystemAttrOctetsSupport 22 octets: > { '00000100 30000000 00000000 00000000 00000000 0010'H } > jmSystemAttrMultiRowSupport 22 octets: > { '00000000 30000000 00000000 00000000 00000000 0030'H } > > Example: Consider an implementation that supports the > fileName(34) MULTI-ROW attribute, but does not support more > than one document per job. Such an implementation would NOT > return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since > such an implementation would never return more than one > fileName value for a job. It would return a zero-length > string, since it never returns more than one value. > > This object helps a management application determine which > attributes may return more than one integer value or more than > one octet string value on jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 5 } > > > >Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike >Elvers, Ang >Caruso, Joe Filion > >(310) 333-6413 > > From harryl at us.ibm.com Thu Jan 7 13:56:25 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F2.00680BEA.00@d53mta05h.boulder.ibm.com> A few days ago, I stated my lack of support in Ron's ballot request... >I am requesting a formal ballot regarding the recent request >from Xerox to expand the object jmSystemAttributeSupport to three objects. I should elaborate that I do not object to the particular jmSystemAttributeSupport changes proposed by Xerox but to the entire notion of submitting an updated version of the Job MIB to the IETF if that version has new mandatory objects which were not part of the agreed PWG standard, closed months ago, and which is the basis of all prototypes and implementations thus far. The existing PWG Job MIB standard (v1) has been intended for submission to the IETF for consideration as an RFC. (It has been debated whether this would be standards track with the Printer MIB, Informational, Experimental etc... but, nonetheless, the Job MIB would be submitted). Recently, there have been proposals, resulting from prototypes, which have been discussed and agreed to be improvements. I agreed to the addition of an optional "mirror table" as part of the IETF submission because it was optional. Later there was the notion of a "system table" to differentiate Job MIB versions. This would be a new mandatory table. Finally, there are proposed modifications in the details of the objects in this table. While I welcome and have been very willing to discuss spec changes to the standard, I feel the PWG process recognizes a v1 PWG Job MIB standard which is in PWG maintenance mode. I believe this should be considered the most stable version and the one that is published to the IETF. A SECOND updated PWG Job MIB standard is entirely feasible but I don't believe it is valid to publish new mandatary objects in the first EXTERNAL version of the standard. I highly recommend at least one coordinated interoperability test prior to declaring the second major version of the Job MIB standard. Harry Lewis - IBM Printing Systems harryl@us.ibm.com From hastings at cp10.es.xerox.com Thu Jan 7 21:35:31 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C49D@x-crt-es-ms1.cp10.es.xerox.com> Harry, I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now with the System Group being entirely removed as you and Ron have suggested. We can also agree that we should make the second EXTERNALLY published version of the MIB AFTER an interoperability test and any updates needed from the interpretability test, as you proposed. Currently, the interoperability test is anticipated to be some time next summer. However, we need to be able to build something with the System Group in it NOW, rather than waiting until after the interoperability test (next summer). So could we also produce NOW an INTERNAL PWG working draft with version 2.0 that does have the MANDATORY System Group in it? This internal PWG working draft would NOT be forwarded to the IETF for publication as an Information RFC until after the interoperability test and any updates that the interoperability tests show were added. Thus the interoperability test would be for both version 1.0 products without the System Group and for version 2.0 products with the MANDATORY System Group. It is straightforward for any testing client software to tell the difference between the two by just querying the System Group and getting back no such object or not. So for process as a result of the PWG Last Call, after Maui I would forward the current JMP MIB document with the OPTIONAL Mirror Table but without the System Group to the IETF as an Internet-Draft. Ron prefers that we call it 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse the IETF. They have only seen the 1.0 spec from February 1998. If it looks ok, Ron will then request the RFC Editor to publish it as an Informational RFC. Secondly, next month I would take the current 1.3 version with the MANDATORY System Group and rename it to be version 2.0. Then implementers that want to can implement it for the Interoperability Tests. However, it would NOT be forwarded to the IETF until after the interoperability test. Implementers at the interoperability test could bring 1.0 or 2.0 conformant products. If new attributes are proposed and agreed to, I can add them to both the 1.0 and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by the IETF and an Informational RFC. After that we only need to keep maintaining the 2.0 spec. How does that sound? Thanks, Tom >-----Original Message----- >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >Sent: Thursday, January 07, 1999 10:56 >To: jmp@pwg.org >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > >>I am requesting a formal ballot regarding the recent request >>from Xerox to expand the object jmSystemAttributeSupport to >three objects. > >I should elaborate that I do not object to the particular >jmSystemAttributeSupport changes proposed by Xerox but to the >entire notion >of submitting an updated version of the Job MIB to the IETF if >that version >has new mandatory objects which were not part of the agreed >PWG standard, >closed months ago, and which is the basis of all prototypes and >implementations thus far. > >The existing PWG Job MIB standard (v1) has been intended for >submission to >the IETF for consideration as an RFC. (It has been debated whether this >would >be standards track with the Printer MIB, Informational, >Experimental etc... >but, nonetheless, the Job MIB would be submitted). > >Recently, there have been proposals, resulting from >prototypes, which have >been discussed and agreed to be improvements. I agreed to the >addition of >an optional "mirror table" as part of the IETF submission >because it was >optional. Later there was the notion of a "system table" to >differentiate >Job MIB versions. This would be a new mandatory table. >Finally, there are >proposed modifications in the details of the objects in this table. > >While I welcome and have been very willing to discuss spec >changes to the >standard, I feel the PWG process recognizes a v1 PWG Job MIB >standard which >is in PWG maintenance mode. I believe this should be >considered the most >stable version and the one that is published to the IETF. A >SECOND updated >PWG Job MIB standard is entirely feasible but I don't believe >it is valid >to publish new mandatary objects in the first EXTERNAL version of the >standard. > >I highly recommend at least one coordinated interoperability >test prior to >declaring the second major version of the Job MIB standard. > >Harry Lewis - IBM Printing Systems >harryl@us.ibm.com > > From harryl at us.ibm.com Fri Jan 8 10:23:51 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F3.0054966E.00@d53mta05h.boulder.ibm.com> Tom. This is a much better proposal. I only have one concern. The System Group was supposed to enable applications to determine whether or not the (optional) mirror table was supported. Perhaps 1.0 should just be the first PWG standard Job MIB (as agreed initially) and the (new) internal version (basis for next external) should have the mirror table and Systems Group. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/07/99 07:35:31 PM To: jmp cc: Harry Lewis/Boulder/IBM, Ron Bergman Subject: RE: JMP> Ballot on Xerox Job MIB comments Harry, I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now with the System Group being entirely removed as you and Ron have suggested. We can also agree that we should make the second EXTERNALLY published version of the MIB AFTER an interoperability test and any updates needed from the interpretability test, as you proposed. Currently, the interoperability test is anticipated to be some time next summer. However, we need to be able to build something with the System Group in it NOW, rather than waiting until after the interoperability test (next summer). So could we also produce NOW an INTERNAL PWG working draft with version 2.0 that does have the MANDATORY System Group in it? This internal PWG working draft would NOT be forwarded to the IETF for publication as an Information RFC until after the interoperability test and any updates that the interoperability tests show were added. Thus the interoperability test would be for both version 1.0 products without the System Group and for version 2.0 products with the MANDATORY System Group. It is straightforward for any testing client software to tell the difference between the two by just querying the System Group and getting back no such object or not. So for process as a result of the PWG Last Call, after Maui I would forward the current JMP MIB document with the OPTIONAL Mirror Table but without the System Group to the IETF as an Internet-Draft. Ron prefers that we call it 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse the IETF. They have only seen the 1.0 spec from February 1998. If it looks ok, Ron will then request the RFC Editor to publish it as an Informational RFC. Secondly, next month I would take the current 1.3 version with the MANDATORY System Group and rename it to be version 2.0. Then implementers that want to can implement it for the Interoperability Tests. However, it would NOT be forwarded to the IETF until after the interoperability test. Implementers at the interoperability test could bring 1.0 or 2.0 conformant products. If new attributes are proposed and agreed to, I can add them to both the 1.0 and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by the IETF and an Informational RFC. After that we only need to keep maintaining the 2.0 spec. How does that sound? Thanks, Tom >-----Original Message----- >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >Sent: Thursday, January 07, 1999 10:56 >To: jmp@pwg.org >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > >>I am requesting a formal ballot regarding the recent request >>from Xerox to expand the object jmSystemAttributeSupport to >three objects. > >I should elaborate that I do not object to the particular >jmSystemAttributeSupport changes proposed by Xerox but to the >entire notion >of submitting an updated version of the Job MIB to the IETF if >that version >has new mandatory objects which were not part of the agreed >PWG standard, >closed months ago, and which is the basis of all prototypes and >implementations thus far. > >The existing PWG Job MIB standard (v1) has been intended for >submission to >the IETF for consideration as an RFC. (It has been debated whether this >would >be standards track with the Printer MIB, Informational, >Experimental etc... >but, nonetheless, the Job MIB would be submitted). > >Recently, there have been proposals, resulting from >prototypes, which have >been discussed and agreed to be improvements. I agreed to the >addition of >an optional "mirror table" as part of the IETF submission >because it was >optional. Later there was the notion of a "system table" to >differentiate >Job MIB versions. This would be a new mandatory table. >Finally, there are >proposed modifications in the details of the objects in this table. > >While I welcome and have been very willing to discuss spec >changes to the >standard, I feel the PWG process recognizes a v1 PWG Job MIB >standard which >is in PWG maintenance mode. I believe this should be >considered the most >stable version and the one that is published to the IETF. A >SECOND updated >PWG Job MIB standard is entirely feasible but I don't believe >it is valid >to publish new mandatary objects in the first EXTERNAL version of the >standard. > >I highly recommend at least one coordinated interoperability >test prior to >declaring the second major version of the Job MIB standard. > >Harry Lewis - IBM Printing Systems >harryl@us.ibm.com > > From rbergma at dpc.com Fri Jan 8 10:37:16 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments In-Reply-To: <872566F3.0054966E.00@d53mta05h.boulder.ibm.com> Message-ID: Since the Mirror table is optional, I do not have a real problem with it either added or removed. But Harry does have a good point and it probably best that it not be included in version 1.0. This would also be a better position for us with the IETF. Anyone else have comments? Ron Bergman Dataproducts Corp. On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > Tom. This is a much better proposal. I only have one concern. > > The System Group was supposed to enable applications to determine whether > or not the (optional) mirror table was supported. Perhaps 1.0 should just > be the first PWG standard Job MIB (as agreed initially) and the (new) > internal version (basis for next external) should have the mirror table and > Systems Group. > > Harry Lewis - IBM Printing Systems > harryl@us.ibm.com > > > > "Hastings, Tom N" on 01/07/99 07:35:31 PM > > To: jmp > cc: Harry Lewis/Boulder/IBM, Ron Bergman > Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > > Harry, > > I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now > with the System Group being entirely removed as you and Ron have suggested. > > We can also agree that we should make the second EXTERNALLY published > version of the MIB AFTER an interoperability test and any updates needed > from the interpretability test, as you proposed. Currently, the > interoperability test is anticipated to be some time next summer. > > However, we need to be able to build something with the System Group in it > NOW, rather than waiting until after the interoperability test (next > summer). So could we also produce NOW an INTERNAL PWG working draft with > version 2.0 that does have the MANDATORY System Group in it? This internal > PWG working draft would NOT be forwarded to the IETF for publication as an > Information RFC until after the interoperability test and any updates that > the interoperability tests show were added. > > Thus the interoperability test would be for both version 1.0 products > without the System Group and for version 2.0 products with the MANDATORY > System Group. It is straightforward for any testing client software to > tell > the difference between the two by just querying the System Group and > getting > back no such object or not. > > So for process as a result of the PWG Last Call, after Maui I would forward > the current JMP MIB document with the OPTIONAL Mirror Table but without the > System Group to the IETF as an Internet-Draft. Ron prefers that we call it > 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse > the > IETF. They have only seen the 1.0 spec from February 1998. If it looks > ok, > Ron will then request the RFC Editor to publish it as an Informational RFC. > > Secondly, next month I would take the current 1.3 version with the > MANDATORY > System Group and rename it to be version 2.0. Then implementers that want > to can implement it for the Interoperability Tests. However, it would NOT > be forwarded to the IETF until after the interoperability test. > Implementers at the interoperability test could bring 1.0 or 2.0 conformant > products. > > If new attributes are proposed and agreed to, I can add them to both the > 1.0 > and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by > the > IETF and an Informational RFC. After that we only need to keep maintaining > the 2.0 spec. > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >Sent: Thursday, January 07, 1999 10:56 > >To: jmp@pwg.org > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > > > >>I am requesting a formal ballot regarding the recent request > >>from Xerox to expand the object jmSystemAttributeSupport to > >three objects. > > > >I should elaborate that I do not object to the particular > >jmSystemAttributeSupport changes proposed by Xerox but to the > >entire notion > >of submitting an updated version of the Job MIB to the IETF if > >that version > >has new mandatory objects which were not part of the agreed > >PWG standard, > >closed months ago, and which is the basis of all prototypes and > >implementations thus far. > > > >The existing PWG Job MIB standard (v1) has been intended for > >submission to > >the IETF for consideration as an RFC. (It has been debated whether this > >would > >be standards track with the Printer MIB, Informational, > >Experimental etc... > >but, nonetheless, the Job MIB would be submitted). > > > >Recently, there have been proposals, resulting from > >prototypes, which have > >been discussed and agreed to be improvements. I agreed to the > >addition of > >an optional "mirror table" as part of the IETF submission > >because it was > >optional. Later there was the notion of a "system table" to > >differentiate > >Job MIB versions. This would be a new mandatory table. > >Finally, there are > >proposed modifications in the details of the objects in this table. > > > >While I welcome and have been very willing to discuss spec > >changes to the > >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >standard which > >is in PWG maintenance mode. I believe this should be > >considered the most > >stable version and the one that is published to the IETF. A > >SECOND updated > >PWG Job MIB standard is entirely feasible but I don't believe > >it is valid > >to publish new mandatary objects in the first EXTERNAL version of the > >standard. > > > >I highly recommend at least one coordinated interoperability > >test prior to > >declaring the second major version of the Job MIB standard. > > > >Harry Lewis - IBM Printing Systems > >harryl@us.ibm.com > > > > > > > > From hastings at cp10.es.xerox.com Fri Jan 8 18:45:20 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C5CB@x-crt-es-ms1.cp10.es.xerox.com> We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From harryl at us.ibm.com Mon Jan 11 10:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F6.00562BB1.00@d53mta05h.boulder.ibm.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 10:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments In-Reply-To: <918C79AB552BD211A2BD00805F15CE8582C5CB@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916069415@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916070095@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074223@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074315@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074970@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075022@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075081@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075112@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From egglestn at lexmark.com Mon Jan 11 14:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Please ignore Message-ID: <199901111949.AA21592@lexmark.lexmark.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084232@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084309@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084376@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084454@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:02:32 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Another test Message-ID: <199901112003.AA23089@interlock2.lexmark.com> Please ignore... Thanks, Roger Eggleston From egglestn at lexmark.com Mon Jan 11 15:19:24 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Test Message-ID: <199901112027.AA25177@interlock2.lexmark.com> Please ignore... Thanks, From egglestn at lexmark.com Mon Jan 11 15:27:34 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> test Message-ID: <199901112030.AA25622@interlock2.lexmark.com> please ignore... From surfchina at gserver.com Mon Jan 18 06:14:17 1999 From: surfchina at gserver.com (Surf China) Date: Wed May 6 13:59:59 2009 Subject: JMP> SurfChina.com - Search Engine for China Message-ID: <199901181114.EAA02986@gserver.com> Dear friend, Do you ever wonder where to find information about China? Well, wonder no more. Come check out SurfChina.com (http://www.surfchina.com), the BEST SEARCH ENGINE for China. SurfChina.com's database consists of thousands of China, Chinese related web sites, all sites are carefully categorized into over 300 categories, which makes search very easy. New sites and categories are added everyday. You can find Chinese companies, Chinese culture sites, travel agencies, employment opportunities, Chinese newspapers, and much, much more. Take a look for yourself, and tell a friend about SurfChina.com, so everyone can take advantage of this wonderful resource. SurfChina.com also provides China statistical information service. We work directly with the State Statistical Bureau of China to provide the latest, the most accurate, and most authritative China statistical data for our clients. To find out more about this service, please visit http://www.surfchina.com/stats/ Sincerely yours, SurfChina.com team From hastings at cp10.es.xerox.com Mon Feb 22 04:14:28 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> I have posed the V1 and V2 PWG Job Monitoring MIB specifications as agreed Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE03F@x-crt-es-ms1.cp10.es.xerox.com> The V1 spec is ready to send to the IETF as an Internet-Draft and request the IESG to publish as an Informational RFC. As agreed, we will call this V1.0, not V1.3, even though the PWG has had an older version that we called V1.0 in February and made it an Internet-Draft (draft-ietf-printmib-job-monitor-07.txt). The V1.0 spec does not have either the Mirror Table or the System Table. The V2 spec has the OPTIONAL Mirror Table and the MANDATORY System Table that shows which attributes are supported and how. We should hold off on making V2 and Internet-Draft so as not to confuse the IETF. The V1 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/draft-ietf-printmib-job-monitor- 08.txt ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito r-08.txt The V2 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.txt Both V1 and V2 compile with three compilers. Here is the change history for V1: 10.1 Changes to produce version 1.0, dated February 19, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.0 [sic], dated January 28, 1999: 1. Changed the version number back to 1.0 for this INTERNET-DRAFT in anticipation of its being published as an Information RFC. 10.2 Changes to produce version 1.2, dated October 2, 1998 The following changes were made to version 1.1, dated October 1, 1998 to make version 1.2, dated October 2, 1998: 1. Removed all REFERENCE clauses since they referred to sections in the specification that were not in the MIB as requested by the IESG. 2. Moved the definitions of the attributes from the TC to a new section 3.3.8 as requested by the IESG. 3. Removed the attributes from the Table of Contents 4. Added the data types as ASN.1 comments after each attribute enum. 5. Changed a number of occurrences of "SHALL" to "is" when they were just definitions, rather than conformance requirements. 1.3 Changes to produce version 1.1, dated October 1, 1998 The following changes were made to version 1.0, dated February 3, 1998 to make version 1.1, dated October 1, 1998: 1. Clarified sections 3.3.3 and 3.3.7 so that the DEFVAL of 0 for index attributes is different from the DEFVAL for jmAttributeValueAsInteger which is -2. 2. Clarified the relationships of the values of the JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 3. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP 'media' values which are media names, media size names, and input tray names. 4. Added the two attributes approved by the PWG for registration in April 1998: mediumTypeConsumed(174) and mediumSizeConsumed(175). 5. Changed "insure" to "ensure'. 6. Correct an incorrect reference in the jmAttributeEntry DESCRIPTION from jmJobTable to jmAttributeTable. Here is the change history for V2: 1.1 Changes to produce version 2.0, dated February 20, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 2.0, dated February 20, 1999: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, and jmSystemAttrMultiRowSupport objects. 4. Changed the version number to 2.0, since a MANDATORY table was added. Tom Hastings (310) 333-6413 From imcdonal at sdsp.mc.xerox.com Mon Feb 22 21:31:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> Compile error in JMP MIB v1 - bad date stamp Message-ID: <9902230231.AA16446@appsrv5.sdsp.mc.xerox.com> Hi Tom, Monday (22 February 1999) The date stamps in the MODULE-IDENTITY macros of the JMP MIBv1 and JMP MIBv2 you posted this morning are both wrong. One (v1) also has too many digits, so it doesn't compile under the latest SMICng version. jmp_mib1.txt: LAST-UPDATED "99021910020000Z" -- , 19 February 1999 jmp_mib2.txt: LAST-UPDATED "9901290000Z" -- , 20 February 1999 We really shouldn't have incorrect date stamps in the compilable MIBs. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc From hastings at cp10.es.xerox.com Mon Mar 1 19:50:44 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-08.txt Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE8D8@x-crt-es-ms1.cp10.es.xerox.com> I'll post the .pdf files later today. Tom -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, March 01, 1999 16:01 To: IETF-Announce; @ns.cnri.reston.va.us@pwg.org Cc: pmp@pwg.org Subject: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Job Monitoring MIB - V1.0 Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis Filename : draft-ietf-printmib-job-monitor-08.txt Pages : 118 Date : 26-Feb-99 This document has been developed and approved by the Printer Working Group (PWG) as a PWG standard. It is intended to be distributed as an Informational RFC. This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-printmib-job-monitor-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: Date: Mon, 1 Mar 1999 16:03:23 -0800 Size: 1083 Url: http://www.pwg.org/archives/jmp/attachments/19990301/40367b43/attachment.mht From hastings at cp10.es.xerox.com Tue Mar 2 13:42:52 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> RESEND: I have posed the V1 and V2 PWG Job Monitoring MIB specifi cations as agreed Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE976@x-crt-es-ms1.cp10.es.xerox.com> I have updated the .doc and .pdf files to agree with the .txt file that I sent to the IETF and was posted for version 1.0. I have also updated the .doc and .pdf files for version 2.0. I did not change the file names. The only changes in these documents was to fix the date. Many places still had 1998, not 1999. The .txt and .mib files remain unchanged (they had the correct dates in them). Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, February 22, 1999 01:14 To: jmp Subject: JMP> I have posed the V1 and V2 PWG Job Monitoring MIB specifications as agreed The V1 spec is ready to send to the IETF as an Internet-Draft and request the IESG to publish as an Informational RFC. As agreed, we will call this V1.0, not V1.3, even though the PWG has had an older version that we called V1.0 in February 1998 [sic] and made it an Internet-Draft (draft-ietf-printmib-job-monitor-07.txt). The V1.0 spec does not have either the Mirror Table or the System Table. The V2 spec has the OPTIONAL Mirror Table and the MANDATORY System Table that shows which attributes are supported and how. We should hold off on making V2 and Internet-Draft so as not to confuse the IETF. The V1 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/draft-ietf-printmib-job-monitor- 08.txt ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito r-08.txt The V2 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.txt Both V1 and V2 compile with three compilers. Here is the change history for V1: 10.1 Changes to produce version 1.0, dated February 19, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.0 [sic], dated January 28, 1999: 1. Changed the version number back to 1.0 for this INTERNET-DRAFT in anticipation of its being published as an Information RFC. 10.2 Changes to produce version 1.2, dated October 2, 1998 The following changes were made to version 1.1, dated October 1, 1998 to make version 1.2, dated October 2, 1998: 1. Removed all REFERENCE clauses since they referred to sections in the specification that were not in the MIB as requested by the IESG. 2. Moved the definitions of the attributes from the TC to a new section 3.3.8 as requested by the IESG. 3. Removed the attributes from the Table of Contents 4. Added the data types as ASN.1 comments after each attribute enum. 5. Changed a number of occurrences of "SHALL" to "is" when they were just definitions, rather than conformance requirements. 1.3 Changes to produce version 1.1, dated October 1, 1998 The following changes were made to version 1.0, dated February 3, 1998 to make version 1.1, dated October 1, 1998: 1. Clarified sections 3.3.3 and 3.3.7 so that the DEFVAL of 0 for index attributes is different from the DEFVAL for jmAttributeValueAsInteger which is -2. 2. Clarified the relationships of the values of the JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 3. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP 'media' values which are media names, media size names, and input tray names. 4. Added the two attributes approved by the PWG for registration in April 1998: mediumTypeConsumed(174) and mediumSizeConsumed(175). 5. Changed "insure" to "ensure'. 6. Correct an incorrect reference in the jmAttributeEntry DESCRIPTION from jmJobTable to jmAttributeTable. Here is the change history for V2: 1.1 Changes to produce version 2.0, dated February 20, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 2.0, dated February 20, 1999: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, and jmSystemAttrMultiRowSupport objects. 4. Changed the version number to 2.0, since a MANDATORY table was added. Tom Hastings (310) 333-6413 From rbergma at dpc.com Tue Mar 16 11:57:49 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: The latest version of the Job MIB has been posted for several weeks now without any comments. Since this latest document is not significantly different from the version previously submitted to the IETF, I do not feel that a normal "Last Call" period is necessary. However, since the IETF meeting is currently in progress, there is no point in submitting a formal request to the IETF until next week. I will submit the document to the IETF next Wednesday (March 24th) unless an objection or problem is reported prior to the end of this "Last Call" period. Also, if anyone would like more time to review the document, I will extend this "Last Call" period as required. Ron Bergman Dataproducts Corp. From imcdonal at sdsp.mc.xerox.com Tue Mar 16 12:50:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903161750.AA28630@appsrv5.sdsp.mc.xerox.com> Hi Ron, Don't the current Internet-Drafts still have the typographic errors in the MODULE-IDENTITY macros that I pointed out on the list when they were posted? At least in SMICng-98, those lines don't compile (too many digits in a UTC timestamp). I assume it's the V1.0 (pre-mirror-table) that you meant to send forward as an Informational RFC to the IESG and not the V2.0 (mirror-table, et al)? Cheers, - Ira McDonald High North Inc From rbergma at dpc.com Tue Mar 16 14:55:20 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903161750.AA28630@appsrv5.sdsp.mc.xerox.com> Message-ID: Ira, I will check with Tom on the first issue. Yes, we are trying to get the version 1.0 MIB published as an RFC as agreed over a year ago. It may be either an Informational or Experimental RFC. Ron Bergman Dataproducts Corp. On Tue, 16 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Don't the current Internet-Drafts still have the typographic > errors in the MODULE-IDENTITY macros that I pointed out on > the list when they were posted? At least in SMICng-98, > those lines don't compile (too many digits in a UTC timestamp). > > I assume it's the V1.0 (pre-mirror-table) that you meant to > send forward as an Informational RFC to the IESG and not > the V2.0 (mirror-table, et al)? > > Cheers, > - Ira McDonald > High North Inc > > From hastings at cp10.es.xerox.com Wed Mar 17 03:01:06 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85CF1AFD@x-crt-es-ms1.cp10.es.xerox.com> I fixed the date being too long BEFORE sending the .txt version to the IETF as pointed out by Ira. The current lines are: jobmonMIB MODULE-IDENTITY LAST-UPDATED "9902190000Z" ORGANIZATION "Printer Working Group (PWG)" Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Tuesday, March 16, 1999 11:55 To: Ira McDonald Cc: jmp@pwg.org; chrisw@iwl.com; lpyoung@lexmark.com Subject: Re: JMP> Job Monitoring MIB - Last Call Ira, I will check with Tom on the first issue. Yes, we are trying to get the version 1.0 MIB published as an RFC as agreed over a year ago. It may be either an Informational or Experimental RFC. Ron Bergman Dataproducts Corp. On Tue, 16 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Don't the current Internet-Drafts still have the typographic > errors in the MODULE-IDENTITY macros that I pointed out on > the list when they were posted? At least in SMICng-98, > those lines don't compile (too many digits in a UTC timestamp). > > I assume it's the V1.0 (pre-mirror-table) that you meant to > send forward as an Informational RFC to the IESG and not > the V2.0 (mirror-table, et al)? > > Cheers, > - Ira McDonald > High North Inc > > From imcdonal at sdsp.mc.xerox.com Wed Mar 17 09:40:15 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903171440.AA17629@appsrv1.sdsp.mc.xerox.com> Hi Ron, Thanks for clarifying. By the way, the PWG Job Mon MIB which was rejected by the IETF for standards track therefore CANNOT be published as 'Experimental' rather than 'Informational'. The IETF standard process reserves 'Experimental' for products of IETF-chartered working groups that are future 'standards track' (ie, Proposed Standard) products. I sure wish we could revisit the Job Mon MIB chartering with the IETF, because it is closely coupled with both IPP (same states and reasons and a superset of attributes) and Printer MIB. Would it be worth approaching Keith Moore and Patrick Faltstrom (our IETF Applications ADs)?? Cheers, - Ira McDonald From rbergma at dpc.com Wed Mar 17 10:57:14 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903171440.AA17629@appsrv1.sdsp.mc.xerox.com> Message-ID: Ira, Our original request was for the document to be an "Informational" RFC. However, Bert Wijnen proposed that it be published as "Experimental". I did query whether "Experimental" implied that the document was on the standards track. The response was - no, a protocol can move from "Experimental" to standards track, but it is not considered to be on the standards track merely due to its "Experimental" status. (This may not agree with the IETF procedure RFCs, but this was the response.) It might be worth the effort to try again for a Standards Track publication. I will draft my request for IESG consideration with this as the goal. If several of us review and work on this proposal, we may be able to put together a strong argument. (I will plan to have the initial draft to the DL early next week.) Chris and Lloyd, are you willing to present a proposal for standards track? Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Thanks for clarifying. By the way, the PWG Job Mon MIB which > was rejected by the IETF for standards track therefore CANNOT > be published as 'Experimental' rather than 'Informational'. > > The IETF standard process reserves 'Experimental' for products > of IETF-chartered working groups that are future 'standards > track' (ie, Proposed Standard) products. > > I sure wish we could revisit the Job Mon MIB chartering > with the IETF, because it is closely coupled with both > IPP (same states and reasons and a superset of attributes) > and Printer MIB. Would it be worth approaching Keith > Moore and Patrick Faltstrom (our IETF Applications ADs)?? > > Cheers, > - Ira McDonald > > From hastings at cp10.es.xerox.com Wed Mar 17 13:27:52 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85CF1B71@x-crt-es-ms1.cp10.es.xerox.com> Sounds good to me. One issue is whether to progress version 1.0 or version 2.0 on standards track? Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, March 17, 1999 07:57 To: Ira McDonald Cc: chrisw@iwl.com; jmp@pwg.org; lpyoung@lexmark.com Subject: Re: JMP> Job Monitoring MIB - Last Call Ira, Our original request was for the document to be an "Informational" RFC. However, Bert Wijnen proposed that it be published as "Experimental". I did query whether "Experimental" implied that the document was on the standards track. The response was - no, a protocol can move from "Experimental" to standards track, but it is not considered to be on the standards track merely due to its "Experimental" status. (This may not agree with the IETF procedure RFCs, but this was the response.) It might be worth the effort to try again for a Standards Track publication. I will draft my request for IESG consideration with this as the goal. If several of us review and work on this proposal, we may be able to put together a strong argument. (I will plan to have the initial draft to the DL early next week.) Chris and Lloyd, are you willing to present a proposal for standards track? Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Thanks for clarifying. By the way, the PWG Job Mon MIB which > was rejected by the IETF for standards track therefore CANNOT > be published as 'Experimental' rather than 'Informational'. > > The IETF standard process reserves 'Experimental' for products > of IETF-chartered working groups that are future 'standards > track' (ie, Proposed Standard) products. > > I sure wish we could revisit the Job Mon MIB chartering > with the IETF, because it is closely coupled with both > IPP (same states and reasons and a superset of attributes) > and Printer MIB. Would it be worth approaching Keith > Moore and Patrick Faltstrom (our IETF Applications ADs)?? > > Cheers, > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Wed Mar 17 19:12:47 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903180012.AA08795@appsrv5.sdsp.mc.xerox.com> Hi Ron, Certainly not all (or even most) Experimental RFCs eventually lead to Proposed Standard RFCs, BUT only products of IETF chartered WGs may be published as Experimental rather than Informational. The IETF has NOT chartered JMP WG and without changes to the PMP WG charter, the JMP can't be a product of the PMP WG (because it's out-of-scope). I think we were naive in trying to take JMP work forward a year ago under the Printer MIB WG charter with the IETF. If we get an actual free-standing Job Mon MIB WG charter from IETF (not so inconceivable now, in light of the IPP/1.1 goal of Proposed Standard, with which the IESG agrees), then getting published as an Experimental RFC makes good sense and is MUCH more likely than getting published (initially) as Proposed Standard. If we are not going for Informational (which RFC 2400 explicitly describes as suitable for standards from other organizations, such as the PWG) but rather Experimental, then Tom Hastings' good question about whether to publish Job Mon MIB v1.0 or v2.0 on that track is highly relevant. I personally favor publishing v2.0 as Experimental, but reducing the conformance level of the last objects added (after the mirror table itself) to Conditionally Mandatory, so that all existing v1.0 conformant implementations are fully compliant with the v2.0 text (such as the IBM implementation Harry Lewis' team built during the JMP development phase). Cheers, - Ira McDonald From rbergma at dpc.com Wed Mar 17 21:07:10 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903180012.AA08795@appsrv5.sdsp.mc.xerox.com> Message-ID: Ira, I was also very surprised when it was proposed by Bert Wijnen to publish the MIB as "Experimental" and I did question this decision. Several other IETF members also agreed that it should be "Experimental". I actually would prefer "Informational", but as long as it is published they can call it a "Dumb PWG Specification". Are you suggesting that we publish 1.0 as "Informational" and 2.0 as "Experimental" or "Standards Track"? Or only publish 2.0? The goal has been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. It may make more sense to just get 1.0 published however the IETF wants and then push for 2.0 to be standards track. Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Certainly not all (or even most) Experimental RFCs eventually > lead to Proposed Standard RFCs, BUT only products of IETF > chartered WGs may be published as Experimental rather > than Informational. The IETF has NOT chartered JMP WG > and without changes to the PMP WG charter, the JMP can't > be a product of the PMP WG (because it's out-of-scope). > > I think we were naive in trying to take JMP work forward > a year ago under the Printer MIB WG charter with the IETF. > If we get an actual free-standing Job Mon MIB WG charter > from IETF (not so inconceivable now, in light of the > IPP/1.1 goal of Proposed Standard, with which the IESG > agrees), then getting published as an Experimental RFC > makes good sense and is MUCH more likely than getting > published (initially) as Proposed Standard. > > If we are not going for Informational (which RFC 2400 > explicitly describes as suitable for standards from > other organizations, such as the PWG) but rather > Experimental, then Tom Hastings' good question about > whether to publish Job Mon MIB v1.0 or v2.0 on that > track is highly relevant. I personally favor > publishing v2.0 as Experimental, but reducing the > conformance level of the last objects added (after > the mirror table itself) to Conditionally Mandatory, > so that all existing v1.0 conformant implementations > are fully compliant with the v2.0 text (such as the > IBM implementation Harry Lewis' team built during > the JMP development phase). > > Cheers, > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Thu Mar 18 15:32:51 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903182032.AA25166@appsrv1.sdsp.mc.xerox.com> Hi Ron, Thursday (18 March 1999) I temporarily lost my mind there. Of course, we should FIRST get the full content of PWG Job Mon MIB v1.0 published as *any* kind of RFC. But it is intriguing that Bert Wijnen suggested 'Experimental'. Shall we pursue a free-standing charter for an IETF Job Mon MIB WG? Harry, do you favor this idea? We could always add the definition of standard SNMP job traps to our charter. They certainly ARE necessary to get the most utility out of the PWG Job Mon MIB. Cheers, - Ira McDonald > ---------------------------------------------------------------------- > Date: Wed, 17 Mar 1999 18:07:10 -0800 (Pacific Standard Time) > From: Ron Bergman > To: Ira McDonald > cc: chrisw@iwl.com, jmp@pwg.org, lpyoung@lexmark.com > Subject: Re: JMP> Job Monitoring MIB - Last Call > > Ira, > > I was also very surprised when it was proposed by Bert Wijnen to publish > the MIB as "Experimental" and I did question this decision. Several other > IETF members also agreed that it should be "Experimental". I actually > would prefer "Informational", but as long as it is published they can call > it a "Dumb PWG Specification". > > Are you suggesting that we publish 1.0 as "Informational" and 2.0 as > "Experimental" or "Standards Track"? Or only publish 2.0? The goal has > been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. > > It may make more sense to just get 1.0 published however the IETF wants > and then push for 2.0 to be standards track. > > Ron Bergman > Dataproducts Corp. From hastings at cp10.es.xerox.com Thu Mar 18 20:34:57 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85DF3A87@x-crt-es-ms1.cp10.es.xerox.com> Ira, I think that the Job Monitoring MIB may not need a new charter to be progressed on standard track. Lets not invoke more process than is necessary. Only if the ADs say we need to do a new charter should we do that. Here is what the IANA Home Page says about the Printer MIB WG: Tom ---------------------------------------------------------------------------- ---- Printer MIB (printmib) Last Modified: 20-Jan-98 Chair(s): Chris Wellens Llyod Young Applications Area Director(s): Keith Moore Patrik Faltstrom Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:pmp@pwg.org To Subscribe: majordomo@pwg.org In Body: In body: subscribe pmp Archive: http://www.pwg.org/hypermail/pmp/ Description of Working Group: The Printer MIB Working Group is chartered to develop a set of managed objects for networked printers. These objects will be the minimum necessary to provide the ability to monitor and control these systems, providing fault, configuration and performance management, and will be consistent with the SNMP framework and existing SNMP standards. At its discretion, the working group may also define a small number of unsolicited notifications (traps) which carry these managed objects. However, the working group recognizes that traps are used sparingly in the SNMP framework. The working group recognizes that the area of networked printers is quite diverse. However, the working group is specifically confined to defining managed objects that instrument critical information about: - printer engine - interpreters - media - input sources - output destinations - I/O interfaces Further, the working group is specifically prohibited from defining managed objects that define instrumentation about: - other marking technologies (e.g., those that mark onto film) - fonts - spooling - print job management Goals and Milestones: Done Post revised Internet-Draft. Done Submit final Internet-Draft to IESG for consideration as a Proposed Standard. Done Meet at Seattle IETF to make final review of MIB. Done Post first Internet-Draft; continue discussion. Done Post Internet-Draft. Solicit implementation experience on RFC1759. Done Post revised Internet-Draft. Done Meet at Memphis IETF for final MIB review. Jul 97 Submit Internet-Draft to IESG for consideration as a Draft Standard. Internet-Drafts: Printer MIB (334475 bytes) Job Monitoring MIB - V1.0 (257216 bytes) Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB (53394 bytes) Printer Finishing MIB (98802 bytes) Request For Comments: Printer MIB (RFC 1759) (239228 bytes) ---------------------------------------------------------------------------- ---- IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org. Return to working group directory. Return to IETF home page. -----Original Message----- From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] Sent: Thursday, March 18, 1999 12:33 To: chrisw@iwl.com; imcdonal@sdsp.mc.xerox.com; jmp@pwg.org; lpyoung@lexmark.com; rbergma@dpc.com Subject: Re: JMP> Job Monitoring MIB - Last Call Hi Ron, Thursday (18 March 1999) I temporarily lost my mind there. Of course, we should FIRST get the full content of PWG Job Mon MIB v1.0 published as *any* kind of RFC. But it is intriguing that Bert Wijnen suggested 'Experimental'. Shall we pursue a free-standing charter for an IETF Job Mon MIB WG? Harry, do you favor this idea? We could always add the definition of standard SNMP job traps to our charter. They certainly ARE necessary to get the most utility out of the PWG Job Mon MIB. Cheers, - Ira McDonald > ---------------------------------------------------------------------- > Date: Wed, 17 Mar 1999 18:07:10 -0800 (Pacific Standard Time) > From: Ron Bergman > To: Ira McDonald > cc: chrisw@iwl.com, jmp@pwg.org, lpyoung@lexmark.com > Subject: Re: JMP> Job Monitoring MIB - Last Call > > Ira, > > I was also very surprised when it was proposed by Bert Wijnen to publish > the MIB as "Experimental" and I did question this decision. Several other > IETF members also agreed that it should be "Experimental". I actually > would prefer "Informational", but as long as it is published they can call > it a "Dumb PWG Specification". > > Are you suggesting that we publish 1.0 as "Informational" and 2.0 as > "Experimental" or "Standards Track"? Or only publish 2.0? The goal has > been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. > > It may make more sense to just get 1.0 published however the IETF wants > and then push for 2.0 to be standards track. > > Ron Bergman > Dataproducts Corp. From lpyoung at lexmark.com Wed Mar 24 08:54:35 1999 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job MIB on standards track Message-ID: <199903241357.AA14658@interlock2.lexmark.com> There has been some recent discussion on the mailing list regarding the Job MIB and whether on not it should be on a standards track or not. The IETF has not been completely clear on its criteria for establishing working groups to develop protocols to go on the standards track. However, in many information conversations with Area Directors and others, Chris and I have learned that the primary concern is overall operation of the Internet. The IETF has seen a significant rise in the number of protocols and MIBs they have been requested to oversee. In order to reduce the workload the Area Directors had to be selective in where they sent their time and have chosen to only focus on items that may impact the overall operation of the Internet. The reason the IETF took an interest in the Internet Printing Protocol is that they saw it having wide ranging implications for Internet operation. If the IPP protocol was badly specified and resulted in large consumption of bandwidth, it becomes a cause for concern for the IETF. These are the types of projects and working groups they want to charter and oversee--those that will have a big impact on the overall Internet. In the case of the Job MIB, the IETF sees this largely as workgroup or LAN-specific kind of operation. The IETF does not want to invest standards time and scrutiny on these projects, as these projects do not have the impact on overall Internet operations that other protocols do. The Area Directors have seen other MIBs be tremendous commercial successes without being on the standards track. Therefore, we do not think we will be successful in introducing the Job MIB on a standards track. Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C08L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW e-mail: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From rbergma at dpc.com Wed Mar 24 11:07:32 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB, Request for Publication as an RFC Message-ID: Bert and David, The Printer Working Group has revised the Job Monitoring MIB draft, incorporating many of the changes that you have recommended. We believe that the documents are now ready to be published as RFCs. The latest drafts are available in the IETF Internet-Drafts directory as: draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) During our previous communications, you had suggested that the MIB document be published as an Experimental RFC. The PWG does not object to either an Informational or an Experimental status. The companion Mapping Recommendations document should be an Informational RFC regardless. We are requesting that you review the updated document and provide a recommendation for publication. Following your review, the PWG will submit the documents to the appropriate IETF representative for publication. A summary of the document changes: 1. All REFERENCES clauses have been removed since they referred to sections in the specification that are not within the actual MIB. This change was recommended by Bert Wijnen and Keith McCloghrie. 2. Moved the definitions of the enumerations from the Textual Convention entries in the MIB to the sections preceding the MIB. This change was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC. This change was recommended by Keith McCloghrie. 3. Added the related data types as ASN.1 comments for each enumeration in JmAttributeTypeTC. 4. Replaced the use of "SHALL" with "is" for those cases where the statement is not a conformance requirement. This change was recommended by Bert Wijnen. 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 for index attributes is different from the DEFVAL of -2 for JmAttributeValueAsInteger. 6. Clarified the relationships of the values of JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 7. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP media values of media name, media size names, and input tray names. 8. Added two new attributes, mediumTypeConsumed(174) and mediumSizeConsumed(175) to JmAttributeTypeTC. 9. Changed "insure" to "ensure". 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION clause from jmJobTable to jmAttributeTable. The PWG would like to thank you for your time and patience in this matter. For the PWG, Ron Bergman Dataproducts Corp. rbergma@dpc.com voice: 805 578 4421 fax: 805 578 4005 From moore at cs.utk.edu Wed Mar 24 11:27:13 1999 From: moore at cs.utk.edu (Keith Moore) Date: Wed May 6 13:59:59 2009 Subject: JMP> Re: Job Monitoring MIB, Request for Publication as an RFC In-Reply-To: Your message of "Wed, 24 Mar 1999 08:07:32 PST." Message-ID: <199903241627.IAA14303@astro.cs.utk.edu> I don't understand. Why is the Printer Working Group, which is not affiliated with IETF, working on documents which are marked as work items of the IETF Printer MIB working group? I'm happy to see that the PWG is asking IETF MIB experts for review of its documents, and I have no objection to the technical changes mentioned in your message. But I continue to find the apparent confusion of PWG members about the relationship of PWG with IETF working groups, quite disconcerting. Keith > Date: Wed, 24 Mar 1999 08:07:32 -0800 (Pacific Standard Time) > From: Ron Bergman > To: WIJNEN@VNET.IBM.COM, dperkins@scruznet.com > cc: jmp@pwg.org, Lloyd Young , > Chris Wellens , > Tom Hastings , > Harry Lewis , moore@cs.utk.edu, scoya@ietf.org, > Harald.Alvestrand@maxware.no, rfc-editor@isi.edu > Subject: Job Monitoring MIB, Request for Publication as an RFC > > Bert and David, > > The Printer Working Group has revised the Job Monitoring MIB draft, > incorporating many of the changes that you have recommended. We believe > that the documents are now ready to be published as RFCs. The latest > drafts are available in the IETF Internet-Drafts directory as: > > draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) > draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) > > During our previous communications, you had suggested that the MIB > document be published as an Experimental RFC. The PWG does not object > to either an Informational or an Experimental status. The companion > Mapping Recommendations document should be an Informational RFC > regardless. > > We are requesting that you review the updated document and provide a > recommendation for publication. Following your review, the PWG will > submit the documents to the appropriate IETF representative for > publication. > > A summary of the document changes: > > 1. All REFERENCES clauses have been removed since they referred to > sections in the specification that are not within the actual MIB. > This change was recommended by Bert Wijnen and Keith McCloghrie. > > 2. Moved the definitions of the enumerations from the Textual Convention > entries in the MIB to the sections preceding the MIB. This change > was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, > JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and > JmJobStateReasons4TC. This change was recommended by Keith > McCloghrie. > > 3. Added the related data types as ASN.1 comments for each enumeration > in JmAttributeTypeTC. > > 4. Replaced the use of "SHALL" with "is" for those cases where the > statement is not a conformance requirement. This change was > recommended by Bert Wijnen. > > 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 > for index attributes is different from the DEFVAL of -2 for > JmAttributeValueAsInteger. > > 6. Clarified the relationships of the values of JmJobCollationTypeTC > with the IPP "multiple-document-handling" attribute. > > 7. Clarified that the values of the mediumRequested(170) and > mediumConsumed(171) attributes may be any of the IPP media values of > media name, media size names, and input tray names. > > 8. Added two new attributes, mediumTypeConsumed(174) and > mediumSizeConsumed(175) to JmAttributeTypeTC. > > 9. Changed "insure" to "ensure". > > 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION > clause from jmJobTable to jmAttributeTable. > > > The PWG would like to thank you for your time and patience in this matter. > > > For the PWG, > > Ron Bergman > Dataproducts Corp. > rbergma@dpc.com > voice: 805 578 4421 > fax: 805 578 4005 > > From WIJNEN at VNET.IBM.COM Wed Mar 24 20:05:22 1999 From: WIJNEN at VNET.IBM.COM (Bert Wijnen) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job Monitoring MIB, Request for Publication as an RFC Message-ID: <199903241904.OAA13179@pwg.org> Ref: Your note of Wed, 24 Mar 1999 08:07:32 -0800 (Pacific St Subject: Re: Job Monitoring MIB, Request for Publication as an RFC I have it on my list of things to do. Of course,the responsible AD (APPS Area, Keith Moore or Patrik Faltstrom) mke the final decision on these documents. Dave Perkins, can you pls review this MIB for the IESG? Pls also not that Harald has moved to an IAB position and that Randy Bush is now co-AD in the Ops and Mgmt Area. Bert From rbergma at dpc.com Fri Mar 26 21:25:39 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Re: Job Monitoring MIB, Request for Publication as an RFC In-Reply-To: <199903241627.IAA14303@astro.cs.utk.edu> Message-ID: Keith, I am sorry for the confusion my email has caused regarding the Job Monitoring MIB. The Job Monitoring MIB is a work product of the IETF Printer MIB Working Group. Ron Bergman Dataproducts Corp. On Wed, 24 Mar 1999, Keith Moore wrote: > I don't understand. Why is the Printer Working Group, which is not > affiliated with IETF, working on documents which are marked as work > items of the IETF Printer MIB working group? > > I'm happy to see that the PWG is asking IETF MIB experts for review > of its documents, and I have no objection to the technical changes > mentioned in your message. But I continue to find the apparent confusion > of PWG members about the relationship of PWG with IETF working groups, > quite disconcerting. > > Keith > > > > Date: Wed, 24 Mar 1999 08:07:32 -0800 (Pacific Standard Time) > > From: Ron Bergman > > To: WIJNEN@VNET.IBM.COM, dperkins@scruznet.com > > cc: jmp@pwg.org, Lloyd Young , > > Chris Wellens , > > Tom Hastings , > > Harry Lewis , moore@cs.utk.edu, scoya@ietf.org, > > Harald.Alvestrand@maxware.no, rfc-editor@isi.edu > > Subject: Job Monitoring MIB, Request for Publication as an RFC > > > > Bert and David, > > > > The Printer Working Group has revised the Job Monitoring MIB draft, > > incorporating many of the changes that you have recommended. We believe > > that the documents are now ready to be published as RFCs. The latest > > drafts are available in the IETF Internet-Drafts directory as: > > > > draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) > > draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) > > > > During our previous communications, you had suggested that the MIB > > document be published as an Experimental RFC. The PWG does not object > > to either an Informational or an Experimental status. The companion > > Mapping Recommendations document should be an Informational RFC > > regardless. > > > > We are requesting that you review the updated document and provide a > > recommendation for publication. Following your review, the PWG will > > submit the documents to the appropriate IETF representative for > > publication. > > > > A summary of the document changes: > > > > 1. All REFERENCES clauses have been removed since they referred to > > sections in the specification that are not within the actual MIB. > > This change was recommended by Bert Wijnen and Keith McCloghrie. > > > > 2. Moved the definitions of the enumerations from the Textual Convention > > entries in the MIB to the sections preceding the MIB. This change > > was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, > > JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and > > JmJobStateReasons4TC. This change was recommended by Keith > > McCloghrie. > > > > 3. Added the related data types as ASN.1 comments for each enumeration > > in JmAttributeTypeTC. > > > > 4. Replaced the use of "SHALL" with "is" for those cases where the > > statement is not a conformance requirement. This change was > > recommended by Bert Wijnen. > > > > 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 > > for index attributes is different from the DEFVAL of -2 for > > JmAttributeValueAsInteger. > > > > 6. Clarified the relationships of the values of JmJobCollationTypeTC > > with the IPP "multiple-document-handling" attribute. > > > > 7. Clarified that the values of the mediumRequested(170) and > > mediumConsumed(171) attributes may be any of the IPP media values of > > media name, media size names, and input tray names. > > > > 8. Added two new attributes, mediumTypeConsumed(174) and > > mediumSizeConsumed(175) to JmAttributeTypeTC. > > > > 9. Changed "insure" to "ensure". > > > > 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION > > clause from jmJobTable to jmAttributeTable. > > > > > > The PWG would like to thank you for your time and patience in this matter. > > > > > > For the PWG, > > > > Ron Bergman > > Dataproducts Corp. > > rbergma@dpc.com > > voice: 805 578 4421 > > fax: 805 578 4005 > > > > > From dcarney at us.ibm.com Mon Apr 12 18:44:53 1999 From: dcarney at us.ibm.com (dcarney@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Add IPP attributes to facilitate better job monitoring? Message-ID: <87256751.007CF77D.00@d53mta08h.boulder.ibm.com> Here at IBM we have implemented a job monitoring application that uses the job MIB. In looking at IPP to see if we could do the same monitoring using IPP instead, I noticed that there are many attributes that are defined in the job MIB that aren't defined in IPP. We have found using our monitoring application that some of these missing attributes are important to be able to do accurate job monitoring. Therefore, my question is whether the IPP group should consider adding some attributes to facilitate better job monitoring. Specifically, the job MIB attributes that are missing and that I think are important: impressionsCompletedCurrentCopy jobCollationType sheetCompletedCopyNumber impressionsInterpreted Numbers 1-3 are needed to present detailed information on job status when the job contains multiple copies--for example, "Printed page 3 of 5, copy 2 of 3". Number 4 is not absolutely essential, but we have found that it is often helpful in unusual situations. It is possible that there are other missing attributes that are "important"--I'll let others bring those up if they feel the need. In doing this effort, I found Tom Hastings' document ietf-ipp.pdf on the pwg ftp site, which compares the list of attributes defined for the job MIB with the list of attributes defined for IPP. Because the document was out-of-date, I updated it and will be publishing the update to the ftp site shortly. Harry Lewis is going to bring copies of the current state of the updated document to New Orleans. Dennis Carney IBM Printing Systems Company From anthony.porter at computer.org Tue Apr 13 06:05:43 1999 From: anthony.porter at computer.org (Anthony Porter) Date: Wed May 6 13:59:59 2009 Subject: JMP> RE: IPP> Add IPP attributes to facilitate better job monitoring? In-Reply-To: <87256751.007CF77D.00@d53mta08h.boulder.ibm.com> Message-ID: <000501be8595$3263dfa0$767010ac@ntw4-ap> I agree with this. impressionsInterpreted is related to Issue #31 where the printer has a separate RIP processor. Since it may take a significant amount of time to RIP a complex document, this value is necessary if users are to have any idea as when a job might be finished. I notice that there does not seem any way to specify collation in IPP-MOD. It is mentioned in the context of multiple documents, but not for multiple copies of single documents. This is important, since many printers cannot collate at all, while others are restricted by the number of output trays. Printers with a separate RIP can collate any number of copies. job-collation ought to be a job template attribute, so that the printer can specify whether it supports collation, and the maximum number of copies it can collate. Certain jobs ought not to be collated, even if the printer can do so. At present the user has no idea whether a job of 500 copies will be collated or not. Anthony Porter -----Original Message----- From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of dcarney@us.ibm.com Sent: Tuesday, 13 April, 1999 12:45 AM To: ipp@pwg.org; jmp@pwg.org Cc: harryl@us.ibm.com; hastings@cp10.es.xerox.com Subject: IPP> Add IPP attributes to facilitate better job monitoring? Here at IBM we have implemented a job monitoring application that uses the job MIB. In looking at IPP to see if we could do the same monitoring using IPP instead, I noticed that there are many attributes that are defined in the job MIB that aren't defined in IPP. We have found using our monitoring application that some of these missing attributes are important to be able to do accurate job monitoring. Therefore, my question is whether the IPP group should consider adding some attributes to facilitate better job monitoring. Specifically, the job MIB attributes that are missing and that I think are important: impressionsCompletedCurrentCopy jobCollationType sheetCompletedCopyNumber impressionsInterpreted Numbers 1-3 are needed to present detailed information on job status when the job contains multiple copies--for example, "Printed page 3 of 5, copy 2 of 3". Number 4 is not absolutely essential, but we have found that it is often helpful in unusual situations. It is possible that there are other missing attributes that are "important"--I'll let others bring those up if they feel the need. In doing this effort, I found Tom Hastings' document ietf-ipp.pdf on the pwg ftp site, which compares the list of attributes defined for the job MIB with the list of attributes defined for IPP. Because the document was out-of-date, I updated it and will be publishing the update to the ftp site shortly. Harry Lewis is going to bring copies of the current state of the updated document to New Orleans. Dennis Carney IBM Printing Systems Company From imcdonal at sdsp.mc.xerox.com Mon Apr 19 20:01:40 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> RFC 2578/2579/2580 - new SMIv2 standards Message-ID: <199904200001.UAA15043@appsrv5.sdsp.mc.xerox.com> Hi folks, These RFCs now OBSOLETE the old RFC 1902/1903/1904 version of SMIv2. Should be read closely. Note that David Perkins (of SMIC/SMICng fame) is one of the co-editors of the new SMIv2 specs. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc From dcarney at us.ibm.com Tue Apr 27 17:00:35 1999 From: dcarney at us.ibm.com (dcarney@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Updated comparison of job mib attributes with IPP attributes Message-ID: <87256760.007369B6.00@d53mta08h.boulder.ibm.com> As promised a while back, I have posted to the ftp site an update of the comparison between the job attributes defined in the job mib and those in IPP. ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11.pdf ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11.doc ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11-rev .pdf ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11-rev .doc (Note: I was not sure of the comparison between JMP and IPP in terms of natural language issues, so I marked those few attributes as "???".) Dennis Carney IBM Printing Systems Company; (303)924-0565 From csibr at ibm.net Wed Jun 9 14:23:54 1999 From: csibr at ibm.net (Edu) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job / Printer Staus monitoring Message-ID: <01BEB28C.195132F0@EDU_FREIRE> I am sorry if this is not the correct recipient for questions like this ! The information I need is how can I monitor printer job status(printing, printed succesfully, not printed due errors, ... and printer status (online, paper jam, ...) using MIB II and SNMP ? Thanks in advance, Eduardo. From hastings at cp10.es.xerox.com Wed Jun 9 19:29:26 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB1E2@x-crt-es-ms1.cp10.es.xerox.com> The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From hastings at cp10.es.xerox.com Wed Jun 9 19:41:02 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB1E6@x-crt-es-ms1.cp10.es.xerox.com> Does anyone have any more technical reasons from the IESG as to why they don't like the attribute structure that we have in the PWG Job Monitoring MIB? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 16:29 To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Angelo.Caruso at usa.xerox.com Thu Jun 10 08:53:37 1999 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <3654E69400ADD211A3A400805FA7CE24083468@usa0111ms2.eng.mc.xerox.com> Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From jkm at underscore.com Thu Jun 10 09:10:41 1999 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional References: <3654E69400ADD211A3A400805FA7CE24083468@usa0111ms2.eng.mc.xerox.com> Message-ID: <375FB951.52D6F84F@underscore.com> Angelo, Excellent suggestion about publishing an explanation of the information model for the Job MIB prior to publishing the actual MIB document itself. Perhaps such a document would have helped the rest of the PWG understand this creature called the Job MIB, too. (Just a guess, though.) ...jay "Caruso, Angelo" wrote: > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just went ahead and > implemented the first instance of this new model, all in one MIB module. > Perhaps we should have published a generic definition of the new model first > as a stand-alone document, and then published the JMP MIB as an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > an > Informational RFC. However, the IESG doesn't approve of our modeling of > management information. By this I assume they mean the attribute mechanism > that we invented to handle the great variability between implementations. > > They also don't recognize the PWG as a standards making body according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. From rbergma at dpc.com Thu Jun 10 10:57:11 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional In-Reply-To: <375FB951.52D6F84F@underscore.com> Message-ID: Angelo, I agree with Jay and propose that work on this paper start immediately. Very good suggestion! Ron Bergman Hitachi Koki Imaging Solutions On Thu, 10 Jun 1999, Jay Martin wrote: > Angelo, > > Excellent suggestion about publishing an explanation of the > information model for the Job MIB prior to publishing the > actual MIB document itself. > > Perhaps such a document would have helped the rest of the PWG > understand this creature called the Job MIB, too. > (Just a guess, though.) > > ...jay > > > "Caruso, Angelo" wrote: > > > > Tom, > > > > Perhaps the IETF is taking issue with the fact that we invented a new > > information model, built on top of SNMP/SMI, and then just went ahead and > > implemented the first instance of this new model, all in one MIB module. > > Perhaps we should have published a generic definition of the new model first > > as a stand-alone document, and then published the JMP MIB as an example > > implementation. > > > > Thanks, > > Ang > > > > -----Original Message----- > > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > > Sent: Wednesday, June 09, 1999 7:29 PM > > To: jmp > > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > > Informational > > > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > > an > > Informational RFC. However, the IESG doesn't approve of our modeling of > > management information. By this I assume they mean the attribute mechanism > > that we invented to handle the great variability between implementations. > > > > They also don't recognize the PWG as a standards making body according to > > the note. > > > > Tom > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: Wednesday, June 09, 1999 3:02 PM > > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > > as an Informational RFC. This > > document is the product of the Printer MIB Working Group. The IESG > > contact persons are Keith Moore and Patrik Faltstrom > > > > Note to RFC Editor: > > > > The IESG requests the following text be included as an IESG Note: > > > > This MIB module uses an unconventional scheme for modeling > > management information (on top of the SNMP model) which is unique to > > this MIB. The IESG recommends against using this document as an > > example for the design of future MIBs. > > > > The "Printer Working Group" industry consortium is not an IETF > > working group, and the IETF does not recognize the Printer Working > > Group as a standards-setting body. This document is being published > > solely to provide information to the Internet community regarding a > > MIB that might be deployed in the marketplace. Publication of > > this document as an RFC is not an endorsement of this MIB. > From hastings at cp10.es.xerox.com Thu Jun 10 14:54:46 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB29C@x-crt-es-ms1.cp10.es.xerox.com> Joe, What about the Job Monitoring MIB V2 that has the attribute support bit vector and the mirror table? Don't they solve your problem? I would assume that such a paper would also include the description of Job Monitoring MIB V2 as well. Thanks, Tom -----Original Message----- From: Filion, Joseph L Sent: Thursday, June 10, 1999 11:51 To: Caruso, Angelo; Hastings, Tom N Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Joe.Filion at usa.xerox.com Thu Jun 10 14:51:13 1999 From: Joe.Filion at usa.xerox.com (Filion, Joseph L) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911012A8753@USA0834MS1> Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Joe.Filion at usa.xerox.com Fri Jun 11 08:18:17 1999 From: Joe.Filion at usa.xerox.com (Filion, Joseph L) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911012A8756@USA0834MS1> Tom (and Ang), Yes, the attribute support bit vector and the mirror table do go a long way towards solving our problem. I guess I understood Angelo's proposal to mean that a description of the structure of the model would be written independent of an instance of that model; so I wouldn't expect to see a description of the Job Monitoring MIB V2 in that description. Would you think the paper being proposed would include descriptions of the attribute vector and mirror tables? JLF -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, June 10, 1999 2:55 PM To: Filion, Joseph L; Caruso, Angelo Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Joe, What about the Job Monitoring MIB V2 that has the attribute support bit vector and the mirror table? Don't they solve your problem? I would assume that such a paper would also include the description of Job Monitoring MIB V2 as well. Thanks, Tom -----Original Message----- From: Filion, Joseph L Sent: Thursday, June 10, 1999 11:51 To: Caruso, Angelo; Hastings, Tom N Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From rbergma at dpc.com Fri Jun 11 10:55:16 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional In-Reply-To: <61E69E92EA1CD211B94700805F65B911012A8756@USA0834MS1> Message-ID: Joe, I agree with your conslusion that this paper should only describe the attribute model. The statement from Tom, that you replied to, appears to imply that this paper would be more of a description of the Job Monitoring MIB model. The Job MIB model appears to adequately covered in the MIB document. But the background and rationale for the attribute objects are not. I have started such a paper and will try to post this initial draft next week. Ron Bergman Hitachi Koki Imaging Solutions On Fri, 11 Jun 1999, Filion, Joseph L wrote: > Tom (and Ang), > > Yes, the attribute support bit vector and the mirror table do go a long way > towards solving our problem. I guess I understood Angelo's proposal to mean > that a description of the structure of the model would be written > independent of an instance of that model; so I wouldn't expect to see a > description of the Job Monitoring MIB V2 in that description. Would you > think the paper being proposed would include descriptions of the attribute > vector and mirror tables? > > JLF > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Thursday, June 10, 1999 2:55 PM > To: Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Joe, > > What about the Job Monitoring MIB V2 that has the attribute support bit > vector and the mirror table? Don't they solve your problem? > > I would assume that such a paper would also include the description of Job > Monitoring MIB V2 as well. > > Thanks, > Tom > > -----Original Message----- > From: Filion, Joseph L > Sent: Thursday, June 10, 1999 11:51 > To: Caruso, Angelo; Hastings, Tom N > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom and Ang, > > Maybe publishing a separate stand-alone document describing the new model > would help (or would have helped), but let's not loose sight of some of the > real issues with the model itself. One issue that continues to bother me is > if you want to get all the information that a printer knows about a job it > is real easy to get from a MIB that uses this model; but if you want to get > two or three specific attributes for all of the jobs, it is very difficult > to do efficiently with this model. Let's face it, we can all think of > management side applications that want to do exactly this, and they cannot > be done without retrieving every bit of data from the table. I am not > saying that this model is not without its merit; I would just like to make > sure that all the pros and cons are on the table. > > Thanks, > JLF > > -----Original Message----- > From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] > Sent: Thursday, June 10, 1999 8:54 AM > To: Hastings, Tom N; jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just went ahead and > implemented the first instance of this new model, all in one MIB module. > Perhaps we should have published a generic definition of the new model first > as a stand-alone document, and then published the JMP MIB as an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > an > Informational RFC. However, the IESG doesn't approve of our modeling of > management information. By this I assume they mean the attribute mechanism > that we invented to handle the great variability between implementations. > > They also don't recognize the PWG as a standards making body according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. > From rbergma at dpc.com Thu Jun 24 16:23:59 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> PMP> Document Action: Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB to Informational (fwd) Message-ID: Thanks to all who worked to make this happen. We finally completed this effort! Ron Bergman Hitachi Koki Imaging Solutions ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 07:07:59 -0400 From: The IESG To: IETF-Announce: ;, ";;"@ns.cnri.reston.va.us, pwg.org@mailgate.dpc.com, "dpc.com;"@unspecified-domain Cc: RFC Editor , Internet Architecture Board , pmp@pwg.org Subject: PMP> Document Action: Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB to Informational The IESG has approved the Internet-Draft 'Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB' as a Informational. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom From Mike.Elvers at usa.xerox.com Fri Jun 25 16:08:31 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023DC@USA0834MS1> Tom (and Ang), I disagree with Joe that these extra tables "go a long way" towards solving our problems. I only see them solving a narrow problem of being able to acquire a column of data (the same attribute for multiple jobs). This in not what we do in the normal course of monitoring a single job. We acquire rows of data and the mirror table does nothing to help that problem. The support bit vector provides a small degree of help in that we know for sure which attributes NOT to look for. It is no guarantee that a given attribute actually does exist though. Mike > -----Original Message----- > From: Filion, Joseph L > Sent: Friday, June 25, 1999 2:00 PM > To: Elvers, Mike > Subject: FW: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > > > -----Original Message----- > From: Filion, Joseph L > Sent: Friday, June 11, 1999 8:18 AM > To: Hastings, Tom N; Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom (and Ang), > > Yes, the attribute support bit vector and the mirror table do > go a long way towards solving our problem. I guess I > understood Angelo's proposal to mean that a description of > the structure of the model would be written independent of an > instance of that model; so I wouldn't expect to see a > description of the Job Monitoring MIB V2 in that description. > Would you think the paper being proposed would include > descriptions of the attribute vector and mirror tables? > > JLF > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Thursday, June 10, 1999 2:55 PM > To: Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Joe, > > What about the Job Monitoring MIB V2 that has the attribute > support bit > vector and the mirror table? Don't they solve your problem? > > I would assume that such a paper would also include the > description of Job > Monitoring MIB V2 as well. > > Thanks, > Tom > > -----Original Message----- > From: Filion, Joseph L > Sent: Thursday, June 10, 1999 11:51 > To: Caruso, Angelo; Hastings, Tom N > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom and Ang, > > Maybe publishing a separate stand-alone document describing > the new model > would help (or would have helped), but let's not loose sight > of some of the > real issues with the model itself. One issue that continues > to bother me is > if you want to get all the information that a printer knows > about a job it > is real easy to get from a MIB that uses this model; but if > you want to get > two or three specific attributes for all of the jobs, it is > very difficult > to do efficiently with this model. Let's face it, we can all think of > management side applications that want to do exactly this, > and they cannot > be done without retrieving every bit of data from the table. I am not > saying that this model is not without its merit; I would just > like to make > sure that all the pros and cons are on the table. > > Thanks, > JLF > > -----Original Message----- > From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] > Sent: Thursday, June 10, 1999 8:54 AM > To: Hastings, Tom N; jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just > went ahead and > implemented the first instance of this new model, all in one > MIB module. > Perhaps we should have published a generic definition of the > new model first > as a stand-alone document, and then published the JMP MIB as > an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > > The PWG Job Monitoring MIB has been approved by the IESG to > be sent out as > an > Informational RFC. However, the IESG doesn't approve of our > modeling of > management information. By this I assume they mean the > attribute mechanism > that we invented to handle the great variability between > implementations. > > They also don't recognize the PWG as a standards making body > according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational > RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is > unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being > published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. > From imcdonal at sdsp.mc.xerox.com Sat Jun 26 15:53:49 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <199906261953.PAA10451@appsrv5.sdsp.mc.xerox.com> Hi Mike, (don't throw stones yet...) What if we added a bit vector to EACH job that says 'one or more instances of this job attribute are CURRENTLY instantiated on this job'? Maintaining this bit vector (a parallel subset of the support vector at all times) doesn't seem that costly to an agent and it *seems* to help with your concerns. Thoughts? - Ira McDonald From rbergma at dpc.com Mon Jun 28 11:39:30 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From rbergma at dpc.com Mon Jun 28 11:39:50 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Mon Jun 28 13:25:46 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: <918C79AB552BD211A2BD00805F15CE8501673345@x-crt-es-ms1.cp10.es.xerox.com> I'll make those changes with the RFC Editor. Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, June 28, 1999 08:40 To: Tom Hastings Cc: jmp@pwg.org Subject: JMP> Job MIB Editorial Changes Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From rbergma at dpc.com Mon Jun 28 16:14:13 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:59 2009 Subject: JMP> Editorial Changes to the Job MIB Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From Mike.Elvers at usa.xerox.com Tue Jun 29 09:40:40 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E2@USA0834MS1> Ira, This isn't exactly a stone, more like a pebble, but, how may more bit vectors do we need to add before we throw up the white flag and say this attribute method of MIB specification was not a good idea? I can immediately come up with at least one more useful bit vector. This one will let us know which attributes actually are currently multi-instanced. Of course none of the bit vectors is ever going to answer the question "What is the meaning (significance, point, ???) of each instance without any given or know previous knowledge?". Mike > -----Original Message----- > From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] > Sent: Saturday, June 26, 1999 3:54 PM > To: Joe.Filion@usa.xerox.com; Mike.Elvers@usa.xerox.com > Cc: Angelo.Caruso@usa.xerox.com; hastings@cp10.es.xerox.com; > jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Hi Mike, > > (don't throw stones yet...) What if we added a bit vector to EACH > job that says 'one or more instances of this job attribute are > CURRENTLY instantiated on this job'? Maintaining this bit vector > (a parallel subset of the support vector at all times) doesn't > seem that costly to an agent and it *seems* to help with your > concerns. > > Thoughts? > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Tue Jun 29 10:53:24 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <199906291453.KAA22533@appsrv5.sdsp.mc.xerox.com> Hi Mike, OK - I see that you don't want to get a useful method for accessing attribute-based MIBs. I think this is unfortunate, because (among other things) LDAP and SLP are becoming common in deployment and they have 'open-ended' objects which have a (few) Mandatory attributes and a (lot of) Optional attributes. My work in the XCMI Comms Config MIB since last December on the Comms Directory Record and Comms Directory Attribute/String tables allows a direct representation in the MIB of an LDAP or SLP 'named object' with a bunch of attributes. We can't possibly constrain the accesses of Xerox network devices to rigid sets of mandatory attributes in LDAP objects, so I was hoping for more refinement to arise here on the PWG Job Mon MIB that was useful in the XCMI CC Directory, HRX Device Detail, and Svc Mon Service Detail applications. I realize that 'jobs' (because they are very dynamic in their attributes present and attribute values over short intervals) are quite different from essentially all 'resource' objects (servers, repositories, etc). There are many more 'jobs' of interest and they have to be presented to the end user in a GUI because they ARE dynamic. I hope we can work to make use of the HRX and Svc Mon Detail groups and the newer CC Directory groups as useful as possible to SNMP agent implementors as well as native and Web client implementors. Cheers, - Ira From Mike.Elvers at usa.xerox.com Tue Jun 29 14:25:59 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E4@USA0834MS1> Ira, You know better than that! Of course I want to make MIBs USEFUL. However, continuing to put bandaides on a bleeding patient does not make that patient well. There are some serious peformance and usability issues with this approach for doing job monitoring which I feel obligated to point out. For example, as of yet, no one has addressed the issue of the semantics of having multiple values. It won't do any good to just harp at me. My concerns warrent being addressed in a profession and civilized manner! Mike > -----Original Message----- > From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] > Sent: Tuesday, June 29, 1999 10:53 AM > To: Joe.Filion@usa.xerox.com; Mike.Elvers@usa.xerox.com; > imcdonal@sdsp.mc.xerox.com > Cc: Angelo.Caruso@usa.xerox.com; hastings@cp10.es.xerox.com; > jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Hi Mike, > > OK - I see that you don't want to get a useful method for > accessing attribute-based MIBs. I think this is unfortunate, > because (among other things) LDAP and SLP are becoming common > in deployment and they have 'open-ended' objects which have a > (few) Mandatory attributes and a (lot of) Optional attributes. > > My work in the XCMI Comms Config MIB since last December on > the Comms Directory Record and Comms Directory Attribute/String > tables allows a direct representation in the MIB of an LDAP > or SLP 'named object' with a bunch of attributes. We can't > possibly constrain the accesses of Xerox network devices to > rigid sets of mandatory attributes in LDAP objects, so I was > hoping for more refinement to arise here on the PWG Job Mon > MIB that was useful in the XCMI CC Directory, HRX Device Detail, > and Svc Mon Service Detail applications. > > I realize that 'jobs' (because they are very dynamic in their > attributes present and attribute values over short intervals) > are quite different from essentially all 'resource' objects > (servers, repositories, etc). There are many more 'jobs' > of interest and they have to be presented to the end user > in a GUI because they ARE dynamic. > > I hope we can work to make use of the HRX and Svc Mon Detail > groups and the newer CC Directory groups as useful as possible > to SNMP agent implementors as well as native and Web client > implementors. > > Cheers, > - Ira > > From harryl at us.ibm.com Tue Jun 29 17:38:56 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <8725679F.0076F9A6.00@d53mta05h.boulder.ibm.com> The Job MIB is working just fine for us. Harry Lewis IBM Printing Systems harryl@us.ibm.com From Mike.Elvers at usa.xerox.com Tue Jun 29 17:44:34 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 13:59:59 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E8@USA0834MS1> Harry, I'm glad to here that. However, I would have to know how you are using it before I could reach any conclusions. Are you prepared to discuss details about your client implementation? Mike > -----Original Message----- > From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > Sent: Tuesday, June 29, 1999 5:39 PM > To: Elvers, Mike > Cc: 'Ira McDonald'; Filion, Joseph L; Elvers, Mike; Caruso, Angelo; > Hastings, Tom N; jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > > > The Job MIB is working just fine for us. > > Harry Lewis > IBM Printing Systems > harryl@us.ibm.com > > From hastings at cp10.es.xerox.com Fri Jul 30 17:09:24 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> 25-word Abstract for PWG Job Monitoring MIB for my MFPA Presentat ion, Oct 26 Message-ID: <918C79AB552BD211A2BD00805F15CE850198E959@x-crt-es-ms1.cp10.es.xerox.com> Ray, Here is the 25-word Abstract for the PWG Job Monitoring MIB for my MFPA session presentation, October 26, in Boston: "The PWG Job Monitoring MIB is an approved Printer Working Group standard that allows monitoring of jobs using SNMP for any job submission protocol". Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Thursday, July 29, 1999 17:42 To: Raymond Lutz Cc: Hastings, Tom N; Rahgozar, Armon; bwagner@digprod.com; Harry Lewis Subject: Re: I'll present Job MIB and IPP; but conflict with IPP Presentation and IPP meeting Raymond, Here is an abstract for the Finisher MIB: "The Finisher MIB is a proposed extension to the Printer MIB (RFC1759) that allows management of printer finishing device subunits using SNMP." Ron On Thu, 29 Jul 1999, Raymond Lutz wrote: > Tom: > I've reorganized the sessions so that the guys that would be best as > speakers won't be in conflict with the PWG as much as possible, and > included your sessions. Please provide a 25-word abstract of each one ASAP. > Thanks for your help! > -raymond > From hastings at cp10.es.xerox.com Wed Oct 6 04:05:45 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:59 2009 Subject: JMP> Slides describing the PWG Job Monitoring MIB have been posted Message-ID: <918C79AB552BD211A2BD00805F15CE8501ECDDC1@x-crt-es-ms1.cp10.es.xerox.com> I've posted a set of slides (27) that describe the PWG Job Monitoring MIB. I will be presenting these slides at the MFPA IOC Conference in Boston, on October 25-26. It gives an overview of the PWG Job Monitoring MIB. The slides are available locally at: ftp://ftp.pwg.org/pub/pwg/jmp/slides/CAP-MFPA-1999-pwg-job-monitoring-mib.pp t Tom From imcdonal at sdsp.mc.xerox.com Sun Oct 10 22:59:25 1999 From: imcdonal at sdsp.mc.xerox.com (Ira Mcdonald) Date: Wed May 6 13:59:59 2009 Subject: JMP> NOT - IPP Notify over SNMP (extension to PWG Job Mon MIB) Message-ID: <199910110259.WAA28029@appsrv1.sdsp.mc.xerox.com> Hi folks, Sunday (10 October 1999) I've just posted a short I-D style document (15 pages, of which 4 matter) that maps IPP Notifications over SNMP via two new traps (Printer and Job) to be added to the PWG Job Monitoring MIB: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-over-snmp-991010.txt Comments are welcome (I'll be away from my email for the next week, so don't mind if I don't reply right away). Cheers, - Ira McDonald High North Inc From harryl at us.ibm.com Tue Nov 23 10:47:53 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:59 2009 Subject: JMP> Re: PWG-ANNOUNCE> Job Monitoring MIB now Available Message-ID: <87256832.0056D038.00@d53mta05h.boulder.ibm.com> Wonderful! We do not see the need for the mirror table but will consider supporting it's future inclusion if it means greater chance for wider adoption of the standard. Harry Lewis IBM Printing Systems Ron Bergman Sent by: owner-pwg-announce@pwg.org 11/22/99 04:36 PM To: pwg-announce@pwg.org cc: Subject: PWG-ANNOUNCE> Job Monitoring MIB now Available The Job Monitoring MIB is now available as RFC2707.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2707.txt The companion mapping document has also been published as RFC2708.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2708.txt The official announcement should be made by the IETF in the next day or so. (But I couldn't wait ;-) Thanks again to everyone who helped make this happen! We now need to determine if there is sufficient interest to pursue the addition of the Xerox Attribute Mirror table and any other updates. Please reply if this subject is of interest or if you strongly object to any further Job MIB work. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Tue Nov 23 17:57:11 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:00 2009 Subject: JMP> FW: PWG-ANNOUNCE> Job Monitoring MIB now Available [RFC 2707 and 2708; reference to mirror table and traps] Message-ID: <918C79AB552BD211A2BD00805F15CE8502514709@x-crt-es-ms1.cp10.es.xerox.com> We're supposed to discuss announcements on the specific list that deals with the subject. So here is Ira's comments on the JMP Announcement. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, November 22, 1999 19:02 To: 'Ron Bergman'; pwg-announce@pwg.org Subject: RE: PWG-ANNOUNCE> Job Monitoring MIB now Available Hi Ron, I saw this a few minutes after it was posted this morning, but resisted the urge to announce it to JMP (knowing you were watching the status as JMP WG chair). Hooray! Although I'm no longer working with Xerox (well...mostly), I support work on the Mirror Attribute group. I *think* there will be interest here at Sharp in the Mirror Attribute group (because it addresses the problems of data modelling different from traditional SNMP MIBs that caused the little IESG disclaimer on page 1 of RFC 2707 *and* because it addresses performance problems identified with Job Mon MIB v1.0). I'd also like to remind folks that the current work on IPP Notifications over SNMP consists (at the suggestion of Ron Bergman) of a small extension to the Job Mon MIB to add two traps and a few leaf objects for the trap bindings. As this work matures in the IPP WG, we will want to update the Job Mon MIB text to incorporate it I think - although it *could* be published as a separate compilable extension (since the changes are wholly in new object and notification groups). Cheers, - Ira McDonald High North -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, November 22, 1999 3:36 PM To: pwg-announce@pwg.org Subject: PWG-ANNOUNCE> Job Monitoring MIB now Available The Job Monitoring MIB is now available as RFC2707.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2707.txt The companion mapping document has also been published as RFC2708.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2708.txt The official announcement should be made by the IETF in the next day or so. (But I couldn't wait ;-) Thanks again to everyone who helped make this happen! We now need to determine if there is sufficient interest to pursue the addition of the Xerox Attribute Mirror table and any other updates. Please reply if this subject is of interest or if you strongly object to any further Job MIB work. Ron Bergman Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Wed Dec 1 21:43:17 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Message-ID: <4BB1E365BF26D311914A00805FA6A1C1264BCA@admsrvnt02> Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From products at newideas-inventions.com Tue Dec 7 16:18:48 1999 From: products at newideas-inventions.com (Don Fass) Date: Wed May 6 14:00:00 2009 Subject: JMP> Important Notice for Prototypers and Professionals in Related Fields Message-ID: <419.436501.67651296products@newideas-inventions.com> Http://www.newideas-inventions.com Dear Prototypers, New Ideas is recognized worldwide as a company able to help you lockup that product line, expand the amount of the order, then provide your organization with consistent repeat residuals infinitum. Your client will learn how to distribute his own proprietary product all over the world from his bedroom in his shorts. Yes, he will benefit from speaking to us. But just as importantly, so will YOU. Moreover, we have ways to influence venture capital acquisition. So, do you have a client with an invention that needs to be launched? We have the designers, prototypers and fabricators able to launch new products instantly, affordably and differently. We naturally see all the new inventions from their embryo stage. As the leading new product development and marketing firm in America, we have an amazing track-record in many fields for example: OraFresh – the amazing tongue cleaner that eliminates bad breath, 44 years ago I launched that famous Adjustable Table that today rolls over each and every hospital bed in the world - at least two in every room; 4.1 million Love Ring sales; countless Photo Wristwatches sold. We developed and marketed the Desert Storm T-shirt, the Christopher Columbus Quincentennial; 1.2 million Black Last Suppers and 7.6 million Panic Button Carbon Monoxide Detectors. Profitably yours, Don Fass http://www.newideas-inventions.com If this information is of no interest to you and you wish your address removed, kindly send an email to products@newideas-inventions.com P.S. For those who are receiving a duplicate message we apologize. New Ideas Staff From hastings at cp10.es.xerox.com Mon Dec 13 14:38:59 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:00 2009 Subject: JMP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [.pdf post ed] Message-ID: <918C79AB552BD211A2BD00805F15CE85025150E5@x-crt-es-ms1.cp10.es.xerox.com> I've posted the .pdf version of the I-D as requested (with line numbers added): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.pdf Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, December 10, 1999 13:05 To: imcdonald@sharplabs.com Cc: ipp@pwg.org Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Ira: Could you create a PDF version of this document? When printed using a browser, all the page breaks are messed up making it very hard to read. Thanks! ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** imcdonald%sharplabs.com@interlock.lexmark.com on 12/06/99 07:49:42 PM To: cmanros%cp10.es.xerox.com@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Hi folks, Monday (6 December 1999) URLs for our revised 'IPP Notifications over SNMP' (1 Dec 1999): ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-over-snmp-01.txt or ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt This document supports full-fidelity IPP notifications over SNMP (any version of SNMP) by defining new printer and job traps for the existing PWG Job Monitoring MIB (RFC 2707, November 1999). Cheers, - Ira McDonald (High North Inc, consultant at Sharp Labs America) Tom Hastings (Xerox Corporation) -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, December 06, 1999 4:25 PM To: IETF-IPP Subject: IPP> ADM - IPP Phone Conference December 8, 1999 IPP Phone Conference - 991103 ============================= We will hold our next IPP phone conference on Wednesday, December 8. We will discuss the following subjects: - Latest input on the Set 2 and Set 3 Optional Operations - Latest input on the IPP Notifications - Nail the Agenda for the IPP meeting in LA next week A number of people registered late, but it looks like we will have some 20 people attending the IPP meeting. Here is the dial-in information: Time: December 8, 1999 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-888-749-8496 (8*534-8273 for Xerox folks) Passcode: 86037# Carl-Uno Carl-Uno Manros Principal Engineer - Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, December 01, 1999 18:43 To: 'ipp@pwg.org'; 'jmp@pwg.org' Cc: McDonald, Ira Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Dec 13 16:46:03 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [ .pdf post ed] Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FE9A@MAILSRVNT02> Hi folks, Thanks, Tom, for distilling this document into PDF for me. In the IPP WG meeting this week and in email notes, please make any comments on the line-numbered PDF version (which faithfully follows the text version in pagination and lines per page). Cheers, - Ira McDonald (outside consultant at Sharp) High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, December 13, 1999 11:39 AM To: don@lexmark.com; imcdonald@sharplabs.com Cc: ipp@pwg.org; jmp Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [.pdf post ed] I've posted the .pdf version of the I-D as requested (with line numbers added): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.pdf Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, December 10, 1999 13:05 To: imcdonald@sharplabs.com Cc: ipp@pwg.org Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Ira: Could you create a PDF version of this document? When printed using a browser, all the page breaks are messed up making it very hard to read. Thanks! ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** imcdonald%sharplabs.com@interlock.lexmark.com on 12/06/99 07:49:42 PM To: cmanros%cp10.es.xerox.com@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Hi folks, Monday (6 December 1999) URLs for our revised 'IPP Notifications over SNMP' (1 Dec 1999): ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-over-snmp-01.txt or ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt This document supports full-fidelity IPP notifications over SNMP (any version of SNMP) by defining new printer and job traps for the existing PWG Job Monitoring MIB (RFC 2707, November 1999). Cheers, - Ira McDonald (High North Inc, consultant at Sharp Labs America) Tom Hastings (Xerox Corporation) -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, December 06, 1999 4:25 PM To: IETF-IPP Subject: IPP> ADM - IPP Phone Conference December 8, 1999 IPP Phone Conference - 991103 ============================= We will hold our next IPP phone conference on Wednesday, December 8. We will discuss the following subjects: - Latest input on the Set 2 and Set 3 Optional Operations - Latest input on the IPP Notifications - Nail the Agenda for the IPP meeting in LA next week A number of people registered late, but it looks like we will have some 20 people attending the IPP meeting. Here is the dial-in information: Time: December 8, 1999 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-888-749-8496 (8*534-8273 for Xerox folks) Passcode: 86037# Carl-Uno Carl-Uno Manros Principal Engineer - Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, December 01, 1999 18:43 To: 'ipp@pwg.org'; 'jmp@pwg.org' Cc: McDonald, Ira Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Dec 21 18:31:49 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> Final edits to Printer MIB v2 - fix broken names Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEB0@MAILSRVNT02> Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 22 11:27:44 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68D8@USA0834MS1> Ira, I am working on getting the enumeration descrepancies out today. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 22 13:24:34 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68D9@USA0834MS1> I'm afraid I won't finish this until tomorrow. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: Elvers, Mike Sent: Wednesday, December 22, 1999 11:28 AM To: 'McDonald, Ira'; 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; Hastings, Tom N; Elvers, Mike; Filion, Joseph L; Gloger, Paul; Whittle, Craig Subject: RE: Final edits to Printer MIB v2 - fix broken names Ira, I am working on getting the enumeration descrepancies out today. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 29 11:20:37 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68DC@USA0834MS1> I was finally able to complete the listing of enumeration changes between version 1 and version 2 of the Printer MIB (RFC17659). Please see the listed items below. I did this is textual mode for those of you who don't have an appropriate email tool for handling attachments or enhanced text. This list includes everything that is different between an enumeration that existed in version 1 and the new definition in version 2. I have not listed new values or any unchanged old values. I have listed the object that defines the enumeration for clarity. I am providing this information so the people are aware of the extent of the changes that were made. I am not suggesting all of these should not be made. In some cases, where spelling is the motivator, (as in the PrtAlertGroupTC or PrtInterpreterLangFamilyTC values) I could see where those kind of changes would be desirable. However, in the cases where it is simple a tense issue or where items were actually deleted, I would suggest that these be reconsidered and thought given to if these are, in fact, essential and necessary. Printer MIB v1 Printer MIB v2 -------------- -------------- prtAlertCode PrtAlertCodeTC coverOpen = 3 coverOpened = 3 interlockOpen = 5 interlockOpened = 5 configurationChange = 7 configurationChanged = 7 jam = 8 jammed = 8 powerUp = 503 poweredUp = 503 powerDown = 504 poweredDown = 504 inputMediaSizeChange = 802 inputMediaSizeChanged = 802 inputMediaWeightChange = 803 inputMediaWeightChanged = 803 inputMediaTypeChange = 804 inputMediaTypeChanged = 804 inputMediaColorChange = 805 inputMediaColorChanged = 805 interpreterMemoryIncrease = 1501 interpreterMemoryIncreased = 1501 interpreterMemoryDecrease = 1502 interpreterMemoryDecreased = 1502 prtAlertGroup PrtAlertGroupTC hostResourceMIBStorageTable = 3 hostResourcesMIBStorageTable = 3 hostResourceMIBDeviceTable = 4 hostResourcesMIBDeviceTable = 4 prtAlertSeverityLevel PrtAlertSeverityLevelTC critical = 3 criticalBinaryChangeEvent = 3 warning = 4 warningUnaryChangeEvent = 4 prtChannelType PrtChannelTypeTC chDCERemoteProcCall = 22 chONCRemoteProcCall = 23 chOLE = 24 chNamedPipe = 25 chDPMF = 28 chPSM = 28 chDLLAPI = 29 chVxDAPI = 30 prtConsoleDisable prtConsoleDisable enabled = 3 operatorConsoleEnabled = 3 disabled = 4 operatorConsoleDisabled = 4 prtCoverStatus PrtCoverStatusTC doorOpen = 3 coverOpen = 3 doorClosed = 4 coverClosed = 4 prtInterpreterLangFamily PrtInterpreterLangFamilyTC langImPress = 33 langimPress = 33 prtMarkerMarkTech PrtMarkerMarkTechTC electroPhotographicLED = 3 electrophotographicLED = 3 electroPhotographicLaser = 4 electrophotographicLaser = 4 electroPhotographicOther = 5 electrophotographicOther = 5 impactMovingHeadDotMatrix9Pin = 6 impactMovingHeadDotMatrix9pin = 6 impactMovingHeadDotMatrix24Pin = 7 impactMovingHeadDotMatrix24pin = 7 prtMediaPathMaxSpeedPrintUnit PrtMediaPathMaxSpeedPrintUnitTC feetPerhour = 16 feetPerHour = 16 prtOutputType PrtOutputTypeTC mailbox = 6 mailBox = 6 subUnitStatus PrtSubUnitStatusTC intendedStateIsOnLine 0 stateIsOnLine 0 intendedStateIsOffLine 32 stateIsOffLine 32 atIntendedState 0 currentlyAtIntendedState 0 transitiioningToIntendedState 64 transitioningToIntendedState 64 Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From charles.a.adams at exgate.tek.com Mon Jan 4 10:34:59 1999 From: charles.a.adams at exgate.tek.com (charles.a.adams@exgate.tek.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <6B57A2A3212BD2119C2600805F6F1413011536FF@us-wv-m11.wv.tek.com> Name: Charles Adams Company: Tektronix, Inc ___ I support this proposed change ___ I reject this proposed change X I abstain from voting for the following reason: We have no opinion on this change. From imcdonal at sdsp.mc.xerox.com Mon Jan 4 11:24:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901041624.AA08040@appsrv1.sdsp.mc.xerox.com> Hi Folks, I vote in favor of this proposed update to the Job Mon MIB. Cheers, - Ira McDonald High North Inc 716-561-5667 From harryl at us.ibm.com Tue Jan 5 11:07:06 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F0.00588C85.00@d53mta05h.boulder.ibm.com> I may change my vote with further consideration but, at this time, I vote "against" based on the fact that continued changes at this point may adversely affect progress with the IETF. It was my understanding that we would take the job MIB as frozen last year to the IETF and make any additions to a future version. Name: Harry Lewis___________________________ Company: IBM_________________________ ___ I support this proposed change _x_ I reject this proposed change ___ I abstain from voting for the following reason: ___________________________________________________________ Harry Lewis - IBM Printing Systems harryl@us.ibm.com From imcdonal at sdsp.mc.xerox.com Tue Jan 5 19:52:04 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901060052.AA03421@appsrv1.sdsp.mc.xerox.com> Hi Harry, I understand your argument (too late, once again), but I think your logic is flawed. We aren't asking the IETF to adopt JMP MIB. We're just asking them to publish it as an Informational RFC. Unlike IPP (which is merely in serious trouble with the IETF), the JMP MIB has fallen entirely from IETF grace. Why do we care if we delay it for a short while to improve it? Also, I watched the same argument (too late, once again) be applied nineteen months ago to abandon work to fix the localisation contexts of all strings in the Printer MIB. And we all saw how quickly the Printer MIB v2 draft moved forward... - Ira McDonald High North Inc 716-461-5667 (w/ voice mail) From hastings at cp10.es.xerox.com Wed Jan 6 19:23:05 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C305@x-crt-es-ms1.cp10.es.xerox.com> >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Tuesday, December 22, 1998 07:42 >To: jmp@pwg.org >Subject: JMP> Ballot on Xerox Job MIB comments > > >I am requesting a formal ballot regarding the recent request >from Xerox to >expand the object jmSystemAttributeSupport to three objects. >Since this >is a very last minute change, it is very important that all who have >participated in this project review this change carefully. >Please return >the following ballot: > > > Name: _____Tom Hastings_______________________ > > Company: __Xerox______________________________ > > _x_ I support this proposed change > > ___ I reject this proposed change > > ___ I abstain from voting for the following reason: > > ___________________________________________________________ > > >Because the holidays will soon be here, I am setting the deadline to >January 13th. So we should have a final vote prior to the >Maui meeting. > >I encourage everyone to vote! > > > Ron Bergman > Dataproducts Corp. > > >---------- Forwarded message ---------- >Date: Mon, 14 Dec 1998 15:47:58 -0800 >From: "Hastings, Tom N" >To: jmp >Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call > >We held a Xerox-wide design review the proposed version 1.3 of >the PWG Job >Monitoring MIB that included a number of client-side >developers as well as >agent developers. We believe that the single bit array, >jmSystemAttributeSupport, indicating attribute support should >be replaced >with three bit arrays: >1) A bit array specifying which supported attributes can >contain meaningful >integer data. >2) A bit array specifying which supported attributes can >contain meaningful >string data. >3) A bit array specifying which supported attributes can have >more than one >integer or more than one string value. >There are two main areas of concern regarding the use of >"dictionary" or >attribute defining MIBs. First is the efficiency with which attribute >values can be requested and obtained from the device and second is the >ability to create generic management middleware that can be >reused when the >MIB is extended with additional attributes and can be used >with different >management applications that use different combinations of >attributes. Such >middleware obtains all of the attributes and keeps a local copy of the >attributes updated as the device runs. Any management application then >deals with the client-side local copy by calling the >client-side management >middleware for any combination of attributes which are >returned immediately >without querying the device. >Some items of note which should be considered in the following >discussion >are: >1) Most management applications must support SNMPv1 and SNMPv2 so that >relying on a getBulk type operation is not viable. >2) Most management applications support multiple SNMP protocol >stacks some >of which have quite small packet size limits such as 480 >octets so relying >on a maximum size of more than that is not viable. >One of the major concerns of many management applications is the >minimization of network traffic and a major factor in >determining the amount >of traffic is the number of strings to be retrieved. The >reason for this is >due to the fact that strings can be fairly long, up to 63 >octets. Couple >this with the limited packet size available and it is easily >seen that if a >large number of strings are to be retrieved then a large >number of packets >will be required. At most only 6 strings can be requested in a single >packet, else there is the risk of not all of the data fitting >in the packet. >This is because each string can be up to 63 octets and the OID for each >string can be around 15-20 octets, say around 80 as a maximum. > 484 divided >by 80 is 6 strings maximum. If only a single bit array is >used then both >the integer and string values will have to be requested for all of the >supported attributes. Since most of the string values will be NULL this >results in a large number of packets with unnecessary data (the null >strings). With an indicator of which attributes can actually >have valid >string data then only those attributes need to be requested >and the number >of needed packets can be optimized. This same argument >applies to integers >as well, although, to a lesser degree since 24 or so integers can be >requested in a single packet. >Being able to request this information from the device rather >than encoding >it directly into management application middleware makes the >application >middleware more robust, generic and re-usable. Encoding the >information >directly into the application middleware that an application >needs means >that the middleware can not be used with any application. It >also means >that if new attributes are added to a MIB then the application >middleware >will have to be modified to accommodate them. Neither of >these situations >is desirable from a software design and product deployment >point-of-view. >Adding the bit array that indicates which attributes might >have more than >one value and which ones cannot, means that the management >application knows >which values should be retrieved with several GetNext >operations in order to >pick up all the values and which only need one direct Get. While the >specification indicates which attribute MAY have multiple values, many >implementations MAY only actually implement one value. For >example, the >number of fileName or documentName attribute values per job >MAY only have a >single value for many implementations that only support one >document per >job, though multiple values are allowed. The same for >mediumRequested, etc. >So the third bit array indicates which attributes could have >more than one >value for that implementation. >Having these three bit arrays also allows management >middleware to obtain >attribute extensions from a device that were registered after >the management >middleware was shipped. Only the management application needs >updating that >wants to take advantage of the newly registered attributes. >Since these bit arrays are all read-only and never change >while the device >operates, they are very low cost in implementation and can be >put into ROM. >While we share the group's concern about "creeping elegance" >and "mission >creep" and want to see the PWG Job Monitoring MIB approved, we >believe that >these three bit arrays are the end. There does not seem to be >any other >support information about an implementation that could be >added to the new >System Group. So we believe that this addition would be the end. >We have produced complete compilable alternatives to V1.3 and >stored them in >a sub-directory of the usual place: >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array s/jmp.dic >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.mib >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib.txt >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib-rev >.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array >s/jmp-mib-rev >.pdf > > >Here are the relevant changes: > > >In Section 3.3.8 Attribute Specification update the paragraphs >on the bit >array support: > >A management application can determine which attributes are supported >and whether the integer and/or the octet string values are supported >with meaningful value by querying the jmSystemAttrIntegerSupport and >jmSystemAttrOctetsSupport objects, respectively. Management >applications can also determine which supported attributes might >support more than one integer value or more than one octet string value >by querying jmSystemAttrMultiRowSupport. > >These support bits are indicated in hex for each range in the line >starting with "support bits starting:". Note: these objects permit a >management application to determine the degree of support, even when >there are no jobs present in the system. They also permit management >middleware to fetch all attribute values for all jobs, including future >extensions, and keep them updated for one or more management >applications at the same time. > > >Replace the jmSystemAttributeSupport bit array object with the >following >three bit array objects: > >jmSystemAttrIntegerSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which attributes of the MIB this > implementation supports with meaningful integer values. > > The value of this object is a sparse bit array in which bit n > is a 1 if attribute n is supported with the > jmAttributeValueAsInteger object with meaningful values, where > n is the value of the enumerated attribute type in the > JmAttributeTypeTC used in jmAttributeTypeIndex (and the > jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). > Bit n MUST be 0 (or beyond the end of the returned bit array), > if attribute n is not supported or is always returned with a '- > 1'(other) or '-2'(unknown) value. > > The high order bit of the first octet in this octet string > corresponds to an attribute type of 0 (reserved), i.e., the bit > string uses the Big Endian numbering convention. Compare with > the BITS data type in SMIv2 [SMIv2-SMI] which has the same > format but requires contiguous enumerated bits. Trailing > octets in the octet string that contain only zero bits MUST NOT > be returned. > > Note: private attributes cannot be represented in this bit > array because their enum values are in the range 2**30 to > 2**31-1. See section 3.3.8. > > Example: An implementation supporting the attributes: > jobStateReasons2(3), jobStateReasons3(4), and jobName(23) > would return a one-octet string value of { '18'H }, since > jobName is an octet string value, not an integer value. > > This object helps a management application determine which > attributes with meaningful integer values MAY be present on > jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 3 } > > > >jmSystemAttrOctetsSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which attributes of the MIB this > implementation supports with meaningful octet string values. > > The format and semantics of this object is the same as > jmSystemAttrIntegerSupport, except that bit n indicates that > attribute n supports the jmAttributeValueAsOctets object with > meaningful values, instead of the jmAttributeValueAsInteger > object. Bit n MUST be 0 (or beyond the end of the returned bit > array), if attribute n is not supported or is always returned > as a zero-length octet string value. > > If an implementation supports both jmAttributeValueAsInteger > and jmAttributeValueAsOctets with meaningful values for > attribute n, bit n MUST appear in both bit array objects with a > 1 value. > > Example: An implementation supporting the attributes: > jobStateReasons2(3), jobStateReasons3(4), and jobName(23) > would return a three-octet string value of { '000001'H }, since > jobStateReasons2 and jobStateReasons3 are integer values, not > octet string values. > > This object helps a management application determine which > attributes with meaningful octet string values MAY be present > on jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 4 } > > >jmSystemAttrMultiRowSupport OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A bit array indicating which MULTI-ROW attributes of the MIB > this implementation supports with multiple integer values > and/or multiple octet string values. > > The format of this object is the same as the > jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport > objects. Bit n MUST be 1, if attribute n is actually supported > with more than one integer and/or more than one octet string > value. Bit n MUST be 0 (or beyond the end of the returned bit > array), if attribute n is not supported, is always returned as > a single integer value, or as a single octet string value. For > every bit n that is a 1 in this bit array, there MUST be a > corresponding 1 for bit n in either jmSystemAttrIntegerSupport, > jmSystemAttrOctetsSupport, or both. > > Example: Consider an implementation supporting: > (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW > integer attributes > (b) the jobName(23) SINGLE-ROW octet string attribute > (c) more than one integer value for the mediumRequested(170) > and mediumConsumed(171) MULTI-ROW attributes AND > (d) more than one octet string value for the fileName(34), > documentName(35), and mediumConsumed(171) MULTI-ROW attributes > (e) no octet string values for mediumRequested(170). > Such an implementation would return: > jmSystemAttrIntegerSupport 22 octets: > { '18000000 00000000 00000000 00000000 00000000 0030'H } > jmSystemAttrOctetsSupport 22 octets: > { '00000100 30000000 00000000 00000000 00000000 0010'H } > jmSystemAttrMultiRowSupport 22 octets: > { '00000000 30000000 00000000 00000000 00000000 0030'H } > > Example: Consider an implementation that supports the > fileName(34) MULTI-ROW attribute, but does not support more > than one document per job. Such an implementation would NOT > return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since > such an implementation would never return more than one > fileName value for a job. It would return a zero-length > string, since it never returns more than one value. > > This object helps a management application determine which > attributes may return more than one integer value or more than > one octet string value on jobs in this system." > DEFVAL { ''H } -- no attributes are required > ::= { jmSystem 5 } > > > >Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike >Elvers, Ang >Caruso, Joe Filion > >(310) 333-6413 > > From harryl at us.ibm.com Thu Jan 7 13:56:25 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F2.00680BEA.00@d53mta05h.boulder.ibm.com> A few days ago, I stated my lack of support in Ron's ballot request... >I am requesting a formal ballot regarding the recent request >from Xerox to expand the object jmSystemAttributeSupport to three objects. I should elaborate that I do not object to the particular jmSystemAttributeSupport changes proposed by Xerox but to the entire notion of submitting an updated version of the Job MIB to the IETF if that version has new mandatory objects which were not part of the agreed PWG standard, closed months ago, and which is the basis of all prototypes and implementations thus far. The existing PWG Job MIB standard (v1) has been intended for submission to the IETF for consideration as an RFC. (It has been debated whether this would be standards track with the Printer MIB, Informational, Experimental etc... but, nonetheless, the Job MIB would be submitted). Recently, there have been proposals, resulting from prototypes, which have been discussed and agreed to be improvements. I agreed to the addition of an optional "mirror table" as part of the IETF submission because it was optional. Later there was the notion of a "system table" to differentiate Job MIB versions. This would be a new mandatory table. Finally, there are proposed modifications in the details of the objects in this table. While I welcome and have been very willing to discuss spec changes to the standard, I feel the PWG process recognizes a v1 PWG Job MIB standard which is in PWG maintenance mode. I believe this should be considered the most stable version and the one that is published to the IETF. A SECOND updated PWG Job MIB standard is entirely feasible but I don't believe it is valid to publish new mandatary objects in the first EXTERNAL version of the standard. I highly recommend at least one coordinated interoperability test prior to declaring the second major version of the Job MIB standard. Harry Lewis - IBM Printing Systems harryl@us.ibm.com From hastings at cp10.es.xerox.com Thu Jan 7 21:35:31 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C49D@x-crt-es-ms1.cp10.es.xerox.com> Harry, I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now with the System Group being entirely removed as you and Ron have suggested. We can also agree that we should make the second EXTERNALLY published version of the MIB AFTER an interoperability test and any updates needed from the interpretability test, as you proposed. Currently, the interoperability test is anticipated to be some time next summer. However, we need to be able to build something with the System Group in it NOW, rather than waiting until after the interoperability test (next summer). So could we also produce NOW an INTERNAL PWG working draft with version 2.0 that does have the MANDATORY System Group in it? This internal PWG working draft would NOT be forwarded to the IETF for publication as an Information RFC until after the interoperability test and any updates that the interoperability tests show were added. Thus the interoperability test would be for both version 1.0 products without the System Group and for version 2.0 products with the MANDATORY System Group. It is straightforward for any testing client software to tell the difference between the two by just querying the System Group and getting back no such object or not. So for process as a result of the PWG Last Call, after Maui I would forward the current JMP MIB document with the OPTIONAL Mirror Table but without the System Group to the IETF as an Internet-Draft. Ron prefers that we call it 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse the IETF. They have only seen the 1.0 spec from February 1998. If it looks ok, Ron will then request the RFC Editor to publish it as an Informational RFC. Secondly, next month I would take the current 1.3 version with the MANDATORY System Group and rename it to be version 2.0. Then implementers that want to can implement it for the Interoperability Tests. However, it would NOT be forwarded to the IETF until after the interoperability test. Implementers at the interoperability test could bring 1.0 or 2.0 conformant products. If new attributes are proposed and agreed to, I can add them to both the 1.0 and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by the IETF and an Informational RFC. After that we only need to keep maintaining the 2.0 spec. How does that sound? Thanks, Tom >-----Original Message----- >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >Sent: Thursday, January 07, 1999 10:56 >To: jmp@pwg.org >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > >>I am requesting a formal ballot regarding the recent request >>from Xerox to expand the object jmSystemAttributeSupport to >three objects. > >I should elaborate that I do not object to the particular >jmSystemAttributeSupport changes proposed by Xerox but to the >entire notion >of submitting an updated version of the Job MIB to the IETF if >that version >has new mandatory objects which were not part of the agreed >PWG standard, >closed months ago, and which is the basis of all prototypes and >implementations thus far. > >The existing PWG Job MIB standard (v1) has been intended for >submission to >the IETF for consideration as an RFC. (It has been debated whether this >would >be standards track with the Printer MIB, Informational, >Experimental etc... >but, nonetheless, the Job MIB would be submitted). > >Recently, there have been proposals, resulting from >prototypes, which have >been discussed and agreed to be improvements. I agreed to the >addition of >an optional "mirror table" as part of the IETF submission >because it was >optional. Later there was the notion of a "system table" to >differentiate >Job MIB versions. This would be a new mandatory table. >Finally, there are >proposed modifications in the details of the objects in this table. > >While I welcome and have been very willing to discuss spec >changes to the >standard, I feel the PWG process recognizes a v1 PWG Job MIB >standard which >is in PWG maintenance mode. I believe this should be >considered the most >stable version and the one that is published to the IETF. A >SECOND updated >PWG Job MIB standard is entirely feasible but I don't believe >it is valid >to publish new mandatary objects in the first EXTERNAL version of the >standard. > >I highly recommend at least one coordinated interoperability >test prior to >declaring the second major version of the Job MIB standard. > >Harry Lewis - IBM Printing Systems >harryl@us.ibm.com > > From harryl at us.ibm.com Fri Jan 8 10:23:51 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F3.0054966E.00@d53mta05h.boulder.ibm.com> Tom. This is a much better proposal. I only have one concern. The System Group was supposed to enable applications to determine whether or not the (optional) mirror table was supported. Perhaps 1.0 should just be the first PWG standard Job MIB (as agreed initially) and the (new) internal version (basis for next external) should have the mirror table and Systems Group. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/07/99 07:35:31 PM To: jmp cc: Harry Lewis/Boulder/IBM, Ron Bergman Subject: RE: JMP> Ballot on Xerox Job MIB comments Harry, I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now with the System Group being entirely removed as you and Ron have suggested. We can also agree that we should make the second EXTERNALLY published version of the MIB AFTER an interoperability test and any updates needed from the interpretability test, as you proposed. Currently, the interoperability test is anticipated to be some time next summer. However, we need to be able to build something with the System Group in it NOW, rather than waiting until after the interoperability test (next summer). So could we also produce NOW an INTERNAL PWG working draft with version 2.0 that does have the MANDATORY System Group in it? This internal PWG working draft would NOT be forwarded to the IETF for publication as an Information RFC until after the interoperability test and any updates that the interoperability tests show were added. Thus the interoperability test would be for both version 1.0 products without the System Group and for version 2.0 products with the MANDATORY System Group. It is straightforward for any testing client software to tell the difference between the two by just querying the System Group and getting back no such object or not. So for process as a result of the PWG Last Call, after Maui I would forward the current JMP MIB document with the OPTIONAL Mirror Table but without the System Group to the IETF as an Internet-Draft. Ron prefers that we call it 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse the IETF. They have only seen the 1.0 spec from February 1998. If it looks ok, Ron will then request the RFC Editor to publish it as an Informational RFC. Secondly, next month I would take the current 1.3 version with the MANDATORY System Group and rename it to be version 2.0. Then implementers that want to can implement it for the Interoperability Tests. However, it would NOT be forwarded to the IETF until after the interoperability test. Implementers at the interoperability test could bring 1.0 or 2.0 conformant products. If new attributes are proposed and agreed to, I can add them to both the 1.0 and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by the IETF and an Informational RFC. After that we only need to keep maintaining the 2.0 spec. How does that sound? Thanks, Tom >-----Original Message----- >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >Sent: Thursday, January 07, 1999 10:56 >To: jmp@pwg.org >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > >>I am requesting a formal ballot regarding the recent request >>from Xerox to expand the object jmSystemAttributeSupport to >three objects. > >I should elaborate that I do not object to the particular >jmSystemAttributeSupport changes proposed by Xerox but to the >entire notion >of submitting an updated version of the Job MIB to the IETF if >that version >has new mandatory objects which were not part of the agreed >PWG standard, >closed months ago, and which is the basis of all prototypes and >implementations thus far. > >The existing PWG Job MIB standard (v1) has been intended for >submission to >the IETF for consideration as an RFC. (It has been debated whether this >would >be standards track with the Printer MIB, Informational, >Experimental etc... >but, nonetheless, the Job MIB would be submitted). > >Recently, there have been proposals, resulting from >prototypes, which have >been discussed and agreed to be improvements. I agreed to the >addition of >an optional "mirror table" as part of the IETF submission >because it was >optional. Later there was the notion of a "system table" to >differentiate >Job MIB versions. This would be a new mandatory table. >Finally, there are >proposed modifications in the details of the objects in this table. > >While I welcome and have been very willing to discuss spec >changes to the >standard, I feel the PWG process recognizes a v1 PWG Job MIB >standard which >is in PWG maintenance mode. I believe this should be >considered the most >stable version and the one that is published to the IETF. A >SECOND updated >PWG Job MIB standard is entirely feasible but I don't believe >it is valid >to publish new mandatary objects in the first EXTERNAL version of the >standard. > >I highly recommend at least one coordinated interoperability >test prior to >declaring the second major version of the Job MIB standard. > >Harry Lewis - IBM Printing Systems >harryl@us.ibm.com > > From rbergma at dpc.com Fri Jan 8 10:37:16 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments In-Reply-To: <872566F3.0054966E.00@d53mta05h.boulder.ibm.com> Message-ID: Since the Mirror table is optional, I do not have a real problem with it either added or removed. But Harry does have a good point and it probably best that it not be included in version 1.0. This would also be a better position for us with the IETF. Anyone else have comments? Ron Bergman Dataproducts Corp. On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > Tom. This is a much better proposal. I only have one concern. > > The System Group was supposed to enable applications to determine whether > or not the (optional) mirror table was supported. Perhaps 1.0 should just > be the first PWG standard Job MIB (as agreed initially) and the (new) > internal version (basis for next external) should have the mirror table and > Systems Group. > > Harry Lewis - IBM Printing Systems > harryl@us.ibm.com > > > > "Hastings, Tom N" on 01/07/99 07:35:31 PM > > To: jmp > cc: Harry Lewis/Boulder/IBM, Ron Bergman > Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > > Harry, > > I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now > with the System Group being entirely removed as you and Ron have suggested. > > We can also agree that we should make the second EXTERNALLY published > version of the MIB AFTER an interoperability test and any updates needed > from the interpretability test, as you proposed. Currently, the > interoperability test is anticipated to be some time next summer. > > However, we need to be able to build something with the System Group in it > NOW, rather than waiting until after the interoperability test (next > summer). So could we also produce NOW an INTERNAL PWG working draft with > version 2.0 that does have the MANDATORY System Group in it? This internal > PWG working draft would NOT be forwarded to the IETF for publication as an > Information RFC until after the interoperability test and any updates that > the interoperability tests show were added. > > Thus the interoperability test would be for both version 1.0 products > without the System Group and for version 2.0 products with the MANDATORY > System Group. It is straightforward for any testing client software to > tell > the difference between the two by just querying the System Group and > getting > back no such object or not. > > So for process as a result of the PWG Last Call, after Maui I would forward > the current JMP MIB document with the OPTIONAL Mirror Table but without the > System Group to the IETF as an Internet-Draft. Ron prefers that we call it > 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse > the > IETF. They have only seen the 1.0 spec from February 1998. If it looks > ok, > Ron will then request the RFC Editor to publish it as an Informational RFC. > > Secondly, next month I would take the current 1.3 version with the > MANDATORY > System Group and rename it to be version 2.0. Then implementers that want > to can implement it for the Interoperability Tests. However, it would NOT > be forwarded to the IETF until after the interoperability test. > Implementers at the interoperability test could bring 1.0 or 2.0 conformant > products. > > If new attributes are proposed and agreed to, I can add them to both the > 1.0 > and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by > the > IETF and an Informational RFC. After that we only need to keep maintaining > the 2.0 spec. > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >Sent: Thursday, January 07, 1999 10:56 > >To: jmp@pwg.org > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > > > > > >A few days ago, I stated my lack of support in Ron's ballot request... > > > >>I am requesting a formal ballot regarding the recent request > >>from Xerox to expand the object jmSystemAttributeSupport to > >three objects. > > > >I should elaborate that I do not object to the particular > >jmSystemAttributeSupport changes proposed by Xerox but to the > >entire notion > >of submitting an updated version of the Job MIB to the IETF if > >that version > >has new mandatory objects which were not part of the agreed > >PWG standard, > >closed months ago, and which is the basis of all prototypes and > >implementations thus far. > > > >The existing PWG Job MIB standard (v1) has been intended for > >submission to > >the IETF for consideration as an RFC. (It has been debated whether this > >would > >be standards track with the Printer MIB, Informational, > >Experimental etc... > >but, nonetheless, the Job MIB would be submitted). > > > >Recently, there have been proposals, resulting from > >prototypes, which have > >been discussed and agreed to be improvements. I agreed to the > >addition of > >an optional "mirror table" as part of the IETF submission > >because it was > >optional. Later there was the notion of a "system table" to > >differentiate > >Job MIB versions. This would be a new mandatory table. > >Finally, there are > >proposed modifications in the details of the objects in this table. > > > >While I welcome and have been very willing to discuss spec > >changes to the > >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >standard which > >is in PWG maintenance mode. I believe this should be > >considered the most > >stable version and the one that is published to the IETF. A > >SECOND updated > >PWG Job MIB standard is entirely feasible but I don't believe > >it is valid > >to publish new mandatary objects in the first EXTERNAL version of the > >standard. > > > >I highly recommend at least one coordinated interoperability > >test prior to > >declaring the second major version of the Job MIB standard. > > > >Harry Lewis - IBM Printing Systems > >harryl@us.ibm.com > > > > > > > > From hastings at cp10.es.xerox.com Fri Jan 8 18:45:20 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <918C79AB552BD211A2BD00805F15CE8582C5CB@x-crt-es-ms1.cp10.es.xerox.com> We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From harryl at us.ibm.com Mon Jan 11 10:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <872566F6.00562BB1.00@d53mta05h.boulder.ibm.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 10:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments In-Reply-To: <918C79AB552BD211A2BD00805F15CE8582C5CB@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916069415@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916070095@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074223@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074315@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916074970@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075022@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From harryl at us.ibm.com Mon Jan 11 09:41:09 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075081@it.qms.com> This sounds like the right approach to me. I wouldn't expect "arbitrary" changes to be proposed. Only, like you indicated, changes based on interop testing. Harry Lewis - IBM Printing Systems harryl@us.ibm.com "Hastings, Tom N" on 01/08/99 04:45:20 PM To: Ron Bergman , Harry Lewis/Boulder/IBM cc: jmp Subject: RE: JMP> Ballot on Xerox Job MIB comments We (Xerox) could go along with removing the mirror table as well, as long as we can get some agreement in the JMP WG that the internal PWG version 2.0 spec is agreed to for the two new groups: the OPTIONAL mirror table the MANDATORY new system group Then implementer's who want or need to can build to the 2.0 spec for the interoperability test next summer with some assurance that these groups won't be changed arbitrarily, but only possibility from the results of the interoperability testing. The best way to ascertain that we have agreement on these two new groups would be to do a Last Call on them, but keep the resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 spec to the IETF until after the interoperability test (and any updates that are found to be needed). How does that sound? Thanks, Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Friday, January 08, 1999 07:37 >To: harryl@us.ibm.com >Cc: Hastings, Tom N; jmp >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > >Since the Mirror table is optional, I do not have a real >problem with it >either added or removed. But Harry does have a good point and >it probably >best that it not be included in version 1.0. This would also >be a better >position for us with the IETF. > >Anyone else have comments? > > Ron Bergman > Dataproducts Corp. > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > >> >> >> Tom. This is a much better proposal. I only have one concern. >> >> The System Group was supposed to enable applications to >determine whether >> or not the (optional) mirror table was supported. Perhaps >1.0 should just >> be the first PWG standard Job MIB (as agreed initially) and the (new) >> internal version (basis for next external) should have the >mirror table and >> Systems Group. >> >> Harry Lewis - IBM Printing Systems >> harryl@us.ibm.com >> >> >> >> "Hastings, Tom N" on 01/07/99 >07:35:31 PM >> >> To: jmp >> cc: Harry Lewis/Boulder/IBM, Ron Bergman >> Subject: RE: JMP> Ballot on Xerox Job MIB comments >> >> >> >> >> >> Harry, >> >> I think that we (Xerox) can agree to forwarding the JMP MIB >to the IETF now >> with the System Group being entirely removed as you and Ron >have suggested. >> >> We can also agree that we should make the second EXTERNALLY published >> version of the MIB AFTER an interoperability test and any >updates needed >> from the interpretability test, as you proposed. Currently, the >> interoperability test is anticipated to be some time next summer. >> >> However, we need to be able to build something with the >System Group in it >> NOW, rather than waiting until after the interoperability test (next >> summer). So could we also produce NOW an INTERNAL PWG >working draft with >> version 2.0 that does have the MANDATORY System Group in it? > This internal >> PWG working draft would NOT be forwarded to the IETF for >publication as an >> Information RFC until after the interoperability test and >any updates that >> the interoperability tests show were added. >> >> Thus the interoperability test would be for both version 1.0 products >> without the System Group and for version 2.0 products with >the MANDATORY >> System Group. It is straightforward for any testing client >software to >> tell >> the difference between the two by just querying the System Group and >> getting >> back no such object or not. >> >> So for process as a result of the PWG Last Call, after Maui >I would forward >> the current JMP MIB document with the OPTIONAL Mirror Table >but without the >> System Group to the IETF as an Internet-Draft. Ron prefers >that we call it >> 1.0 (with a January 1999 date), rather than 1.3 so that we >don't confuse >> the >> IETF. They have only seen the 1.0 spec from February 1998. >If it looks >> ok, >> Ron will then request the RFC Editor to publish it as an >Informational RFC. >> >> Secondly, next month I would take the current 1.3 version with the >> MANDATORY >> System Group and rename it to be version 2.0. Then >implementers that want >> to can implement it for the Interoperability Tests. >However, it would NOT >> be forwarded to the IETF until after the interoperability test. >> Implementers at the interoperability test could bring 1.0 or >2.0 conformant >> products. >> >> If new attributes are proposed and agreed to, I can add them >to both the >> 1.0 >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as >published by >> the >> IETF and an Informational RFC. After that we only need to >keep maintaining >> the 2.0 spec. >> >> How does that sound? >> >> Thanks, >> Tom >> >> >-----Original Message----- >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] >> >Sent: Thursday, January 07, 1999 10:56 >> >To: jmp@pwg.org >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments >> > >> > >> > >> > >> >A few days ago, I stated my lack of support in Ron's ballot >request... >> > >> >>I am requesting a formal ballot regarding the recent request >> >>from Xerox to expand the object jmSystemAttributeSupport to >> >three objects. >> > >> >I should elaborate that I do not object to the particular >> >jmSystemAttributeSupport changes proposed by Xerox but to the >> >entire notion >> >of submitting an updated version of the Job MIB to the IETF if >> >that version >> >has new mandatory objects which were not part of the agreed >> >PWG standard, >> >closed months ago, and which is the basis of all prototypes and >> >implementations thus far. >> > >> >The existing PWG Job MIB standard (v1) has been intended for >> >submission to >> >the IETF for consideration as an RFC. (It has been debated >whether this >> >would >> >be standards track with the Printer MIB, Informational, >> >Experimental etc... >> >but, nonetheless, the Job MIB would be submitted). >> > >> >Recently, there have been proposals, resulting from >> >prototypes, which have >> >been discussed and agreed to be improvements. I agreed to the >> >addition of >> >an optional "mirror table" as part of the IETF submission >> >because it was >> >optional. Later there was the notion of a "system table" to >> >differentiate >> >Job MIB versions. This would be a new mandatory table. >> >Finally, there are >> >proposed modifications in the details of the objects in this table. >> > >> >While I welcome and have been very willing to discuss spec >> >changes to the >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB >> >standard which >> >is in PWG maintenance mode. I believe this should be >> >considered the most >> >stable version and the one that is published to the IETF. A >> >SECOND updated >> >PWG Job MIB standard is entirely feasible but I don't believe >> >it is valid >> >to publish new mandatary objects in the first EXTERNAL >version of the >> >standard. >> > >> >I highly recommend at least one coordinated interoperability >> >test prior to >> >declaring the second major version of the Job MIB standard. >> > >> >Harry Lewis - IBM Printing Systems >> >harryl@us.ibm.com >> > >> > >> >> >> >> > From rbergma at dpc.com Mon Jan 11 08:33:03 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: <9901119160.AA916075112@it.qms.com> Tom, I believe that the group has approved, in concept, both the mirror table and the system table for version 2. I don't know if everyone has completed a through review of your proposal to expand the attributes- supported object into three parts. (I certainly have not had the time!) I am sure that improvements will be proposed both as a result of further review, implementation experience, and interoperability testing, but I do not expect major changes. Ron On Fri, 8 Jan 1999, Hastings, Tom N wrote: > We (Xerox) could go along with removing the mirror table as well, as long as > we can get some agreement in the JMP WG that the internal PWG version 2.0 > spec is agreed to for the two new groups: > > the OPTIONAL mirror table > the MANDATORY new system group > > Then implementer's who want or need to can build to the 2.0 spec for the > interoperability test next summer with some assurance that these groups > won't be changed arbitrarily, but only possibility from the results of the > interoperability testing. The best way to ascertain that we have agreement > on these two new groups would be to do a Last Call on them, but keep the > resulting spec as a PWG Working Draft. I.e., not forward the version 2.0 > spec to the IETF until after the interoperability test (and any updates that > are found to be needed). > > How does that sound? > > Thanks, > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Friday, January 08, 1999 07:37 > >To: harryl@us.ibm.com > >Cc: Hastings, Tom N; jmp > >Subject: RE: JMP> Ballot on Xerox Job MIB comments > > > > > >Since the Mirror table is optional, I do not have a real > >problem with it > >either added or removed. But Harry does have a good point and > >it probably > >best that it not be included in version 1.0. This would also > >be a better > >position for us with the IETF. > > > >Anyone else have comments? > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Fri, 8 Jan 1999 harryl@us.ibm.com wrote: > > > >> > >> > >> Tom. This is a much better proposal. I only have one concern. > >> > >> The System Group was supposed to enable applications to > >determine whether > >> or not the (optional) mirror table was supported. Perhaps > >1.0 should just > >> be the first PWG standard Job MIB (as agreed initially) and the (new) > >> internal version (basis for next external) should have the > >mirror table and > >> Systems Group. > >> > >> Harry Lewis - IBM Printing Systems > >> harryl@us.ibm.com > >> > >> > >> > >> "Hastings, Tom N" on 01/07/99 > >07:35:31 PM > >> > >> To: jmp > >> cc: Harry Lewis/Boulder/IBM, Ron Bergman > >> Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > >> > >> > >> > >> > >> Harry, > >> > >> I think that we (Xerox) can agree to forwarding the JMP MIB > >to the IETF now > >> with the System Group being entirely removed as you and Ron > >have suggested. > >> > >> We can also agree that we should make the second EXTERNALLY published > >> version of the MIB AFTER an interoperability test and any > >updates needed > >> from the interpretability test, as you proposed. Currently, the > >> interoperability test is anticipated to be some time next summer. > >> > >> However, we need to be able to build something with the > >System Group in it > >> NOW, rather than waiting until after the interoperability test (next > >> summer). So could we also produce NOW an INTERNAL PWG > >working draft with > >> version 2.0 that does have the MANDATORY System Group in it? > > This internal > >> PWG working draft would NOT be forwarded to the IETF for > >publication as an > >> Information RFC until after the interoperability test and > >any updates that > >> the interoperability tests show were added. > >> > >> Thus the interoperability test would be for both version 1.0 products > >> without the System Group and for version 2.0 products with > >the MANDATORY > >> System Group. It is straightforward for any testing client > >software to > >> tell > >> the difference between the two by just querying the System Group and > >> getting > >> back no such object or not. > >> > >> So for process as a result of the PWG Last Call, after Maui > >I would forward > >> the current JMP MIB document with the OPTIONAL Mirror Table > >but without the > >> System Group to the IETF as an Internet-Draft. Ron prefers > >that we call it > >> 1.0 (with a January 1999 date), rather than 1.3 so that we > >don't confuse > >> the > >> IETF. They have only seen the 1.0 spec from February 1998. > >If it looks > >> ok, > >> Ron will then request the RFC Editor to publish it as an > >Informational RFC. > >> > >> Secondly, next month I would take the current 1.3 version with the > >> MANDATORY > >> System Group and rename it to be version 2.0. Then > >implementers that want > >> to can implement it for the Interoperability Tests. > >However, it would NOT > >> be forwarded to the IETF until after the interoperability test. > >> Implementers at the interoperability test could bring 1.0 or > >2.0 conformant > >> products. > >> > >> If new attributes are proposed and agreed to, I can add them > >to both the > >> 1.0 > >> and 2.0 specs until we make version 2.0 an EXTERNAL spec as > >published by > >> the > >> IETF and an Informational RFC. After that we only need to > >keep maintaining > >> the 2.0 spec. > >> > >> How does that sound? > >> > >> Thanks, > >> Tom > >> > >> >-----Original Message----- > >> >From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > >> >Sent: Thursday, January 07, 1999 10:56 > >> >To: jmp@pwg.org > >> >Subject: RE: JMP> Ballot on Xerox Job MIB comments > >> > > >> > > >> > > >> > > >> >A few days ago, I stated my lack of support in Ron's ballot > >request... > >> > > >> >>I am requesting a formal ballot regarding the recent request > >> >>from Xerox to expand the object jmSystemAttributeSupport to > >> >three objects. > >> > > >> >I should elaborate that I do not object to the particular > >> >jmSystemAttributeSupport changes proposed by Xerox but to the > >> >entire notion > >> >of submitting an updated version of the Job MIB to the IETF if > >> >that version > >> >has new mandatory objects which were not part of the agreed > >> >PWG standard, > >> >closed months ago, and which is the basis of all prototypes and > >> >implementations thus far. > >> > > >> >The existing PWG Job MIB standard (v1) has been intended for > >> >submission to > >> >the IETF for consideration as an RFC. (It has been debated > >whether this > >> >would > >> >be standards track with the Printer MIB, Informational, > >> >Experimental etc... > >> >but, nonetheless, the Job MIB would be submitted). > >> > > >> >Recently, there have been proposals, resulting from > >> >prototypes, which have > >> >been discussed and agreed to be improvements. I agreed to the > >> >addition of > >> >an optional "mirror table" as part of the IETF submission > >> >because it was > >> >optional. Later there was the notion of a "system table" to > >> >differentiate > >> >Job MIB versions. This would be a new mandatory table. > >> >Finally, there are > >> >proposed modifications in the details of the objects in this table. > >> > > >> >While I welcome and have been very willing to discuss spec > >> >changes to the > >> >standard, I feel the PWG process recognizes a v1 PWG Job MIB > >> >standard which > >> >is in PWG maintenance mode. I believe this should be > >> >considered the most > >> >stable version and the one that is published to the IETF. A > >> >SECOND updated > >> >PWG Job MIB standard is entirely feasible but I don't believe > >> >it is valid > >> >to publish new mandatary objects in the first EXTERNAL > >version of the > >> >standard. > >> > > >> >I highly recommend at least one coordinated interoperability > >> >test prior to > >> >declaring the second major version of the Job MIB standard. > >> > > >> >Harry Lewis - IBM Printing Systems > >> >harryl@us.ibm.com > >> > > >> > > >> > >> > >> > >> > > > From egglestn at lexmark.com Mon Jan 11 14:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Please ignore Message-ID: <199901111949.AA21592@lexmark.lexmark.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084232@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084309@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084376@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:47:01 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Please ignore Message-ID: <9901119160.AA916084454@it.qms.com> This is just a test, please ignore... From egglestn at lexmark.com Mon Jan 11 15:02:32 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Another test Message-ID: <199901112003.AA23089@interlock2.lexmark.com> Please ignore... Thanks, Roger Eggleston From egglestn at lexmark.com Mon Jan 11 15:19:24 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Test Message-ID: <199901112027.AA25177@interlock2.lexmark.com> Please ignore... Thanks, From egglestn at lexmark.com Mon Jan 11 15:27:34 1999 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> test Message-ID: <199901112030.AA25622@interlock2.lexmark.com> please ignore... From hastings at cp10.es.xerox.com Mon Feb 22 04:14:28 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> I have posed the V1 and V2 PWG Job Monitoring MIB specifications as agreed Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE03F@x-crt-es-ms1.cp10.es.xerox.com> The V1 spec is ready to send to the IETF as an Internet-Draft and request the IESG to publish as an Informational RFC. As agreed, we will call this V1.0, not V1.3, even though the PWG has had an older version that we called V1.0 in February and made it an Internet-Draft (draft-ietf-printmib-job-monitor-07.txt). The V1.0 spec does not have either the Mirror Table or the System Table. The V2 spec has the OPTIONAL Mirror Table and the MANDATORY System Table that shows which attributes are supported and how. We should hold off on making V2 and Internet-Draft so as not to confuse the IETF. The V1 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/draft-ietf-printmib-job-monitor- 08.txt ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito r-08.txt The V2 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.txt Both V1 and V2 compile with three compilers. Here is the change history for V1: 10.1 Changes to produce version 1.0, dated February 19, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.0 [sic], dated January 28, 1999: 1. Changed the version number back to 1.0 for this INTERNET-DRAFT in anticipation of its being published as an Information RFC. 10.2 Changes to produce version 1.2, dated October 2, 1998 The following changes were made to version 1.1, dated October 1, 1998 to make version 1.2, dated October 2, 1998: 1. Removed all REFERENCE clauses since they referred to sections in the specification that were not in the MIB as requested by the IESG. 2. Moved the definitions of the attributes from the TC to a new section 3.3.8 as requested by the IESG. 3. Removed the attributes from the Table of Contents 4. Added the data types as ASN.1 comments after each attribute enum. 5. Changed a number of occurrences of "SHALL" to "is" when they were just definitions, rather than conformance requirements. 1.3 Changes to produce version 1.1, dated October 1, 1998 The following changes were made to version 1.0, dated February 3, 1998 to make version 1.1, dated October 1, 1998: 1. Clarified sections 3.3.3 and 3.3.7 so that the DEFVAL of 0 for index attributes is different from the DEFVAL for jmAttributeValueAsInteger which is -2. 2. Clarified the relationships of the values of the JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 3. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP 'media' values which are media names, media size names, and input tray names. 4. Added the two attributes approved by the PWG for registration in April 1998: mediumTypeConsumed(174) and mediumSizeConsumed(175). 5. Changed "insure" to "ensure'. 6. Correct an incorrect reference in the jmAttributeEntry DESCRIPTION from jmJobTable to jmAttributeTable. Here is the change history for V2: 1.1 Changes to produce version 2.0, dated February 20, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 2.0, dated February 20, 1999: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, and jmSystemAttrMultiRowSupport objects. 4. Changed the version number to 2.0, since a MANDATORY table was added. Tom Hastings (310) 333-6413 From imcdonal at sdsp.mc.xerox.com Mon Feb 22 21:31:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> Compile error in JMP MIB v1 - bad date stamp Message-ID: <9902230231.AA16446@appsrv5.sdsp.mc.xerox.com> Hi Tom, Monday (22 February 1999) The date stamps in the MODULE-IDENTITY macros of the JMP MIBv1 and JMP MIBv2 you posted this morning are both wrong. One (v1) also has too many digits, so it doesn't compile under the latest SMICng version. jmp_mib1.txt: LAST-UPDATED "99021910020000Z" -- , 19 February 1999 jmp_mib2.txt: LAST-UPDATED "9901290000Z" -- , 20 February 1999 We really shouldn't have incorrect date stamps in the compilable MIBs. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc From hastings at cp10.es.xerox.com Mon Mar 1 19:50:44 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-08.txt Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE8D8@x-crt-es-ms1.cp10.es.xerox.com> I'll post the .pdf files later today. Tom -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, March 01, 1999 16:01 To: IETF-Announce; @ns.cnri.reston.va.us@pwg.org Cc: pmp@pwg.org Subject: PMP> I-D ACTION:draft-ietf-printmib-job-monitor-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Job Monitoring MIB - V1.0 Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis Filename : draft-ietf-printmib-job-monitor-08.txt Pages : 118 Date : 26-Feb-99 This document has been developed and approved by the Printer Working Group (PWG) as a PWG standard. It is intended to be distributed as an Informational RFC. This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-printmib-job-monitor-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: Date: Mon, 1 Mar 1999 16:03:23 -0800 Size: 1083 Url: http://www.pwg.org/archives/jmp/attachments/19990301/40367b43/attachment-0001.mht From hastings at cp10.es.xerox.com Tue Mar 2 13:42:52 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> RESEND: I have posed the V1 and V2 PWG Job Monitoring MIB specifi cations as agreed Message-ID: <918C79AB552BD211A2BD00805F15CE85BCE976@x-crt-es-ms1.cp10.es.xerox.com> I have updated the .doc and .pdf files to agree with the .txt file that I sent to the IETF and was posted for version 1.0. I have also updated the .doc and .pdf files for version 2.0. I did not change the file names. The only changes in these documents was to fix the date. Many places still had 1998, not 1999. The .txt and .mib files remain unchanged (they had the correct dates in them). Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, February 22, 1999 01:14 To: jmp Subject: JMP> I have posed the V1 and V2 PWG Job Monitoring MIB specifications as agreed The V1 spec is ready to send to the IETF as an Internet-Draft and request the IESG to publish as an Informational RFC. As agreed, we will call this V1.0, not V1.3, even though the PWG has had an older version that we called V1.0 in February 1998 [sic] and made it an Internet-Draft (draft-ietf-printmib-job-monitor-07.txt). The V1.0 spec does not have either the Mirror Table or the System Table. The V2 spec has the OPTIONAL Mirror Table and the MANDATORY System Table that shows which attributes are supported and how. We should hold off on making V2 and Internet-Draft so as not to confuse the IETF. The V1 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp-mib-1.0.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/draft-ietf-printmib-job-monitor- 08.txt ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito r-08.txt The V2 files are available at: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version1/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/version2/jmp-mib-2.0.txt Both V1 and V2 compile with three compilers. Here is the change history for V1: 10.1 Changes to produce version 1.0, dated February 19, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.0 [sic], dated January 28, 1999: 1. Changed the version number back to 1.0 for this INTERNET-DRAFT in anticipation of its being published as an Information RFC. 10.2 Changes to produce version 1.2, dated October 2, 1998 The following changes were made to version 1.1, dated October 1, 1998 to make version 1.2, dated October 2, 1998: 1. Removed all REFERENCE clauses since they referred to sections in the specification that were not in the MIB as requested by the IESG. 2. Moved the definitions of the attributes from the TC to a new section 3.3.8 as requested by the IESG. 3. Removed the attributes from the Table of Contents 4. Added the data types as ASN.1 comments after each attribute enum. 5. Changed a number of occurrences of "SHALL" to "is" when they were just definitions, rather than conformance requirements. 1.3 Changes to produce version 1.1, dated October 1, 1998 The following changes were made to version 1.0, dated February 3, 1998 to make version 1.1, dated October 1, 1998: 1. Clarified sections 3.3.3 and 3.3.7 so that the DEFVAL of 0 for index attributes is different from the DEFVAL for jmAttributeValueAsInteger which is -2. 2. Clarified the relationships of the values of the JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 3. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP 'media' values which are media names, media size names, and input tray names. 4. Added the two attributes approved by the PWG for registration in April 1998: mediumTypeConsumed(174) and mediumSizeConsumed(175). 5. Changed "insure" to "ensure'. 6. Correct an incorrect reference in the jmAttributeEntry DESCRIPTION from jmJobTable to jmAttributeTable. Here is the change history for V2: 1.1 Changes to produce version 2.0, dated February 20, 1999 The following changes were made to version 1.2, dated October 2, 1998 to make version 2.0, dated February 20, 1999: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, and jmSystemAttrMultiRowSupport objects. 4. Changed the version number to 2.0, since a MANDATORY table was added. Tom Hastings (310) 333-6413 From rbergma at dpc.com Tue Mar 16 11:57:49 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: The latest version of the Job MIB has been posted for several weeks now without any comments. Since this latest document is not significantly different from the version previously submitted to the IETF, I do not feel that a normal "Last Call" period is necessary. However, since the IETF meeting is currently in progress, there is no point in submitting a formal request to the IETF until next week. I will submit the document to the IETF next Wednesday (March 24th) unless an objection or problem is reported prior to the end of this "Last Call" period. Also, if anyone would like more time to review the document, I will extend this "Last Call" period as required. Ron Bergman Dataproducts Corp. From imcdonal at sdsp.mc.xerox.com Tue Mar 16 12:50:17 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903161750.AA28630@appsrv5.sdsp.mc.xerox.com> Hi Ron, Don't the current Internet-Drafts still have the typographic errors in the MODULE-IDENTITY macros that I pointed out on the list when they were posted? At least in SMICng-98, those lines don't compile (too many digits in a UTC timestamp). I assume it's the V1.0 (pre-mirror-table) that you meant to send forward as an Informational RFC to the IESG and not the V2.0 (mirror-table, et al)? Cheers, - Ira McDonald High North Inc From rbergma at dpc.com Tue Mar 16 14:55:20 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903161750.AA28630@appsrv5.sdsp.mc.xerox.com> Message-ID: Ira, I will check with Tom on the first issue. Yes, we are trying to get the version 1.0 MIB published as an RFC as agreed over a year ago. It may be either an Informational or Experimental RFC. Ron Bergman Dataproducts Corp. On Tue, 16 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Don't the current Internet-Drafts still have the typographic > errors in the MODULE-IDENTITY macros that I pointed out on > the list when they were posted? At least in SMICng-98, > those lines don't compile (too many digits in a UTC timestamp). > > I assume it's the V1.0 (pre-mirror-table) that you meant to > send forward as an Informational RFC to the IESG and not > the V2.0 (mirror-table, et al)? > > Cheers, > - Ira McDonald > High North Inc > > From hastings at cp10.es.xerox.com Wed Mar 17 03:01:06 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85CF1AFD@x-crt-es-ms1.cp10.es.xerox.com> I fixed the date being too long BEFORE sending the .txt version to the IETF as pointed out by Ira. The current lines are: jobmonMIB MODULE-IDENTITY LAST-UPDATED "9902190000Z" ORGANIZATION "Printer Working Group (PWG)" Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Tuesday, March 16, 1999 11:55 To: Ira McDonald Cc: jmp@pwg.org; chrisw@iwl.com; lpyoung@lexmark.com Subject: Re: JMP> Job Monitoring MIB - Last Call Ira, I will check with Tom on the first issue. Yes, we are trying to get the version 1.0 MIB published as an RFC as agreed over a year ago. It may be either an Informational or Experimental RFC. Ron Bergman Dataproducts Corp. On Tue, 16 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Don't the current Internet-Drafts still have the typographic > errors in the MODULE-IDENTITY macros that I pointed out on > the list when they were posted? At least in SMICng-98, > those lines don't compile (too many digits in a UTC timestamp). > > I assume it's the V1.0 (pre-mirror-table) that you meant to > send forward as an Informational RFC to the IESG and not > the V2.0 (mirror-table, et al)? > > Cheers, > - Ira McDonald > High North Inc > > From imcdonal at sdsp.mc.xerox.com Wed Mar 17 09:40:15 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903171440.AA17629@appsrv1.sdsp.mc.xerox.com> Hi Ron, Thanks for clarifying. By the way, the PWG Job Mon MIB which was rejected by the IETF for standards track therefore CANNOT be published as 'Experimental' rather than 'Informational'. The IETF standard process reserves 'Experimental' for products of IETF-chartered working groups that are future 'standards track' (ie, Proposed Standard) products. I sure wish we could revisit the Job Mon MIB chartering with the IETF, because it is closely coupled with both IPP (same states and reasons and a superset of attributes) and Printer MIB. Would it be worth approaching Keith Moore and Patrick Faltstrom (our IETF Applications ADs)?? Cheers, - Ira McDonald From rbergma at dpc.com Wed Mar 17 10:57:14 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903171440.AA17629@appsrv1.sdsp.mc.xerox.com> Message-ID: Ira, Our original request was for the document to be an "Informational" RFC. However, Bert Wijnen proposed that it be published as "Experimental". I did query whether "Experimental" implied that the document was on the standards track. The response was - no, a protocol can move from "Experimental" to standards track, but it is not considered to be on the standards track merely due to its "Experimental" status. (This may not agree with the IETF procedure RFCs, but this was the response.) It might be worth the effort to try again for a Standards Track publication. I will draft my request for IESG consideration with this as the goal. If several of us review and work on this proposal, we may be able to put together a strong argument. (I will plan to have the initial draft to the DL early next week.) Chris and Lloyd, are you willing to present a proposal for standards track? Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Thanks for clarifying. By the way, the PWG Job Mon MIB which > was rejected by the IETF for standards track therefore CANNOT > be published as 'Experimental' rather than 'Informational'. > > The IETF standard process reserves 'Experimental' for products > of IETF-chartered working groups that are future 'standards > track' (ie, Proposed Standard) products. > > I sure wish we could revisit the Job Mon MIB chartering > with the IETF, because it is closely coupled with both > IPP (same states and reasons and a superset of attributes) > and Printer MIB. Would it be worth approaching Keith > Moore and Patrick Faltstrom (our IETF Applications ADs)?? > > Cheers, > - Ira McDonald > > From hastings at cp10.es.xerox.com Wed Mar 17 13:27:52 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85CF1B71@x-crt-es-ms1.cp10.es.xerox.com> Sounds good to me. One issue is whether to progress version 1.0 or version 2.0 on standards track? Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, March 17, 1999 07:57 To: Ira McDonald Cc: chrisw@iwl.com; jmp@pwg.org; lpyoung@lexmark.com Subject: Re: JMP> Job Monitoring MIB - Last Call Ira, Our original request was for the document to be an "Informational" RFC. However, Bert Wijnen proposed that it be published as "Experimental". I did query whether "Experimental" implied that the document was on the standards track. The response was - no, a protocol can move from "Experimental" to standards track, but it is not considered to be on the standards track merely due to its "Experimental" status. (This may not agree with the IETF procedure RFCs, but this was the response.) It might be worth the effort to try again for a Standards Track publication. I will draft my request for IESG consideration with this as the goal. If several of us review and work on this proposal, we may be able to put together a strong argument. (I will plan to have the initial draft to the DL early next week.) Chris and Lloyd, are you willing to present a proposal for standards track? Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Thanks for clarifying. By the way, the PWG Job Mon MIB which > was rejected by the IETF for standards track therefore CANNOT > be published as 'Experimental' rather than 'Informational'. > > The IETF standard process reserves 'Experimental' for products > of IETF-chartered working groups that are future 'standards > track' (ie, Proposed Standard) products. > > I sure wish we could revisit the Job Mon MIB chartering > with the IETF, because it is closely coupled with both > IPP (same states and reasons and a superset of attributes) > and Printer MIB. Would it be worth approaching Keith > Moore and Patrick Faltstrom (our IETF Applications ADs)?? > > Cheers, > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Wed Mar 17 19:12:47 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903180012.AA08795@appsrv5.sdsp.mc.xerox.com> Hi Ron, Certainly not all (or even most) Experimental RFCs eventually lead to Proposed Standard RFCs, BUT only products of IETF chartered WGs may be published as Experimental rather than Informational. The IETF has NOT chartered JMP WG and without changes to the PMP WG charter, the JMP can't be a product of the PMP WG (because it's out-of-scope). I think we were naive in trying to take JMP work forward a year ago under the Printer MIB WG charter with the IETF. If we get an actual free-standing Job Mon MIB WG charter from IETF (not so inconceivable now, in light of the IPP/1.1 goal of Proposed Standard, with which the IESG agrees), then getting published as an Experimental RFC makes good sense and is MUCH more likely than getting published (initially) as Proposed Standard. If we are not going for Informational (which RFC 2400 explicitly describes as suitable for standards from other organizations, such as the PWG) but rather Experimental, then Tom Hastings' good question about whether to publish Job Mon MIB v1.0 or v2.0 on that track is highly relevant. I personally favor publishing v2.0 as Experimental, but reducing the conformance level of the last objects added (after the mirror table itself) to Conditionally Mandatory, so that all existing v1.0 conformant implementations are fully compliant with the v2.0 text (such as the IBM implementation Harry Lewis' team built during the JMP development phase). Cheers, - Ira McDonald From rbergma at dpc.com Wed Mar 17 21:07:10 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call In-Reply-To: <9903180012.AA08795@appsrv5.sdsp.mc.xerox.com> Message-ID: Ira, I was also very surprised when it was proposed by Bert Wijnen to publish the MIB as "Experimental" and I did question this decision. Several other IETF members also agreed that it should be "Experimental". I actually would prefer "Informational", but as long as it is published they can call it a "Dumb PWG Specification". Are you suggesting that we publish 1.0 as "Informational" and 2.0 as "Experimental" or "Standards Track"? Or only publish 2.0? The goal has been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. It may make more sense to just get 1.0 published however the IETF wants and then push for 2.0 to be standards track. Ron Bergman Dataproducts Corp. On Wed, 17 Mar 1999, Ira McDonald wrote: > Hi Ron, > > Certainly not all (or even most) Experimental RFCs eventually > lead to Proposed Standard RFCs, BUT only products of IETF > chartered WGs may be published as Experimental rather > than Informational. The IETF has NOT chartered JMP WG > and without changes to the PMP WG charter, the JMP can't > be a product of the PMP WG (because it's out-of-scope). > > I think we were naive in trying to take JMP work forward > a year ago under the Printer MIB WG charter with the IETF. > If we get an actual free-standing Job Mon MIB WG charter > from IETF (not so inconceivable now, in light of the > IPP/1.1 goal of Proposed Standard, with which the IESG > agrees), then getting published as an Experimental RFC > makes good sense and is MUCH more likely than getting > published (initially) as Proposed Standard. > > If we are not going for Informational (which RFC 2400 > explicitly describes as suitable for standards from > other organizations, such as the PWG) but rather > Experimental, then Tom Hastings' good question about > whether to publish Job Mon MIB v1.0 or v2.0 on that > track is highly relevant. I personally favor > publishing v2.0 as Experimental, but reducing the > conformance level of the last objects added (after > the mirror table itself) to Conditionally Mandatory, > so that all existing v1.0 conformant implementations > are fully compliant with the v2.0 text (such as the > IBM implementation Harry Lewis' team built during > the JMP development phase). > > Cheers, > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Thu Mar 18 15:32:51 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <9903182032.AA25166@appsrv1.sdsp.mc.xerox.com> Hi Ron, Thursday (18 March 1999) I temporarily lost my mind there. Of course, we should FIRST get the full content of PWG Job Mon MIB v1.0 published as *any* kind of RFC. But it is intriguing that Bert Wijnen suggested 'Experimental'. Shall we pursue a free-standing charter for an IETF Job Mon MIB WG? Harry, do you favor this idea? We could always add the definition of standard SNMP job traps to our charter. They certainly ARE necessary to get the most utility out of the PWG Job Mon MIB. Cheers, - Ira McDonald > ---------------------------------------------------------------------- > Date: Wed, 17 Mar 1999 18:07:10 -0800 (Pacific Standard Time) > From: Ron Bergman > To: Ira McDonald > cc: chrisw@iwl.com, jmp@pwg.org, lpyoung@lexmark.com > Subject: Re: JMP> Job Monitoring MIB - Last Call > > Ira, > > I was also very surprised when it was proposed by Bert Wijnen to publish > the MIB as "Experimental" and I did question this decision. Several other > IETF members also agreed that it should be "Experimental". I actually > would prefer "Informational", but as long as it is published they can call > it a "Dumb PWG Specification". > > Are you suggesting that we publish 1.0 as "Informational" and 2.0 as > "Experimental" or "Standards Track"? Or only publish 2.0? The goal has > been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. > > It may make more sense to just get 1.0 published however the IETF wants > and then push for 2.0 to be standards track. > > Ron Bergman > Dataproducts Corp. From hastings at cp10.es.xerox.com Thu Mar 18 20:34:57 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB - Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE85DF3A87@x-crt-es-ms1.cp10.es.xerox.com> Ira, I think that the Job Monitoring MIB may not need a new charter to be progressed on standard track. Lets not invoke more process than is necessary. Only if the ADs say we need to do a new charter should we do that. Here is what the IANA Home Page says about the Printer MIB WG: Tom ---------------------------------------------------------------------------- ---- Printer MIB (printmib) Last Modified: 20-Jan-98 Chair(s): Chris Wellens Llyod Young Applications Area Director(s): Keith Moore Patrik Faltstrom Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:pmp@pwg.org To Subscribe: majordomo@pwg.org In Body: In body: subscribe pmp Archive: http://www.pwg.org/hypermail/pmp/ Description of Working Group: The Printer MIB Working Group is chartered to develop a set of managed objects for networked printers. These objects will be the minimum necessary to provide the ability to monitor and control these systems, providing fault, configuration and performance management, and will be consistent with the SNMP framework and existing SNMP standards. At its discretion, the working group may also define a small number of unsolicited notifications (traps) which carry these managed objects. However, the working group recognizes that traps are used sparingly in the SNMP framework. The working group recognizes that the area of networked printers is quite diverse. However, the working group is specifically confined to defining managed objects that instrument critical information about: - printer engine - interpreters - media - input sources - output destinations - I/O interfaces Further, the working group is specifically prohibited from defining managed objects that define instrumentation about: - other marking technologies (e.g., those that mark onto film) - fonts - spooling - print job management Goals and Milestones: Done Post revised Internet-Draft. Done Submit final Internet-Draft to IESG for consideration as a Proposed Standard. Done Meet at Seattle IETF to make final review of MIB. Done Post first Internet-Draft; continue discussion. Done Post Internet-Draft. Solicit implementation experience on RFC1759. Done Post revised Internet-Draft. Done Meet at Memphis IETF for final MIB review. Jul 97 Submit Internet-Draft to IESG for consideration as a Draft Standard. Internet-Drafts: Printer MIB (334475 bytes) Job Monitoring MIB - V1.0 (257216 bytes) Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB (53394 bytes) Printer Finishing MIB (98802 bytes) Request For Comments: Printer MIB (RFC 1759) (239228 bytes) ---------------------------------------------------------------------------- ---- IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org. Return to working group directory. Return to IETF home page. -----Original Message----- From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] Sent: Thursday, March 18, 1999 12:33 To: chrisw@iwl.com; imcdonal@sdsp.mc.xerox.com; jmp@pwg.org; lpyoung@lexmark.com; rbergma@dpc.com Subject: Re: JMP> Job Monitoring MIB - Last Call Hi Ron, Thursday (18 March 1999) I temporarily lost my mind there. Of course, we should FIRST get the full content of PWG Job Mon MIB v1.0 published as *any* kind of RFC. But it is intriguing that Bert Wijnen suggested 'Experimental'. Shall we pursue a free-standing charter for an IETF Job Mon MIB WG? Harry, do you favor this idea? We could always add the definition of standard SNMP job traps to our charter. They certainly ARE necessary to get the most utility out of the PWG Job Mon MIB. Cheers, - Ira McDonald > ---------------------------------------------------------------------- > Date: Wed, 17 Mar 1999 18:07:10 -0800 (Pacific Standard Time) > From: Ron Bergman > To: Ira McDonald > cc: chrisw@iwl.com, jmp@pwg.org, lpyoung@lexmark.com > Subject: Re: JMP> Job Monitoring MIB - Last Call > > Ira, > > I was also very surprised when it was proposed by Bert Wijnen to publish > the MIB as "Experimental" and I did question this decision. Several other > IETF members also agreed that it should be "Experimental". I actually > would prefer "Informational", but as long as it is published they can call > it a "Dumb PWG Specification". > > Are you suggesting that we publish 1.0 as "Informational" and 2.0 as > "Experimental" or "Standards Track"? Or only publish 2.0? The goal has > been to get an RFC number on 1.0 and then finish 2.0 after a Bake-off. > > It may make more sense to just get 1.0 published however the IETF wants > and then push for 2.0 to be standards track. > > Ron Bergman > Dataproducts Corp. From lpyoung at lexmark.com Wed Mar 24 08:54:35 1999 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job MIB on standards track Message-ID: <199903241357.AA14658@interlock2.lexmark.com> There has been some recent discussion on the mailing list regarding the Job MIB and whether on not it should be on a standards track or not. The IETF has not been completely clear on its criteria for establishing working groups to develop protocols to go on the standards track. However, in many information conversations with Area Directors and others, Chris and I have learned that the primary concern is overall operation of the Internet. The IETF has seen a significant rise in the number of protocols and MIBs they have been requested to oversee. In order to reduce the workload the Area Directors had to be selective in where they sent their time and have chosen to only focus on items that may impact the overall operation of the Internet. The reason the IETF took an interest in the Internet Printing Protocol is that they saw it having wide ranging implications for Internet operation. If the IPP protocol was badly specified and resulted in large consumption of bandwidth, it becomes a cause for concern for the IETF. These are the types of projects and working groups they want to charter and oversee--those that will have a big impact on the overall Internet. In the case of the Job MIB, the IETF sees this largely as workgroup or LAN-specific kind of operation. The IETF does not want to invest standards time and scrutiny on these projects, as these projects do not have the impact on overall Internet operations that other protocols do. The Area Directors have seen other MIBs be tremendous commercial successes without being on the standards track. Therefore, we do not think we will be successful in introducing the Job MIB on a standards track. Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C08L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW e-mail: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From rbergma at dpc.com Wed Mar 24 11:07:32 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB, Request for Publication as an RFC Message-ID: Bert and David, The Printer Working Group has revised the Job Monitoring MIB draft, incorporating many of the changes that you have recommended. We believe that the documents are now ready to be published as RFCs. The latest drafts are available in the IETF Internet-Drafts directory as: draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) During our previous communications, you had suggested that the MIB document be published as an Experimental RFC. The PWG does not object to either an Informational or an Experimental status. The companion Mapping Recommendations document should be an Informational RFC regardless. We are requesting that you review the updated document and provide a recommendation for publication. Following your review, the PWG will submit the documents to the appropriate IETF representative for publication. A summary of the document changes: 1. All REFERENCES clauses have been removed since they referred to sections in the specification that are not within the actual MIB. This change was recommended by Bert Wijnen and Keith McCloghrie. 2. Moved the definitions of the enumerations from the Textual Convention entries in the MIB to the sections preceding the MIB. This change was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC. This change was recommended by Keith McCloghrie. 3. Added the related data types as ASN.1 comments for each enumeration in JmAttributeTypeTC. 4. Replaced the use of "SHALL" with "is" for those cases where the statement is not a conformance requirement. This change was recommended by Bert Wijnen. 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 for index attributes is different from the DEFVAL of -2 for JmAttributeValueAsInteger. 6. Clarified the relationships of the values of JmJobCollationTypeTC with the IPP "multiple-document-handling" attribute. 7. Clarified that the values of the mediumRequested(170) and mediumConsumed(171) attributes may be any of the IPP media values of media name, media size names, and input tray names. 8. Added two new attributes, mediumTypeConsumed(174) and mediumSizeConsumed(175) to JmAttributeTypeTC. 9. Changed "insure" to "ensure". 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION clause from jmJobTable to jmAttributeTable. The PWG would like to thank you for your time and patience in this matter. For the PWG, Ron Bergman Dataproducts Corp. rbergma@dpc.com voice: 805 578 4421 fax: 805 578 4005 From moore at cs.utk.edu Wed Mar 24 11:27:13 1999 From: moore at cs.utk.edu (Keith Moore) Date: Wed May 6 14:00:17 2009 Subject: JMP> Re: Job Monitoring MIB, Request for Publication as an RFC In-Reply-To: Your message of "Wed, 24 Mar 1999 08:07:32 PST." Message-ID: <199903241627.IAA14303@astro.cs.utk.edu> I don't understand. Why is the Printer Working Group, which is not affiliated with IETF, working on documents which are marked as work items of the IETF Printer MIB working group? I'm happy to see that the PWG is asking IETF MIB experts for review of its documents, and I have no objection to the technical changes mentioned in your message. But I continue to find the apparent confusion of PWG members about the relationship of PWG with IETF working groups, quite disconcerting. Keith > Date: Wed, 24 Mar 1999 08:07:32 -0800 (Pacific Standard Time) > From: Ron Bergman > To: WIJNEN@VNET.IBM.COM, dperkins@scruznet.com > cc: jmp@pwg.org, Lloyd Young , > Chris Wellens , > Tom Hastings , > Harry Lewis , moore@cs.utk.edu, scoya@ietf.org, > Harald.Alvestrand@maxware.no, rfc-editor@isi.edu > Subject: Job Monitoring MIB, Request for Publication as an RFC > > Bert and David, > > The Printer Working Group has revised the Job Monitoring MIB draft, > incorporating many of the changes that you have recommended. We believe > that the documents are now ready to be published as RFCs. The latest > drafts are available in the IETF Internet-Drafts directory as: > > draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) > draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) > > During our previous communications, you had suggested that the MIB > document be published as an Experimental RFC. The PWG does not object > to either an Informational or an Experimental status. The companion > Mapping Recommendations document should be an Informational RFC > regardless. > > We are requesting that you review the updated document and provide a > recommendation for publication. Following your review, the PWG will > submit the documents to the appropriate IETF representative for > publication. > > A summary of the document changes: > > 1. All REFERENCES clauses have been removed since they referred to > sections in the specification that are not within the actual MIB. > This change was recommended by Bert Wijnen and Keith McCloghrie. > > 2. Moved the definitions of the enumerations from the Textual Convention > entries in the MIB to the sections preceding the MIB. This change > was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, > JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and > JmJobStateReasons4TC. This change was recommended by Keith > McCloghrie. > > 3. Added the related data types as ASN.1 comments for each enumeration > in JmAttributeTypeTC. > > 4. Replaced the use of "SHALL" with "is" for those cases where the > statement is not a conformance requirement. This change was > recommended by Bert Wijnen. > > 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 > for index attributes is different from the DEFVAL of -2 for > JmAttributeValueAsInteger. > > 6. Clarified the relationships of the values of JmJobCollationTypeTC > with the IPP "multiple-document-handling" attribute. > > 7. Clarified that the values of the mediumRequested(170) and > mediumConsumed(171) attributes may be any of the IPP media values of > media name, media size names, and input tray names. > > 8. Added two new attributes, mediumTypeConsumed(174) and > mediumSizeConsumed(175) to JmAttributeTypeTC. > > 9. Changed "insure" to "ensure". > > 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION > clause from jmJobTable to jmAttributeTable. > > > The PWG would like to thank you for your time and patience in this matter. > > > For the PWG, > > Ron Bergman > Dataproducts Corp. > rbergma@dpc.com > voice: 805 578 4421 > fax: 805 578 4005 > > From WIJNEN at VNET.IBM.COM Wed Mar 24 20:05:22 1999 From: WIJNEN at VNET.IBM.COM (Bert Wijnen) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job Monitoring MIB, Request for Publication as an RFC Message-ID: <199903241904.OAA13179@pwg.org> Ref: Your note of Wed, 24 Mar 1999 08:07:32 -0800 (Pacific St Subject: Re: Job Monitoring MIB, Request for Publication as an RFC I have it on my list of things to do. Of course,the responsible AD (APPS Area, Keith Moore or Patrik Faltstrom) mke the final decision on these documents. Dave Perkins, can you pls review this MIB for the IESG? Pls also not that Harald has moved to an IAB position and that Randy Bush is now co-AD in the Ops and Mgmt Area. Bert From rbergma at dpc.com Fri Mar 26 21:25:39 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Re: Job Monitoring MIB, Request for Publication as an RFC In-Reply-To: <199903241627.IAA14303@astro.cs.utk.edu> Message-ID: Keith, I am sorry for the confusion my email has caused regarding the Job Monitoring MIB. The Job Monitoring MIB is a work product of the IETF Printer MIB Working Group. Ron Bergman Dataproducts Corp. On Wed, 24 Mar 1999, Keith Moore wrote: > I don't understand. Why is the Printer Working Group, which is not > affiliated with IETF, working on documents which are marked as work > items of the IETF Printer MIB working group? > > I'm happy to see that the PWG is asking IETF MIB experts for review > of its documents, and I have no objection to the technical changes > mentioned in your message. But I continue to find the apparent confusion > of PWG members about the relationship of PWG with IETF working groups, > quite disconcerting. > > Keith > > > > Date: Wed, 24 Mar 1999 08:07:32 -0800 (Pacific Standard Time) > > From: Ron Bergman > > To: WIJNEN@VNET.IBM.COM, dperkins@scruznet.com > > cc: jmp@pwg.org, Lloyd Young , > > Chris Wellens , > > Tom Hastings , > > Harry Lewis , moore@cs.utk.edu, scoya@ietf.org, > > Harald.Alvestrand@maxware.no, rfc-editor@isi.edu > > Subject: Job Monitoring MIB, Request for Publication as an RFC > > > > Bert and David, > > > > The Printer Working Group has revised the Job Monitoring MIB draft, > > incorporating many of the changes that you have recommended. We believe > > that the documents are now ready to be published as RFCs. The latest > > drafts are available in the IETF Internet-Drafts directory as: > > > > draft-ietf-printmib-job-monitor-08.txt (Feb 19, 1999) > > draft-ietf-printmib-job-protomap-04.txt (Sept 21, 1998) > > > > During our previous communications, you had suggested that the MIB > > document be published as an Experimental RFC. The PWG does not object > > to either an Informational or an Experimental status. The companion > > Mapping Recommendations document should be an Informational RFC > > regardless. > > > > We are requesting that you review the updated document and provide a > > recommendation for publication. Following your review, the PWG will > > submit the documents to the appropriate IETF representative for > > publication. > > > > A summary of the document changes: > > > > 1. All REFERENCES clauses have been removed since they referred to > > sections in the specification that are not within the actual MIB. > > This change was recommended by Bert Wijnen and Keith McCloghrie. > > > > 2. Moved the definitions of the enumerations from the Textual Convention > > entries in the MIB to the sections preceding the MIB. This change > > was applied to JmAttributeTypeTC, JmJobSubmissionIDTypeTC, > > JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and > > JmJobStateReasons4TC. This change was recommended by Keith > > McCloghrie. > > > > 3. Added the related data types as ASN.1 comments for each enumeration > > in JmAttributeTypeTC. > > > > 4. Replaced the use of "SHALL" with "is" for those cases where the > > statement is not a conformance requirement. This change was > > recommended by Bert Wijnen. > > > > 5. Clarified sections 3.3.3 and 3.3.7 to explain that the DEFVAL of 0 > > for index attributes is different from the DEFVAL of -2 for > > JmAttributeValueAsInteger. > > > > 6. Clarified the relationships of the values of JmJobCollationTypeTC > > with the IPP "multiple-document-handling" attribute. > > > > 7. Clarified that the values of the mediumRequested(170) and > > mediumConsumed(171) attributes may be any of the IPP media values of > > media name, media size names, and input tray names. > > > > 8. Added two new attributes, mediumTypeConsumed(174) and > > mediumSizeConsumed(175) to JmAttributeTypeTC. > > > > 9. Changed "insure" to "ensure". > > > > 10. Fixed an incorrect reference in the jmAttributeEntry DESCRIPTION > > clause from jmJobTable to jmAttributeTable. > > > > > > The PWG would like to thank you for your time and patience in this matter. > > > > > > For the PWG, > > > > Ron Bergman > > Dataproducts Corp. > > rbergma@dpc.com > > voice: 805 578 4421 > > fax: 805 578 4005 > > > > > From dcarney at us.ibm.com Mon Apr 12 18:44:53 1999 From: dcarney at us.ibm.com (dcarney@us.ibm.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Add IPP attributes to facilitate better job monitoring? Message-ID: <87256751.007CF77D.00@d53mta08h.boulder.ibm.com> Here at IBM we have implemented a job monitoring application that uses the job MIB. In looking at IPP to see if we could do the same monitoring using IPP instead, I noticed that there are many attributes that are defined in the job MIB that aren't defined in IPP. We have found using our monitoring application that some of these missing attributes are important to be able to do accurate job monitoring. Therefore, my question is whether the IPP group should consider adding some attributes to facilitate better job monitoring. Specifically, the job MIB attributes that are missing and that I think are important: impressionsCompletedCurrentCopy jobCollationType sheetCompletedCopyNumber impressionsInterpreted Numbers 1-3 are needed to present detailed information on job status when the job contains multiple copies--for example, "Printed page 3 of 5, copy 2 of 3". Number 4 is not absolutely essential, but we have found that it is often helpful in unusual situations. It is possible that there are other missing attributes that are "important"--I'll let others bring those up if they feel the need. In doing this effort, I found Tom Hastings' document ietf-ipp.pdf on the pwg ftp site, which compares the list of attributes defined for the job MIB with the list of attributes defined for IPP. Because the document was out-of-date, I updated it and will be publishing the update to the ftp site shortly. Harry Lewis is going to bring copies of the current state of the updated document to New Orleans. Dennis Carney IBM Printing Systems Company From anthony.porter at computer.org Tue Apr 13 06:05:43 1999 From: anthony.porter at computer.org (Anthony Porter) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: IPP> Add IPP attributes to facilitate better job monitoring? In-Reply-To: <87256751.007CF77D.00@d53mta08h.boulder.ibm.com> Message-ID: <000501be8595$3263dfa0$767010ac@ntw4-ap> I agree with this. impressionsInterpreted is related to Issue #31 where the printer has a separate RIP processor. Since it may take a significant amount of time to RIP a complex document, this value is necessary if users are to have any idea as when a job might be finished. I notice that there does not seem any way to specify collation in IPP-MOD. It is mentioned in the context of multiple documents, but not for multiple copies of single documents. This is important, since many printers cannot collate at all, while others are restricted by the number of output trays. Printers with a separate RIP can collate any number of copies. job-collation ought to be a job template attribute, so that the printer can specify whether it supports collation, and the maximum number of copies it can collate. Certain jobs ought not to be collated, even if the printer can do so. At present the user has no idea whether a job of 500 copies will be collated or not. Anthony Porter -----Original Message----- From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of dcarney@us.ibm.com Sent: Tuesday, 13 April, 1999 12:45 AM To: ipp@pwg.org; jmp@pwg.org Cc: harryl@us.ibm.com; hastings@cp10.es.xerox.com Subject: IPP> Add IPP attributes to facilitate better job monitoring? Here at IBM we have implemented a job monitoring application that uses the job MIB. In looking at IPP to see if we could do the same monitoring using IPP instead, I noticed that there are many attributes that are defined in the job MIB that aren't defined in IPP. We have found using our monitoring application that some of these missing attributes are important to be able to do accurate job monitoring. Therefore, my question is whether the IPP group should consider adding some attributes to facilitate better job monitoring. Specifically, the job MIB attributes that are missing and that I think are important: impressionsCompletedCurrentCopy jobCollationType sheetCompletedCopyNumber impressionsInterpreted Numbers 1-3 are needed to present detailed information on job status when the job contains multiple copies--for example, "Printed page 3 of 5, copy 2 of 3". Number 4 is not absolutely essential, but we have found that it is often helpful in unusual situations. It is possible that there are other missing attributes that are "important"--I'll let others bring those up if they feel the need. In doing this effort, I found Tom Hastings' document ietf-ipp.pdf on the pwg ftp site, which compares the list of attributes defined for the job MIB with the list of attributes defined for IPP. Because the document was out-of-date, I updated it and will be publishing the update to the ftp site shortly. Harry Lewis is going to bring copies of the current state of the updated document to New Orleans. Dennis Carney IBM Printing Systems Company From imcdonal at sdsp.mc.xerox.com Mon Apr 19 20:01:40 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> RFC 2578/2579/2580 - new SMIv2 standards Message-ID: <199904200001.UAA15043@appsrv5.sdsp.mc.xerox.com> Hi folks, These RFCs now OBSOLETE the old RFC 1902/1903/1904 version of SMIv2. Should be read closely. Note that David Perkins (of SMIC/SMICng fame) is one of the co-editors of the new SMIv2 specs. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc From dcarney at us.ibm.com Tue Apr 27 17:00:35 1999 From: dcarney at us.ibm.com (dcarney@us.ibm.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Updated comparison of job mib attributes with IPP attributes Message-ID: <87256760.007369B6.00@d53mta08h.boulder.ibm.com> As promised a while back, I have posted to the ftp site an update of the comparison between the job attributes defined in the job mib and those in IPP. ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11.pdf ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11.doc ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11-rev .pdf ftp://pwg@ftp.pwg.org/export/home/ftp/pub/pwg/jmp/protomap/ietf-ipp-v11-rev .doc (Note: I was not sure of the comparison between JMP and IPP in terms of natural language issues, so I marked those few attributes as "???".) Dennis Carney IBM Printing Systems Company; (303)924-0565 From csibr at ibm.net Wed Jun 9 14:23:54 1999 From: csibr at ibm.net (Edu) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job / Printer Staus monitoring Message-ID: <01BEB28C.195132F0@EDU_FREIRE> I am sorry if this is not the correct recipient for questions like this ! The information I need is how can I monitor printer job status(printing, printed succesfully, not printed due errors, ... and printer status (online, paper jam, ...) using MIB II and SNMP ? Thanks in advance, Eduardo. From hastings at cp10.es.xerox.com Wed Jun 9 19:29:26 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB1E2@x-crt-es-ms1.cp10.es.xerox.com> The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From hastings at cp10.es.xerox.com Wed Jun 9 19:41:02 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB1E6@x-crt-es-ms1.cp10.es.xerox.com> Does anyone have any more technical reasons from the IESG as to why they don't like the attribute structure that we have in the PWG Job Monitoring MIB? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 16:29 To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Angelo.Caruso at usa.xerox.com Thu Jun 10 08:53:37 1999 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <3654E69400ADD211A3A400805FA7CE24083468@usa0111ms2.eng.mc.xerox.com> Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From jkm at underscore.com Thu Jun 10 09:10:41 1999 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional References: <3654E69400ADD211A3A400805FA7CE24083468@usa0111ms2.eng.mc.xerox.com> Message-ID: <375FB951.52D6F84F@underscore.com> Angelo, Excellent suggestion about publishing an explanation of the information model for the Job MIB prior to publishing the actual MIB document itself. Perhaps such a document would have helped the rest of the PWG understand this creature called the Job MIB, too. (Just a guess, though.) ...jay "Caruso, Angelo" wrote: > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just went ahead and > implemented the first instance of this new model, all in one MIB module. > Perhaps we should have published a generic definition of the new model first > as a stand-alone document, and then published the JMP MIB as an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > an > Informational RFC. However, the IESG doesn't approve of our modeling of > management information. By this I assume they mean the attribute mechanism > that we invented to handle the great variability between implementations. > > They also don't recognize the PWG as a standards making body according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. From rbergma at dpc.com Thu Jun 10 10:57:11 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional In-Reply-To: <375FB951.52D6F84F@underscore.com> Message-ID: Angelo, I agree with Jay and propose that work on this paper start immediately. Very good suggestion! Ron Bergman Hitachi Koki Imaging Solutions On Thu, 10 Jun 1999, Jay Martin wrote: > Angelo, > > Excellent suggestion about publishing an explanation of the > information model for the Job MIB prior to publishing the > actual MIB document itself. > > Perhaps such a document would have helped the rest of the PWG > understand this creature called the Job MIB, too. > (Just a guess, though.) > > ...jay > > > "Caruso, Angelo" wrote: > > > > Tom, > > > > Perhaps the IETF is taking issue with the fact that we invented a new > > information model, built on top of SNMP/SMI, and then just went ahead and > > implemented the first instance of this new model, all in one MIB module. > > Perhaps we should have published a generic definition of the new model first > > as a stand-alone document, and then published the JMP MIB as an example > > implementation. > > > > Thanks, > > Ang > > > > -----Original Message----- > > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > > Sent: Wednesday, June 09, 1999 7:29 PM > > To: jmp > > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > > Informational > > > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > > an > > Informational RFC. However, the IESG doesn't approve of our modeling of > > management information. By this I assume they mean the attribute mechanism > > that we invented to handle the great variability between implementations. > > > > They also don't recognize the PWG as a standards making body according to > > the note. > > > > Tom > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: Wednesday, June 09, 1999 3:02 PM > > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > > as an Informational RFC. This > > document is the product of the Printer MIB Working Group. The IESG > > contact persons are Keith Moore and Patrik Faltstrom > > > > Note to RFC Editor: > > > > The IESG requests the following text be included as an IESG Note: > > > > This MIB module uses an unconventional scheme for modeling > > management information (on top of the SNMP model) which is unique to > > this MIB. The IESG recommends against using this document as an > > example for the design of future MIBs. > > > > The "Printer Working Group" industry consortium is not an IETF > > working group, and the IETF does not recognize the Printer Working > > Group as a standards-setting body. This document is being published > > solely to provide information to the Internet community regarding a > > MIB that might be deployed in the marketplace. Publication of > > this document as an RFC is not an endorsement of this MIB. > From hastings at cp10.es.xerox.com Thu Jun 10 14:54:46 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <918C79AB552BD211A2BD00805F15CE85014EB29C@x-crt-es-ms1.cp10.es.xerox.com> Joe, What about the Job Monitoring MIB V2 that has the attribute support bit vector and the mirror table? Don't they solve your problem? I would assume that such a paper would also include the description of Job Monitoring MIB V2 as well. Thanks, Tom -----Original Message----- From: Filion, Joseph L Sent: Thursday, June 10, 1999 11:51 To: Caruso, Angelo; Hastings, Tom N Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Joe.Filion at usa.xerox.com Thu Jun 10 14:51:13 1999 From: Joe.Filion at usa.xerox.com (Filion, Joseph L) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911012A8753@USA0834MS1> Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From Joe.Filion at usa.xerox.com Fri Jun 11 08:18:17 1999 From: Joe.Filion at usa.xerox.com (Filion, Joseph L) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911012A8756@USA0834MS1> Tom (and Ang), Yes, the attribute support bit vector and the mirror table do go a long way towards solving our problem. I guess I understood Angelo's proposal to mean that a description of the structure of the model would be written independent of an instance of that model; so I wouldn't expect to see a description of the Job Monitoring MIB V2 in that description. Would you think the paper being proposed would include descriptions of the attribute vector and mirror tables? JLF -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, June 10, 1999 2:55 PM To: Filion, Joseph L; Caruso, Angelo Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Joe, What about the Job Monitoring MIB V2 that has the attribute support bit vector and the mirror table? Don't they solve your problem? I would assume that such a paper would also include the description of Job Monitoring MIB V2 as well. Thanks, Tom -----Original Message----- From: Filion, Joseph L Sent: Thursday, June 10, 1999 11:51 To: Caruso, Angelo; Hastings, Tom N Cc: jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom and Ang, Maybe publishing a separate stand-alone document describing the new model would help (or would have helped), but let's not loose sight of some of the real issues with the model itself. One issue that continues to bother me is if you want to get all the information that a printer knows about a job it is real easy to get from a MIB that uses this model; but if you want to get two or three specific attributes for all of the jobs, it is very difficult to do efficiently with this model. Let's face it, we can all think of management side applications that want to do exactly this, and they cannot be done without retrieving every bit of data from the table. I am not saying that this model is not without its merit; I would just like to make sure that all the pros and cons are on the table. Thanks, JLF -----Original Message----- From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] Sent: Thursday, June 10, 1999 8:54 AM To: Hastings, Tom N; jmp Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Tom, Perhaps the IETF is taking issue with the fact that we invented a new information model, built on top of SNMP/SMI, and then just went ahead and implemented the first instance of this new model, all in one MIB module. Perhaps we should have published a generic definition of the new model first as a stand-alone document, and then published the JMP MIB as an example implementation. Thanks, Ang -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, June 09, 1999 7:29 PM To: jmp Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informational The PWG Job Monitoring MIB has been approved by the IESG to be sent out as an Informational RFC. However, the IESG doesn't approve of our modeling of management information. By this I assume they mean the attribute mechanism that we invented to handle the great variability between implementations. They also don't recognize the PWG as a standards making body according to the note. Tom -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, June 09, 1999 3:02 PM Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org Subject: Document Action: Job Monitoring MIB - V1 to Informational The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' as an Informational RFC. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom Note to RFC Editor: The IESG requests the following text be included as an IESG Note: This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. From rbergma at dpc.com Fri Jun 11 10:55:16 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional In-Reply-To: <61E69E92EA1CD211B94700805F65B911012A8756@USA0834MS1> Message-ID: Joe, I agree with your conslusion that this paper should only describe the attribute model. The statement from Tom, that you replied to, appears to imply that this paper would be more of a description of the Job Monitoring MIB model. The Job MIB model appears to adequately covered in the MIB document. But the background and rationale for the attribute objects are not. I have started such a paper and will try to post this initial draft next week. Ron Bergman Hitachi Koki Imaging Solutions On Fri, 11 Jun 1999, Filion, Joseph L wrote: > Tom (and Ang), > > Yes, the attribute support bit vector and the mirror table do go a long way > towards solving our problem. I guess I understood Angelo's proposal to mean > that a description of the structure of the model would be written > independent of an instance of that model; so I wouldn't expect to see a > description of the Job Monitoring MIB V2 in that description. Would you > think the paper being proposed would include descriptions of the attribute > vector and mirror tables? > > JLF > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Thursday, June 10, 1999 2:55 PM > To: Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Joe, > > What about the Job Monitoring MIB V2 that has the attribute support bit > vector and the mirror table? Don't they solve your problem? > > I would assume that such a paper would also include the description of Job > Monitoring MIB V2 as well. > > Thanks, > Tom > > -----Original Message----- > From: Filion, Joseph L > Sent: Thursday, June 10, 1999 11:51 > To: Caruso, Angelo; Hastings, Tom N > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom and Ang, > > Maybe publishing a separate stand-alone document describing the new model > would help (or would have helped), but let's not loose sight of some of the > real issues with the model itself. One issue that continues to bother me is > if you want to get all the information that a printer knows about a job it > is real easy to get from a MIB that uses this model; but if you want to get > two or three specific attributes for all of the jobs, it is very difficult > to do efficiently with this model. Let's face it, we can all think of > management side applications that want to do exactly this, and they cannot > be done without retrieving every bit of data from the table. I am not > saying that this model is not without its merit; I would just like to make > sure that all the pros and cons are on the table. > > Thanks, > JLF > > -----Original Message----- > From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] > Sent: Thursday, June 10, 1999 8:54 AM > To: Hastings, Tom N; jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just went ahead and > implemented the first instance of this new model, all in one MIB module. > Perhaps we should have published a generic definition of the new model first > as a stand-alone document, and then published the JMP MIB as an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > > The PWG Job Monitoring MIB has been approved by the IESG to be sent out as > an > Informational RFC. However, the IESG doesn't approve of our modeling of > management information. By this I assume they mean the attribute mechanism > that we invented to handle the great variability between implementations. > > They also don't recognize the PWG as a standards making body according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. > From rbergma at dpc.com Thu Jun 24 16:23:59 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> PMP> Document Action: Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB to Informational (fwd) Message-ID: Thanks to all who worked to make this happen. We finally completed this effort! Ron Bergman Hitachi Koki Imaging Solutions ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 07:07:59 -0400 From: The IESG To: IETF-Announce: ;, ";;"@ns.cnri.reston.va.us, pwg.org@mailgate.dpc.com, "dpc.com;"@unspecified-domain Cc: RFC Editor , Internet Architecture Board , pmp@pwg.org Subject: PMP> Document Action: Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB to Informational The IESG has approved the Internet-Draft 'Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB' as a Informational. This document is the product of the Printer MIB Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom From Mike.Elvers at usa.xerox.com Fri Jun 25 16:08:31 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023DC@USA0834MS1> Tom (and Ang), I disagree with Joe that these extra tables "go a long way" towards solving our problems. I only see them solving a narrow problem of being able to acquire a column of data (the same attribute for multiple jobs). This in not what we do in the normal course of monitoring a single job. We acquire rows of data and the mirror table does nothing to help that problem. The support bit vector provides a small degree of help in that we know for sure which attributes NOT to look for. It is no guarantee that a given attribute actually does exist though. Mike > -----Original Message----- > From: Filion, Joseph L > Sent: Friday, June 25, 1999 2:00 PM > To: Elvers, Mike > Subject: FW: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > > > -----Original Message----- > From: Filion, Joseph L > Sent: Friday, June 11, 1999 8:18 AM > To: Hastings, Tom N; Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom (and Ang), > > Yes, the attribute support bit vector and the mirror table do > go a long way towards solving our problem. I guess I > understood Angelo's proposal to mean that a description of > the structure of the model would be written independent of an > instance of that model; so I wouldn't expect to see a > description of the Job Monitoring MIB V2 in that description. > Would you think the paper being proposed would include > descriptions of the attribute vector and mirror tables? > > JLF > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Thursday, June 10, 1999 2:55 PM > To: Filion, Joseph L; Caruso, Angelo > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Joe, > > What about the Job Monitoring MIB V2 that has the attribute > support bit > vector and the mirror table? Don't they solve your problem? > > I would assume that such a paper would also include the > description of Job > Monitoring MIB V2 as well. > > Thanks, > Tom > > -----Original Message----- > From: Filion, Joseph L > Sent: Thursday, June 10, 1999 11:51 > To: Caruso, Angelo; Hastings, Tom N > Cc: jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom and Ang, > > Maybe publishing a separate stand-alone document describing > the new model > would help (or would have helped), but let's not loose sight > of some of the > real issues with the model itself. One issue that continues > to bother me is > if you want to get all the information that a printer knows > about a job it > is real easy to get from a MIB that uses this model; but if > you want to get > two or three specific attributes for all of the jobs, it is > very difficult > to do efficiently with this model. Let's face it, we can all think of > management side applications that want to do exactly this, > and they cannot > be done without retrieving every bit of data from the table. I am not > saying that this model is not without its merit; I would just > like to make > sure that all the pros and cons are on the table. > > Thanks, > JLF > > -----Original Message----- > From: Caruso, Angelo [mailto:Angelo.Caruso@usa.xerox.com] > Sent: Thursday, June 10, 1999 8:54 AM > To: Hastings, Tom N; jmp > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Tom, > > Perhaps the IETF is taking issue with the fact that we invented a new > information model, built on top of SNMP/SMI, and then just > went ahead and > implemented the first instance of this new model, all in one > MIB module. > Perhaps we should have published a generic definition of the > new model first > as a stand-alone document, and then published the JMP MIB as > an example > implementation. > > Thanks, > Ang > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, June 09, 1999 7:29 PM > To: jmp > Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informational > > > The PWG Job Monitoring MIB has been approved by the IESG to > be sent out as > an > Informational RFC. However, the IESG doesn't approve of our > modeling of > management information. By this I assume they mean the > attribute mechanism > that we invented to handle the great variability between > implementations. > > They also don't recognize the PWG as a standards making body > according to > the note. > > Tom > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, June 09, 1999 3:02 PM > Cc: RFC Editor; Internet Architecture Board; pmp@pwg.org > Subject: Document Action: Job Monitoring MIB - V1 to Informational > > > > > The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1' > as an Informational > RFC. This > document is the product of the Printer MIB Working Group. The IESG > contact persons are Keith Moore and Patrik Faltstrom > > > Note to RFC Editor: > > The IESG requests the following text be included as an IESG Note: > > This MIB module uses an unconventional scheme for modeling > management information (on top of the SNMP model) which is > unique to > this MIB. The IESG recommends against using this document as an > example for the design of future MIBs. > > The "Printer Working Group" industry consortium is not an IETF > working group, and the IETF does not recognize the Printer Working > Group as a standards-setting body. This document is being > published > solely to provide information to the Internet community regarding a > MIB that might be deployed in the marketplace. Publication of > this document as an RFC is not an endorsement of this MIB. > From imcdonal at sdsp.mc.xerox.com Sat Jun 26 15:53:49 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <199906261953.PAA10451@appsrv5.sdsp.mc.xerox.com> Hi Mike, (don't throw stones yet...) What if we added a bit vector to EACH job that says 'one or more instances of this job attribute are CURRENTLY instantiated on this job'? Maintaining this bit vector (a parallel subset of the support vector at all times) doesn't seem that costly to an agent and it *seems* to help with your concerns. Thoughts? - Ira McDonald From rbergma at dpc.com Mon Jun 28 11:39:30 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From rbergma at dpc.com Mon Jun 28 11:39:50 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Mon Jun 28 13:25:46 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> Job MIB Editorial Changes Message-ID: <918C79AB552BD211A2BD00805F15CE8501673345@x-crt-es-ms1.cp10.es.xerox.com> I'll make those changes with the RFC Editor. Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, June 28, 1999 08:40 To: Tom Hastings Cc: jmp@pwg.org Subject: JMP> Job MIB Editorial Changes Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From rbergma at dpc.com Mon Jun 28 16:14:13 1999 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Editorial Changes to the Job MIB Message-ID: Tom, I have noticed two editorial issues in the Job MIB that should be corrected before the document is published. The document should be in the RFC Editor's queue by now. Could you contact the RFC Editor concerning these issues? 1. The Table of Contents is incorrect from section 8 forward. The Table of Contents skips "8 Notices" and lists "8 Authors Addresses" which is really section 9. 2. The "10 Change History" section should be removed. This section was very useful information for the PWG during the development of the MIB and was helpful for the IESG review, but it makes no sense in the first version of an IETF document. All of the changes listed are editorial and it is not essential to maintain this information for those who have implemented to the original "version 1.0". (This information will always be available in the copy of the Internet- Draft archive on the PWG web site.) When we work on version 2.0 (or 1.1 or whatever) we will definitely need to include the differences from version 1.0 in the new document. Ron Bergman Hitachi Koki Imaging Solutions From Mike.Elvers at usa.xerox.com Tue Jun 29 09:40:40 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E2@USA0834MS1> Ira, This isn't exactly a stone, more like a pebble, but, how may more bit vectors do we need to add before we throw up the white flag and say this attribute method of MIB specification was not a good idea? I can immediately come up with at least one more useful bit vector. This one will let us know which attributes actually are currently multi-instanced. Of course none of the bit vectors is ever going to answer the question "What is the meaning (significance, point, ???) of each instance without any given or know previous knowledge?". Mike > -----Original Message----- > From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] > Sent: Saturday, June 26, 1999 3:54 PM > To: Joe.Filion@usa.xerox.com; Mike.Elvers@usa.xerox.com > Cc: Angelo.Caruso@usa.xerox.com; hastings@cp10.es.xerox.com; > jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Hi Mike, > > (don't throw stones yet...) What if we added a bit vector to EACH > job that says 'one or more instances of this job attribute are > CURRENTLY instantiated on this job'? Maintaining this bit vector > (a parallel subset of the support vector at all times) doesn't > seem that costly to an agent and it *seems* to help with your > concerns. > > Thoughts? > - Ira McDonald > > From imcdonal at sdsp.mc.xerox.com Tue Jun 29 10:53:24 1999 From: imcdonal at sdsp.mc.xerox.com (Ira McDonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <199906291453.KAA22533@appsrv5.sdsp.mc.xerox.com> Hi Mike, OK - I see that you don't want to get a useful method for accessing attribute-based MIBs. I think this is unfortunate, because (among other things) LDAP and SLP are becoming common in deployment and they have 'open-ended' objects which have a (few) Mandatory attributes and a (lot of) Optional attributes. My work in the XCMI Comms Config MIB since last December on the Comms Directory Record and Comms Directory Attribute/String tables allows a direct representation in the MIB of an LDAP or SLP 'named object' with a bunch of attributes. We can't possibly constrain the accesses of Xerox network devices to rigid sets of mandatory attributes in LDAP objects, so I was hoping for more refinement to arise here on the PWG Job Mon MIB that was useful in the XCMI CC Directory, HRX Device Detail, and Svc Mon Service Detail applications. I realize that 'jobs' (because they are very dynamic in their attributes present and attribute values over short intervals) are quite different from essentially all 'resource' objects (servers, repositories, etc). There are many more 'jobs' of interest and they have to be presented to the end user in a GUI because they ARE dynamic. I hope we can work to make use of the HRX and Svc Mon Detail groups and the newer CC Directory groups as useful as possible to SNMP agent implementors as well as native and Web client implementors. Cheers, - Ira From Mike.Elvers at usa.xerox.com Tue Jun 29 14:25:59 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E4@USA0834MS1> Ira, You know better than that! Of course I want to make MIBs USEFUL. However, continuing to put bandaides on a bleeding patient does not make that patient well. There are some serious peformance and usability issues with this approach for doing job monitoring which I feel obligated to point out. For example, as of yet, no one has addressed the issue of the semantics of having multiple values. It won't do any good to just harp at me. My concerns warrent being addressed in a profession and civilized manner! Mike > -----Original Message----- > From: Ira McDonald [mailto:imcdonal@sdsp.mc.xerox.com] > Sent: Tuesday, June 29, 1999 10:53 AM > To: Joe.Filion@usa.xerox.com; Mike.Elvers@usa.xerox.com; > imcdonal@sdsp.mc.xerox.com > Cc: Angelo.Caruso@usa.xerox.com; hastings@cp10.es.xerox.com; > jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > Hi Mike, > > OK - I see that you don't want to get a useful method for > accessing attribute-based MIBs. I think this is unfortunate, > because (among other things) LDAP and SLP are becoming common > in deployment and they have 'open-ended' objects which have a > (few) Mandatory attributes and a (lot of) Optional attributes. > > My work in the XCMI Comms Config MIB since last December on > the Comms Directory Record and Comms Directory Attribute/String > tables allows a direct representation in the MIB of an LDAP > or SLP 'named object' with a bunch of attributes. We can't > possibly constrain the accesses of Xerox network devices to > rigid sets of mandatory attributes in LDAP objects, so I was > hoping for more refinement to arise here on the PWG Job Mon > MIB that was useful in the XCMI CC Directory, HRX Device Detail, > and Svc Mon Service Detail applications. > > I realize that 'jobs' (because they are very dynamic in their > attributes present and attribute values over short intervals) > are quite different from essentially all 'resource' objects > (servers, repositories, etc). There are many more 'jobs' > of interest and they have to be presented to the end user > in a GUI because they ARE dynamic. > > I hope we can work to make use of the HRX and Svc Mon Detail > groups and the newer CC Directory groups as useful as possible > to SNMP agent implementors as well as native and Web client > implementors. > > Cheers, > - Ira > > From harryl at us.ibm.com Tue Jun 29 17:38:56 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <8725679F.0076F9A6.00@d53mta05h.boulder.ibm.com> The Job MIB is working just fine for us. Harry Lewis IBM Printing Systems harryl@us.ibm.com From Mike.Elvers at usa.xerox.com Tue Jun 29 17:44:34 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to Informat ional Message-ID: <61E69E92EA1CD211B94700805F65B911F023E8@USA0834MS1> Harry, I'm glad to here that. However, I would have to know how you are using it before I could reach any conclusions. Are you prepared to discuss details about your client implementation? Mike > -----Original Message----- > From: harryl@us.ibm.com [mailto:harryl@us.ibm.com] > Sent: Tuesday, June 29, 1999 5:39 PM > To: Elvers, Mike > Cc: 'Ira McDonald'; Filion, Joseph L; Elvers, Mike; Caruso, Angelo; > Hastings, Tom N; jmp@pwg.org > Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to > Informat ional > > > > > The Job MIB is working just fine for us. > > Harry Lewis > IBM Printing Systems > harryl@us.ibm.com > > From hastings at cp10.es.xerox.com Fri Jul 30 17:09:24 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> 25-word Abstract for PWG Job Monitoring MIB for my MFPA Presentat ion, Oct 26 Message-ID: <918C79AB552BD211A2BD00805F15CE850198E959@x-crt-es-ms1.cp10.es.xerox.com> Ray, Here is the 25-word Abstract for the PWG Job Monitoring MIB for my MFPA session presentation, October 26, in Boston: "The PWG Job Monitoring MIB is an approved Printer Working Group standard that allows monitoring of jobs using SNMP for any job submission protocol". Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Thursday, July 29, 1999 17:42 To: Raymond Lutz Cc: Hastings, Tom N; Rahgozar, Armon; bwagner@digprod.com; Harry Lewis Subject: Re: I'll present Job MIB and IPP; but conflict with IPP Presentation and IPP meeting Raymond, Here is an abstract for the Finisher MIB: "The Finisher MIB is a proposed extension to the Printer MIB (RFC1759) that allows management of printer finishing device subunits using SNMP." Ron On Thu, 29 Jul 1999, Raymond Lutz wrote: > Tom: > I've reorganized the sessions so that the guys that would be best as > speakers won't be in conflict with the PWG as much as possible, and > included your sessions. Please provide a 25-word abstract of each one ASAP. > Thanks for your help! > -raymond > From hastings at cp10.es.xerox.com Wed Oct 6 04:05:45 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> Slides describing the PWG Job Monitoring MIB have been posted Message-ID: <918C79AB552BD211A2BD00805F15CE8501ECDDC1@x-crt-es-ms1.cp10.es.xerox.com> I've posted a set of slides (27) that describe the PWG Job Monitoring MIB. I will be presenting these slides at the MFPA IOC Conference in Boston, on October 25-26. It gives an overview of the PWG Job Monitoring MIB. The slides are available locally at: ftp://ftp.pwg.org/pub/pwg/jmp/slides/CAP-MFPA-1999-pwg-job-monitoring-mib.pp t Tom From imcdonal at sdsp.mc.xerox.com Sun Oct 10 22:59:25 1999 From: imcdonal at sdsp.mc.xerox.com (Ira Mcdonald) Date: Wed May 6 14:00:17 2009 Subject: JMP> NOT - IPP Notify over SNMP (extension to PWG Job Mon MIB) Message-ID: <199910110259.WAA28029@appsrv1.sdsp.mc.xerox.com> Hi folks, Sunday (10 October 1999) I've just posted a short I-D style document (15 pages, of which 4 matter) that maps IPP Notifications over SNMP via two new traps (Printer and Job) to be added to the PWG Job Monitoring MIB: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-over-snmp-991010.txt Comments are welcome (I'll be away from my email for the next week, so don't mind if I don't reply right away). Cheers, - Ira McDonald High North Inc From harryl at us.ibm.com Tue Nov 23 10:47:53 1999 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:17 2009 Subject: JMP> Re: PWG-ANNOUNCE> Job Monitoring MIB now Available Message-ID: <87256832.0056D038.00@d53mta05h.boulder.ibm.com> Wonderful! We do not see the need for the mirror table but will consider supporting it's future inclusion if it means greater chance for wider adoption of the standard. Harry Lewis IBM Printing Systems Ron Bergman Sent by: owner-pwg-announce@pwg.org 11/22/99 04:36 PM To: pwg-announce@pwg.org cc: Subject: PWG-ANNOUNCE> Job Monitoring MIB now Available The Job Monitoring MIB is now available as RFC2707.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2707.txt The companion mapping document has also been published as RFC2708.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2708.txt The official announcement should be made by the IETF in the next day or so. (But I couldn't wait ;-) Thanks again to everyone who helped make this happen! We now need to determine if there is sufficient interest to pursue the addition of the Xerox Attribute Mirror table and any other updates. Please reply if this subject is of interest or if you strongly object to any further Job MIB work. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Tue Nov 23 17:57:11 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: PWG-ANNOUNCE> Job Monitoring MIB now Available [RFC 2707 and 2708; reference to mirror table and traps] Message-ID: <918C79AB552BD211A2BD00805F15CE8502514709@x-crt-es-ms1.cp10.es.xerox.com> We're supposed to discuss announcements on the specific list that deals with the subject. So here is Ira's comments on the JMP Announcement. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, November 22, 1999 19:02 To: 'Ron Bergman'; pwg-announce@pwg.org Subject: RE: PWG-ANNOUNCE> Job Monitoring MIB now Available Hi Ron, I saw this a few minutes after it was posted this morning, but resisted the urge to announce it to JMP (knowing you were watching the status as JMP WG chair). Hooray! Although I'm no longer working with Xerox (well...mostly), I support work on the Mirror Attribute group. I *think* there will be interest here at Sharp in the Mirror Attribute group (because it addresses the problems of data modelling different from traditional SNMP MIBs that caused the little IESG disclaimer on page 1 of RFC 2707 *and* because it addresses performance problems identified with Job Mon MIB v1.0). I'd also like to remind folks that the current work on IPP Notifications over SNMP consists (at the suggestion of Ron Bergman) of a small extension to the Job Mon MIB to add two traps and a few leaf objects for the trap bindings. As this work matures in the IPP WG, we will want to update the Job Mon MIB text to incorporate it I think - although it *could* be published as a separate compilable extension (since the changes are wholly in new object and notification groups). Cheers, - Ira McDonald High North -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, November 22, 1999 3:36 PM To: pwg-announce@pwg.org Subject: PWG-ANNOUNCE> Job Monitoring MIB now Available The Job Monitoring MIB is now available as RFC2707.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2707.txt The companion mapping document has also been published as RFC2708.txt. The full URL is: ftp://ftp.isi.edu/in-notes/rfc2708.txt The official announcement should be made by the IETF in the next day or so. (But I couldn't wait ;-) Thanks again to everyone who helped make this happen! We now need to determine if there is sufficient interest to pursue the addition of the Xerox Attribute Mirror table and any other updates. Please reply if this subject is of interest or if you strongly object to any further Job MIB work. Ron Bergman Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Wed Dec 1 21:43:17 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Message-ID: <4BB1E365BF26D311914A00805FA6A1C1264BCA@admsrvnt02> Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From products at newideas-inventions.com Tue Dec 7 16:18:48 1999 From: products at newideas-inventions.com (Don Fass) Date: Wed May 6 14:00:17 2009 Subject: JMP> Important Notice for Prototypers and Professionals in Related Fields Message-ID: <419.436501.67651296products@newideas-inventions.com> Http://www.newideas-inventions.com Dear Prototypers, New Ideas is recognized worldwide as a company able to help you lockup that product line, expand the amount of the order, then provide your organization with consistent repeat residuals infinitum. Your client will learn how to distribute his own proprietary product all over the world from his bedroom in his shorts. Yes, he will benefit from speaking to us. But just as importantly, so will YOU. Moreover, we have ways to influence venture capital acquisition. So, do you have a client with an invention that needs to be launched? We have the designers, prototypers and fabricators able to launch new products instantly, affordably and differently. We naturally see all the new inventions from their embryo stage. As the leading new product development and marketing firm in America, we have an amazing track-record in many fields for example: OraFresh – the amazing tongue cleaner that eliminates bad breath, 44 years ago I launched that famous Adjustable Table that today rolls over each and every hospital bed in the world - at least two in every room; 4.1 million Love Ring sales; countless Photo Wristwatches sold. We developed and marketed the Desert Storm T-shirt, the Christopher Columbus Quincentennial; 1.2 million Black Last Suppers and 7.6 million Panic Button Carbon Monoxide Detectors. Profitably yours, Don Fass http://www.newideas-inventions.com If this information is of no interest to you and you wish your address removed, kindly send an email to products@newideas-inventions.com P.S. For those who are receiving a duplicate message we apologize. New Ideas Staff From hastings at cp10.es.xerox.com Mon Dec 13 14:38:59 1999 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:17 2009 Subject: JMP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [.pdf post ed] Message-ID: <918C79AB552BD211A2BD00805F15CE85025150E5@x-crt-es-ms1.cp10.es.xerox.com> I've posted the .pdf version of the I-D as requested (with line numbers added): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.pdf Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, December 10, 1999 13:05 To: imcdonald@sharplabs.com Cc: ipp@pwg.org Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Ira: Could you create a PDF version of this document? When printed using a browser, all the page breaks are messed up making it very hard to read. Thanks! ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** imcdonald%sharplabs.com@interlock.lexmark.com on 12/06/99 07:49:42 PM To: cmanros%cp10.es.xerox.com@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Hi folks, Monday (6 December 1999) URLs for our revised 'IPP Notifications over SNMP' (1 Dec 1999): ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-over-snmp-01.txt or ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt This document supports full-fidelity IPP notifications over SNMP (any version of SNMP) by defining new printer and job traps for the existing PWG Job Monitoring MIB (RFC 2707, November 1999). Cheers, - Ira McDonald (High North Inc, consultant at Sharp Labs America) Tom Hastings (Xerox Corporation) -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, December 06, 1999 4:25 PM To: IETF-IPP Subject: IPP> ADM - IPP Phone Conference December 8, 1999 IPP Phone Conference - 991103 ============================= We will hold our next IPP phone conference on Wednesday, December 8. We will discuss the following subjects: - Latest input on the Set 2 and Set 3 Optional Operations - Latest input on the IPP Notifications - Nail the Agenda for the IPP meeting in LA next week A number of people registered late, but it looks like we will have some 20 people attending the IPP meeting. Here is the dial-in information: Time: December 8, 1999 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-888-749-8496 (8*534-8273 for Xerox folks) Passcode: 86037# Carl-Uno Carl-Uno Manros Principal Engineer - Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, December 01, 1999 18:43 To: 'ipp@pwg.org'; 'jmp@pwg.org' Cc: McDonald, Ira Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Dec 13 16:46:03 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [ .pdf post ed] Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FE9A@MAILSRVNT02> Hi folks, Thanks, Tom, for distilling this document into PDF for me. In the IPP WG meeting this week and in email notes, please make any comments on the line-numbered PDF version (which faithfully follows the text version in pagination and lines per page). Cheers, - Ira McDonald (outside consultant at Sharp) High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, December 13, 1999 11:39 AM To: don@lexmark.com; imcdonald@sharplabs.com Cc: ipp@pwg.org; jmp Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted [.pdf post ed] I've posted the .pdf version of the I-D as requested (with line numbers added): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.pdf Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, December 10, 1999 13:05 To: imcdonald@sharplabs.com Cc: ipp@pwg.org Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Ira: Could you create a PDF version of this document? When printed using a browser, all the page breaks are messed up making it very hard to read. Thanks! ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** imcdonald%sharplabs.com@interlock.lexmark.com on 12/06/99 07:49:42 PM To: cmanros%cp10.es.xerox.com@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> ADM - IPP Phone Conference December 8, 1999 Hi folks, Monday (6 December 1999) URLs for our revised 'IPP Notifications over SNMP' (1 Dec 1999): ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-over-snmp-01.txt or ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt This document supports full-fidelity IPP notifications over SNMP (any version of SNMP) by defining new printer and job traps for the existing PWG Job Monitoring MIB (RFC 2707, November 1999). Cheers, - Ira McDonald (High North Inc, consultant at Sharp Labs America) Tom Hastings (Xerox Corporation) -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, December 06, 1999 4:25 PM To: IETF-IPP Subject: IPP> ADM - IPP Phone Conference December 8, 1999 IPP Phone Conference - 991103 ============================= We will hold our next IPP phone conference on Wednesday, December 8. We will discuss the following subjects: - Latest input on the Set 2 and Set 3 Optional Operations - Latest input on the IPP Notifications - Nail the Agenda for the IPP meeting in LA next week A number of people registered late, but it looks like we will have some 20 people attending the IPP meeting. Here is the dial-in information: Time: December 8, 1999 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-888-749-8496 (8*534-8273 for Xerox folks) Passcode: 86037# Carl-Uno Carl-Uno Manros Principal Engineer - Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, December 01, 1999 18:43 To: 'ipp@pwg.org'; 'jmp@pwg.org' Cc: McDonald, Ira Subject: IPP> NOT - Revised 'IPP Notifications over SNMP' I-D posted Copies: IPP WG JMP WG Hi folks, Wednesday (1 December 1999) I've just sent an updated version of 'IPP Notifications over SNMP' to the Internet-Drafts editor and posted a shadow copy on the PWG server: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-01.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (8 December) at 10-12 PST / 1-3 EST. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (3 November 1999) - see change log below. Cheers, - Ira McDonald High North Inc [PS - Windows utilities ate the formfeeds at the top of second and subsequent pages when I mailed the document to Cynthia Clark (I-D Editor) just now as a text body. *However* the above pointer to the PWG FTP server copy contains the correct text, including formfeeds (and I did a rename to make sure the filename case was correct). In the immediate future, I'll get a Linux or Solaris user and email account here at Sharp Labs so that this help (???) from Windows tools and MS Exchange mail servers no longer happens. Stay tuned...] ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 1 December 1999 1) Deleted 'JmTriggerEventTC' textual convention (see below). 2) Revised SYNTAX of 'jmEventTriggerEvent' object from 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to support use of IPP standard keywords. 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects for consistency w/ [IPP-NOT] and to reduce ambiguity about printer states inherent in RFC 1759. 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to add SHOULD (recommendation) for 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 5) Revised 'SNMP Mapping for IPP Printer Events' section to add direct mapping of IPP notification attributes to 'jmEventPrinterState', 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs' objects. 6) Revised 'Rules for Encoding Notifications' section to add 'jmEventPrinterState' and 'jmEventPrinterStateReasons'. 7) Revised 'IANA Considerations' section to specify there are none - no enumerated or keyword textual conventions are now defined in this document. 8) Revised 'Internationalization Considerations' section to specify that US English keywords are used in 'jmEventTriggerEvent', 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects and thus no explicit natural language tagging is required. - 10 October 1999 1) Initial version. ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Wednesday (1 December 1999) IPP: Please place this document in the Internet-Drafts repository as: (December 1999) It replaces the previous: (October 1999) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Dec 21 18:31:49 1999 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> Final edits to Printer MIB v2 - fix broken names Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEB0@MAILSRVNT02> Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 22 11:27:44 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68D8@USA0834MS1> Ira, I am working on getting the enumeration descrepancies out today. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 22 13:24:34 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68D9@USA0834MS1> I'm afraid I won't finish this until tomorrow. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: Elvers, Mike Sent: Wednesday, December 22, 1999 11:28 AM To: 'McDonald, Ira'; 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; Hastings, Tom N; Elvers, Mike; Filion, Joseph L; Gloger, Paul; Whittle, Craig Subject: RE: Final edits to Printer MIB v2 - fix broken names Ira, I am working on getting the enumeration descrepancies out today. Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc From Mike.Elvers at usa.xerox.com Wed Dec 29 11:20:37 1999 From: Mike.Elvers at usa.xerox.com (Elvers, Mike) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: Final edits to Printer MIB v2 - fix broken names Message-ID: <61E69E92EA1CD211B94700805F65B911025B68DC@USA0834MS1> I was finally able to complete the listing of enumeration changes between version 1 and version 2 of the Printer MIB (RFC17659). Please see the listed items below. I did this is textual mode for those of you who don't have an appropriate email tool for handling attachments or enhanced text. This list includes everything that is different between an enumeration that existed in version 1 and the new definition in version 2. I have not listed new values or any unchanged old values. I have listed the object that defines the enumeration for clarity. I am providing this information so the people are aware of the extent of the changes that were made. I am not suggesting all of these should not be made. In some cases, where spelling is the motivator, (as in the PrtAlertGroupTC or PrtInterpreterLangFamilyTC values) I could see where those kind of changes would be desirable. However, in the cases where it is simple a tense issue or where items were actually deleted, I would suggest that these be reconsidered and thought given to if these are, in fact, essential and necessary. Printer MIB v1 Printer MIB v2 -------------- -------------- prtAlertCode PrtAlertCodeTC coverOpen = 3 coverOpened = 3 interlockOpen = 5 interlockOpened = 5 configurationChange = 7 configurationChanged = 7 jam = 8 jammed = 8 powerUp = 503 poweredUp = 503 powerDown = 504 poweredDown = 504 inputMediaSizeChange = 802 inputMediaSizeChanged = 802 inputMediaWeightChange = 803 inputMediaWeightChanged = 803 inputMediaTypeChange = 804 inputMediaTypeChanged = 804 inputMediaColorChange = 805 inputMediaColorChanged = 805 interpreterMemoryIncrease = 1501 interpreterMemoryIncreased = 1501 interpreterMemoryDecrease = 1502 interpreterMemoryDecreased = 1502 prtAlertGroup PrtAlertGroupTC hostResourceMIBStorageTable = 3 hostResourcesMIBStorageTable = 3 hostResourceMIBDeviceTable = 4 hostResourcesMIBDeviceTable = 4 prtAlertSeverityLevel PrtAlertSeverityLevelTC critical = 3 criticalBinaryChangeEvent = 3 warning = 4 warningUnaryChangeEvent = 4 prtChannelType PrtChannelTypeTC chDCERemoteProcCall = 22 chONCRemoteProcCall = 23 chOLE = 24 chNamedPipe = 25 chDPMF = 28 chPSM = 28 chDLLAPI = 29 chVxDAPI = 30 prtConsoleDisable prtConsoleDisable enabled = 3 operatorConsoleEnabled = 3 disabled = 4 operatorConsoleDisabled = 4 prtCoverStatus PrtCoverStatusTC doorOpen = 3 coverOpen = 3 doorClosed = 4 coverClosed = 4 prtInterpreterLangFamily PrtInterpreterLangFamilyTC langImPress = 33 langimPress = 33 prtMarkerMarkTech PrtMarkerMarkTechTC electroPhotographicLED = 3 electrophotographicLED = 3 electroPhotographicLaser = 4 electrophotographicLaser = 4 electroPhotographicOther = 5 electrophotographicOther = 5 impactMovingHeadDotMatrix9Pin = 6 impactMovingHeadDotMatrix9pin = 6 impactMovingHeadDotMatrix24Pin = 7 impactMovingHeadDotMatrix24pin = 7 prtMediaPathMaxSpeedPrintUnit PrtMediaPathMaxSpeedPrintUnitTC feetPerhour = 16 feetPerHour = 16 prtOutputType PrtOutputTypeTC mailbox = 6 mailBox = 6 subUnitStatus PrtSubUnitStatusTC intendedStateIsOnLine 0 stateIsOnLine 0 intendedStateIsOffLine 32 stateIsOffLine 32 atIntendedState 0 currentlyAtIntendedState 0 transitiioningToIntendedState 64 transitioningToIntendedState 64 Mike X Mike Elvers The Document Company Xerox 200 Crosskeys Office Park M/S 815-000 Fairport, New York 14450 Phone: 716-425-6449 Intelnet: 8*225-6449 Email: mailto:mike.elvers@usa.xerox.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 21, 1999 6:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com'; 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com'; 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com'; 'pgloger@cp10.es.xerox.com'; McDonald, Ira; Whittle, Craig Subject: Final edits to Printer MIB v2 - fix broken names Hi Harry Lewis and PMP folks, I've just learned from Ron Bergman (PMP chair) that the IETF Host Resources MIB v2 is 'close' to moving forward to IESG 'last call', after Steve Waldbusser's recent work. BEFORE we send the final text of the Printer MIB v2 to the IESG, I urge that we restore to original Printer MIB (RFC 1759) names: 1) Several textual conventions originally from Printer MIB v1 (RFC 1759), which were renamed with a 'Prt...' prefix - this breaks IMPORTS into other MIB modules; 2) Several enumeration labels originally from Printer MIB v1 (RFC 1759), which were renamed, apparently for clarity - this breaks open management stations and client tools. UNLESS the above corrections are made, it is IMPOSSIBLE to build a hybrid device or client software implementation, which conforms simultaneously to both Printer MIB v1 and Printer MIB v2. I don't have the detailed list here at the moment but Ron Bergman (Hitachi/Koki) has encountered the renamed textual conventions and Mike Elvers (Xerox) has encountered the renamed enumeration labels - they CAN supply the short list of corrections to be made. If you are not an implementor, you may not realize how serious the breakage is from these small name errors. If you are an implementor, you've already had to hand-edit the Printer MIB v2 text in order to proceed with your own development. These are NOT just hypothetical problems. Cheers, - Ira McDonald (outside consultant at Sharp Labs America) High North Inc