From imcdonald at sharplabs.com Tue Jan 11 16:47:51 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> FW: I-D ACTION:draft-ietf-snmpv3-update-mib-00.txt Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEE2@MAILSRVNT02> Hi folks, WARNING - the following document from the IETF SNMPv3 WG changes the syntax (type) of text objects in the System group of IETF MIB-II (RFC 1213) from 'DisplayString' (ASCII) to 'SnmpAdminString' (UTF-8 Unicode). This change was made at the explicit direction of the IESG, for conformance with 'IETF Policy on Character Sets and Languages' (RFC 2277). The IESG will no longer allow *any* MIB to be submitted for the Internet 'standards track' (or remain there for existing MIBs) unless all uses of 'DisplayString' (except language tag keywords from RFC 1766, which are *not* text) are changed to 'SnmpAdminString' (UTF-8 Unicode). This will definitely impact the Printer MIB v2 and Host Resources MIB v2 drafts when they are submitted to the IESG. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, January 11, 2000 3:40 AM Cc: snmpv3@lists.tislabs.com Subject: I-D ACTION:draft-ietf-snmpv3-update-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : Management Information Base for the Simple Network Management Protocol Author(s) R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser Filename : draft-ietf-snmpv3-update-mib-00.txt Pages : 29 Date : 10-Jan-00 This internet-draft, a work item of the SNMPv3 working group, is intended to obsolete RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-update-mib-00.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-snmpv3-update-mib-00.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-snmpv3-update-mib-00.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: Tue, 11 Jan 2000 13:56:38 -0800 Size: 933 Url: http://www.pwg.org/archives/jmp/attachments/20000111/43901443/attachment.mht From imcdonald at sharplabs.com Tue Jan 11 16:57:49 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> FW: [Details on change from ASCII to UTF-8 in MIB-II] Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEE3@MAILSRVNT02> Hi folks, Randy Presuhn (editor of the RFC 190x updates for the IETF SNMPv3 WG) has some good clarifications below. In particular, he observes that the 'over-the-wire' syntax of these objects does *not* change (always was the ASN.1 base type 'OCTET STRING'). Read on, if you're interested in the reasoning details. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] Sent: Tuesday, January 11, 2000 10:19 AM To: snmpv3@lists.tislabs.com Subject: Re: Issue 1907-18 proposed text Hi - > Message-Id: > In-Reply-To: <200001060232.SAA17791@dorothy.peer.com> > References: <200001060232.SAA17791@dorothy.peer.com> > Date: Mon, 10 Jan 2000 07:48:30 -0500 > To: Randy Presuhn , snmpv3@lists.tislabs.com > From: Robert Story > Subject: Re: Issue 1907-18 proposed text ... > I'm relatively new to this list, so I have missed the initial > discussion of this issue. Does anyone have a link to the list > archives and a timeframe for the initial discussion so I could catch > up? Given the disclaimer that I'm probably raising objections that > have already been raised (and possibly resolved), here's my two cents. There was fairly extensive discussion on the lists of the entity MIB working group. The thread started in July/August 1997. It revived in July and August of 1999, with concurrent discussion on the mibs@ops.ietf.org list. If there are problems accessing those archives, let me know and I'll see if I can distill out a relevant subset of the discussion. > I think that changing the semantics/syntax of an existing object is a > really bad idea. I can't tell you how many times I've had to explain > to a client that we couldn't change the syntax of an object once the > MIB was published. I don't relish the prospect of now having to tell > these clients that their existing agents/management applications need > to be updated because one of the standards has gone and changed the > semantics/syntax of an existing object. Neither the syntax nor the semantics would be changed. The syntax remains OCTET STRING. The semantics are laid out in the DESCRIPTION clause. The change is that a restriction in the permitted repertoire would be lifted. It's rather like the CCRs that prohibit tile roofs for houses in my neighborhood. There may have been a reason for such a restriction 25 years ago, but it no longer makes sense. > I'm all for adding support for multibyte characters, but I think we > should follow the same rules we impose on the rest of the world. > I've never liked the "do as I say, not as I do" mentality. > > Why not add a new branch, copy the existing one, update > DisplayStrings to SnmpAdminStrings, and depreciate the old branch? > Adding multibyte character support is going to mean that agents and > management applications are going to have to be updated, regardless > of whether or not the change is 'in-place' or a new branch is to be > supported. That's why the "weasel words" are proposed for the DESCRIPTION clauses. As a practical matter, robust management systems have long had to deal with the reality that some agent implementations have not enforced the NVT ASCII constraint. See the archives of the entity mib and MIBs mailing lists for detailed arguments. The decision to take this approach in those cases was not arrived at lightly, and the trade-offs should be thoroughly understood in this case as well. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Feb 28 18:51:46 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> Review of the SNMP Notifications Method Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FF7F@MAILSRVNT02> Hi Ron, I just asked Harry Lewis this same question earlier this afternoon and he agreed. So did Tom Hastings a few minutes ago. So, unless someone strongly objects, in my spare time (hah!) I'll rework the IPP Notifications over SNMP proposal to generalize the 'jmPrinterEvent' trap to be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, Fax MIB, or whatever). I'll *try* to get the new draft posted before the I-D cutoff on 10 March. Ron, what do you think about working this update to the Job Mon MIB via email and one or a few dedicated telecons? I can't travel to the PWG meetings. And in any case, they seem to be pretty full already with other topics. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, February 28, 2000 1:59 PM To: McDonald, Ira Subject: Re: IPP> Review of the SNMP Notifications Method Ira, A change to jmDeviceEvent is a very good idea! The MFPA is presently trying to incorporate as much of the PWG work as possible into the Multifunction standards and this will certainly help with notifications. I don't believe that Sharp is an MFPA member, but you can still participate in the standards development. You can even attend the meetings. I expect to see more PWG participation in MFPA activities this year, now the the MFPA is doing some "real" work. Ron "McDonald, Ira" wrote: > Hi Ron, > > I've been contemplating, in support of the Scanner MIB > work and any possible future Fax MIB, abstracting the > current IPP Notifications over SNMP a little bit and > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > (which could then serve for Scanner MIB and private > MIB events). The PWG Job Monitoring MIB already > has 'JmJobServiceTypes' to express print, scan, fax-in, > fax-out, etc. in jobs and is therefore already abstracted > away from strictly print jobs. > > I had hoped to issue the new I-D before the 10 March > deadline (Carl-Uno isn't that when I-Ds are cutoff' > before IETF Adelaide, Australia??), but I've got the > flu and a ton of other work, so probably not. > > I copied the IPP WG on this note, so folks would know > what's happening as early as possible (before this > Wednesday's IPP WG Telecon). > > Cheers, > - Ira McDonald > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Wednesday, February 23, 2000 6:28 PM > To: Ira McDonald > Cc: Carl-Uno Manros > Subject: IPP> Review of the SNMP Notifications Method > > Ira, > > So far there has not been any group review of your proposal > for SNMP Notifications. The last two meetings had a very > full schedule with the new Set Operations and the other > notification methods. > > I have volunteered to lead the discussion on this document > and hope to have a slot in the Tokyo meeting. > > In the mean time I hope to do an extensive review of your > proposal. As I stated previously, it looks like an excellent > base for SNMP notifications. I do have some suggested > improvements which I believe can be made available by > the end of next week. (I had hoped to complete this task > prior to the LA meeting, but other task seem to get in the > way.) If we could at least have some discussions prior to > the Tokyo meeting, they could then be presented to the > group for additional feedback. > > I do not feel that any changes need to be made to your > document for the IETF meeting. From past experience, > there is not much feedback from these meetings unless > specific issues are contained in the presentation. Also, > I have not seen any participation from SNMP experts in > the IPP discussions. > > Ron Bergman > Hitachi Koki Imaging Solutions From rbergma at hitachi-hkis.com Mon Feb 28 19:35:31 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> Re: IPP> Review of the SNMP Notifications Method References: <1115A7CFAC25D311BC4000508B2CA53730FF7F@MAILSRVNT02> Message-ID: <38BB1453.11978486@hitachi-hkis.com> Ira, I agree with trying to do more via email. Right now the IPP telecons are eating into too much of my time, so I would prefer to try email. Maybe telecons after the Toyko meeting, in place of some of the normal IPP calls. I really don't see any point in trying to get a new draft to the IETF. If you can, fine, but I would not recommend this be our "primary goal". I should have my promised comments before the end of the week and these may have more impact on the draft and generate more discussion. Ron "McDonald, Ira" wrote: > Hi Ron, > > I just asked Harry Lewis this same question earlier > this afternoon and he agreed. So did Tom Hastings > a few minutes ago. > > So, unless someone strongly objects, in my spare time > (hah!) I'll rework the IPP Notifications over SNMP > proposal to generalize the 'jmPrinterEvent' trap to > be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, > Fax MIB, or whatever). I'll *try* to get the new > draft posted before the I-D cutoff on 10 March. > > Ron, what do you think about working this update to > the Job Mon MIB via email and one or a few dedicated > telecons? I can't travel to the PWG meetings. And > in any case, they seem to be pretty full already with > other topics. > > Cheers, > - Ira McDonald (consulting architect at Sharp Labs America) > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Monday, February 28, 2000 1:59 PM > To: McDonald, Ira > Subject: Re: IPP> Review of the SNMP Notifications Method > > Ira, > > A change to jmDeviceEvent is a very good idea! The > MFPA is presently trying to incorporate as much of the > PWG work as possible into the Multifunction standards > and this will certainly help with notifications. > > I don't believe that Sharp is an MFPA member, but > you can still participate in the standards development. > You can even attend the meetings. I expect to see > more PWG participation in MFPA activities this year, > now the the MFPA is doing some "real" work. > > Ron > > "McDonald, Ira" wrote: > > > Hi Ron, > > > > I've been contemplating, in support of the Scanner MIB > > work and any possible future Fax MIB, abstracting the > > current IPP Notifications over SNMP a little bit and > > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > > (which could then serve for Scanner MIB and private > > MIB events). The PWG Job Monitoring MIB already > > has 'JmJobServiceTypes' to express print, scan, fax-in, > > fax-out, etc. in jobs and is therefore already abstracted > > away from strictly print jobs. > > > > I had hoped to issue the new I-D before the 10 March > > deadline (Carl-Uno isn't that when I-Ds are cutoff' > > before IETF Adelaide, Australia??), but I've got the > > flu and a ton of other work, so probably not. > > > > I copied the IPP WG on this note, so folks would know > > what's happening as early as possible (before this > > Wednesday's IPP WG Telecon). > > > > Cheers, > > - Ira McDonald > > > > -----Original Message----- > > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > > Sent: Wednesday, February 23, 2000 6:28 PM > > To: Ira McDonald > > Cc: Carl-Uno Manros > > Subject: IPP> Review of the SNMP Notifications Method > > > > Ira, > > > > So far there has not been any group review of your proposal > > for SNMP Notifications. The last two meetings had a very > > full schedule with the new Set Operations and the other > > notification methods. > > > > I have volunteered to lead the discussion on this document > > and hope to have a slot in the Tokyo meeting. > > > > In the mean time I hope to do an extensive review of your > > proposal. As I stated previously, it looks like an excellent > > base for SNMP notifications. I do have some suggested > > improvements which I believe can be made available by > > the end of next week. (I had hoped to complete this task > > prior to the LA meeting, but other task seem to get in the > > way.) If we could at least have some discussions prior to > > the Tokyo meeting, they could then be presented to the > > group for additional feedback. > > > > I do not feel that any changes need to be made to your > > document for the IETF meeting. From past experience, > > there is not much feedback from these meetings unless > > specific issues are contained in the presentation. Also, > > I have not seen any participation from SNMP experts in > > the IPP discussions. > > > > Ron Bergman > > Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Mon Feb 28 19:23:01 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> Review of the SNMP Notifications Method Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FF84@MAILSRVNT02> Hi Ron, Right - cart before the horse - I'll look forward to your comments and will *not* try to turn a new draft in the few remaining days before the I-D deadline. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, February 28, 2000 4:36 PM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: Re: IPP> Review of the SNMP Notifications Method Ira, I agree with trying to do more via email. Right now the IPP telecons are eating into too much of my time, so I would prefer to try email. Maybe telecons after the Toyko meeting, in place of some of the normal IPP calls. I really don't see any point in trying to get a new draft to the IETF. If you can, fine, but I would not recommend this be our "primary goal". I should have my promised comments before the end of the week and these may have more impact on the draft and generate more discussion. Ron "McDonald, Ira" wrote: > Hi Ron, > > I just asked Harry Lewis this same question earlier > this afternoon and he agreed. So did Tom Hastings > a few minutes ago. > > So, unless someone strongly objects, in my spare time > (hah!) I'll rework the IPP Notifications over SNMP > proposal to generalize the 'jmPrinterEvent' trap to > be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, > Fax MIB, or whatever). I'll *try* to get the new > draft posted before the I-D cutoff on 10 March. > > Ron, what do you think about working this update to > the Job Mon MIB via email and one or a few dedicated > telecons? I can't travel to the PWG meetings. And > in any case, they seem to be pretty full already with > other topics. > > Cheers, > - Ira McDonald (consulting architect at Sharp Labs America) > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Monday, February 28, 2000 1:59 PM > To: McDonald, Ira > Subject: Re: IPP> Review of the SNMP Notifications Method > > Ira, > > A change to jmDeviceEvent is a very good idea! The > MFPA is presently trying to incorporate as much of the > PWG work as possible into the Multifunction standards > and this will certainly help with notifications. > > I don't believe that Sharp is an MFPA member, but > you can still participate in the standards development. > You can even attend the meetings. I expect to see > more PWG participation in MFPA activities this year, > now the the MFPA is doing some "real" work. > > Ron > > "McDonald, Ira" wrote: > > > Hi Ron, > > > > I've been contemplating, in support of the Scanner MIB > > work and any possible future Fax MIB, abstracting the > > current IPP Notifications over SNMP a little bit and > > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > > (which could then serve for Scanner MIB and private > > MIB events). The PWG Job Monitoring MIB already > > has 'JmJobServiceTypes' to express print, scan, fax-in, > > fax-out, etc. in jobs and is therefore already abstracted > > away from strictly print jobs. > > > > I had hoped to issue the new I-D before the 10 March > > deadline (Carl-Uno isn't that when I-Ds are cutoff' > > before IETF Adelaide, Australia??), but I've got the > > flu and a ton of other work, so probably not. > > > > I copied the IPP WG on this note, so folks would know > > what's happening as early as possible (before this > > Wednesday's IPP WG Telecon). > > > > Cheers, > > - Ira McDonald > > > > -----Original Message----- > > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > > Sent: Wednesday, February 23, 2000 6:28 PM > > To: Ira McDonald > > Cc: Carl-Uno Manros > > Subject: IPP> Review of the SNMP Notifications Method > > > > Ira, > > > > So far there has not been any group review of your proposal > > for SNMP Notifications. The last two meetings had a very > > full schedule with the new Set Operations and the other > > notification methods. > > > > I have volunteered to lead the discussion on this document > > and hope to have a slot in the Tokyo meeting. > > > > In the mean time I hope to do an extensive review of your > > proposal. As I stated previously, it looks like an excellent > > base for SNMP notifications. I do have some suggested > > improvements which I believe can be made available by > > the end of next week. (I had hoped to complete this task > > prior to the LA meeting, but other task seem to get in the > > way.) If we could at least have some discussions prior to > > the Tokyo meeting, they could then be presented to the > > group for additional feedback. > > > > I do not feel that any changes need to be made to your > > document for the IETF meeting. From past experience, > > there is not much feedback from these meetings unless > > specific issues are contained in the presentation. Also, > > I have not seen any participation from SNMP experts in > > the IPP discussions. > > > > Ron Bergman > > Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Tue Mar 7 17:58:17 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFA1@MAILSRVNT02> Hi Ron, My replies are below, prefixed by '> (ira)'. It would appear that I won't have the time after some future concensus to put out a revised I-D before the 10 March deadline (especially if I have to add all your proposed objects - see below). [These comments all address my latest IPP Notifications over SNMP - which defines two traps to add to the PWG Job Monitoring MIB and a few objects for bindings]. In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Wednesday, March 01, 2000 6:36 PM To: Ira McDonald Cc: ipp@pwg.org Subject: Comments on the SNMP Notifications Document Ira, At last here are my comments. I hope this starts a good discussion. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but is should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscdription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. > 3. Section 3.1: "jmEventEventPrinterState" should be "jmEventPrinterState". > (ira) > Noted - thanks 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 7. Scheme Name: I was going to propose "snmpnotify", but if "snmp" can be used, it is better yet! > (ira) > Lost my mind - 'snmp:' would indicate an SNMP Agent (command > receiver) entity. > We need to define 'snmpnotify:' (notification receiver) for > the SNMP Manager entity that gets notified. 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. I hate to ask, but any comments? Ron Bergman Hitachi Koki Imaging Solutions, Inc. From rbergma at hitachi-hkis.com Thu Mar 9 12:06:19 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> Re: Comments on the SNMP Notifications Document References: <1115A7CFAC25D311BC4000508B2CA53730FFA1@MAILSRVNT02> Message-ID: <38C7DA0A.EC77EF4A@hitachi-hkis.com> Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Thu Mar 9 16:03:46 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> Re: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFAE@MAILSRVNT02> Hi Ron, I just read through all of this. Good comments. I'm kind of burned out at the moment (from flu and too many hours editing) so it may be next week before I reply. Many thanks for your careful reading. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, March 09, 2000 9:06 AM To: McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: IPP> Re: Comments on the SNMP Notifications Document Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Fri Mar 10 19:08:43 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> Re: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFB5@MAILSRVNT02> Hi Ron and PWG folks, At our IPP WG Telecon this Wednesday (8 March), Ron asked that I have a revised draft of the Job MIB-based IPP notifications over SNMP document out in time for review during the upcoming PWG meeting in Tokyo (at the beginning of April). I've been thinking about Ron's comments and have just spoken with Harry Lewis about my ideas for changes. So here's what I propose to do (and some about why): 1) Define objects for all of the Job event bindings that occur in Job Attribute table members - because it's impossible in ASN.1 to reference an *instance* of an object (and the *type* of each job attribute is part of its *instance qualifier*, that is, it's an index element). - this brings us full circle to six months ago. 2) Define THREE Job events (state change, progress, complete) with bindings that exactly match IPP Notifications Spec requirements - this allows in-band event registration via SNMP using any of the methods I've seen in vendor private MIBs (view-based like old SNMPv2c Party MIB, booleans for each trap, or bit-masks for each trap). - this also works with script-based open management stations (HP OpenView, CA Unicenter, IBM Tivoli, etc.) which CANNOT be used with a single generic job event (because they case on the OID of the base NOTIFICATION-TYPE/TRAP-TYPE macro). - this brings us full circle to six months ago. 3) Generalize the Printer event to Device event - this allows the Job MIB which already supports other MFP job types (fax, scan, etc.) to be used for event notification for Scanner MIB, Fax MIB, MFP MIB, etc. - this allows future (possible) expansion of IPP to support other MFP job types 4) Change the scheme name to 'snmpnotify:' with some discussion of parameters - the work to register the 'snmpnotify:' scheme will ultimately have to be carried on in a separate I-D anyway and worked with the IETF SNMPv3 WG. 5) Specify that the Job Mon MIB traps may ONLY be delivered as unacknowledged Trap-PDUs and NOT as acknowledged Inform-PDUs - this is because there is NOT a table of all job events with unique objects for each delivered event (which would be impossible for resource reasons for job progress events, anyway). - thus the leaf objects that hold the Job trap bindings have a given value only instantaneously (until the subsequent trap is emitted from the MIB). - using acknowledged Informs would FORCE us to have a full-blown event table. I plan to begin the above edits immediately and to put a revised draft on the PWG FTP server by Friday (24 March 2000), two weeks from now - it will also be forwarded as an Internet-Draft but will not be available for the Adelaide, Australia IETF 47 the following week of 26-31 March. Comments? Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: McDonald, Ira Sent: Thursday, March 09, 2000 1:04 PM To: 'Ron Bergman'; McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: RE: IPP> Re: Comments on the SNMP Notifications Document Hi Ron, I just read through all of this. Good comments. I'm kind of burned out at the moment (from flu and too many hours editing) so it may be next week before I reply. Many thanks for your careful reading. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, March 09, 2000 9:06 AM To: McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: IPP> Re: Comments on the SNMP Notifications Document Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Mon Mar 20 02:37:00 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> NOT - IPP Notify over SNMP (Job Mon traps) v0.2 - 19 March 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFD8@MAILSRVNT02> Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just posted an updated version of 'IPP Notifications over SNMP' to the PWG server (for the upcoming PWG meeting in Japan in April): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (23 March 2000) at 10-12 PST / 1-3 EST. I have NOT forwarded this draft to the Internet-Drafts editor yet. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (16 March 2000) - see change log below. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 19 March 2000 1) Renamed Printer Event notification group to Device Basic Event and 'jmPrinterEventV2Event' notification to 'jmDeviceBasicV2Event', to better align with IPP and to support non-printing jobs. 2) Revised 'jmDeviceBasicV2Event' notification to remove 'hrDeviceStatus', 'hrPrinterStatus', 'hrPrinterDetectedErrorState' from mandatory trap bindings because they were redundant, per request of Ron Bergman. 3) Renamed Job Event notification group to Job Basic Event and 'jmJobEventV2Event' notification to 'jmJobBasicV2Event', to better align with IPP and to support variant job events. 4) Defined new Job Completed Event notification group and defined new Job Progress Event notification group, to better align with IPP and to support variant job events. 5) Renamed Event object group to Event Binding, 'jmEventPrinterState' to 'jmEventDeviceState', 'jmEventPrinterStateReasons' to 'jmEventDeviceStateReasons', 'jmEventPrinterIsAcceptingJobs' to 'jmEventDeviceIsAcceptingJobs', to support non-printing jobs. 6) Revised Event Binding object group, adding explicit objects 'jmEventDeviceURI', 'jmEventDeviceName', 'jmEventJobSetIndex', 'jmEventJobIndex', 'jmEventJobName', 'jmEventJobState', 'jmEventJobStateReasons', 'jmEventJobKOctets', 'jmEventJobKOctetsProcessed', 'jmEventJobImpressions', 'jmEventJobImpressionsCompleted', 'jmEventJobMediaSheets', 'jmEventJobMediaSheetsCompleted', 'jmEventJobImpressionsCompletedCC', 'jmEventJobCollationType', 'jmEventJobSheetCompletedCopyNum', 'jmEventJobSheetCompletedDocNum', per request of Ron Bergman. 7) Revised SYNTAX of 'jmEventTriggerEvent' object from from 'JmUTF8StringTC' (string) to IPP-aligned enumeration, per request of Ron Bergman. 8) Removed all references to Printer MIB v2, as they were of limited value, per request of Ron Bergman. 9) Revised 'SNMP Mapping for IPP Printer Events' section for renamed event binding objects, per request of Ron Bergman. 10) Revised 'Rules for Encoding Notifications' section to truncate additional string bindings, per request of Ron Bergman. 11) Revised 'Registration via IPP' section, to change scheme name from 'ipp-snmp:' to 'snmpnotify:', per request of Ron Bergman. - 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. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Mar 21 17:58:42 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RFC 2790 - Host Resources MIB v2 - Let's move Printer MIB v2 Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFE5@MAILSRVNT02> Hi folks, RFC 2790 - Host Resources MIB v2 (March 2000) - IETF Draft Standard status This was posted last week (14 March 2000) but got past me until it showed up in the RFC Index today. So now it's time to get on with Printer MIB v2. I urge that we fold the text of Finisher MIB into the Printer MIB v2 text (after all it completes the model in original Printer MIB, RFC 1759, March 1995) and NOT publish Finisher MIB as a separate RFC. I also urge that we press on as quickly as possible with publishing a definitive text for Printer MIB v2 (with the approved additions from July 1999 for new generic alerts and 'chIPP' specification) and move it to PMP WG last call and send it onward for IESG last call. More than one vendor has already shipped a product with Printer MIB v2 new objects implemented. Remember that since the bar is now *very* high for advancement to Draft Standard, the Printer MIB v2 MUST be published at Proposed Standard and convincing proof of interoperable implementations of EVERY object and object group must be presented to the IESG and publicly posted before we can request movement to Draft Standard status. Cheers, - Ira McDonald, consulting architect at Sharp Labs America High North Inc From hastings at cp10.es.xerox.com Wed Mar 22 18:54:15 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> NOT - [Downloaded .pdf file for] IPP Notify over SNMP (J ob Mon traps) v0.2 - 19 March 2000 Message-ID: <918C79AB552BD211A2BD00805F15CE8502C9576B@x-crt-es-ms1.cp10.es.xerox.com> I've down loaded the .pdf file with line numbers: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.pdf Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, March 19, 2000 23:37 To: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: IPP> NOT - IPP Notify over SNMP (Job Mon traps) v0.2 - 19 March 2000 Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just posted an updated version of 'IPP Notifications over SNMP' to the PWG server (for the upcoming PWG meeting in Japan in April): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (23 March 2000) at 10-12 PST / 1-3 EST. I have NOT forwarded this draft to the Internet-Drafts editor yet. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (16 March 2000) - see change log below. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 19 March 2000 1) Renamed Printer Event notification group to Device Basic Event and 'jmPrinterEventV2Event' notification to 'jmDeviceBasicV2Event', to better align with IPP and to support non-printing jobs. 2) Revised 'jmDeviceBasicV2Event' notification to remove 'hrDeviceStatus', 'hrPrinterStatus', 'hrPrinterDetectedErrorState' from mandatory trap bindings because they were redundant, per request of Ron Bergman. 3) Renamed Job Event notification group to Job Basic Event and 'jmJobEventV2Event' notification to 'jmJobBasicV2Event', to better align with IPP and to support variant job events. 4) Defined new Job Completed Event notification group and defined new Job Progress Event notification group, to better align with IPP and to support variant job events. 5) Renamed Event object group to Event Binding, 'jmEventPrinterState' to 'jmEventDeviceState', 'jmEventPrinterStateReasons' to 'jmEventDeviceStateReasons', 'jmEventPrinterIsAcceptingJobs' to 'jmEventDeviceIsAcceptingJobs', to support non-printing jobs. 6) Revised Event Binding object group, adding explicit objects 'jmEventDeviceURI', 'jmEventDeviceName', 'jmEventJobSetIndex', 'jmEventJobIndex', 'jmEventJobName', 'jmEventJobState', 'jmEventJobStateReasons', 'jmEventJobKOctets', 'jmEventJobKOctetsProcessed', 'jmEventJobImpressions', 'jmEventJobImpressionsCompleted', 'jmEventJobMediaSheets', 'jmEventJobMediaSheetsCompleted', 'jmEventJobImpressionsCompletedCC', 'jmEventJobCollationType', 'jmEventJobSheetCompletedCopyNum', 'jmEventJobSheetCompletedDocNum', per request of Ron Bergman. 7) Revised SYNTAX of 'jmEventTriggerEvent' object from from 'JmUTF8StringTC' (string) to IPP-aligned enumeration, per request of Ron Bergman. 8) Removed all references to Printer MIB v2, as they were of limited value, per request of Ron Bergman. 9) Revised 'SNMP Mapping for IPP Printer Events' section for renamed event binding objects, per request of Ron Bergman. 10) Revised 'Rules for Encoding Notifications' section to truncate additional string bindings, per request of Ron Bergman. 11) Revised 'Registration via IPP' section, to change scheme name from 'ipp-snmp:' to 'snmpnotify:', per request of Ron Bergman. - 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. ------------------------------------------------------------------------ From marclev at yahoo.com Thu Apr 13 18:11:36 2000 From: marclev at yahoo.com (Marc Lev) Date: Wed May 6 14:00:00 2009 Subject: JMP> We pay cash, now! Message-ID: <200004132207.SAA11369@pwg.org> Do you know someone who is currently trying to sell their mobile home or mobile home park? Do you know of someoone who is receiving payments from the sale of a mobile home or mobile home park? If you answered yes to either of these questions we may be able to help. At Trans World Funding we are in the business of helping people convert payments from mobile home and park sales into immediate cash. We have investors who purchase mobile home notes and give the sellers a lump sum of cash instead of them having to receive monthly payments over a long period of time. We can also finance the purchase of new mobile homes for dealerships throughout the country. If you know of someone who is selling a mobile home or mobile home park, this may help them sell it much faster! If you know someone who has sold a mobile home or park with seller financing and is receiving payments, this may help them financially. Please feel free to contact me at any time. Marc L. Lev, DCFS President Trans World Funding TWF2000@aol.com (410) 243-9382 PS We are much more liberal and more flexable than a conventional bank! PPS We pay very nice referral fees. If you have received this e-mail in error, please remain calm. We have either communicated in the past or our names are on the same list. If you wish to be removed from our mailing list, just send us a blank e-mail and put the word remove in the subject line. Thank you for your time. From hastings at cp10.es.xerox.com Fri May 5 12:34:20 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:00 2009 Subject: JMP> FW: Job MIB Bake Off and Status Message-ID: <918C79AB552BD211A2BD00805F15CE85031F45F2@x-crt-es-ms1.cp10.es.xerox.com> Job MIB WG, What should we tell Brian about a Job MIB Bakeoff? Could it be piggy backed on the IPP bakeoff planned for this October? Tom -----Original Message----- From: Brian Anderson [mailto:banderson@sofha.com] Sent: Thursday, May 04, 2000 10:02 To: hastings@cp10.es.xerox.com Subject: Job MIB Bake Off and Status Hi Tom: It has been a long time since I followed what is happening with the Job MIB. Is there still plans to have a Bake Off this year? Also can you tell me if the Job MIB will support assigning job id's to forms? That is a downloaded form such as letterhead form or fax form that stays resident in a device. Thank you, - Brian Anderson Director of Sales and Marketing SOFHA USA 8001 Irvine Center Drive Fourth Floor Irvine CA, 92618 Tel: 949/754-3105, Fax: 949/754-4001 Email: banderson@sofha.com From imcdonald at sharplabs.com Mon May 22 21:28:41 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> NOT - Simpler traps for Job Mon MIB proposal Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD69@MAILSRVNT02> Hi folks, Tuesday (18 April 2000) Below is an ASN.1 sketch of a set of objects and notifications for the Job Monitoring MIB (IPP notifications over SNMP). A shortcoming in past drafts is the lack of persisent tables for device (printer) and job events. This proposal has persistent event tables, plus an extension mechanism for extra trap bindings (for 'job-completed' and 'job-progress' events). The tables are: Device, Device Event, Job Event, and Job Extra (for additional bindings with the Job Progress Event). The traps are: Device Event, Job Event, and Job Progress Event (for both 'job-progress' and 'job-completed' events). The '...Notify[Language|Text|TextFormat' objects may be null strings. Comments? Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc ------------------------------------------------------------------------ -- Device Group -- Systems which implement IETF Host Resources MIB RFC 2790 should -- set 'jmDeviceIndex' equal to 'hrDeviceIndex' for the same device -- INDEX { jmDeviceIndex } jmDeviceEntry ::= SEQUENCE { jmDeviceIndex Integer32 (1..2147483647) jmDeviceName SnmpAdminString, jmDeviceURI SnmpAdminString, jmDeviceServiceTypes JmJobServiceTypesTC, jmDeviceState JmDeviceStateTC, jmDeviceStateReasons SnmpAdminString, jmDeviceIsAcceptingJobs TruthValue } -- Device Event Group -- INDEX { jmDeviceIndex, -- jmDeviceEventIndex } jmDeviceEventEntry ::= SEQUENCE { jmDeviceEventIndex Integer32 (1..2147483647), jmDeviceEventState JmDeviceStateTC, jmDeviceEventStateReasons SnmpAdminString, jmDeviceEventIsAcceptingJobs TruthValue, jmDeviceEventTriggerEvent SnmpAdminString, jmDeviceEventNotifyCharset CodedCharSet, jmDeviceEventNotifyLanguage SnmpAdminString, jmDeviceEventNotifyTextFormat SnmpAdminString, jmDeviceEventNotifyText OCTET STRING (SIZE (0..255)), jmDeviceEventUpTime TimeTicks, jmDeviceEventDateTime DateAndTime } -- Device Event Notify (Trap/Inform) jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventState, jmDeviceEventStateReasons, jmDeviceEventIsAcceptingJobs, jmDeviceEventTriggerEvent, jmDeviceEventNotifyCharset, jmDeviceEventNotifyLanguage, jmDeviceEventNotifyTextFormat, jmDeviceEventNotifyText, jmDeviceEventUpTime, jmDeviceEventDateTime } -- Job Event Group -- INDEX { jmJobSetIndex, -- jmJobIndex, -- jmJobEventIndex } jmJobEventEntry ::= SEQUENCE { jmJobEventIndex Integer32 (1..2147483647), jmJobEventState JmJobStateTC, jmJobEventStateReasons OCTET STRING (SIZE (4..16)), jmJobEventTriggerEvent SnmpAdminString, jmJobEventNotifyCharset CodedCharSet, jmJobEventNotifyLanguage SnmpAdminString, jmJobEventNotifyTextFormat SnmpAdminString, jmJobEventNotifyText OCTET STRING (SIZE (0..255)), jmJobEventUpTime TimeTicks, jmJobEventDateTime DateAndTime, jmJobCountKOctetsProcessed Integer32 (-2..2147483647), jmJobCountImpressionsCompleted Integer32 (-2..2147483647) } -- Job Event Notify (Trap/Inform) jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventState, jmJobEventStateReasons, jmJobEventTriggerEvent, jmJobEventNotifyCharset, jmJobEventNotifyLanguage, jmJobEventNotifyTextFormat, jmJobEventNotifyText, jmJobEventUpTime, jmJobEventDateTime } -- Job Progress Notify (Trap/Inform) -- For both job-progress and job-completed events jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventState, jmJobEventStateReasons, jmJobEventTriggerEvent, jmJobEventNotifyCharset, jmJobEventNotifyLanguage, jmJobEventNotifyTextFormat, jmJobEventNotifyText, jmJobEventUpTime, jmJobEventDateTime, jmJobCountKOctetsProcessed, jmJobCountImpressionsCompleted } -- Job Extra Group -- Optional group for extra bindings on job events -- INDEX { jmJobSetIndex, -- jmJobIndex, -- jmJobEventIndex, -- jmJobExtraAttributeTypeIndex } jmJobExtraEntry ::= SEQUENCE { jmJobExtraAttributeTypeIndex JmAttributeTypeTC, jmJobExtraAttributeValueInteger Integer32 (-2..2147483647), jmJobExtraAttributeValueOctets OCTET STRING (SIZE (0..63)) } ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed May 31 21:04:04 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD76@MAILSRVNT02> Hi folks, Tuesday (18 April 2000) Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventNotifyEvent, jmDeviceState, jmDeviceStateReasons } jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons } jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons, jmJobEventKOctetsProcessed, jmJobEventImpressionsCompleted } I propose to write this all up in a revised Internet-Draft in the near future. Comments? Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc ------------------------------------------------------------------------ Changes from previous proposal of 22 May 2000: 1) Revised INDEX clauses of tables to always use single-level indices. 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and 'jmJobEventJobIndex' pointer objects to event tables but not traps. 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap because it's redundant with a value of '...DeviceStateReasons'. 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' from event tables and traps because they're incompatible with SNMP libraries (which assemble trap bindings and then send the IDENTICAL trap to all registered destinations) - in IPP, each destination MAY request a DIFFERENT value of '...NotifyLanguage', etc. 5) Deleted '...UpTime' from traps because 'sysUpTime' is included in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. 6) Deleted '...DateTime' from traps and event tables because it's redundant with '...UpTime' objects. 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I think this is the agreement for all IPP notification methods). ------------------------------------------------------------------------ -- Device Table - devices which support job services -- -- Systems which also implement IETF Host Resources MIB (RFC 2790) -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device -- INDEX { jmDeviceIndex } jmDeviceEntry ::= SEQUENCE { jmDeviceIndex Integer32 (1..2147483647), jmDeviceName SnmpAdminString, jmDeviceURI SnmpAdminString, jmDeviceServiceTypes JmJobServiceTypesTC, jmDeviceState JmDeviceStateTC, jmDeviceStateReasons SnmpAdminString } -- Device Event Table -- -- Rows are persistent until system reboot or table overflow -- INDEX { jmDeviceEventIndex } jmDeviceEventEntry ::= SEQUENCE { jmDeviceEventIndex Integer32 (1..2147483647), jmDeviceEventNotifyEvent SnmpAdminString, jmDeviceEventNotifyTime TimeTicks, jmDeviceEventDeviceIndex Integer32 (1..2147483647), jmDeviceEventDeviceState JmDeviceStateTC, jmDeviceEventDeviceStateReasons SnmpAdminString } -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For all device events jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventNotifyEvent, jmDeviceState, jmDeviceStateReasons } -- Job Event Table - persistent only for lifetime of job -- -- Rows are persistent ONLY for lifetime of job -- INDEX { jmJobEventIndex } jmJobEventEntry ::= SEQUENCE { jmJobEventIndex Integer32 (1..2147483647), jmJobEventNotifyEvent SnmpAdminString, jmJobEventNotifyTime TimeTicks, jmJobEventJobSetIndex Integer32 (1..32767), jmJobEventJobIndex Integer32 (1..2147483647), jmJobEventJobState JmJobStateTC, jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), jmJobEventKOctetsProcessed Integer32 (-2..2147483647), jmJobEventImpressionsCompleted Integer32 (-2..2147483647) } -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For basic job events jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons } -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For both job-progress and job-completed events jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons, jmJobEventKOctetsProcessed, jmJobEventImpressionsCompleted } ------------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Jun 1 14:15:48 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 References: <1115A7CFAC25D311BC4000508B2CA5375ECD76@MAILSRVNT02> Message-ID: <3936A853.11F24E60@hitachi-hkis.com> Ira, Its getting hard to keep up with your changes;-) The smaller content for both jmDeviceEventV2Event and jmJobEventV2Event seem to be reasonable. This is most likely all anyone would want for these traps. However, the jmJobProgressV2Event should contain sufficient information to allow the client application to maintain a set of "gas gauge" style displays. This makes this trap fairly heavy, but without this information the trap is not very useful. I eliminated jmJobState and jmJobEventJobStateReasons since a state change seldom happens during printing, at least as compared to progress, and a separate jmJobEventV2Event trap can be sent to report state changes. I don't believe that this trap content will exceed the 485 byte limit, but I did not do a byte count. Here is my revised proposal: jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, -- new object jmJobKOctetsPerCopyRequested, -- from Job MIB jmJobKOctetsProcessed, -- from Job MIB jmJobImpressionsPerCopyRequested, -- from Job MIB jmJobImpressionsCompleted, -- from Job MIB jmJobEventCopiesRequested, -- new object jmJobEventJobCollationType, -- new object jmJobEventMediaSheetsCompleted, -- new object jmJobEventSheetCompletedCopyNumber, -- new object jmJobEventSheetCompletedDocNumber -- new object } Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi folks, Tuesday (18 April 2000) > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > I propose to write this all up in a revised Internet-Draft in the near > future. > > Comments? > > Cheers, > - Ira McDonald, consulting architect at Xerox and Sharp > High North Inc > > ------------------------------------------------------------------------ > > Changes from previous proposal of 22 May 2000: > > 1) Revised INDEX clauses of tables to always use single-level indices. > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > because it's redundant with a value of '...DeviceStateReasons'. > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > from event tables and traps because they're incompatible with SNMP > libraries (which assemble trap bindings and then send the IDENTICAL > trap to all registered destinations) - in IPP, each destination MAY > request a DIFFERENT value of '...NotifyLanguage', etc. > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > 6) Deleted '...DateTime' from traps and event tables because it's > redundant with '...UpTime' objects. > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > think this is the agreement for all IPP notification methods). > > ------------------------------------------------------------------------ > > -- Device Table - devices which support job services > -- > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > -- INDEX { jmDeviceIndex } > jmDeviceEntry ::= SEQUENCE { > jmDeviceIndex Integer32 (1..2147483647), > jmDeviceName SnmpAdminString, > jmDeviceURI SnmpAdminString, > jmDeviceServiceTypes JmJobServiceTypesTC, > jmDeviceState JmDeviceStateTC, > jmDeviceStateReasons SnmpAdminString > } > > -- Device Event Table > -- > -- Rows are persistent until system reboot or table overflow > > -- INDEX { jmDeviceEventIndex } > jmDeviceEventEntry ::= SEQUENCE { > jmDeviceEventIndex Integer32 (1..2147483647), > jmDeviceEventNotifyEvent SnmpAdminString, > jmDeviceEventNotifyTime TimeTicks, > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > jmDeviceEventDeviceState JmDeviceStateTC, > jmDeviceEventDeviceStateReasons SnmpAdminString > } > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For all device events > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > -- Job Event Table - persistent only for lifetime of job > -- > -- Rows are persistent ONLY for lifetime of job > > -- INDEX { jmJobEventIndex } > jmJobEventEntry ::= SEQUENCE { > jmJobEventIndex Integer32 (1..2147483647), > jmJobEventNotifyEvent SnmpAdminString, > jmJobEventNotifyTime TimeTicks, > jmJobEventJobSetIndex Integer32 (1..32767), > jmJobEventJobIndex Integer32 (1..2147483647), > jmJobEventJobState JmJobStateTC, > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > } > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For basic job events > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For both job-progress and job-completed events > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Fri Jun 2 09:11:20 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> Very small Job Mon traps (IPP notifications) - 31 May 20 00 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD79@MAILSRVNT02> Hi Ron, Thanks very much for your quick feedback. I see your point about a detailed trap for job-progress. But in recent IPP discussions, the agreement was that REQUIRED content for IPP events would be very small (this latest sketch of mine is aligned with IPP here) and servers (IPP Printers) or clients could OPTIONALLY add additional bindings. Any SNMP trap may have additional bindings, by SNMP rules. What you're requesting is that ALL job-progress traps have 'gas gauge' bindings - but this places a higher conformance requirement on Job Mon MIB implementations to support these optional job attributes for this 'gas gauge'. SMI standard usage is never to bind static info (names, submitted job size, etc.) into traps, but to let the client separately read and cache such static info. This is part of the problem with these 'gas gauge' bindings. In your private traps at Hitachi/Koki, did you have this many bindings for the 'job-progress'? One other comment - after I sent this out the other day, I realized that 'job-basic' (state, config, etc.) and 'job-completed' can and should have rows in the job event table, but 'job-progress' should NOT have a row in the job event table (because of information explosion with page-by-page 'job-progress' rows). Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, June 01, 2000 11:16 AM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Ira, Its getting hard to keep up with your changes;-) The smaller content for both jmDeviceEventV2Event and jmJobEventV2Event seem to be reasonable. This is most likely all anyone would want for these traps. However, the jmJobProgressV2Event should contain sufficient information to allow the client application to maintain a set of "gas gauge" style displays. This makes this trap fairly heavy, but without this information the trap is not very useful. I eliminated jmJobState and jmJobEventJobStateReasons since a state change seldom happens during printing, at least as compared to progress, and a separate jmJobEventV2Event trap can be sent to report state changes. I don't believe that this trap content will exceed the 485 byte limit, but I did not do a byte count. Here is my revised proposal: jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, -- new object jmJobKOctetsPerCopyRequested, -- from Job MIB jmJobKOctetsProcessed, -- from Job MIB jmJobImpressionsPerCopyRequested, -- from Job MIB jmJobImpressionsCompleted, -- from Job MIB jmJobEventCopiesRequested, -- new object jmJobEventJobCollationType, -- new object jmJobEventMediaSheetsCompleted, -- new object jmJobEventSheetCompletedCopyNumber, -- new object jmJobEventSheetCompletedDocNumber -- new object } Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi folks, Tuesday (18 April 2000) > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > I propose to write this all up in a revised Internet-Draft in the near > future. > > Comments? > > Cheers, > - Ira McDonald, consulting architect at Xerox and Sharp > High North Inc > > ------------------------------------------------------------------------ > > Changes from previous proposal of 22 May 2000: > > 1) Revised INDEX clauses of tables to always use single-level indices. > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > because it's redundant with a value of '...DeviceStateReasons'. > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > from event tables and traps because they're incompatible with SNMP > libraries (which assemble trap bindings and then send the IDENTICAL > trap to all registered destinations) - in IPP, each destination MAY > request a DIFFERENT value of '...NotifyLanguage', etc. > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > 6) Deleted '...DateTime' from traps and event tables because it's > redundant with '...UpTime' objects. > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > think this is the agreement for all IPP notification methods). > > ------------------------------------------------------------------------ > > -- Device Table - devices which support job services > -- > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > -- INDEX { jmDeviceIndex } > jmDeviceEntry ::= SEQUENCE { > jmDeviceIndex Integer32 (1..2147483647), > jmDeviceName SnmpAdminString, > jmDeviceURI SnmpAdminString, > jmDeviceServiceTypes JmJobServiceTypesTC, > jmDeviceState JmDeviceStateTC, > jmDeviceStateReasons SnmpAdminString > } > > -- Device Event Table > -- > -- Rows are persistent until system reboot or table overflow > > -- INDEX { jmDeviceEventIndex } > jmDeviceEventEntry ::= SEQUENCE { > jmDeviceEventIndex Integer32 (1..2147483647), > jmDeviceEventNotifyEvent SnmpAdminString, > jmDeviceEventNotifyTime TimeTicks, > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > jmDeviceEventDeviceState JmDeviceStateTC, > jmDeviceEventDeviceStateReasons SnmpAdminString > } > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For all device events > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > -- Job Event Table - persistent only for lifetime of job > -- > -- Rows are persistent ONLY for lifetime of job > > -- INDEX { jmJobEventIndex } > jmJobEventEntry ::= SEQUENCE { > jmJobEventIndex Integer32 (1..2147483647), > jmJobEventNotifyEvent SnmpAdminString, > jmJobEventNotifyTime TimeTicks, > jmJobEventJobSetIndex Integer32 (1..32767), > jmJobEventJobIndex Integer32 (1..2147483647), > jmJobEventJobState JmJobStateTC, > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > } > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For basic job events > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For both job-progress and job-completed events > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > ------------------------------------------------------------------------ From rbergma at hitachi-hkis.com Fri Jun 2 17:10:43 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 References: <1115A7CFAC25D311BC4000508B2CA5375ECD79@MAILSRVNT02> Message-ID: <393822D3.8714840E@hitachi-hkis.com> Ira, A while back I would have agreed with you regarding the "static" information. However, experience has shown that this information is not always available at the begining of the job. It is much more efficient to provide this information in the trap than have the client continually poll until it is available. Hitachi printers don't currently include all the information proposed, since our collation type is fixed. Also, I do not see much use in tracking octets processed. (But I lost that argument years ago during the Job MIB development.) The total objects in the progress trap is only 10, which seems to be faitly modest compared to some of the earlier trap proposals. The advantage of one progress trap definition is interoperability. This will allow a job monitor application to be developed that will support any printer that supports the trap, I have always tried to favor light-weight protocols, but in this case including all the important information in a single trap is the most efficient. Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi Ron, > > Thanks very much for your quick feedback. > > I see your point about a detailed trap for job-progress. > > But in recent IPP discussions, the agreement was that > REQUIRED content for IPP events would be very small > (this latest sketch of mine is aligned with IPP here) > and servers (IPP Printers) or clients could OPTIONALLY > add additional bindings. > > Any SNMP trap may have additional bindings, by SNMP rules. > > What you're requesting is that ALL job-progress traps > have 'gas gauge' bindings - but this places a higher > conformance requirement on Job Mon MIB implementations > to support these optional job attributes for this 'gas > gauge'. > > SMI standard usage is never to bind static info (names, > submitted job size, etc.) into traps, but to let the > client separately read and cache such static info. > This is part of the problem with these 'gas gauge' > bindings. > > In your private traps at Hitachi/Koki, did you have this > many bindings for the 'job-progress'? > > One other comment - after I sent this out the other day, > I realized that 'job-basic' (state, config, etc.) and > 'job-completed' can and should have rows in the > job event table, but 'job-progress' should NOT have a > row in the job event table (because of information > explosion with page-by-page 'job-progress' rows). > > Cheers, > - Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Thursday, June 01, 2000 11:16 AM > To: McDonald, Ira > Cc: 'ipp@pwg.org'; 'jmp@pwg.org' > Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May > 2000 > > Ira, > > Its getting hard to keep up with your changes;-) > > The smaller content for both jmDeviceEventV2Event > and jmJobEventV2Event seem to be reasonable. This > is most likely all anyone would want for these > traps. However, the jmJobProgressV2Event should > contain sufficient information to allow the client > application to maintain a set of "gas gauge" style > displays. This makes this trap fairly heavy, but > without this information the trap is not very useful. > > I eliminated jmJobState and jmJobEventJobStateReasons > since a state change seldom happens during printing, > at least as compared to progress, and a separate > jmJobEventV2Event trap can be sent to report state > changes. > > I don't believe that this trap content will exceed > the 485 byte limit, but I did not do a byte count. > > Here is my revised proposal: > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, -- new object > jmJobKOctetsPerCopyRequested, -- from Job MIB > jmJobKOctetsProcessed, -- from Job MIB > jmJobImpressionsPerCopyRequested, -- from Job MIB > jmJobImpressionsCompleted, -- from Job MIB > jmJobEventCopiesRequested, -- new object > jmJobEventJobCollationType, -- new object > jmJobEventMediaSheetsCompleted, -- new object > jmJobEventSheetCompletedCopyNumber, -- new object > jmJobEventSheetCompletedDocNumber -- new object > } > > Ron Bergman > Hitachi Koki Imaging Solutions > > "McDonald, Ira" wrote: > > > Hi folks, Tuesday (18 April 2000) > > > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > I propose to write this all up in a revised Internet-Draft in the near > > future. > > > > Comments? > > > > Cheers, > > - Ira McDonald, consulting architect at Xerox and Sharp > > High North Inc > > > > ------------------------------------------------------------------------ > > > > Changes from previous proposal of 22 May 2000: > > > > 1) Revised INDEX clauses of tables to always use single-level indices. > > > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > > because it's redundant with a value of '...DeviceStateReasons'. > > > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > > from event tables and traps because they're incompatible with SNMP > > libraries (which assemble trap bindings and then send the IDENTICAL > > trap to all registered destinations) - in IPP, each destination MAY > > request a DIFFERENT value of '...NotifyLanguage', etc. > > > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > > > 6) Deleted '...DateTime' from traps and event tables because it's > > redundant with '...UpTime' objects. > > > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > > think this is the agreement for all IPP notification methods). > > > > ------------------------------------------------------------------------ > > > > -- Device Table - devices which support job services > > -- > > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > > > -- INDEX { jmDeviceIndex } > > jmDeviceEntry ::= SEQUENCE { > > jmDeviceIndex Integer32 (1..2147483647), > > jmDeviceName SnmpAdminString, > > jmDeviceURI SnmpAdminString, > > jmDeviceServiceTypes JmJobServiceTypesTC, > > jmDeviceState JmDeviceStateTC, > > jmDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Table > > -- > > -- Rows are persistent until system reboot or table overflow > > > > -- INDEX { jmDeviceEventIndex } > > jmDeviceEventEntry ::= SEQUENCE { > > jmDeviceEventIndex Integer32 (1..2147483647), > > jmDeviceEventNotifyEvent SnmpAdminString, > > jmDeviceEventNotifyTime TimeTicks, > > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > > jmDeviceEventDeviceState JmDeviceStateTC, > > jmDeviceEventDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For all device events > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > -- Job Event Table - persistent only for lifetime of job > > -- > > -- Rows are persistent ONLY for lifetime of job > > > > -- INDEX { jmJobEventIndex } > > jmJobEventEntry ::= SEQUENCE { > > jmJobEventIndex Integer32 (1..2147483647), > > jmJobEventNotifyEvent SnmpAdminString, > > jmJobEventNotifyTime TimeTicks, > > jmJobEventJobSetIndex Integer32 (1..32767), > > jmJobEventJobIndex Integer32 (1..2147483647), > > jmJobEventJobState JmJobStateTC, > > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > > } > > > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For basic job events > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For both job-progress and job-completed events > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Jun 5 11:28:54 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD7D@MAILSRVNT02> Hi Ron, I agree - Interoperability is our goal. I agree we should have the separate Job Progress trap with all ten bindings - but NOT record Job Progress traps in the alert table 'jmJobEventTable'. The Job Progress bindings (except the few from 'jmJobTable') should have leaf objects defined to hold their bindings. All other job events should be recorded in the alert table 'jmJobEventTable', except that Job Completed won't redundantly record the progress counters there (just bind them from the base objects in 'jmJobTable' into the trap). All device events should be recorded in the device table 'jmDeviceEventTable'. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Friday, June 02, 2000 2:11 PM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Ira, A while back I would have agreed with you regarding the "static" information. However, experience has shown that this information is not always available at the begining of the job. It is much more efficient to provide this information in the trap than have the client continually poll until it is available. Hitachi printers don't currently include all the information proposed, since our collation type is fixed. Also, I do not see much use in tracking octets processed. (But I lost that argument years ago during the Job MIB development.) The total objects in the progress trap is only 10, which seems to be faitly modest compared to some of the earlier trap proposals. The advantage of one progress trap definition is interoperability. This will allow a job monitor application to be developed that will support any printer that supports the trap, I have always tried to favor light-weight protocols, but in this case including all the important information in a single trap is the most efficient. Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi Ron, > > Thanks very much for your quick feedback. > > I see your point about a detailed trap for job-progress. > > But in recent IPP discussions, the agreement was that > REQUIRED content for IPP events would be very small > (this latest sketch of mine is aligned with IPP here) > and servers (IPP Printers) or clients could OPTIONALLY > add additional bindings. > > Any SNMP trap may have additional bindings, by SNMP rules. > > What you're requesting is that ALL job-progress traps > have 'gas gauge' bindings - but this places a higher > conformance requirement on Job Mon MIB implementations > to support these optional job attributes for this 'gas > gauge'. > > SMI standard usage is never to bind static info (names, > submitted job size, etc.) into traps, but to let the > client separately read and cache such static info. > This is part of the problem with these 'gas gauge' > bindings. > > In your private traps at Hitachi/Koki, did you have this > many bindings for the 'job-progress'? > > One other comment - after I sent this out the other day, > I realized that 'job-basic' (state, config, etc.) and > 'job-completed' can and should have rows in the > job event table, but 'job-progress' should NOT have a > row in the job event table (because of information > explosion with page-by-page 'job-progress' rows). > > Cheers, > - Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Thursday, June 01, 2000 11:16 AM > To: McDonald, Ira > Cc: 'ipp@pwg.org'; 'jmp@pwg.org' > Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May > 2000 > > Ira, > > Its getting hard to keep up with your changes;-) > > The smaller content for both jmDeviceEventV2Event > and jmJobEventV2Event seem to be reasonable. This > is most likely all anyone would want for these > traps. However, the jmJobProgressV2Event should > contain sufficient information to allow the client > application to maintain a set of "gas gauge" style > displays. This makes this trap fairly heavy, but > without this information the trap is not very useful. > > I eliminated jmJobState and jmJobEventJobStateReasons > since a state change seldom happens during printing, > at least as compared to progress, and a separate > jmJobEventV2Event trap can be sent to report state > changes. > > I don't believe that this trap content will exceed > the 485 byte limit, but I did not do a byte count. > > Here is my revised proposal: > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, -- new object > jmJobKOctetsPerCopyRequested, -- from Job MIB > jmJobKOctetsProcessed, -- from Job MIB > jmJobImpressionsPerCopyRequested, -- from Job MIB > jmJobImpressionsCompleted, -- from Job MIB > jmJobEventCopiesRequested, -- new object > jmJobEventJobCollationType, -- new object > jmJobEventMediaSheetsCompleted, -- new object > jmJobEventSheetCompletedCopyNumber, -- new object > jmJobEventSheetCompletedDocNumber -- new object > } > > Ron Bergman > Hitachi Koki Imaging Solutions > > "McDonald, Ira" wrote: > > > Hi folks, Tuesday (18 April 2000) > > > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > I propose to write this all up in a revised Internet-Draft in the near > > future. > > > > Comments? > > > > Cheers, > > - Ira McDonald, consulting architect at Xerox and Sharp > > High North Inc > > > > ------------------------------------------------------------------------ > > > > Changes from previous proposal of 22 May 2000: > > > > 1) Revised INDEX clauses of tables to always use single-level indices. > > > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > > because it's redundant with a value of '...DeviceStateReasons'. > > > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > > from event tables and traps because they're incompatible with SNMP > > libraries (which assemble trap bindings and then send the IDENTICAL > > trap to all registered destinations) - in IPP, each destination MAY > > request a DIFFERENT value of '...NotifyLanguage', etc. > > > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > > > 6) Deleted '...DateTime' from traps and event tables because it's > > redundant with '...UpTime' objects. > > > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > > think this is the agreement for all IPP notification methods). > > > > ------------------------------------------------------------------------ > > > > -- Device Table - devices which support job services > > -- > > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > > > -- INDEX { jmDeviceIndex } > > jmDeviceEntry ::= SEQUENCE { > > jmDeviceIndex Integer32 (1..2147483647), > > jmDeviceName SnmpAdminString, > > jmDeviceURI SnmpAdminString, > > jmDeviceServiceTypes JmJobServiceTypesTC, > > jmDeviceState JmDeviceStateTC, > > jmDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Table > > -- > > -- Rows are persistent until system reboot or table overflow > > > > -- INDEX { jmDeviceEventIndex } > > jmDeviceEventEntry ::= SEQUENCE { > > jmDeviceEventIndex Integer32 (1..2147483647), > > jmDeviceEventNotifyEvent SnmpAdminString, > > jmDeviceEventNotifyTime TimeTicks, > > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > > jmDeviceEventDeviceState JmDeviceStateTC, > > jmDeviceEventDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For all device events > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > -- Job Event Table - persistent only for lifetime of job > > -- > > -- Rows are persistent ONLY for lifetime of job > > > > -- INDEX { jmJobEventIndex } > > jmJobEventEntry ::= SEQUENCE { > > jmJobEventIndex Integer32 (1..2147483647), > > jmJobEventNotifyEvent SnmpAdminString, > > jmJobEventNotifyTime TimeTicks, > > jmJobEventJobSetIndex Integer32 (1..32767), > > jmJobEventJobIndex Integer32 (1..2147483647), > > jmJobEventJobState JmJobStateTC, > > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > > } > > > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For basic job events > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For both job-progress and job-completed events > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Fri Jul 7 10:30:00 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> Revised I-D draft-ietf-ipp-not-over-snmp-03.txt Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECDEB@MAILSRVNT02> Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: draft-ietf-ipp-not-over-snmp-03.txt - flat text IETF style draft-ietf-ipp-not-over-snmp-03.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000706.mib - flat text of ASN.1 (Job Mon MIB w/ traps) jmp-trap-000706.pdf - line numbered PDF of text Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Thursday (6 July 2000) IPP: Please place this document in the Internet-Drafts repository as: (July 2000) It replaces the previous: (March 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 6 July 2000 1) Added 'SnmpAdminString' to IMPORTS clause for new objects. 2) Corrected OID in MODULE-IDENTITY to use forward reference to definition of 'pwg' from 'enterprises' and 'mibs' from 'pwg'. 3) Added 'JmServiceStateTC' textual convention. 4) Added 'jmMirrorAttr' and 'jmSystem' object identifiers reserved for future extensions. 5) Major rewrite, per email discussion on IETF IPP WG list, to specify four new small (traditional) SNMP traps for: 'jmServiceBasicV2Event' (generalized from IPP Printer event), 'jmJobBasicV2Event' (corresponds IPP Job event), 'jmJobCompletedV2Event' (corresponds IPP Job completed event), 'jmJobProgressV2Event' (corresponds IPP Job progress event). 6) Major rewrite, per email discussion on IETF IPP WG list, to specify four new SNMP object groups: 'jmServiceTable' (name, URI, state, etc. - from IPP Printer), 'jmServiceEventTable' (records IPP Printer events for polling), 'jmJobEventTable' (records IPP Job events for polling), 'jmJobProgressGroup' (leaf objects for IPP Job progress event). 7) Revised section 3.1 'SNMP Mapping for IPP Printer Events' and section 3.2 'SNMP Mapping for IPP Job Events', to agree with above. 8) Deleted obsolete section 3.3 'Rules for Encoding Notifications', as event bindings now always fit over all SNMP transport protocols. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed Jul 19 11:08:09 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RESEND: Posted new I-D - Printer MIB v2 - 14 July 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE1A@MAILSRVNT02> This got lost in the PWG reflector last Friday, - Ira -----Original Message----- From: McDonald, Ira Sent: Friday, July 14, 2000 11:42 AM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'rbergma@hitachi-hkis.com'; 'harryl@us.ibm.com'; 'ggocek@crt.xerox.com'; McDonald, Ira Subject: Posted new I-D - Printer MIB v2 - 14 July 2000 Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Friday (14 July 2000) As most of you know, Harry Lewis (IBM) has performed a great deal of work finishing up the edits to the Printer MIB v2. Since Harry is away from his office until 25 July, Gary Gocek (Xerox) has finished up minor changes necessary to generate the IETF style flat text. This version of the MIB compiles cleanly under Mosy, SMICng, and Epilogue. I've just sent the (hopefully) final version of 'IETF Printer MIB v2' to the Internet-Drafts editor. This version is for Printer MIB WG 'last call' and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-info-05.txt - IETF style flat text draft-ietf-printmib-info-05.pdf - line numbered PDF of '.txt' draft-ietf-printmib-info-05.doc - MS Word source draft-ietf-printmib-info-05.mib - extracted ASN.1 from '.txt' My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Friday (14 July 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (July 2000) It replaces the previous draft: (January 1999) Note: Edits to Printer MIB v2 were delayed awaiting the Host Resources MIB v2 (RFC 2790, March 2000). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790), as well as the Interfaces Group of MIB-II (RFC 1213). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Randy Turner (2Wire, co-editor) Gary Gocek (Xerox, contributing editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC2790 - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790) - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual-conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4) - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections - Updated references - Added Appendix E - Overall Printer Status Table - Updated participant and contact information ------------------------------------------------------------------------ From hof at oce.nl Thu Aug 3 09:58:41 2000 From: hof at oce.nl (Harry Offermans) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <39897A91.53F893A9@oce.nl> The status of teh Job monitoring MIB is informational and the location in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I have is, if the Job Monitoring MIB is, will be or is intended to be used for job managament applications. The usage I think of is in the same way as the Printer MIB or MIB II. Or is the purpose to have a job description that can be used in IPP. ?? -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Aug 3 11:14:25 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> Message-ID: <39898C51.6B9CF030@hitachi-hkis.com> Harry, The Job Monitoring MIB is intended for use in job management applications. It is currently supported by several printer vendors. It is an Informational RFC due to a reduction in scope of the IETF. Due to an extremely large increase in their activity they will no longer publish SNMP MIBs that are not directly related to network management. The MIB also has provided a good model for use in IPP. Ron Bergman Chairman, Job Monitoring MIB Working Group Hitachi Koki Imaging Solutions Harry Offermans wrote: > The status of teh Job monitoring MIB is informational and the location > in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I > have is, if the Job Monitoring MIB is, will be or is intended to be > used for job managament applications. The usage I think of is in the > same way as the Printer MIB or MIB II. Or is the purpose to have a job > description that can be used in IPP. ?? > > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 > Harry Offermans OCE Research & Development > mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 > Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands > ------------------------------------------------------------------ > This note does not necessarily represent the position of Oce > Technologies B.V. Therefore no liability or responsibility for > whatever will be accepted. > ------------------------------------------------------------------ From imcdonald at sharplabs.com Thu Aug 3 11:27:19 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE3C@mailsrvnt02.enet.sharplabs.com> Hi Harry, The Job Monitoring MIB is a PWG Standard (and is published an an IETF Informational RFC for the convenience of the network management community). The Job object in IPP (developed AFTER the Job Mon MIB) was intentionally technically aligned with the Job attributes in the Job Mon MIB. The Job Mon MIB is intended to be used to instrument jobs from ANY print channel (IPP, LPR, etc.) in ANY print format (PostScript, etc.). It is a companion to the Printer MIB. The work-in-progress (mine) to add Service (Printer) and Job SNMP traps to the Job Mon MIB was inspired by the notifications work item in the IETF IPP WG (and is an OPTIONAL mapping for IPP notifications). Because of further changes in the IPP notifications base spec, I'm revising the Job traps spec once more. Should be posted (to this list) within the next few weeks. I hope this helps. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Harry Offermans [mailto:hof@oce.nl] Sent: Thursday, August 03, 2000 6:59 AM To: jmp@pwg.org Subject: JMP> status and usage of Job monitoring MIB The status of teh Job monitoring MIB is informational and the location in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I have is, if the Job Monitoring MIB is, will be or is intended to be used for job managament applications. The usage I think of is in the same way as the Printer MIB or MIB II. Or is the purpose to have a job description that can be used in IPP. ?? -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Aug 3 11:46:26 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> <39898C51.6B9CF030@hitachi-hkis.com> Message-ID: <398993D2.DF84BF28@hitachi-hkis.com> Harry, What I intended to say was "...they will no longer publish SNMP MIBs on the standards track that are not directly related to..." ^^^^^^^^^^^^^^^^^^^^^^ Ron Bergman Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > > Harry Offermans wrote: > > > The status of teh Job monitoring MIB is informational and the location > > in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I > > have is, if the Job Monitoring MIB is, will be or is intended to be > > used for job managament applications. The usage I think of is in the > > same way as the Printer MIB or MIB II. Or is the purpose to have a job > > description that can be used in IPP. ?? > > > > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 > > Harry Offermans OCE Research & Development > > mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 > > Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands > > ------------------------------------------------------------------ > > This note does not necessarily represent the position of Oce > > Technologies B.V. Therefore no liability or responsibility for > > whatever will be accepted. > > ------------------------------------------------------------------ From hof at oce.nl Fri Aug 4 11:04:07 2000 From: hof at oce.nl (Harry Offermans) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> <39898C51.6B9CF030@hitachi-hkis.com> Message-ID: <398ADB67.9B47F0E3@oce.nl> Ron, Ira Thank you for the background information. About the printer vendors who support the Job Monitoring Mib. Is a list available containing vendors and applications they provide? Are these applications proprietary or can they cooperate with devices from other vendors who support the Job Monitoring Mib? Harry Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Aug 7 13:20:30 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE42@mailsrvnt02.enet.sharplabs.com> Hi Harry, I'm not aware of any list of Job Monitoring MIB implementations. In general, any properly implemented client will interwork with any Job Monitoring MIB implementation in a network printer or spooler. There has never been a public interoperability test of different vendors' implementations of the Job Monitoring MIB - there should be. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Harry Offermans [mailto:hof@oce.nl] Sent: Friday, August 04, 2000 8:04 AM To: Ron Bergman; jmp@pwg.org; imcdonald@sharplabs.com Subject: Re: JMP> status and usage of Job monitoring MIB Ron, Ira Thank you for the background information. About the printer vendors who support the Job Monitoring Mib. Is a list available containing vendors and applications they provide? Are these applications proprietary or can they cooperate with devices from other vendors who support the Job Monitoring Mib? Harry Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Aug 8 19:08:26 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE49@mailsrvnt02.enet.sharplabs.com> Copies: IPP WG JMP WG Hi folks, Tuesday (8 August 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the file: draft-ietf-ipp-not-over-snmp-04.txt - flat text IETF style When Tom Hastings gets a chance, we'll also post PDF in the file: draft-ietf-ipp-not-over-snmp-04.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000808.mib - flat text of ASN.1 (Job Mon MIB w/ traps) When Tom Hastings gets a chance, we'll also post PDF in the file: jmp-trap-000808.pdf - line numbered PDF of text Note: This version is intended for IETF IPP WG 'last call'. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Tuesday (8 August 2000) IPP: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous: (July 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 8 August 2000 1) Deleted 'printer-full', 'printer-no-longer-full', 'printer-almost-idle', and 'printer-not-almost-idle' event types, and added 'printer-stopped' in 'jmServiceEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 2) Deleted 'job-purged' event type and added 'job-stopped' in 'jmJobEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 3) Renamed 'jmServiceEventNotifyEvent' object to 'jmServiceEventNotifyTriggerEvent' (most specific event) and added 'jmServiceEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 4) Renamed 'jmJobEventNotifyEvent' object to 'jmJobEventNotifyTriggerEvent' (most specific event) and added 'jmJobEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 5) Renamed all NOTIFICATION-TYPEs (traps) for clarity, changing 'jmServiceBasicV2Event' to 'jmServiceEventV2Notify', 'jmJobBasicV2Event' to 'jmJobEventV2Notify', 'jmJobCompletedV2Event' to 'jmJobCompletedV2Notify', and 'jmJobProgressV2Event' to 'jmJobProgressV2Notify'. ------------------------------------------------------------------------ From hastings at cp10.es.xerox.com Wed Aug 9 09:57:56 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: IPP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 [.pd f and .doc posted] Message-ID: <918C79AB552BD211A2BD00805F15CE85039A9ED7@x-crt-es-ms1.cp10.es.xerox.com> I've posted the line numbered .pdf and .doc files in: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-04.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-04.doc Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, August 08, 2000 16:08 To: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: IPP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 Copies: IPP WG JMP WG Hi folks, Tuesday (8 August 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the file: draft-ietf-ipp-not-over-snmp-04.txt - flat text IETF style When Tom Hastings gets a chance, we'll also post PDF in the file: draft-ietf-ipp-not-over-snmp-04.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000808.mib - flat text of ASN.1 (Job Mon MIB w/ traps) When Tom Hastings gets a chance, we'll also post PDF in the file: jmp-trap-000808.pdf - line numbered PDF of text Note: This version is intended for IETF IPP WG 'last call'. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Tuesday (8 August 2000) IPP: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous: (July 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 8 August 2000 1) Deleted 'printer-full', 'printer-no-longer-full', 'printer-almost-idle', and 'printer-not-almost-idle' event types, and added 'printer-stopped' in 'jmServiceEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 2) Deleted 'job-purged' event type and added 'job-stopped' in 'jmJobEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 3) Renamed 'jmServiceEventNotifyEvent' object to 'jmServiceEventNotifyTriggerEvent' (most specific event) and added 'jmServiceEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 4) Renamed 'jmJobEventNotifyEvent' object to 'jmJobEventNotifyTriggerEvent' (most specific event) and added 'jmJobEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 5) Renamed all NOTIFICATION-TYPEs (traps) for clarity, changing 'jmServiceBasicV2Event' to 'jmServiceEventV2Notify', 'jmJobBasicV2Event' to 'jmJobEventV2Notify', 'jmJobCompletedV2Event' to 'jmJobCompletedV2Notify', and 'jmJobProgressV2Event' to 'jmJobProgressV2Notify'. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed Aug 9 23:31:59 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE4F@mailsrvnt02.enet.sharplabs.com> Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Wednesday (9 August 2000) I've just sent the final version of 'IETF Printer MIB v2' with all edits resulting from the Printer MIB WG 'last call' to the Internet-Drafts editor. This version is for submission to the IESG for IETF 'last call' (normally four weeks for revisions to existing RFCs) and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-mib-info-06.txt - IETF style flat text draft-ietf-printmib-mib-info-06.pdf - line numbered PDF of '.txt' draft-ietf-printmib-mib-info-06.doc - MS Word source draft-ietf-printmib-mib-info-06.mib - extracted ASN.1 from '.txt' NOTE - The filename on the title page of the '.doc' (source) and '.pdf' versions is still incorrect (missing the '-mib' infix). I hand-edited the '.txt' and fixed the filename on the title page, so that I could post these files tonight. My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Wednesday (9 August 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous draft: (July 2000) Note: The '-05' version was originally forwarded with the (incorrect) name 'draft-ietf-printmib-info-05.txt'. Corrected by the I-D Editor (thank you). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790 [28]), as well as the Interfaces Group of MIB-II (RFC 1213 [14]). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Gary Gocek (Xerox, co-editor) Randy Turner (2Wire, co-editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC 1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process. - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC 2790. - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790). - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC 2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. - Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual- conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types. - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events. - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4). - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to reflect the new syntax. - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections. - Updated references. - Added Appendix E - Overall Printer Status Table. - Updated participant and contact information. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Thu Aug 10 21:34:04 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:00 2009 Subject: JMP> RE: PMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE57@mailsrvnt02.enet.sharplabs.com> Hi folks, Gary Gocek fixed the document title in the '.doc' and '.pdf' versions and I've just stored the corrected ones to the PWG FTP server (same path and filenames as yesterday - see note below). Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, August 09, 2000 8:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org' Cc: 'rbergma@hitachi-hkis.com'; 'harryl@us.ibm.com'; 'ggocek@crt.xerox.com'; McDonald, Ira; 'imcdonal@sdsp.mc.xerox.com' Subject: PMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Wednesday (9 August 2000) I've just sent the final version of 'IETF Printer MIB v2' with all edits resulting from the Printer MIB WG 'last call' to the Internet-Drafts editor. This version is for submission to the IESG for IETF 'last call' (normally four weeks for revisions to existing RFCs) and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-mib-info-06.txt - IETF style flat text draft-ietf-printmib-mib-info-06.pdf - line numbered PDF of '.txt' draft-ietf-printmib-mib-info-06.doc - MS Word source draft-ietf-printmib-mib-info-06.mib - extracted ASN.1 from '.txt' NOTE - The filename on the title page of the '.doc' (source) and '.pdf' versions is still incorrect (missing the '-mib' infix). I hand-edited the '.txt' and fixed the filename on the title page, so that I could post these files tonight. My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Wednesday (9 August 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous draft: (July 2000) Note: The '-05' version was originally forwarded with the (incorrect) name 'draft-ietf-printmib-info-05.txt'. Corrected by the I-D Editor (thank you). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790 [28]), as well as the Interfaces Group of MIB-II (RFC 1213 [14]). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Gary Gocek (Xerox, co-editor) Randy Turner (2Wire, co-editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC 1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process. - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC 2790. - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790). - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC 2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. - Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual- conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types. - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events. - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4). - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to reflect the new syntax. - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections. - Updated references. - Added Appendix E - Overall Printer Status Table. - Updated participant and contact information. ------------------------------------------------------------------------ From roland200pk at yahoo.com Fri Sep 29 11:50:23 2000 From: roland200pk at yahoo.com (Ghulam Mustafa) Date: Wed May 6 14:00:00 2009 Subject: JMP> job required Message-ID: <20000929155023.73671.qmail@web9904.mail.yahoo.com> dear sir My name is ghulam-mustafa. i am 26 years old.i am working in one of the leading pakistani printing press. ( naw-i- waqat) daily newspaper as a machine operator since from 1996.i can operate and repair roland , parva single colour , two ,four and roland 200 machines.i worked in ( pakistan machinery and equepment ) in machinical department for three years. p.m.e is an authorised representative of manroland in pakistan.i have also worked in shirkat printing press for one year. i can operate all types of sheet fed printing machines.therefore i want to become a part of your esteemad organization. if my skills are required than let me know very soon . i shall delivered all my experience certificate . Thank you My postal address saray lal sing no 36. Mustafabad dharampura lahore pakistan. E_MAIL address ; roland200pk@yahoo.com FAX No.0092-42-7355324 __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ From roland200pk at yahoo.com Sun Nov 5 10:56:26 2000 From: roland200pk at yahoo.com (Ghulam Mustafa) Date: Wed May 6 14:00:00 2009 Subject: JMP> job required Message-ID: <20001105155626.54695.qmail@web9908.mail.yahoo.com> dear sir My name is ghulam-mustafa. i am 26 years old.i am working in one of the leading pakistani printing press. ( naw-i- waqat) daily newspaper as a machine operator since from 1996.i can operate and repair roland , parva single colour , two ,four and roland 200 machines.i worked in ( pakistan machinery and equepment ) in machinical department for three years. p.m.e is an authorised representative of manroland in pakistan.i have also worked in shirkat printing press for one year. i can operate all types of sheet fed printing machines.therefore i want to become a part of your esteemad organization. if my skills are required than let me know very soon . i shall delivered all my experience certificate . Thank you My postal address saray lal sing no 36. Mustafabad dharampura lahore pakistan. E_MAIL address ; roland200pk@yahoo.com FAX No.0092-42-7355324 NOTE; i had already sand above my subject 'however i did not recive any responce from your sied kindely answar back soon my request thank you __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From kr2 at aport2000.ru Mon Dec 25 10:40:49 2000 From: kr2 at aport2000.ru (kr2@aport2000.ru) Date: Wed May 6 14:00:00 2009 Subject: JMP> ÁÅÑÏËÀÒÍÀß ÄÎÑÒÀÂÊÀ ÍÎÓÒÁÓÊÎÂ, ÌÓËÜÒÈÌÅÄÈÀ-ÏÐÎÅÊÒÎÐÎÂ, ÎÁÎÐÓÄÎÂÀÍÈß CISCO Message-ID: <200012251540.JAA14107@server1.Kpac.org> An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/jmp/attachments/20001225/94d6e5b9/attachment.html From journal at new_acropol.ru Fri Dec 29 16:07:39 2000 From: journal at new_acropol.ru (journal@new_acropol.ru) Date: Wed May 6 14:00:00 2009 Subject: JMP> Ñ ÍÎÂÛÌ ÃÎÄÎÌ Message-ID: <200012292107.PAA27367@server1.Kpac.org> An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/jmp/attachments/20001229/e8ead371/attachment.html From imcdonald at sharplabs.com Tue Jan 11 16:47:51 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: I-D ACTION:draft-ietf-snmpv3-update-mib-00.txt Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEE2@MAILSRVNT02> Hi folks, WARNING - the following document from the IETF SNMPv3 WG changes the syntax (type) of text objects in the System group of IETF MIB-II (RFC 1213) from 'DisplayString' (ASCII) to 'SnmpAdminString' (UTF-8 Unicode). This change was made at the explicit direction of the IESG, for conformance with 'IETF Policy on Character Sets and Languages' (RFC 2277). The IESG will no longer allow *any* MIB to be submitted for the Internet 'standards track' (or remain there for existing MIBs) unless all uses of 'DisplayString' (except language tag keywords from RFC 1766, which are *not* text) are changed to 'SnmpAdminString' (UTF-8 Unicode). This will definitely impact the Printer MIB v2 and Host Resources MIB v2 drafts when they are submitted to the IESG. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, January 11, 2000 3:40 AM Cc: snmpv3@lists.tislabs.com Subject: I-D ACTION:draft-ietf-snmpv3-update-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : Management Information Base for the Simple Network Management Protocol Author(s) R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser Filename : draft-ietf-snmpv3-update-mib-00.txt Pages : 29 Date : 10-Jan-00 This internet-draft, a work item of the SNMPv3 working group, is intended to obsolete RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-update-mib-00.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-snmpv3-update-mib-00.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-snmpv3-update-mib-00.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: Tue, 11 Jan 2000 13:56:38 -0800 Size: 933 Url: http://www.pwg.org/archives/jmp/attachments/20000111/43901443/attachment-0001.mht From imcdonald at sharplabs.com Tue Jan 11 16:57:49 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> FW: [Details on change from ASCII to UTF-8 in MIB-II] Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FEE3@MAILSRVNT02> Hi folks, Randy Presuhn (editor of the RFC 190x updates for the IETF SNMPv3 WG) has some good clarifications below. In particular, he observes that the 'over-the-wire' syntax of these objects does *not* change (always was the ASN.1 base type 'OCTET STRING'). Read on, if you're interested in the reasoning details. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] Sent: Tuesday, January 11, 2000 10:19 AM To: snmpv3@lists.tislabs.com Subject: Re: Issue 1907-18 proposed text Hi - > Message-Id: > In-Reply-To: <200001060232.SAA17791@dorothy.peer.com> > References: <200001060232.SAA17791@dorothy.peer.com> > Date: Mon, 10 Jan 2000 07:48:30 -0500 > To: Randy Presuhn , snmpv3@lists.tislabs.com > From: Robert Story > Subject: Re: Issue 1907-18 proposed text ... > I'm relatively new to this list, so I have missed the initial > discussion of this issue. Does anyone have a link to the list > archives and a timeframe for the initial discussion so I could catch > up? Given the disclaimer that I'm probably raising objections that > have already been raised (and possibly resolved), here's my two cents. There was fairly extensive discussion on the lists of the entity MIB working group. The thread started in July/August 1997. It revived in July and August of 1999, with concurrent discussion on the mibs@ops.ietf.org list. If there are problems accessing those archives, let me know and I'll see if I can distill out a relevant subset of the discussion. > I think that changing the semantics/syntax of an existing object is a > really bad idea. I can't tell you how many times I've had to explain > to a client that we couldn't change the syntax of an object once the > MIB was published. I don't relish the prospect of now having to tell > these clients that their existing agents/management applications need > to be updated because one of the standards has gone and changed the > semantics/syntax of an existing object. Neither the syntax nor the semantics would be changed. The syntax remains OCTET STRING. The semantics are laid out in the DESCRIPTION clause. The change is that a restriction in the permitted repertoire would be lifted. It's rather like the CCRs that prohibit tile roofs for houses in my neighborhood. There may have been a reason for such a restriction 25 years ago, but it no longer makes sense. > I'm all for adding support for multibyte characters, but I think we > should follow the same rules we impose on the rest of the world. > I've never liked the "do as I say, not as I do" mentality. > > Why not add a new branch, copy the existing one, update > DisplayStrings to SnmpAdminStrings, and depreciate the old branch? > Adding multibyte character support is going to mean that agents and > management applications are going to have to be updated, regardless > of whether or not the change is 'in-place' or a new branch is to be > supported. That's why the "weasel words" are proposed for the DESCRIPTION clauses. As a practical matter, robust management systems have long had to deal with the reality that some agent implementations have not enforced the NVT ASCII constraint. See the archives of the entity mib and MIBs mailing lists for detailed arguments. The decision to take this approach in those cases was not arrived at lightly, and the trade-offs should be thoroughly understood in this case as well. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Feb 28 18:51:46 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:17 2009 Subject: JMP> RE: IPP> Review of the SNMP Notifications Method Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FF7F@MAILSRVNT02> Hi Ron, I just asked Harry Lewis this same question earlier this afternoon and he agreed. So did Tom Hastings a few minutes ago. So, unless someone strongly objects, in my spare time (hah!) I'll rework the IPP Notifications over SNMP proposal to generalize the 'jmPrinterEvent' trap to be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, Fax MIB, or whatever). I'll *try* to get the new draft posted before the I-D cutoff on 10 March. Ron, what do you think about working this update to the Job Mon MIB via email and one or a few dedicated telecons? I can't travel to the PWG meetings. And in any case, they seem to be pretty full already with other topics. Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, February 28, 2000 1:59 PM To: McDonald, Ira Subject: Re: IPP> Review of the SNMP Notifications Method Ira, A change to jmDeviceEvent is a very good idea! The MFPA is presently trying to incorporate as much of the PWG work as possible into the Multifunction standards and this will certainly help with notifications. I don't believe that Sharp is an MFPA member, but you can still participate in the standards development. You can even attend the meetings. I expect to see more PWG participation in MFPA activities this year, now the the MFPA is doing some "real" work. Ron "McDonald, Ira" wrote: > Hi Ron, > > I've been contemplating, in support of the Scanner MIB > work and any possible future Fax MIB, abstracting the > current IPP Notifications over SNMP a little bit and > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > (which could then serve for Scanner MIB and private > MIB events). The PWG Job Monitoring MIB already > has 'JmJobServiceTypes' to express print, scan, fax-in, > fax-out, etc. in jobs and is therefore already abstracted > away from strictly print jobs. > > I had hoped to issue the new I-D before the 10 March > deadline (Carl-Uno isn't that when I-Ds are cutoff' > before IETF Adelaide, Australia??), but I've got the > flu and a ton of other work, so probably not. > > I copied the IPP WG on this note, so folks would know > what's happening as early as possible (before this > Wednesday's IPP WG Telecon). > > Cheers, > - Ira McDonald > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Wednesday, February 23, 2000 6:28 PM > To: Ira McDonald > Cc: Carl-Uno Manros > Subject: IPP> Review of the SNMP Notifications Method > > Ira, > > So far there has not been any group review of your proposal > for SNMP Notifications. The last two meetings had a very > full schedule with the new Set Operations and the other > notification methods. > > I have volunteered to lead the discussion on this document > and hope to have a slot in the Tokyo meeting. > > In the mean time I hope to do an extensive review of your > proposal. As I stated previously, it looks like an excellent > base for SNMP notifications. I do have some suggested > improvements which I believe can be made available by > the end of next week. (I had hoped to complete this task > prior to the LA meeting, but other task seem to get in the > way.) If we could at least have some discussions prior to > the Tokyo meeting, they could then be presented to the > group for additional feedback. > > I do not feel that any changes need to be made to your > document for the IETF meeting. From past experience, > there is not much feedback from these meetings unless > specific issues are contained in the presentation. Also, > I have not seen any participation from SNMP experts in > the IPP discussions. > > Ron Bergman > Hitachi Koki Imaging Solutions From rbergma at hitachi-hkis.com Mon Feb 28 19:35:31 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:17 2009 Subject: JMP> Re: IPP> Review of the SNMP Notifications Method References: <1115A7CFAC25D311BC4000508B2CA53730FF7F@MAILSRVNT02> Message-ID: <38BB1453.11978486@hitachi-hkis.com> Ira, I agree with trying to do more via email. Right now the IPP telecons are eating into too much of my time, so I would prefer to try email. Maybe telecons after the Toyko meeting, in place of some of the normal IPP calls. I really don't see any point in trying to get a new draft to the IETF. If you can, fine, but I would not recommend this be our "primary goal". I should have my promised comments before the end of the week and these may have more impact on the draft and generate more discussion. Ron "McDonald, Ira" wrote: > Hi Ron, > > I just asked Harry Lewis this same question earlier > this afternoon and he agreed. So did Tom Hastings > a few minutes ago. > > So, unless someone strongly objects, in my spare time > (hah!) I'll rework the IPP Notifications over SNMP > proposal to generalize the 'jmPrinterEvent' trap to > be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, > Fax MIB, or whatever). I'll *try* to get the new > draft posted before the I-D cutoff on 10 March. > > Ron, what do you think about working this update to > the Job Mon MIB via email and one or a few dedicated > telecons? I can't travel to the PWG meetings. And > in any case, they seem to be pretty full already with > other topics. > > Cheers, > - Ira McDonald (consulting architect at Sharp Labs America) > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Monday, February 28, 2000 1:59 PM > To: McDonald, Ira > Subject: Re: IPP> Review of the SNMP Notifications Method > > Ira, > > A change to jmDeviceEvent is a very good idea! The > MFPA is presently trying to incorporate as much of the > PWG work as possible into the Multifunction standards > and this will certainly help with notifications. > > I don't believe that Sharp is an MFPA member, but > you can still participate in the standards development. > You can even attend the meetings. I expect to see > more PWG participation in MFPA activities this year, > now the the MFPA is doing some "real" work. > > Ron > > "McDonald, Ira" wrote: > > > Hi Ron, > > > > I've been contemplating, in support of the Scanner MIB > > work and any possible future Fax MIB, abstracting the > > current IPP Notifications over SNMP a little bit and > > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > > (which could then serve for Scanner MIB and private > > MIB events). The PWG Job Monitoring MIB already > > has 'JmJobServiceTypes' to express print, scan, fax-in, > > fax-out, etc. in jobs and is therefore already abstracted > > away from strictly print jobs. > > > > I had hoped to issue the new I-D before the 10 March > > deadline (Carl-Uno isn't that when I-Ds are cutoff' > > before IETF Adelaide, Australia??), but I've got the > > flu and a ton of other work, so probably not. > > > > I copied the IPP WG on this note, so folks would know > > what's happening as early as possible (before this > > Wednesday's IPP WG Telecon). > > > > Cheers, > > - Ira McDonald > > > > -----Original Message----- > > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > > Sent: Wednesday, February 23, 2000 6:28 PM > > To: Ira McDonald > > Cc: Carl-Uno Manros > > Subject: IPP> Review of the SNMP Notifications Method > > > > Ira, > > > > So far there has not been any group review of your proposal > > for SNMP Notifications. The last two meetings had a very > > full schedule with the new Set Operations and the other > > notification methods. > > > > I have volunteered to lead the discussion on this document > > and hope to have a slot in the Tokyo meeting. > > > > In the mean time I hope to do an extensive review of your > > proposal. As I stated previously, it looks like an excellent > > base for SNMP notifications. I do have some suggested > > improvements which I believe can be made available by > > the end of next week. (I had hoped to complete this task > > prior to the LA meeting, but other task seem to get in the > > way.) If we could at least have some discussions prior to > > the Tokyo meeting, they could then be presented to the > > group for additional feedback. > > > > I do not feel that any changes need to be made to your > > document for the IETF meeting. From past experience, > > there is not much feedback from these meetings unless > > specific issues are contained in the presentation. Also, > > I have not seen any participation from SNMP experts in > > the IPP discussions. > > > > Ron Bergman > > Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Mon Feb 28 19:23:01 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> Review of the SNMP Notifications Method Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FF84@MAILSRVNT02> Hi Ron, Right - cart before the horse - I'll look forward to your comments and will *not* try to turn a new draft in the few remaining days before the I-D deadline. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Monday, February 28, 2000 4:36 PM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: Re: IPP> Review of the SNMP Notifications Method Ira, I agree with trying to do more via email. Right now the IPP telecons are eating into too much of my time, so I would prefer to try email. Maybe telecons after the Toyko meeting, in place of some of the normal IPP calls. I really don't see any point in trying to get a new draft to the IETF. If you can, fine, but I would not recommend this be our "primary goal". I should have my promised comments before the end of the week and these may have more impact on the draft and generate more discussion. Ron "McDonald, Ira" wrote: > Hi Ron, > > I just asked Harry Lewis this same question earlier > this afternoon and he agreed. So did Tom Hastings > a few minutes ago. > > So, unless someone strongly objects, in my spare time > (hah!) I'll rework the IPP Notifications over SNMP > proposal to generalize the 'jmPrinterEvent' trap to > be 'jmDeviceEvent' (usable from Scanner MIB, MFP MIB, > Fax MIB, or whatever). I'll *try* to get the new > draft posted before the I-D cutoff on 10 March. > > Ron, what do you think about working this update to > the Job Mon MIB via email and one or a few dedicated > telecons? I can't travel to the PWG meetings. And > in any case, they seem to be pretty full already with > other topics. > > Cheers, > - Ira McDonald (consulting architect at Sharp Labs America) > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Monday, February 28, 2000 1:59 PM > To: McDonald, Ira > Subject: Re: IPP> Review of the SNMP Notifications Method > > Ira, > > A change to jmDeviceEvent is a very good idea! The > MFPA is presently trying to incorporate as much of the > PWG work as possible into the Multifunction standards > and this will certainly help with notifications. > > I don't believe that Sharp is an MFPA member, but > you can still participate in the standards development. > You can even attend the meetings. I expect to see > more PWG participation in MFPA activities this year, > now the the MFPA is doing some "real" work. > > Ron > > "McDonald, Ira" wrote: > > > Hi Ron, > > > > I've been contemplating, in support of the Scanner MIB > > work and any possible future Fax MIB, abstracting the > > current IPP Notifications over SNMP a little bit and > > changing the 'jmPrinterEvent' to be 'jmDeviceEvent' > > (which could then serve for Scanner MIB and private > > MIB events). The PWG Job Monitoring MIB already > > has 'JmJobServiceTypes' to express print, scan, fax-in, > > fax-out, etc. in jobs and is therefore already abstracted > > away from strictly print jobs. > > > > I had hoped to issue the new I-D before the 10 March > > deadline (Carl-Uno isn't that when I-Ds are cutoff' > > before IETF Adelaide, Australia??), but I've got the > > flu and a ton of other work, so probably not. > > > > I copied the IPP WG on this note, so folks would know > > what's happening as early as possible (before this > > Wednesday's IPP WG Telecon). > > > > Cheers, > > - Ira McDonald > > > > -----Original Message----- > > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > > Sent: Wednesday, February 23, 2000 6:28 PM > > To: Ira McDonald > > Cc: Carl-Uno Manros > > Subject: IPP> Review of the SNMP Notifications Method > > > > Ira, > > > > So far there has not been any group review of your proposal > > for SNMP Notifications. The last two meetings had a very > > full schedule with the new Set Operations and the other > > notification methods. > > > > I have volunteered to lead the discussion on this document > > and hope to have a slot in the Tokyo meeting. > > > > In the mean time I hope to do an extensive review of your > > proposal. As I stated previously, it looks like an excellent > > base for SNMP notifications. I do have some suggested > > improvements which I believe can be made available by > > the end of next week. (I had hoped to complete this task > > prior to the LA meeting, but other task seem to get in the > > way.) If we could at least have some discussions prior to > > the Tokyo meeting, they could then be presented to the > > group for additional feedback. > > > > I do not feel that any changes need to be made to your > > document for the IETF meeting. From past experience, > > there is not much feedback from these meetings unless > > specific issues are contained in the presentation. Also, > > I have not seen any participation from SNMP experts in > > the IPP discussions. > > > > Ron Bergman > > Hitachi Koki Imaging Solutions From imcdonald at sharplabs.com Tue Mar 7 17:58:17 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFA1@MAILSRVNT02> Hi Ron, My replies are below, prefixed by '> (ira)'. It would appear that I won't have the time after some future concensus to put out a revised I-D before the 10 March deadline (especially if I have to add all your proposed objects - see below). [These comments all address my latest IPP Notifications over SNMP - which defines two traps to add to the PWG Job Monitoring MIB and a few objects for bindings]. In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Wednesday, March 01, 2000 6:36 PM To: Ira McDonald Cc: ipp@pwg.org Subject: Comments on the SNMP Notifications Document Ira, At last here are my comments. I hope this starts a good discussion. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but is should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscdription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. > 3. Section 3.1: "jmEventEventPrinterState" should be "jmEventPrinterState". > (ira) > Noted - thanks 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 7. Scheme Name: I was going to propose "snmpnotify", but if "snmp" can be used, it is better yet! > (ira) > Lost my mind - 'snmp:' would indicate an SNMP Agent (command > receiver) entity. > We need to define 'snmpnotify:' (notification receiver) for > the SNMP Manager entity that gets notified. 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. I hate to ask, but any comments? Ron Bergman Hitachi Koki Imaging Solutions, Inc. From rbergma at hitachi-hkis.com Thu Mar 9 12:06:19 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:18 2009 Subject: JMP> Re: Comments on the SNMP Notifications Document References: <1115A7CFAC25D311BC4000508B2CA53730FFA1@MAILSRVNT02> Message-ID: <38C7DA0A.EC77EF4A@hitachi-hkis.com> Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Thu Mar 9 16:03:46 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> Re: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFAE@MAILSRVNT02> Hi Ron, I just read through all of this. Good comments. I'm kind of burned out at the moment (from flu and too many hours editing) so it may be next week before I reply. Many thanks for your careful reading. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, March 09, 2000 9:06 AM To: McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: IPP> Re: Comments on the SNMP Notifications Document Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Fri Mar 10 19:08:43 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> Re: Comments on the SNMP Notifications Document Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFB5@MAILSRVNT02> Hi Ron and PWG folks, At our IPP WG Telecon this Wednesday (8 March), Ron asked that I have a revised draft of the Job MIB-based IPP notifications over SNMP document out in time for review during the upcoming PWG meeting in Tokyo (at the beginning of April). I've been thinking about Ron's comments and have just spoken with Harry Lewis about my ideas for changes. So here's what I propose to do (and some about why): 1) Define objects for all of the Job event bindings that occur in Job Attribute table members - because it's impossible in ASN.1 to reference an *instance* of an object (and the *type* of each job attribute is part of its *instance qualifier*, that is, it's an index element). - this brings us full circle to six months ago. 2) Define THREE Job events (state change, progress, complete) with bindings that exactly match IPP Notifications Spec requirements - this allows in-band event registration via SNMP using any of the methods I've seen in vendor private MIBs (view-based like old SNMPv2c Party MIB, booleans for each trap, or bit-masks for each trap). - this also works with script-based open management stations (HP OpenView, CA Unicenter, IBM Tivoli, etc.) which CANNOT be used with a single generic job event (because they case on the OID of the base NOTIFICATION-TYPE/TRAP-TYPE macro). - this brings us full circle to six months ago. 3) Generalize the Printer event to Device event - this allows the Job MIB which already supports other MFP job types (fax, scan, etc.) to be used for event notification for Scanner MIB, Fax MIB, MFP MIB, etc. - this allows future (possible) expansion of IPP to support other MFP job types 4) Change the scheme name to 'snmpnotify:' with some discussion of parameters - the work to register the 'snmpnotify:' scheme will ultimately have to be carried on in a separate I-D anyway and worked with the IETF SNMPv3 WG. 5) Specify that the Job Mon MIB traps may ONLY be delivered as unacknowledged Trap-PDUs and NOT as acknowledged Inform-PDUs - this is because there is NOT a table of all job events with unique objects for each delivered event (which would be impossible for resource reasons for job progress events, anyway). - thus the leaf objects that hold the Job trap bindings have a given value only instantaneously (until the subsequent trap is emitted from the MIB). - using acknowledged Informs would FORCE us to have a full-blown event table. I plan to begin the above edits immediately and to put a revised draft on the PWG FTP server by Friday (24 March 2000), two weeks from now - it will also be forwarded as an Internet-Draft but will not be available for the Adelaide, Australia IETF 47 the following week of 26-31 March. Comments? Cheers, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: McDonald, Ira Sent: Thursday, March 09, 2000 1:04 PM To: 'Ron Bergman'; McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: RE: IPP> Re: Comments on the SNMP Notifications Document Hi Ron, I just read through all of this. Good comments. I'm kind of burned out at the moment (from flu and too many hours editing) so it may be next week before I reply. Many thanks for your careful reading. Cheers, - Ira -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, March 09, 2000 9:06 AM To: McDonald, Ira Cc: ipp@pwg.org; 'jmp@pwg.org' Subject: IPP> Re: Comments on the SNMP Notifications Document Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see (1 December 1999) Ira, My comments are prefixed by '* (ron)'. I have deleted items 3 and 7, since I believe they are resolved. 1. Job MIB Event Group, jmEventPrinterState: This object syntax is defined as OCTET STRING, but it should match the syntax of the IPP attribute "printer-state", which is an enumeration. The enums values also should be aligned with "printer-state" (i.e. idle(3), processing(4), stopped(5) ). > (ira) > I changed this to a string (keyword) in the most recent draft > to decouple from IPP. When we generalize 'printer-state' to > 'device-state', the three IPP states may NOT be appropriate > or complete. * (ron) * There are advantages to maintaining commonality with IPP. (I also * prefer enums over strings for SNMP.) We certainly also need to keep * 'device-state' aligned with 'printer-state', if and when this * attribute is created. 2. Job MIB Event Group: The value of the objects in this group can have many values, unique to each notification and subscription. In order for these objects to be properly identified, this group should be a table with multiple indexes. Some of the indexes necessary would be (more may be necessary): - jmGeneralJobSetIndex - jmJobIndex - jmEventIndex (new, must be defined) - jmEventSubscriptionID However, I don't see any need for direct access to any these objects. The only need for this group is to define the OIDs for use by the SNMP notification. Within the context of the notification, these is no need to provide a unique OID to each instance of an object. A better solution would be to change the MAX-ACCESS clause from "read-only" to "not-accessible". Since this would be a somewhat unusual application of an SNMP object group, a short explanation needs to be added. > (ira) > TRAPs may NOT include objects that are 'not-accessible', only > 'read-only' or higher (or the incompatible 'accessible-for-notify' > in RFC 2578, which obsoletes RFC 1902 - it's irrational to > use 'accessible-for-notify' in a MIB definition - it can't > be translated to SMIv1 or classic SMIv2). > > I had separate objects in the last draft for each binding (without > indexing), but removed them as redundant with the existing MIB. > TRAPs are permitted to have optional bindings in SNMPv1/v2/v3. > Therefore, we don't need to enumerate the bindings in OBJECTS > clause of NOTIFICATION-TYPE macro. * (ron) * My error! I forgot about the recent issue with the Printer MIB * alert table index in the trap! So I sadly accept 'read-only', * but a statement needs to be added such as: * "These objects are provided for identification of values that * are returned in a printer event or job event notification only. * Indexing is not defined for these objects to properly define * the context of the value outside of the applicable notification. * It is not recommended that an SNMP Manager perform a Get to any * of these objects. The value returned by an SNMP Agent, to a * Set, is implementation dependent as to its validity." 4. The notification contains 5 objects to define printer status (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, jmEventPrinterState, and jmEventPrinterStateReasons). This seems like a large number of objects just to indicate what is wrong with the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add very little value and I strongly recommend their removal. hrPrinterDetectedErrorState could be considered of marginal value, due to the presence of jmEventPrinterStateReasons, but would provide easier machine processing capability. Certainly jmEventPrinterState and jmEventPrinterStateReasons are sufficient for human use. > (ira) > The idea was that the notification would kill two birds. > 1) Deliver IPP notifications for printers. > 2) Let existing Printer MIB implementations emit 'reports' > and 'warnings' and non-critical 'errors' via traps. > Therefore, the 'hrxxx' objects - I'm willing to remove them > and remove the coupling with HR MIB their presence causes > for the (presently decoupled) Job Mon MIB. * (ron) * Although this is certainly a noble goal, I would prefer a simpler * notification rather than be 'all things to all people.' 5. The mapping of printer-uri to prtChannelInformation does not seem appropriate. I also question the need for both the printer name and the printer URI in the notification. We sometimes go overboard and I am surprised that the printer location, manufacturer, model, serial number, and date of manufacture are not also included;-). > (ira) * (ron) * Did your comment get lost? 6. The representation of an attribute in a notification presents another unique problem. The OID of an attribute cannot be determined without first processing the entire attribute table in the Job Monitoring MIB within the device. Even after this processing, it cannot be guaranteed that the OIDs will be stable. To resolve this issue it would be best to include additional entries in the Job MIB Event group for each attribute that is needed in the notification. Thus, 10 new objects would need to be added. > (ira) > See my comments at your point (2) above. > I was trying not to define redundant objects. I'm happy to > add these trap binding objects BACK into the MIB, but then > I have to define several traps, because of the different > (per IPP Notifications spec) bindings of various job events. > - Messy - not very extensible. > > I also believe it's *critical* to have a keyword string > state-reasons (like IPP) to allow vendor private extensions > which are not possible with the current Job Mon MIB bit-wise > encoding of state-reasons. This is a major ask from > my Sharp implementor community. * (ron) * This really a messy issue! I am not sure how an attribute * could be uniquely defined in a trap (inform) without an OID * assignment as proposed. Also, why does this method prevent * additional var-binds from being appended to the trap? * * I agree that keyword strings are more flexible for the job * state reasons. (I missed this one!) Remove the three OIDs * that I added for job state reasons below. This leaves only * seven new objects. Better yet! jmEventJobName for "jmAttributeValue...jobName.1" jmEventJobStateReasons2 for ... jmEventJobStateReasons3 for ... jmEventJobStateReasons4 for ... jmEventSheetsCompleted for ... jmEventJobCollationType for ... jmEventSheetCompletedCopyNumber for ... jmEventSheetCompletedDocumentNumber for ... jmEventImpressionsInterpreted for ... jmEventImpressionsCompletedCurrentCopy for ... jmEventJobName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable string name of the job assigned by the submitting user to allow the user to distinguish this job among others submitted by the same user. The name may be truncated, if necessary, to fit into the SNMP datagram. This value is equivalent to the Job MIB Attribute jobName that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 8 } jmEventJobStateReasons2 OBJECT-TYPE SYNTAX JmJobStateReasons2TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons3 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons2 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 9 } jmEventJobStateReasons3 OBJECT-TYPE SYNTAX JmJobStateReasons3TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons4. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons3 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 10 } jmEventJobStateReasons4 OBJECT-TYPE SYNTAX JmJobStateReasons4TC MAX-ACCESS read-only STATUS current DESCRIPTION "Provides addition information concerning the state of the job, in addition to or instead of the information presented in jmJobStateReasons1, jmEventJobStateReasons2 or jmEventJobStateReasons3. The value of this object corresponds to the value of the Job MIB Attribute jobStateReasons4 that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 11 } jmEventSheetsCompleted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the total number of media sheets that have completed marking and stacking for this job. This value is equivalent to the Job MIB Attribute sheetsCompleted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 12 } jmEventJobCollationType OBJECT-TYPE SYNTAX JmJobCollationTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of collation used for this job. This value is equivalent to the Job MIB Attribute jobCollationType that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 13 } jmEventSheetCompletedCopyNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the copy being stacked for the current copy document in this job. This value is equivalent to the Job MIB Attribute sheetCompletedCopyNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 14 } jmEventSheetCompletedDocumentNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the ordinal number of the document in the job that is currently being stacked. This value is equivalent to the Job MIB Attribute sheetCompletedDocumentNumber that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 15 } jmEventImpressionsInterpreted OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the job . This value is equivalent to the Job MIB Attribute impressionsInterpreted that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 16 } jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current number of impressions completed for the current copy of the current document . This value is equivalent to the Job MIB Attribute impressionsCompletedCurrentCopy that is associated with the job. See: Section 7 'Notification Content' in [IPP-NOT]." ::= { jmEvent 17 } 8. You had proposed including three optional parameters in the scheme URL. (version, pdu-type, and community-name) We also need an IPP attribute so that the printer can be queried to determine which scheme parameters are supported. (if we are not careful here we will have another "3 musketeers" situation) For discussion purposes, I propose the following: attribute name: snmp-notifications-supported attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform, snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap, and snmpV3uInform. > (ira) > I'm worried about the possible number of optional URL parameters. > This needs more thought. > I'd also like to observe that some of your SNMP flavors (above > and below) are marked Historic or Obsolete by the IETF. In particular, > SNMPv3c (community) doesn't exist according to the IETF. > And I don't much like encouraging people to use Inform (acknowledged > event) because end-nodes (printers) are NEVER supposed to generate > an Inform (it's reserved for the use of middle-tier management > stations 'rolling up' event summaries to their superiors). * (ron) * I didn't research the status of the values above, so some of them * can possibly be removed. I was just trying to present the concept. * * Your comment on informs catches me by surprise. First we had * discussed the use of informs in early discussions. (snmpnotify * was proposed in place of snmptrap as the scheme name to allow * informs?) Second, I did read in the SNMPv2 document (not sure * which) of their use as you state. However, in some early Job * MIB meetings on adding traps, Randy Turner pointed out that the * newer SNMP documents removed that restriction on informs. (I * do not know which document he was referring to, nor have I * personally seen any text to this regard.) Informs do provide * additional delivery reliability in those exceptional situations * where this is desired. So it seems good to be able to support. There is a potential problem with SNMPv3, in that the PDU can be encoded by any one of multiple methods, and I totally ignored SNMPv2u security in a v3 packet. But having each variant combination a separate value prevents illegal combinations. All for now. I expect you will ignore this until the IDs for the Adelaide meeting are completed. Ron From imcdonald at sharplabs.com Mon Mar 20 02:37:00 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> NOT - IPP Notify over SNMP (Job Mon traps) v0.2 - 19 March 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFD8@MAILSRVNT02> Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just posted an updated version of 'IPP Notifications over SNMP' to the PWG server (for the upcoming PWG meeting in Japan in April): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (23 March 2000) at 10-12 PST / 1-3 EST. I have NOT forwarded this draft to the Internet-Drafts editor yet. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (16 March 2000) - see change log below. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 19 March 2000 1) Renamed Printer Event notification group to Device Basic Event and 'jmPrinterEventV2Event' notification to 'jmDeviceBasicV2Event', to better align with IPP and to support non-printing jobs. 2) Revised 'jmDeviceBasicV2Event' notification to remove 'hrDeviceStatus', 'hrPrinterStatus', 'hrPrinterDetectedErrorState' from mandatory trap bindings because they were redundant, per request of Ron Bergman. 3) Renamed Job Event notification group to Job Basic Event and 'jmJobEventV2Event' notification to 'jmJobBasicV2Event', to better align with IPP and to support variant job events. 4) Defined new Job Completed Event notification group and defined new Job Progress Event notification group, to better align with IPP and to support variant job events. 5) Renamed Event object group to Event Binding, 'jmEventPrinterState' to 'jmEventDeviceState', 'jmEventPrinterStateReasons' to 'jmEventDeviceStateReasons', 'jmEventPrinterIsAcceptingJobs' to 'jmEventDeviceIsAcceptingJobs', to support non-printing jobs. 6) Revised Event Binding object group, adding explicit objects 'jmEventDeviceURI', 'jmEventDeviceName', 'jmEventJobSetIndex', 'jmEventJobIndex', 'jmEventJobName', 'jmEventJobState', 'jmEventJobStateReasons', 'jmEventJobKOctets', 'jmEventJobKOctetsProcessed', 'jmEventJobImpressions', 'jmEventJobImpressionsCompleted', 'jmEventJobMediaSheets', 'jmEventJobMediaSheetsCompleted', 'jmEventJobImpressionsCompletedCC', 'jmEventJobCollationType', 'jmEventJobSheetCompletedCopyNum', 'jmEventJobSheetCompletedDocNum', per request of Ron Bergman. 7) Revised SYNTAX of 'jmEventTriggerEvent' object from from 'JmUTF8StringTC' (string) to IPP-aligned enumeration, per request of Ron Bergman. 8) Removed all references to Printer MIB v2, as they were of limited value, per request of Ron Bergman. 9) Revised 'SNMP Mapping for IPP Printer Events' section for renamed event binding objects, per request of Ron Bergman. 10) Revised 'Rules for Encoding Notifications' section to truncate additional string bindings, per request of Ron Bergman. 11) Revised 'Registration via IPP' section, to change scheme name from 'ipp-snmp:' to 'snmpnotify:', per request of Ron Bergman. - 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. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Mar 21 17:58:42 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RFC 2790 - Host Resources MIB v2 - Let's move Printer MIB v2 Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FFE5@MAILSRVNT02> Hi folks, RFC 2790 - Host Resources MIB v2 (March 2000) - IETF Draft Standard status This was posted last week (14 March 2000) but got past me until it showed up in the RFC Index today. So now it's time to get on with Printer MIB v2. I urge that we fold the text of Finisher MIB into the Printer MIB v2 text (after all it completes the model in original Printer MIB, RFC 1759, March 1995) and NOT publish Finisher MIB as a separate RFC. I also urge that we press on as quickly as possible with publishing a definitive text for Printer MIB v2 (with the approved additions from July 1999 for new generic alerts and 'chIPP' specification) and move it to PMP WG last call and send it onward for IESG last call. More than one vendor has already shipped a product with Printer MIB v2 new objects implemented. Remember that since the bar is now *very* high for advancement to Draft Standard, the Printer MIB v2 MUST be published at Proposed Standard and convincing proof of interoperable implementations of EVERY object and object group must be presented to the IESG and publicly posted before we can request movement to Draft Standard status. Cheers, - Ira McDonald, consulting architect at Sharp Labs America High North Inc From hastings at cp10.es.xerox.com Wed Mar 22 18:54:15 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> NOT - [Downloaded .pdf file for] IPP Notify over SNMP (J ob Mon traps) v0.2 - 19 March 2000 Message-ID: <918C79AB552BD211A2BD00805F15CE8502C9576B@x-crt-es-ms1.cp10.es.xerox.com> I've down loaded the .pdf file with line numbers: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.pdf Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, March 19, 2000 23:37 To: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: IPP> NOT - IPP Notify over SNMP (Job Mon traps) v0.2 - 19 March 2000 Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just posted an updated version of 'IPP Notifications over SNMP' to the PWG server (for the upcoming PWG meeting in Japan in April): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-02.txt I'd like to add this to our IPP WG Telecon agenda for next Wednesday (23 March 2000) at 10-12 PST / 1-3 EST. I have NOT forwarded this draft to the Internet-Drafts editor yet. All changes were agreed to when we last discussed this document at the IPP WG Telecon on Wednesday (16 March 2000) - see change log below. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ CHANGE LOG Changes in reverse chronological order (most recent first). - 19 March 2000 1) Renamed Printer Event notification group to Device Basic Event and 'jmPrinterEventV2Event' notification to 'jmDeviceBasicV2Event', to better align with IPP and to support non-printing jobs. 2) Revised 'jmDeviceBasicV2Event' notification to remove 'hrDeviceStatus', 'hrPrinterStatus', 'hrPrinterDetectedErrorState' from mandatory trap bindings because they were redundant, per request of Ron Bergman. 3) Renamed Job Event notification group to Job Basic Event and 'jmJobEventV2Event' notification to 'jmJobBasicV2Event', to better align with IPP and to support variant job events. 4) Defined new Job Completed Event notification group and defined new Job Progress Event notification group, to better align with IPP and to support variant job events. 5) Renamed Event object group to Event Binding, 'jmEventPrinterState' to 'jmEventDeviceState', 'jmEventPrinterStateReasons' to 'jmEventDeviceStateReasons', 'jmEventPrinterIsAcceptingJobs' to 'jmEventDeviceIsAcceptingJobs', to support non-printing jobs. 6) Revised Event Binding object group, adding explicit objects 'jmEventDeviceURI', 'jmEventDeviceName', 'jmEventJobSetIndex', 'jmEventJobIndex', 'jmEventJobName', 'jmEventJobState', 'jmEventJobStateReasons', 'jmEventJobKOctets', 'jmEventJobKOctetsProcessed', 'jmEventJobImpressions', 'jmEventJobImpressionsCompleted', 'jmEventJobMediaSheets', 'jmEventJobMediaSheetsCompleted', 'jmEventJobImpressionsCompletedCC', 'jmEventJobCollationType', 'jmEventJobSheetCompletedCopyNum', 'jmEventJobSheetCompletedDocNum', per request of Ron Bergman. 7) Revised SYNTAX of 'jmEventTriggerEvent' object from from 'JmUTF8StringTC' (string) to IPP-aligned enumeration, per request of Ron Bergman. 8) Removed all references to Printer MIB v2, as they were of limited value, per request of Ron Bergman. 9) Revised 'SNMP Mapping for IPP Printer Events' section for renamed event binding objects, per request of Ron Bergman. 10) Revised 'Rules for Encoding Notifications' section to truncate additional string bindings, per request of Ron Bergman. 11) Revised 'Registration via IPP' section, to change scheme name from 'ipp-snmp:' to 'snmpnotify:', per request of Ron Bergman. - 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. ------------------------------------------------------------------------ From hastings at cp10.es.xerox.com Fri May 5 12:34:20 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:18 2009 Subject: JMP> FW: Job MIB Bake Off and Status Message-ID: <918C79AB552BD211A2BD00805F15CE85031F45F2@x-crt-es-ms1.cp10.es.xerox.com> Job MIB WG, What should we tell Brian about a Job MIB Bakeoff? Could it be piggy backed on the IPP bakeoff planned for this October? Tom -----Original Message----- From: Brian Anderson [mailto:banderson@sofha.com] Sent: Thursday, May 04, 2000 10:02 To: hastings@cp10.es.xerox.com Subject: Job MIB Bake Off and Status Hi Tom: It has been a long time since I followed what is happening with the Job MIB. Is there still plans to have a Bake Off this year? Also can you tell me if the Job MIB will support assigning job id's to forms? That is a downloaded form such as letterhead form or fax form that stays resident in a device. Thank you, - Brian Anderson Director of Sales and Marketing SOFHA USA 8001 Irvine Center Drive Fourth Floor Irvine CA, 92618 Tel: 949/754-3105, Fax: 949/754-4001 Email: banderson@sofha.com From imcdonald at sharplabs.com Mon May 22 21:28:41 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> NOT - Simpler traps for Job Mon MIB proposal Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD69@MAILSRVNT02> Hi folks, Tuesday (18 April 2000) Below is an ASN.1 sketch of a set of objects and notifications for the Job Monitoring MIB (IPP notifications over SNMP). A shortcoming in past drafts is the lack of persisent tables for device (printer) and job events. This proposal has persistent event tables, plus an extension mechanism for extra trap bindings (for 'job-completed' and 'job-progress' events). The tables are: Device, Device Event, Job Event, and Job Extra (for additional bindings with the Job Progress Event). The traps are: Device Event, Job Event, and Job Progress Event (for both 'job-progress' and 'job-completed' events). The '...Notify[Language|Text|TextFormat' objects may be null strings. Comments? Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc ------------------------------------------------------------------------ -- Device Group -- Systems which implement IETF Host Resources MIB RFC 2790 should -- set 'jmDeviceIndex' equal to 'hrDeviceIndex' for the same device -- INDEX { jmDeviceIndex } jmDeviceEntry ::= SEQUENCE { jmDeviceIndex Integer32 (1..2147483647) jmDeviceName SnmpAdminString, jmDeviceURI SnmpAdminString, jmDeviceServiceTypes JmJobServiceTypesTC, jmDeviceState JmDeviceStateTC, jmDeviceStateReasons SnmpAdminString, jmDeviceIsAcceptingJobs TruthValue } -- Device Event Group -- INDEX { jmDeviceIndex, -- jmDeviceEventIndex } jmDeviceEventEntry ::= SEQUENCE { jmDeviceEventIndex Integer32 (1..2147483647), jmDeviceEventState JmDeviceStateTC, jmDeviceEventStateReasons SnmpAdminString, jmDeviceEventIsAcceptingJobs TruthValue, jmDeviceEventTriggerEvent SnmpAdminString, jmDeviceEventNotifyCharset CodedCharSet, jmDeviceEventNotifyLanguage SnmpAdminString, jmDeviceEventNotifyTextFormat SnmpAdminString, jmDeviceEventNotifyText OCTET STRING (SIZE (0..255)), jmDeviceEventUpTime TimeTicks, jmDeviceEventDateTime DateAndTime } -- Device Event Notify (Trap/Inform) jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventState, jmDeviceEventStateReasons, jmDeviceEventIsAcceptingJobs, jmDeviceEventTriggerEvent, jmDeviceEventNotifyCharset, jmDeviceEventNotifyLanguage, jmDeviceEventNotifyTextFormat, jmDeviceEventNotifyText, jmDeviceEventUpTime, jmDeviceEventDateTime } -- Job Event Group -- INDEX { jmJobSetIndex, -- jmJobIndex, -- jmJobEventIndex } jmJobEventEntry ::= SEQUENCE { jmJobEventIndex Integer32 (1..2147483647), jmJobEventState JmJobStateTC, jmJobEventStateReasons OCTET STRING (SIZE (4..16)), jmJobEventTriggerEvent SnmpAdminString, jmJobEventNotifyCharset CodedCharSet, jmJobEventNotifyLanguage SnmpAdminString, jmJobEventNotifyTextFormat SnmpAdminString, jmJobEventNotifyText OCTET STRING (SIZE (0..255)), jmJobEventUpTime TimeTicks, jmJobEventDateTime DateAndTime, jmJobCountKOctetsProcessed Integer32 (-2..2147483647), jmJobCountImpressionsCompleted Integer32 (-2..2147483647) } -- Job Event Notify (Trap/Inform) jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventState, jmJobEventStateReasons, jmJobEventTriggerEvent, jmJobEventNotifyCharset, jmJobEventNotifyLanguage, jmJobEventNotifyTextFormat, jmJobEventNotifyText, jmJobEventUpTime, jmJobEventDateTime } -- Job Progress Notify (Trap/Inform) -- For both job-progress and job-completed events jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventState, jmJobEventStateReasons, jmJobEventTriggerEvent, jmJobEventNotifyCharset, jmJobEventNotifyLanguage, jmJobEventNotifyTextFormat, jmJobEventNotifyText, jmJobEventUpTime, jmJobEventDateTime, jmJobCountKOctetsProcessed, jmJobCountImpressionsCompleted } -- Job Extra Group -- Optional group for extra bindings on job events -- INDEX { jmJobSetIndex, -- jmJobIndex, -- jmJobEventIndex, -- jmJobExtraAttributeTypeIndex } jmJobExtraEntry ::= SEQUENCE { jmJobExtraAttributeTypeIndex JmAttributeTypeTC, jmJobExtraAttributeValueInteger Integer32 (-2..2147483647), jmJobExtraAttributeValueOctets OCTET STRING (SIZE (0..63)) } ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed May 31 21:04:04 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD76@MAILSRVNT02> Hi folks, Tuesday (18 April 2000) Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventNotifyEvent, jmDeviceState, jmDeviceStateReasons } jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons } jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons, jmJobEventKOctetsProcessed, jmJobEventImpressionsCompleted } I propose to write this all up in a revised Internet-Draft in the near future. Comments? Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc ------------------------------------------------------------------------ Changes from previous proposal of 22 May 2000: 1) Revised INDEX clauses of tables to always use single-level indices. 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and 'jmJobEventJobIndex' pointer objects to event tables but not traps. 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap because it's redundant with a value of '...DeviceStateReasons'. 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' from event tables and traps because they're incompatible with SNMP libraries (which assemble trap bindings and then send the IDENTICAL trap to all registered destinations) - in IPP, each destination MAY request a DIFFERENT value of '...NotifyLanguage', etc. 5) Deleted '...UpTime' from traps because 'sysUpTime' is included in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. 6) Deleted '...DateTime' from traps and event tables because it's redundant with '...UpTime' objects. 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I think this is the agreement for all IPP notification methods). ------------------------------------------------------------------------ -- Device Table - devices which support job services -- -- Systems which also implement IETF Host Resources MIB (RFC 2790) -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device -- INDEX { jmDeviceIndex } jmDeviceEntry ::= SEQUENCE { jmDeviceIndex Integer32 (1..2147483647), jmDeviceName SnmpAdminString, jmDeviceURI SnmpAdminString, jmDeviceServiceTypes JmJobServiceTypesTC, jmDeviceState JmDeviceStateTC, jmDeviceStateReasons SnmpAdminString } -- Device Event Table -- -- Rows are persistent until system reboot or table overflow -- INDEX { jmDeviceEventIndex } jmDeviceEventEntry ::= SEQUENCE { jmDeviceEventIndex Integer32 (1..2147483647), jmDeviceEventNotifyEvent SnmpAdminString, jmDeviceEventNotifyTime TimeTicks, jmDeviceEventDeviceIndex Integer32 (1..2147483647), jmDeviceEventDeviceState JmDeviceStateTC, jmDeviceEventDeviceStateReasons SnmpAdminString } -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For all device events jmDeviceEventV2Event NOTIFICATION-TYPE OBJECTS { jmDeviceEventNotifyEvent, jmDeviceState, jmDeviceStateReasons } -- Job Event Table - persistent only for lifetime of job -- -- Rows are persistent ONLY for lifetime of job -- INDEX { jmJobEventIndex } jmJobEventEntry ::= SEQUENCE { jmJobEventIndex Integer32 (1..2147483647), jmJobEventNotifyEvent SnmpAdminString, jmJobEventNotifyTime TimeTicks, jmJobEventJobSetIndex Integer32 (1..32767), jmJobEventJobIndex Integer32 (1..2147483647), jmJobEventJobState JmJobStateTC, jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), jmJobEventKOctetsProcessed Integer32 (-2..2147483647), jmJobEventImpressionsCompleted Integer32 (-2..2147483647) } -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For basic job events jmJobEventV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons } -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform -- -- For both job-progress and job-completed events jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, jmJobState, jmJobEventJobStateReasons, jmJobEventKOctetsProcessed, jmJobEventImpressionsCompleted } ------------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Jun 1 14:15:48 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:18 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 References: <1115A7CFAC25D311BC4000508B2CA5375ECD76@MAILSRVNT02> Message-ID: <3936A853.11F24E60@hitachi-hkis.com> Ira, Its getting hard to keep up with your changes;-) The smaller content for both jmDeviceEventV2Event and jmJobEventV2Event seem to be reasonable. This is most likely all anyone would want for these traps. However, the jmJobProgressV2Event should contain sufficient information to allow the client application to maintain a set of "gas gauge" style displays. This makes this trap fairly heavy, but without this information the trap is not very useful. I eliminated jmJobState and jmJobEventJobStateReasons since a state change seldom happens during printing, at least as compared to progress, and a separate jmJobEventV2Event trap can be sent to report state changes. I don't believe that this trap content will exceed the 485 byte limit, but I did not do a byte count. Here is my revised proposal: jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, -- new object jmJobKOctetsPerCopyRequested, -- from Job MIB jmJobKOctetsProcessed, -- from Job MIB jmJobImpressionsPerCopyRequested, -- from Job MIB jmJobImpressionsCompleted, -- from Job MIB jmJobEventCopiesRequested, -- new object jmJobEventJobCollationType, -- new object jmJobEventMediaSheetsCompleted, -- new object jmJobEventSheetCompletedCopyNumber, -- new object jmJobEventSheetCompletedDocNumber -- new object } Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi folks, Tuesday (18 April 2000) > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > I propose to write this all up in a revised Internet-Draft in the near > future. > > Comments? > > Cheers, > - Ira McDonald, consulting architect at Xerox and Sharp > High North Inc > > ------------------------------------------------------------------------ > > Changes from previous proposal of 22 May 2000: > > 1) Revised INDEX clauses of tables to always use single-level indices. > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > because it's redundant with a value of '...DeviceStateReasons'. > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > from event tables and traps because they're incompatible with SNMP > libraries (which assemble trap bindings and then send the IDENTICAL > trap to all registered destinations) - in IPP, each destination MAY > request a DIFFERENT value of '...NotifyLanguage', etc. > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > 6) Deleted '...DateTime' from traps and event tables because it's > redundant with '...UpTime' objects. > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > think this is the agreement for all IPP notification methods). > > ------------------------------------------------------------------------ > > -- Device Table - devices which support job services > -- > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > -- INDEX { jmDeviceIndex } > jmDeviceEntry ::= SEQUENCE { > jmDeviceIndex Integer32 (1..2147483647), > jmDeviceName SnmpAdminString, > jmDeviceURI SnmpAdminString, > jmDeviceServiceTypes JmJobServiceTypesTC, > jmDeviceState JmDeviceStateTC, > jmDeviceStateReasons SnmpAdminString > } > > -- Device Event Table > -- > -- Rows are persistent until system reboot or table overflow > > -- INDEX { jmDeviceEventIndex } > jmDeviceEventEntry ::= SEQUENCE { > jmDeviceEventIndex Integer32 (1..2147483647), > jmDeviceEventNotifyEvent SnmpAdminString, > jmDeviceEventNotifyTime TimeTicks, > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > jmDeviceEventDeviceState JmDeviceStateTC, > jmDeviceEventDeviceStateReasons SnmpAdminString > } > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For all device events > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > -- Job Event Table - persistent only for lifetime of job > -- > -- Rows are persistent ONLY for lifetime of job > > -- INDEX { jmJobEventIndex } > jmJobEventEntry ::= SEQUENCE { > jmJobEventIndex Integer32 (1..2147483647), > jmJobEventNotifyEvent SnmpAdminString, > jmJobEventNotifyTime TimeTicks, > jmJobEventJobSetIndex Integer32 (1..32767), > jmJobEventJobIndex Integer32 (1..2147483647), > jmJobEventJobState JmJobStateTC, > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > } > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For basic job events > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For both job-progress and job-completed events > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Fri Jun 2 09:11:20 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> Very small Job Mon traps (IPP notifications) - 31 May 20 00 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD79@MAILSRVNT02> Hi Ron, Thanks very much for your quick feedback. I see your point about a detailed trap for job-progress. But in recent IPP discussions, the agreement was that REQUIRED content for IPP events would be very small (this latest sketch of mine is aligned with IPP here) and servers (IPP Printers) or clients could OPTIONALLY add additional bindings. Any SNMP trap may have additional bindings, by SNMP rules. What you're requesting is that ALL job-progress traps have 'gas gauge' bindings - but this places a higher conformance requirement on Job Mon MIB implementations to support these optional job attributes for this 'gas gauge'. SMI standard usage is never to bind static info (names, submitted job size, etc.) into traps, but to let the client separately read and cache such static info. This is part of the problem with these 'gas gauge' bindings. In your private traps at Hitachi/Koki, did you have this many bindings for the 'job-progress'? One other comment - after I sent this out the other day, I realized that 'job-basic' (state, config, etc.) and 'job-completed' can and should have rows in the job event table, but 'job-progress' should NOT have a row in the job event table (because of information explosion with page-by-page 'job-progress' rows). Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Thursday, June 01, 2000 11:16 AM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Ira, Its getting hard to keep up with your changes;-) The smaller content for both jmDeviceEventV2Event and jmJobEventV2Event seem to be reasonable. This is most likely all anyone would want for these traps. However, the jmJobProgressV2Event should contain sufficient information to allow the client application to maintain a set of "gas gauge" style displays. This makes this trap fairly heavy, but without this information the trap is not very useful. I eliminated jmJobState and jmJobEventJobStateReasons since a state change seldom happens during printing, at least as compared to progress, and a separate jmJobEventV2Event trap can be sent to report state changes. I don't believe that this trap content will exceed the 485 byte limit, but I did not do a byte count. Here is my revised proposal: jmJobProgressV2Event NOTIFICATION-TYPE OBJECTS { jmJobEventNotifyEvent, -- new object jmJobKOctetsPerCopyRequested, -- from Job MIB jmJobKOctetsProcessed, -- from Job MIB jmJobImpressionsPerCopyRequested, -- from Job MIB jmJobImpressionsCompleted, -- from Job MIB jmJobEventCopiesRequested, -- new object jmJobEventJobCollationType, -- new object jmJobEventMediaSheetsCompleted, -- new object jmJobEventSheetCompletedCopyNumber, -- new object jmJobEventSheetCompletedDocNumber -- new object } Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi folks, Tuesday (18 April 2000) > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > I propose to write this all up in a revised Internet-Draft in the near > future. > > Comments? > > Cheers, > - Ira McDonald, consulting architect at Xerox and Sharp > High North Inc > > ------------------------------------------------------------------------ > > Changes from previous proposal of 22 May 2000: > > 1) Revised INDEX clauses of tables to always use single-level indices. > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > because it's redundant with a value of '...DeviceStateReasons'. > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > from event tables and traps because they're incompatible with SNMP > libraries (which assemble trap bindings and then send the IDENTICAL > trap to all registered destinations) - in IPP, each destination MAY > request a DIFFERENT value of '...NotifyLanguage', etc. > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > 6) Deleted '...DateTime' from traps and event tables because it's > redundant with '...UpTime' objects. > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > think this is the agreement for all IPP notification methods). > > ------------------------------------------------------------------------ > > -- Device Table - devices which support job services > -- > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > -- INDEX { jmDeviceIndex } > jmDeviceEntry ::= SEQUENCE { > jmDeviceIndex Integer32 (1..2147483647), > jmDeviceName SnmpAdminString, > jmDeviceURI SnmpAdminString, > jmDeviceServiceTypes JmJobServiceTypesTC, > jmDeviceState JmDeviceStateTC, > jmDeviceStateReasons SnmpAdminString > } > > -- Device Event Table > -- > -- Rows are persistent until system reboot or table overflow > > -- INDEX { jmDeviceEventIndex } > jmDeviceEventEntry ::= SEQUENCE { > jmDeviceEventIndex Integer32 (1..2147483647), > jmDeviceEventNotifyEvent SnmpAdminString, > jmDeviceEventNotifyTime TimeTicks, > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > jmDeviceEventDeviceState JmDeviceStateTC, > jmDeviceEventDeviceStateReasons SnmpAdminString > } > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For all device events > > jmDeviceEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmDeviceEventNotifyEvent, > jmDeviceState, > jmDeviceStateReasons > } > > -- Job Event Table - persistent only for lifetime of job > -- > -- Rows are persistent ONLY for lifetime of job > > -- INDEX { jmJobEventIndex } > jmJobEventEntry ::= SEQUENCE { > jmJobEventIndex Integer32 (1..2147483647), > jmJobEventNotifyEvent SnmpAdminString, > jmJobEventNotifyTime TimeTicks, > jmJobEventJobSetIndex Integer32 (1..32767), > jmJobEventJobIndex Integer32 (1..2147483647), > jmJobEventJobState JmJobStateTC, > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > } > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For basic job events > > jmJobEventV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons > } > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > -- > -- For both job-progress and job-completed events > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, > jmJobState, > jmJobEventJobStateReasons, > jmJobEventKOctetsProcessed, > jmJobEventImpressionsCompleted > } > > ------------------------------------------------------------------------ From rbergma at hitachi-hkis.com Fri Jun 2 17:10:43 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:18 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 References: <1115A7CFAC25D311BC4000508B2CA5375ECD79@MAILSRVNT02> Message-ID: <393822D3.8714840E@hitachi-hkis.com> Ira, A while back I would have agreed with you regarding the "static" information. However, experience has shown that this information is not always available at the begining of the job. It is much more efficient to provide this information in the trap than have the client continually poll until it is available. Hitachi printers don't currently include all the information proposed, since our collation type is fixed. Also, I do not see much use in tracking octets processed. (But I lost that argument years ago during the Job MIB development.) The total objects in the progress trap is only 10, which seems to be faitly modest compared to some of the earlier trap proposals. The advantage of one progress trap definition is interoperability. This will allow a job monitor application to be developed that will support any printer that supports the trap, I have always tried to favor light-weight protocols, but in this case including all the important information in a single trap is the most efficient. Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi Ron, > > Thanks very much for your quick feedback. > > I see your point about a detailed trap for job-progress. > > But in recent IPP discussions, the agreement was that > REQUIRED content for IPP events would be very small > (this latest sketch of mine is aligned with IPP here) > and servers (IPP Printers) or clients could OPTIONALLY > add additional bindings. > > Any SNMP trap may have additional bindings, by SNMP rules. > > What you're requesting is that ALL job-progress traps > have 'gas gauge' bindings - but this places a higher > conformance requirement on Job Mon MIB implementations > to support these optional job attributes for this 'gas > gauge'. > > SMI standard usage is never to bind static info (names, > submitted job size, etc.) into traps, but to let the > client separately read and cache such static info. > This is part of the problem with these 'gas gauge' > bindings. > > In your private traps at Hitachi/Koki, did you have this > many bindings for the 'job-progress'? > > One other comment - after I sent this out the other day, > I realized that 'job-basic' (state, config, etc.) and > 'job-completed' can and should have rows in the > job event table, but 'job-progress' should NOT have a > row in the job event table (because of information > explosion with page-by-page 'job-progress' rows). > > Cheers, > - Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Thursday, June 01, 2000 11:16 AM > To: McDonald, Ira > Cc: 'ipp@pwg.org'; 'jmp@pwg.org' > Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May > 2000 > > Ira, > > Its getting hard to keep up with your changes;-) > > The smaller content for both jmDeviceEventV2Event > and jmJobEventV2Event seem to be reasonable. This > is most likely all anyone would want for these > traps. However, the jmJobProgressV2Event should > contain sufficient information to allow the client > application to maintain a set of "gas gauge" style > displays. This makes this trap fairly heavy, but > without this information the trap is not very useful. > > I eliminated jmJobState and jmJobEventJobStateReasons > since a state change seldom happens during printing, > at least as compared to progress, and a separate > jmJobEventV2Event trap can be sent to report state > changes. > > I don't believe that this trap content will exceed > the 485 byte limit, but I did not do a byte count. > > Here is my revised proposal: > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, -- new object > jmJobKOctetsPerCopyRequested, -- from Job MIB > jmJobKOctetsProcessed, -- from Job MIB > jmJobImpressionsPerCopyRequested, -- from Job MIB > jmJobImpressionsCompleted, -- from Job MIB > jmJobEventCopiesRequested, -- new object > jmJobEventJobCollationType, -- new object > jmJobEventMediaSheetsCompleted, -- new object > jmJobEventSheetCompletedCopyNumber, -- new object > jmJobEventSheetCompletedDocNumber -- new object > } > > Ron Bergman > Hitachi Koki Imaging Solutions > > "McDonald, Ira" wrote: > > > Hi folks, Tuesday (18 April 2000) > > > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > I propose to write this all up in a revised Internet-Draft in the near > > future. > > > > Comments? > > > > Cheers, > > - Ira McDonald, consulting architect at Xerox and Sharp > > High North Inc > > > > ------------------------------------------------------------------------ > > > > Changes from previous proposal of 22 May 2000: > > > > 1) Revised INDEX clauses of tables to always use single-level indices. > > > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > > because it's redundant with a value of '...DeviceStateReasons'. > > > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > > from event tables and traps because they're incompatible with SNMP > > libraries (which assemble trap bindings and then send the IDENTICAL > > trap to all registered destinations) - in IPP, each destination MAY > > request a DIFFERENT value of '...NotifyLanguage', etc. > > > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > > > 6) Deleted '...DateTime' from traps and event tables because it's > > redundant with '...UpTime' objects. > > > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > > think this is the agreement for all IPP notification methods). > > > > ------------------------------------------------------------------------ > > > > -- Device Table - devices which support job services > > -- > > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > > > -- INDEX { jmDeviceIndex } > > jmDeviceEntry ::= SEQUENCE { > > jmDeviceIndex Integer32 (1..2147483647), > > jmDeviceName SnmpAdminString, > > jmDeviceURI SnmpAdminString, > > jmDeviceServiceTypes JmJobServiceTypesTC, > > jmDeviceState JmDeviceStateTC, > > jmDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Table > > -- > > -- Rows are persistent until system reboot or table overflow > > > > -- INDEX { jmDeviceEventIndex } > > jmDeviceEventEntry ::= SEQUENCE { > > jmDeviceEventIndex Integer32 (1..2147483647), > > jmDeviceEventNotifyEvent SnmpAdminString, > > jmDeviceEventNotifyTime TimeTicks, > > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > > jmDeviceEventDeviceState JmDeviceStateTC, > > jmDeviceEventDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For all device events > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > -- Job Event Table - persistent only for lifetime of job > > -- > > -- Rows are persistent ONLY for lifetime of job > > > > -- INDEX { jmJobEventIndex } > > jmJobEventEntry ::= SEQUENCE { > > jmJobEventIndex Integer32 (1..2147483647), > > jmJobEventNotifyEvent SnmpAdminString, > > jmJobEventNotifyTime TimeTicks, > > jmJobEventJobSetIndex Integer32 (1..32767), > > jmJobEventJobIndex Integer32 (1..2147483647), > > jmJobEventJobState JmJobStateTC, > > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > > } > > > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For basic job events > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For both job-progress and job-completed events > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Jun 5 11:28:54 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD7D@MAILSRVNT02> Hi Ron, I agree - Interoperability is our goal. I agree we should have the separate Job Progress trap with all ten bindings - but NOT record Job Progress traps in the alert table 'jmJobEventTable'. The Job Progress bindings (except the few from 'jmJobTable') should have leaf objects defined to hold their bindings. All other job events should be recorded in the alert table 'jmJobEventTable', except that Job Completed won't redundantly record the progress counters there (just bind them from the base objects in 'jmJobTable' into the trap). All device events should be recorded in the device table 'jmDeviceEventTable'. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] Sent: Friday, June 02, 2000 2:11 PM To: McDonald, Ira Cc: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May 2000 Ira, A while back I would have agreed with you regarding the "static" information. However, experience has shown that this information is not always available at the begining of the job. It is much more efficient to provide this information in the trap than have the client continually poll until it is available. Hitachi printers don't currently include all the information proposed, since our collation type is fixed. Also, I do not see much use in tracking octets processed. (But I lost that argument years ago during the Job MIB development.) The total objects in the progress trap is only 10, which seems to be faitly modest compared to some of the earlier trap proposals. The advantage of one progress trap definition is interoperability. This will allow a job monitor application to be developed that will support any printer that supports the trap, I have always tried to favor light-weight protocols, but in this case including all the important information in a single trap is the most efficient. Ron Bergman Hitachi Koki Imaging Solutions "McDonald, Ira" wrote: > Hi Ron, > > Thanks very much for your quick feedback. > > I see your point about a detailed trap for job-progress. > > But in recent IPP discussions, the agreement was that > REQUIRED content for IPP events would be very small > (this latest sketch of mine is aligned with IPP here) > and servers (IPP Printers) or clients could OPTIONALLY > add additional bindings. > > Any SNMP trap may have additional bindings, by SNMP rules. > > What you're requesting is that ALL job-progress traps > have 'gas gauge' bindings - but this places a higher > conformance requirement on Job Mon MIB implementations > to support these optional job attributes for this 'gas > gauge'. > > SMI standard usage is never to bind static info (names, > submitted job size, etc.) into traps, but to let the > client separately read and cache such static info. > This is part of the problem with these 'gas gauge' > bindings. > > In your private traps at Hitachi/Koki, did you have this > many bindings for the 'job-progress'? > > One other comment - after I sent this out the other day, > I realized that 'job-basic' (state, config, etc.) and > 'job-completed' can and should have rows in the > job event table, but 'job-progress' should NOT have a > row in the job event table (because of information > explosion with page-by-page 'job-progress' rows). > > Cheers, > - Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > -----Original Message----- > From: Ron Bergman [mailto:rbergma@hitachi-hkis.com] > Sent: Thursday, June 01, 2000 11:16 AM > To: McDonald, Ira > Cc: 'ipp@pwg.org'; 'jmp@pwg.org' > Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May > 2000 > > Ira, > > Its getting hard to keep up with your changes;-) > > The smaller content for both jmDeviceEventV2Event > and jmJobEventV2Event seem to be reasonable. This > is most likely all anyone would want for these > traps. However, the jmJobProgressV2Event should > contain sufficient information to allow the client > application to maintain a set of "gas gauge" style > displays. This makes this trap fairly heavy, but > without this information the trap is not very useful. > > I eliminated jmJobState and jmJobEventJobStateReasons > since a state change seldom happens during printing, > at least as compared to progress, and a separate > jmJobEventV2Event trap can be sent to report state > changes. > > I don't believe that this trap content will exceed > the 485 byte limit, but I did not do a byte count. > > Here is my revised proposal: > > jmJobProgressV2Event NOTIFICATION-TYPE > OBJECTS { > jmJobEventNotifyEvent, -- new object > jmJobKOctetsPerCopyRequested, -- from Job MIB > jmJobKOctetsProcessed, -- from Job MIB > jmJobImpressionsPerCopyRequested, -- from Job MIB > jmJobImpressionsCompleted, -- from Job MIB > jmJobEventCopiesRequested, -- new object > jmJobEventJobCollationType, -- new object > jmJobEventMediaSheetsCompleted, -- new object > jmJobEventSheetCompletedCopyNumber, -- new object > jmJobEventSheetCompletedDocNumber -- new object > } > > Ron Bergman > Hitachi Koki Imaging Solutions > > "McDonald, Ira" wrote: > > > Hi folks, Tuesday (18 April 2000) > > > > Very small Job Monitoring MIB traps (for IPP Notifications over SNMP). > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > I propose to write this all up in a revised Internet-Draft in the near > > future. > > > > Comments? > > > > Cheers, > > - Ira McDonald, consulting architect at Xerox and Sharp > > High North Inc > > > > ------------------------------------------------------------------------ > > > > Changes from previous proposal of 22 May 2000: > > > > 1) Revised INDEX clauses of tables to always use single-level indices. > > > > 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and > > 'jmJobEventJobIndex' pointer objects to event tables but not traps. > > > > 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap > > because it's redundant with a value of '...DeviceStateReasons'. > > > > 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText' > > from event tables and traps because they're incompatible with SNMP > > libraries (which assemble trap bindings and then send the IDENTICAL > > trap to all registered destinations) - in IPP, each destination MAY > > request a DIFFERENT value of '...NotifyLanguage', etc. > > > > 5) Deleted '...UpTime' from traps because 'sysUpTime' is included > > in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents. > > > > 6) Deleted '...DateTime' from traps and event tables because it's > > redundant with '...UpTime' objects. > > > > 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's > > redundant with attributes in 'jmJobTable' and 'jmAttributeTable'. > > > > 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I > > think this is the agreement for all IPP notification methods). > > > > ------------------------------------------------------------------------ > > > > -- Device Table - devices which support job services > > -- > > -- Systems which also implement IETF Host Resources MIB (RFC 2790) > > -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device > > > > -- INDEX { jmDeviceIndex } > > jmDeviceEntry ::= SEQUENCE { > > jmDeviceIndex Integer32 (1..2147483647), > > jmDeviceName SnmpAdminString, > > jmDeviceURI SnmpAdminString, > > jmDeviceServiceTypes JmJobServiceTypesTC, > > jmDeviceState JmDeviceStateTC, > > jmDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Table > > -- > > -- Rows are persistent until system reboot or table overflow > > > > -- INDEX { jmDeviceEventIndex } > > jmDeviceEventEntry ::= SEQUENCE { > > jmDeviceEventIndex Integer32 (1..2147483647), > > jmDeviceEventNotifyEvent SnmpAdminString, > > jmDeviceEventNotifyTime TimeTicks, > > jmDeviceEventDeviceIndex Integer32 (1..2147483647), > > jmDeviceEventDeviceState JmDeviceStateTC, > > jmDeviceEventDeviceStateReasons SnmpAdminString > > } > > > > -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For all device events > > > > jmDeviceEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmDeviceEventNotifyEvent, > > jmDeviceState, > > jmDeviceStateReasons > > } > > > > -- Job Event Table - persistent only for lifetime of job > > -- > > -- Rows are persistent ONLY for lifetime of job > > > > -- INDEX { jmJobEventIndex } > > jmJobEventEntry ::= SEQUENCE { > > jmJobEventIndex Integer32 (1..2147483647), > > jmJobEventNotifyEvent SnmpAdminString, > > jmJobEventNotifyTime TimeTicks, > > jmJobEventJobSetIndex Integer32 (1..32767), > > jmJobEventJobIndex Integer32 (1..2147483647), > > jmJobEventJobState JmJobStateTC, > > jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)), > > jmJobEventKOctetsProcessed Integer32 (-2..2147483647), > > jmJobEventImpressionsCompleted Integer32 (-2..2147483647) > > } > > > > -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For basic job events > > > > jmJobEventV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons > > } > > > > -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform > > -- > > -- For both job-progress and job-completed events > > > > jmJobProgressV2Event NOTIFICATION-TYPE > > OBJECTS { > > jmJobEventNotifyEvent, > > jmJobState, > > jmJobEventJobStateReasons, > > jmJobEventKOctetsProcessed, > > jmJobEventImpressionsCompleted > > } > > > > ------------------------------------------------------------------------ From imcdonald at sharplabs.com Fri Jul 7 10:30:00 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> Revised I-D draft-ietf-ipp-not-over-snmp-03.txt Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECDEB@MAILSRVNT02> Copies: IPP WG JMP WG Hi folks, Sunday (19 March 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: draft-ietf-ipp-not-over-snmp-03.txt - flat text IETF style draft-ietf-ipp-not-over-snmp-03.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000706.mib - flat text of ASN.1 (Job Mon MIB w/ traps) jmp-trap-000706.pdf - line numbered PDF of text Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Thursday (6 July 2000) IPP: Please place this document in the Internet-Drafts repository as: (July 2000) It replaces the previous: (March 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 6 July 2000 1) Added 'SnmpAdminString' to IMPORTS clause for new objects. 2) Corrected OID in MODULE-IDENTITY to use forward reference to definition of 'pwg' from 'enterprises' and 'mibs' from 'pwg'. 3) Added 'JmServiceStateTC' textual convention. 4) Added 'jmMirrorAttr' and 'jmSystem' object identifiers reserved for future extensions. 5) Major rewrite, per email discussion on IETF IPP WG list, to specify four new small (traditional) SNMP traps for: 'jmServiceBasicV2Event' (generalized from IPP Printer event), 'jmJobBasicV2Event' (corresponds IPP Job event), 'jmJobCompletedV2Event' (corresponds IPP Job completed event), 'jmJobProgressV2Event' (corresponds IPP Job progress event). 6) Major rewrite, per email discussion on IETF IPP WG list, to specify four new SNMP object groups: 'jmServiceTable' (name, URI, state, etc. - from IPP Printer), 'jmServiceEventTable' (records IPP Printer events for polling), 'jmJobEventTable' (records IPP Job events for polling), 'jmJobProgressGroup' (leaf objects for IPP Job progress event). 7) Revised section 3.1 'SNMP Mapping for IPP Printer Events' and section 3.2 'SNMP Mapping for IPP Job Events', to agree with above. 8) Deleted obsolete section 3.3 'Rules for Encoding Notifications', as event bindings now always fit over all SNMP transport protocols. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed Jul 19 11:08:09 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RESEND: Posted new I-D - Printer MIB v2 - 14 July 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE1A@MAILSRVNT02> This got lost in the PWG reflector last Friday, - Ira -----Original Message----- From: McDonald, Ira Sent: Friday, July 14, 2000 11:42 AM To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'rbergma@hitachi-hkis.com'; 'harryl@us.ibm.com'; 'ggocek@crt.xerox.com'; McDonald, Ira Subject: Posted new I-D - Printer MIB v2 - 14 July 2000 Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Friday (14 July 2000) As most of you know, Harry Lewis (IBM) has performed a great deal of work finishing up the edits to the Printer MIB v2. Since Harry is away from his office until 25 July, Gary Gocek (Xerox) has finished up minor changes necessary to generate the IETF style flat text. This version of the MIB compiles cleanly under Mosy, SMICng, and Epilogue. I've just sent the (hopefully) final version of 'IETF Printer MIB v2' to the Internet-Drafts editor. This version is for Printer MIB WG 'last call' and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-info-05.txt - IETF style flat text draft-ietf-printmib-info-05.pdf - line numbered PDF of '.txt' draft-ietf-printmib-info-05.doc - MS Word source draft-ietf-printmib-info-05.mib - extracted ASN.1 from '.txt' My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Friday (14 July 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (July 2000) It replaces the previous draft: (January 1999) Note: Edits to Printer MIB v2 were delayed awaiting the Host Resources MIB v2 (RFC 2790, March 2000). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790), as well as the Interfaces Group of MIB-II (RFC 1213). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Randy Turner (2Wire, co-editor) Gary Gocek (Xerox, contributing editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC2790 - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790) - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual-conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4) - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections - Updated references - Added Appendix E - Overall Printer Status Table - Updated participant and contact information ------------------------------------------------------------------------ From hof at oce.nl Thu Aug 3 09:58:41 2000 From: hof at oce.nl (Harry Offermans) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <39897A91.53F893A9@oce.nl> The status of teh Job monitoring MIB is informational and the location in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I have is, if the Job Monitoring MIB is, will be or is intended to be used for job managament applications. The usage I think of is in the same way as the Printer MIB or MIB II. Or is the purpose to have a job description that can be used in IPP. ?? -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Aug 3 11:14:25 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> Message-ID: <39898C51.6B9CF030@hitachi-hkis.com> Harry, The Job Monitoring MIB is intended for use in job management applications. It is currently supported by several printer vendors. It is an Informational RFC due to a reduction in scope of the IETF. Due to an extremely large increase in their activity they will no longer publish SNMP MIBs that are not directly related to network management. The MIB also has provided a good model for use in IPP. Ron Bergman Chairman, Job Monitoring MIB Working Group Hitachi Koki Imaging Solutions Harry Offermans wrote: > The status of teh Job monitoring MIB is informational and the location > in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I > have is, if the Job Monitoring MIB is, will be or is intended to be > used for job managament applications. The usage I think of is in the > same way as the Printer MIB or MIB II. Or is the purpose to have a job > description that can be used in IPP. ?? > > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 > Harry Offermans OCE Research & Development > mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 > Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands > ------------------------------------------------------------------ > This note does not necessarily represent the position of Oce > Technologies B.V. Therefore no liability or responsibility for > whatever will be accepted. > ------------------------------------------------------------------ From imcdonald at sharplabs.com Thu Aug 3 11:27:19 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE3C@mailsrvnt02.enet.sharplabs.com> Hi Harry, The Job Monitoring MIB is a PWG Standard (and is published an an IETF Informational RFC for the convenience of the network management community). The Job object in IPP (developed AFTER the Job Mon MIB) was intentionally technically aligned with the Job attributes in the Job Mon MIB. The Job Mon MIB is intended to be used to instrument jobs from ANY print channel (IPP, LPR, etc.) in ANY print format (PostScript, etc.). It is a companion to the Printer MIB. The work-in-progress (mine) to add Service (Printer) and Job SNMP traps to the Job Mon MIB was inspired by the notifications work item in the IETF IPP WG (and is an OPTIONAL mapping for IPP notifications). Because of further changes in the IPP notifications base spec, I'm revising the Job traps spec once more. Should be posted (to this list) within the next few weeks. I hope this helps. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Harry Offermans [mailto:hof@oce.nl] Sent: Thursday, August 03, 2000 6:59 AM To: jmp@pwg.org Subject: JMP> status and usage of Job monitoring MIB The status of teh Job monitoring MIB is informational and the location in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I have is, if the Job Monitoring MIB is, will be or is intended to be used for job managament applications. The usage I think of is in the same way as the Printer MIB or MIB II. Or is the purpose to have a job description that can be used in IPP. ?? -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From rbergma at hitachi-hkis.com Thu Aug 3 11:46:26 2000 From: rbergma at hitachi-hkis.com (Ron Bergman) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> <39898C51.6B9CF030@hitachi-hkis.com> Message-ID: <398993D2.DF84BF28@hitachi-hkis.com> Harry, What I intended to say was "...they will no longer publish SNMP MIBs on the standards track that are not directly related to..." ^^^^^^^^^^^^^^^^^^^^^^ Ron Bergman Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > > Harry Offermans wrote: > > > The status of teh Job monitoring MIB is informational and the location > > in the MIB tree is private/enterprises/oid_pwg/oi_mibs. The question I > > have is, if the Job Monitoring MIB is, will be or is intended to be > > used for job managament applications. The usage I think of is in the > > same way as the Printer MIB or MIB II. Or is the purpose to have a job > > description that can be used in IPP. ?? > > > > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 > > Harry Offermans OCE Research & Development > > mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 > > Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands > > ------------------------------------------------------------------ > > This note does not necessarily represent the position of Oce > > Technologies B.V. Therefore no liability or responsibility for > > whatever will be accepted. > > ------------------------------------------------------------------ From hof at oce.nl Fri Aug 4 11:04:07 2000 From: hof at oce.nl (Harry Offermans) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB References: <39897A91.53F893A9@oce.nl> <39898C51.6B9CF030@hitachi-hkis.com> Message-ID: <398ADB67.9B47F0E3@oce.nl> Ron, Ira Thank you for the background information. About the printer vendors who support the Job Monitoring Mib. Is a list available containing vendors and applications they provide? Are these applications proprietary or can they cooperate with devices from other vendors who support the Job Monitoring Mib? Harry Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From imcdonald at sharplabs.com Mon Aug 7 13:20:30 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> status and usage of Job monitoring MIB Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE42@mailsrvnt02.enet.sharplabs.com> Hi Harry, I'm not aware of any list of Job Monitoring MIB implementations. In general, any properly implemented client will interwork with any Job Monitoring MIB implementation in a network printer or spooler. There has never been a public interoperability test of different vendors' implementations of the Job Monitoring MIB - there should be. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Harry Offermans [mailto:hof@oce.nl] Sent: Friday, August 04, 2000 8:04 AM To: Ron Bergman; jmp@pwg.org; imcdonald@sharplabs.com Subject: Re: JMP> status and usage of Job monitoring MIB Ron, Ira Thank you for the background information. About the printer vendors who support the Job Monitoring Mib. Is a list available containing vendors and applications they provide? Are these applications proprietary or can they cooperate with devices from other vendors who support the Job Monitoring Mib? Harry Ron Bergman wrote: > Harry, > > The Job Monitoring MIB is intended for use in job management > applications. It is currently supported by several printer vendors. > It is an Informational RFC due to a reduction in scope of the IETF. > Due to an extremely large increase in their activity they will no > longer publish SNMP MIBs that are not directly related to > network management. > > The MIB also has provided a good model for use in IPP. > > Ron Bergman > Chairman, Job Monitoring MIB Working Group > Hitachi Koki Imaging Solutions > -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 Harry Offermans OCE Research & Development mailto: hof@oce.nl Tel: +31 77 359 3198 Fax: +31 77 359 5473 Address: OCE Technologies/PO BOX 101/5900 MA Venlo/The Netherlands ------------------------------------------------------------------ This note does not necessarily represent the position of Oce Technologies B.V. Therefore no liability or responsibility for whatever will be accepted. ------------------------------------------------------------------ From imcdonald at sharplabs.com Tue Aug 8 19:08:26 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE49@mailsrvnt02.enet.sharplabs.com> Copies: IPP WG JMP WG Hi folks, Tuesday (8 August 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the file: draft-ietf-ipp-not-over-snmp-04.txt - flat text IETF style When Tom Hastings gets a chance, we'll also post PDF in the file: draft-ietf-ipp-not-over-snmp-04.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000808.mib - flat text of ASN.1 (Job Mon MIB w/ traps) When Tom Hastings gets a chance, we'll also post PDF in the file: jmp-trap-000808.pdf - line numbered PDF of text Note: This version is intended for IETF IPP WG 'last call'. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Tuesday (8 August 2000) IPP: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous: (July 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 8 August 2000 1) Deleted 'printer-full', 'printer-no-longer-full', 'printer-almost-idle', and 'printer-not-almost-idle' event types, and added 'printer-stopped' in 'jmServiceEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 2) Deleted 'job-purged' event type and added 'job-stopped' in 'jmJobEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 3) Renamed 'jmServiceEventNotifyEvent' object to 'jmServiceEventNotifyTriggerEvent' (most specific event) and added 'jmServiceEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 4) Renamed 'jmJobEventNotifyEvent' object to 'jmJobEventNotifyTriggerEvent' (most specific event) and added 'jmJobEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 5) Renamed all NOTIFICATION-TYPEs (traps) for clarity, changing 'jmServiceBasicV2Event' to 'jmServiceEventV2Notify', 'jmJobBasicV2Event' to 'jmJobEventV2Notify', 'jmJobCompletedV2Event' to 'jmJobCompletedV2Notify', and 'jmJobProgressV2Event' to 'jmJobProgressV2Notify'. ------------------------------------------------------------------------ From hastings at cp10.es.xerox.com Wed Aug 9 09:57:56 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: IPP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 [.pd f and .doc posted] Message-ID: <918C79AB552BD211A2BD00805F15CE85039A9ED7@x-crt-es-ms1.cp10.es.xerox.com> I've posted the line numbered .pdf and .doc files in: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-04.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over-snmp-04.doc Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, August 08, 2000 16:08 To: 'ipp@pwg.org'; 'jmp@pwg.org' Subject: IPP> draft-ietf-ipp-not-over-snmp-04.txt - 8 August 2000 Copies: IPP WG JMP WG Hi folks, Tuesday (8 August 2000) I've just sent a new version of 'IPP Notifications over SNMP' to to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the file: draft-ietf-ipp-not-over-snmp-04.txt - flat text IETF style When Tom Hastings gets a chance, we'll also post PDF in the file: draft-ietf-ipp-not-over-snmp-04.pdf - line numbered PDF of text I integrated the new ASN.1 proposed in this document into the original Job Monitoring MIB (RFC 2707) and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/' in the files: jmp-trap-000808.mib - flat text of ASN.1 (Job Mon MIB w/ traps) When Tom Hastings gets a chance, we'll also post PDF in the file: jmp-trap-000808.pdf - line numbered PDF of text Note: This version is intended for IETF IPP WG 'last call'. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Tom Hastings" "Ira McDonald" I-D Editor, Tuesday (8 August 2000) IPP: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous: (July 2000) Thanks very much, - Ira McDonald (IPP WG member) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ CHANGE LOG - 8 August 2000 1) Deleted 'printer-full', 'printer-no-longer-full', 'printer-almost-idle', and 'printer-not-almost-idle' event types, and added 'printer-stopped' in 'jmServiceEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 2) Deleted 'job-purged' event type and added 'job-stopped' in 'jmJobEventNotifyTriggerEvent', for alignment with revised [IPP-NOT]; 3) Renamed 'jmServiceEventNotifyEvent' object to 'jmServiceEventNotifyTriggerEvent' (most specific event) and added 'jmServiceEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 4) Renamed 'jmJobEventNotifyEvent' object to 'jmJobEventNotifyTriggerEvent' (most specific event) and added 'jmJobEventNotifyGroupEvent' (most general event), for higher fidelity mapping to IPP 'notify-subscribed-event'; 5) Renamed all NOTIFICATION-TYPEs (traps) for clarity, changing 'jmServiceBasicV2Event' to 'jmServiceEventV2Notify', 'jmJobBasicV2Event' to 'jmJobEventV2Notify', 'jmJobCompletedV2Event' to 'jmJobCompletedV2Notify', and 'jmJobProgressV2Event' to 'jmJobProgressV2Notify'. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Wed Aug 9 23:31:59 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE4F@mailsrvnt02.enet.sharplabs.com> Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Wednesday (9 August 2000) I've just sent the final version of 'IETF Printer MIB v2' with all edits resulting from the Printer MIB WG 'last call' to the Internet-Drafts editor. This version is for submission to the IESG for IETF 'last call' (normally four weeks for revisions to existing RFCs) and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-mib-info-06.txt - IETF style flat text draft-ietf-printmib-mib-info-06.pdf - line numbered PDF of '.txt' draft-ietf-printmib-mib-info-06.doc - MS Word source draft-ietf-printmib-mib-info-06.mib - extracted ASN.1 from '.txt' NOTE - The filename on the title page of the '.doc' (source) and '.pdf' versions is still incorrect (missing the '-mib' infix). I hand-edited the '.txt' and fixed the filename on the title page, so that I could post these files tonight. My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Wednesday (9 August 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous draft: (July 2000) Note: The '-05' version was originally forwarded with the (incorrect) name 'draft-ietf-printmib-info-05.txt'. Corrected by the I-D Editor (thank you). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790 [28]), as well as the Interfaces Group of MIB-II (RFC 1213 [14]). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Gary Gocek (Xerox, co-editor) Randy Turner (2Wire, co-editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC 1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process. - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC 2790. - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790). - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC 2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. - Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual- conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types. - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events. - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4). - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to reflect the new syntax. - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections. - Updated references. - Added Appendix E - Overall Printer Status Table. - Updated participant and contact information. ------------------------------------------------------------------------ From imcdonald at sharplabs.com Thu Aug 10 21:34:04 2000 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:00:18 2009 Subject: JMP> RE: PMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE57@mailsrvnt02.enet.sharplabs.com> Hi folks, Gary Gocek fixed the document title in the '.doc' and '.pdf' versions and I've just stored the corrected ones to the PWG FTP server (same path and filenames as yesterday - see note below). Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, August 09, 2000 8:32 PM To: 'pmp@pwg.org'; 'jmp@pwg.org' Cc: 'rbergma@hitachi-hkis.com'; 'harryl@us.ibm.com'; 'ggocek@crt.xerox.com'; McDonald, Ira; 'imcdonal@sdsp.mc.xerox.com' Subject: PMP> draft-ietf-printmib-mib-info-06.txt - 9 August 2000 Copies: Printer MIB WG Job Mon MIB WG "Ron Bergman" "Harry Lewis" "Gary Gocek" "Ira McDonald" Hi folks, Wednesday (9 August 2000) I've just sent the final version of 'IETF Printer MIB v2' with all edits resulting from the Printer MIB WG 'last call' to the Internet-Drafts editor. This version is for submission to the IESG for IETF 'last call' (normally four weeks for revisions to existing RFCs) and subsequent publication as a Proposed Standard RFC - since new objects are defined beyond RFC 1759, this MIB must start over on the Internet 'standards track'. I posted a copy on the PWG anonymous FTP server in the directory 'ftp://ftp.pwg.org/pub/pwg/pmp/drafts/' in the files: draft-ietf-printmib-mib-info-06.txt - IETF style flat text draft-ietf-printmib-mib-info-06.pdf - line numbered PDF of '.txt' draft-ietf-printmib-mib-info-06.doc - MS Word source draft-ietf-printmib-mib-info-06.mib - extracted ASN.1 from '.txt' NOTE - The filename on the title page of the '.doc' (source) and '.pdf' versions is still incorrect (missing the '-mib' infix). I hand-edited the '.txt' and fixed the filename on the title page, so that I could post these files tonight. My note to the I-D editor and the change log from this document follow. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ Copies: "Internet Drafts Editor" "Ron Bergman" "Harry Lewis" "Randy Turner" "Gary Gocek" "Ira McDonald" I-D Editor, Wednesday (9 August 2000) Printer MIB: Please place this document in the Internet-Drafts repository as: (August 2000) It replaces the previous draft: (July 2000) Note: The '-05' version was originally forwarded with the (incorrect) name 'draft-ietf-printmib-info-05.txt'. Corrected by the I-D Editor (thank you). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790 [28]), as well as the Interfaces Group of MIB-II (RFC 1213 [14]). Thanks very much, - Printer MIB v2 Editors Harry Lewis (IBM, co-editor) Gary Gocek (Xerox, co-editor) Randy Turner (2Wire, co-editor) Ira McDonald (High North, contributing editor) ------------------------------------------------------------------------ [Change Log] 4. Differences from Previous Version This draft supercedes and replaces RFC 1759. The following changes are included here. - Minor editorial corrections and changes. - Updated Coded Character Set description and IANA registration process. - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC 2790. - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790). - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC 2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. - Clarfied the international considerations. - Added prtChannelInformation to the Channel Group textual- conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types. - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarify alerts based on unary vs. binary change events. - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4). - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to reflect the new syntax. - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections. - Updated references. - Added Appendix E - Overall Printer Status Table. - Updated participant and contact information. ------------------------------------------------------------------------