From jkm at underscore.com Mon Feb 10 03:30:07 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> What is the next step? Message-ID: I'd like to thank everyone who attended the SENSE session at the PWG meetings last week in San Jose. Based on what you heard at the session (or, if you didn't attend the session but might have read some of the SENSE documents on the PWG server), what would YOU recommend the next step should be? As I stated in the SENSE session, the documentation currently existing on the PWG server (ftp://ftp.pwg.org/pub/pwg/sense) is a bit out of date...but not that much. Most importantly, the primary concepts described in that documentation has remained intact now for close to one year. What would YOU like to see happen with SENSE at this point? If you'd like to see (up-to-date) documentation, then please state exactly what kinds of documentation you would be willing to read in the next 30-45 days such that you would be willing to discuss details at the upcoming Austin, TX, meeting in April? As I mentioned in the session, there have been very few comments posted on the existing SENSE documentation (which has been around for close to one year now), so please understand why I am a bit hesitant to exert effort at this point if no one really has the time (or interest) to pursue this topic. I look forward to your comments, no matter what the tone. ;-) Please post your comments to the SENSE mailing list so that everyone can see your comments. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at vnet.ibm.com Wed Feb 12 15:31:35 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go with SENSE Message-ID: <199702122038.PAA25403@lists.underscore.com> Jay, I think you've done such a good job with SENSE that I'm not sure what there is for a *printer* to do. What would a SENSE implementation like to see in the printer... the STEP protocol? it's a great technology and one that can accomplish a lot, very simply, My only thought, regarding where to go at this point, is perhaps STEP can be expanded to cover job events (job started, job ended, page printed...). What are your thoughts on this? Harry Lewis - IBM Printing Systems From JKMARTIN at us.oracle.com Wed Feb 12 17:32:35 1997 From: JKMARTIN at us.oracle.com (JKMARTIN.US.ORACLE.COM) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go with SENSE In-Reply-To: Where to go with SENSE> Message-ID: <199702122319.PAA03664@mailsun3-fddi.us.oracle.com> --=_ORCL_30541665_0_11919702121620450 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Harry, You know, you're the first person to respond to my "What next?" message on the SENSE mailing list. I really wonder how many people are interested in it...at least right now, anyway. Just so no one misunderstands, I really believe it is NOT in our best interest to push a spec effort when no one is really going to follow thru with it. It's just a waste of my time, as writing such spec language is quite time consuming. As far as SENSE and the printer goes, yes, the easiest (and best, IMHO) thing for a printer to do with SENSE is to embed a simple STEP.1 Publisher that speaks to (at least) one SENSE server. It really should be no big deal. SENSE should be able to address the asynchronous event requirements for the Job Monitoring MIB. At this point, I would suggest that the JMP group define all desirable events...but in an abstract sense (no pun intended), and not around SNMP Traps, etc. I wonder who in the JMP would be willing to start such an effort? SENSE or no SENSE, that effort must be done in the JMP sooner or later, anyway. ...jay --=_ORCL_30541665_0_11919702121620450 Content-Type:message/rfc822 Date: 12 Feb 97 12:31:35 From:"Harry Lewis " To:sense@pwg.org Subject:SENSE> Where to go with SENSE Return-Path: Sender:owner-sense@pwg.org MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Jay, I think you've done such a good job with SENSE that I'm not sure what there is for a *printer* to do. What would a SENSE implementation like to see in the printer... the STEP protocol? it's a great technology and one that can accomplish a lot, very simply, My only thought, regarding where to go at this point, is perhaps STEP can be expanded to cover job events (job started, job ended, page printed...). What are your thoughts on this? Harry Lewis - IBM Printing Systems --=_ORCL_30541665_0_11919702121620450-- From harryl at vnet.ibm.com Wed Feb 12 23:57:41 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Re:Where to go with SENSE Message-ID: <199702130503.AAA29030@lists.underscore.com> Jay wrote, >You know, you're the first person to respond to my "What next?" message >on the SENSE mailing list. I really wonder how many people are interested >in it...at least right now, anyway. Just so no one misunderstands, >I really believe it is NOT in our best interest to push a spec effort >when no one is really going to follow thru with it. It's just a waste of >my time, as writing such spec language is quite time consuming. It's been so hard, lately to keep up with all that's going on with PWG! Plus a REAL job!! We're all in this boat (including YOU!) and I suspect this has more to do with the (quiet) response than lack of interest. Nonetheless, I agree... it's work you can't (and shouldn't) afford to do if there's not a good chance that PWG members will make use of it. >As far as SENSE and the printer goes, yes, the easiest (and best, IMHO) >thing for a printer to do with SENSE is to embed a simple STEP.1 Publisher >that speaks to (at least) one SENSE server. It really should be no big >deal. Let me get this straight. A STEP.1 publisher would not need to implement the SENSE message format. Just the Text Event Protocol itself and this is designed to work with standard networking protocols. Right? Can I ask, how would a STEP.1 publisher communicate with a SENSE server? Could it be via a telnet session? Is there a preferred method? >SENSE should be able to address the asynchronous event requirements for >the Job Monitoring MIB. At this point, I would suggest that the JMP group >define all desirable events...but in an abstract sense (no pun intended), >and not around SNMP Traps, etc. I wonder who in the JMP would be willing >to start such an effort? SENSE or no SENSE, that effort must be done >in the JMP sooner or later, anyway. I would be willing to do this in a couple weeks after a major deadline of mine passes. I'm a bit reluctant, because it seems every time we try to define a practical set of (anything) what should be a few tweaks turns into a free-for-all and, before you know it, we've made an unscalable mountain of a (very useful) mole hill. Sorry, it's late... and I'm feeling rough around the edges. This is not aimed at anyone in particular, in fact the readers are probably thinking I should take a look in the mirror (WHEREs that hrPrtDetectedErrorState 2nd Octet proposal... Harry?). If I were to start with JMP events... it would look like this JobEvent (Job Index; Time stamp) Started Completed (bin x) PageCompleted (page n) CopyCompleted (copy i) Alarm (type) Jam Canceled (which means canceled, aborted, terminated etc) Paused I would stipulate that periodicity on PageCompleted is adjustable via SNMP set or vendor specific (every page, every 3 pages, every 5 seconds no matter what page it catches etc.). I'm sure we could find a few more good ones, but, like your current STEP.1 proposal, a brief list like this could go a long way to facilitating job management. Harry Lewis - IBM Printing Systems From jds at underscore.com Thu Feb 13 11:56:48 1997 From: jds at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Re:Where to go with SENSE In-Reply-To: Re:Where to go with SENSE> Message-ID: <199702130503.AAA29030@lists.underscore.com> > Let me get this straight. A STEP.1 publisher would not need to > implement the SENSE message format. Just the Text Event Protocol > itself and this is designed to work with standard networking > protocols. Right? > > Can I ask, how would a STEP.1 publisher communicate with a SENSE > server? Could it be via a telnet session? Is there a preferred > method? No, STEP.1 describes a protocol data format that is encapsulated in the opaque data field of the SENSE message format. A property in the encapsulating message would describe the data as a STEP.1 event. A STEP.1 Publisher communicates with the SENSE Server using the Common SENSE protocol, where STEP.1 is the format of the opaque data in the event message. See FTP://ftp.pwg.org/pub/pwgsense/msgfmt.ps Recall the Publication/Edition model of SENSE: A Publication is registered to describe the printer; an Edition is registered to represent the STEP.1 event stream. A STEP.1 Publisher then issues events for that Edition. The SENSE Server then distributes these events to interested Subscribers. Initial registration of this Publication and Edition might be handled by a STEP.1 Publisher embedded in the printer, or it might be delegated to external software. If you wanted the printer to work as automagically as possible, the embedded Publisher would handle the registration as needed after determining the appropriate SENSE domain and locating the SENSE Server. Hmm, what we've been calling STEP.1 is called STEP.SingleLine.CC in FTP://ftp.pwg.org/pub/pwg/sense/snsapx.htm#editions /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From jkm at underscore.com Thu Feb 13 13:44:12 1997 From: jkm at underscore.com (jkm@underscore.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> What SENSE technology should be put inside a printer? Message-ID: <199702132019.MAA12510@mailsun3-fddi.us.oracle.com> --=_ORCL_30601081_0_11919702131320290 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" After reading the exchange between Harry Lewis and Jeff Schnitzer, I'm starting to think that there might be a very, VERY cheap way to provide SENSE-able features within (ie, embedded into) a printer. For those present at my SENSE presentation last week, recall my description of Lexmark's simple Intervention Required (IR) mechanism that allows for simple printer condition/status via TCP. Briefly, the IR mechanism is such that a mgmt app can connect to a well-known TCP port on the printer, after which the printer transmits simple lines containing two-digit strings that describe the current state (ie, mostly alert-like conditions). (There's a bit more that goes on here, such as a simple acknowledgement from the mgmt app, but I'll leave that out for now). Now, what we can do with regard to SENSE is to devise a similar simpleton kind of technique, where the printer issues a STEP.1-formatted line of text describing an event condition. Recall that this format is essentially: nnn text... Where "nnn" is a specially encoded decimal digit string describing a combination of (in this order, left-to-right) "support level", "health" and "activity". For example: 342 Tray 1 has been removed (I don't have the STEP.1 condition code table in front of me, so the above numeric condition value may not be correct for this type of alert condition.) The printer's connection management strategy could be the same as Lexmark's IR mechanism where the printer just sits there and handles in-bound connections to some well-known port, etc. How many simultaneous connections would be implementation-specific, just as in any TCP-based service. Would printer vendors be willing to implement this simple method? If so, then I can tell you right now that Underscore's reference implementation of the SENSE Framework can plug-in support for that vendor RIGHT NOW. Comments? (Particularly from printer vendors!) ...jay --=_ORCL_30601081_0_11919702131320290 Content-Type:message/rfc822 Date: 13 Feb 97 08:56:48 From:"Jeff Schnitzer " To:Harry,Lewis, Subject:Re: SENSE> Re:Where to go with SENSE Cc:jkm@inet-user-gw-1.us.oracle.com,sense@pwg.org Return-Path: Sender:jds@us.oracle.com Organization:Underscore, Inc. X-Mailer:Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) References:<199702130503.AAA29030@lists.underscore.com>References:<199702130503.AAA29030@lists.underscore.com> MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" > Let me get this straight. A STEP.1 publisher would not need to > implement the SENSE message format. Just the Text Event Protocol > itself and this is designed to work with standard networking > protocols. Right? > > Can I ask, how would a STEP.1 publisher communicate with a SENSE > server? Could it be via a telnet session? Is there a preferred > method? No, STEP.1 describes a protocol data format that is encapsulated in the opaque data field of the SENSE message format. A property in the encapsulating message would describe the data as a STEP.1 event. A STEP.1 Publisher communicates with the SENSE Server using the Common SENSE protocol, where STEP.1 is the format of the opaque data in the event message. See FTP://ftp.pwg.org/pub/pwgsense/msgfmt.ps Recall the Publication/Edition model of SENSE: A Publication is registered to describe the printer; an Edition is registered to represent the STEP.1 event stream. A STEP.1 Publisher then issues events for that Edition. The SENSE Server then distributes these events to interested Subscribers. Initial registration of this Publication and Edition might be handled by a STEP.1 Publisher embedded in the printer, or it might be delegated to external software. If you wanted the printer to work as automagically as possible, the embedded Publisher would handle the registration as needed after determining the appropriate SENSE domain and locating the SENSE Server. Hmm, what we've been calling STEP.1 is called STEP.SingleLine.CC in FTP://ftp.pwg.org/pub/pwg/sense/snsapx.htm#editions /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- --=_ORCL_30601081_0_11919702131320290-- From harryl at vnet.ibm.com Thu Feb 13 15:31:15 1997 From: harryl at vnet.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE clarifications Message-ID: <199702132036.PAA01905@lists.underscore.com> Jeff, thanks for your previous clarification that the Step.1 protocol rides in the Opaque Data field of the SENSE message. I should have known. It's all very clear following your explanation. One more question. I've heard Jay refer to the UDP nature of SENSE as a salability plus, but where is the acknowledgment scheme specified that makes the SENSE message reliable? Harry Lewis. From JKMARTIN at us.oracle.com Fri Feb 14 01:22:16 1997 From: JKMARTIN at us.oracle.com (JKMARTIN.US.ORACLE.COM) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE clarifications In-Reply-To: SENSE clarifications> Message-ID: <199702140624.WAA27555@mailsun3-fddi.us.oracle.com> --=_ORCL_30656829_0_11919702132325530 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Harry, Whenever the SENSE server sends an event message to a subscriber, the server periodically retransmits the event until the subscriber sends a reply. Of course, there are limits as to the number of retransmits, and the overall TTL (time to live) of the message to limit the resources required by the server. Similarly, a publisher (the agent submitting events to the server on behalf of an "entity", in this case, a printer) uses the same approach in submitting events; the publisher periodically retries until the server acknowledges receipt of the event, with the same types of max-retries and TTL as above. In the manner, we get what we refer to as "reasonable reliability". Comments from anyone? Is this "good enough"? ...jay --=_ORCL_30656829_0_11919702132325530 Content-Type:message/rfc822 Date: 13 Feb 97 12:31:15 From:"Harry Lewis " To:jds@underscore.com,sense@pwg.org Subject:SENSE> SENSE clarifications Return-Path: Sender:owner-sense@pwg.org MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Jeff, thanks for your previous clarification that the Step.1 protocol rides in the Opaque Data field of the SENSE message. I should have known. It's all very clear following your explanation. One more question. I've heard Jay refer to the UDP nature of SENSE as a salability plus, but where is the acknowledgment scheme specified that makes the SENSE message reliable? Harry Lewis. --=_ORCL_30656829_0_11919702132325530-- From jds at underscore.com Wed Apr 2 12:11:54 1997 From: jds at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Majordomo Filtering of PWG Mailing lists Message-ID: <199702140624.WAA27555@mailsun3-fddi.us.oracle.com> Several individuals have recently had mail rejected by the Majordomo mailing list software we are using on the PWG server. I thought I'd take this opportunity to explain what is happenning. In order to eliminate mail storms (like those we experienced when Underscore first set up the PWG server), the Majordomo software looks for suspicious phrases in both the subject line and a more extended list in the first five lines of the message body. I'll detail the forbidden text below. In addition, Majordomo imposes certain other limits to avoid problems with various older mail agents: - Header lines must not exceed 192 bytes. - Header fields must not exceed 1024 bytes. - Message size in excess of 120,000 bytes. The filtered subjects are those that start with: - subscribe - unsubscribe - help - RCPT: - Delivery Confirmation - NON-DELIVERY of - Undeliverable Message - Receipt Confirmation - Failed mail - change <*> address - request <*> addition The phrase are filtered against appearing anywhere in the first five lines of the message body: - delete me - remove me - add me - change <*> address - request <*> addition - subscribe - sub - unsubscribe - unsub - mail11 - undeliverable - transcript of session - original message was received - message could not be delivered - block not createable after - bounce - bounced - not deliver after - returned mail Finally, Majordomo may reject messages if any of the first five lines of the message body begin with: - help - info - lists - which - index - who - get - approve - passwd - newinfo - config - newconfig - writeconfig - mkdigest I hope this helps explain things. If you can't find a way to rephrase a forbidden phrase, you might try "pig-latin"... /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From jkm at underscore.com Mon May 5 13:57:07 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Insights into SENSE in the context of Printer MIB traps Message-ID: <199705051757.NAA19196@uscore.underscore.com> This message was originally posted to the Printer MIB/MIF (PMP) list. ----- Begin Included Message ----- Date: Mon, 5 May 1997 09:28:08 -0400 (EDT) From: JK Martin To: chrisw@iwl.com Subject: PMP> Re: I must be missing something... Cc: pmp@pwg.org, sense@pwg.com Chris, Hope you don't mind my posting your message and my reply to the PMP list. I've also copied the SENSE discussion list, as > I have been in Death Valley for a few days, and out of email contact.... in > reading your response to Gail on a different subject, you mentioned that > your PrintAlert product is intended to monitor network printers. You had > also mentioned that you were doing some sort of testing for a large > customer of all the printers. So, I am wondering if you tried setting up > the IBM, the DataProducts, and the Lexmark printers to send traps to your > PrintAlert software, and what the results were? We know that Tektronix, > Kyocera, and Xerox do not send traps. We know that HP is doing it a > proprietary way. So, did you find interoperability with the remaining > three? Good questions, Chris. The following does not give you the kind of answer you were looking for, but should give you some food for thought in this area. First, to parrot the SNMP designers, "Traps are Bad." However, in our case, the reasons traps are bad are different than that stated by the SNMP designers. We believe SNMP traps are "Bad" because they are ill- defined, and not because they add excessive network traffic. Our PrintAlert product has nothing to do with traps. Why? Because our product must be able to come and go at any time. The lack of standards for trap registration force us to use other means. PrintAlert is based on SENSE (another PWG project). The backend agents (called "Publishers") talk to the target network printers, then post the equivalent of traps (with *far* more information than Printer MIB traps, I might add) to the SENSE server. Applications (called "Subscribers") interested in MIB-like data (called "Publications") can contact the server and get that data, even if the associated Publisher is not currently running; as a result, a SENSE server can provide "disconnected service" for entity-related information. Subscriber applications interested in trap-like stuff contact the server and "subscribe" to one or more "Editions" defined for a given Publication. (An "Edition" is an abstraction used to define an arbitrary event stream.) When an Edition Publisher discovers a relevant event has occured for the associated Publication, the Publisher posts an Edition Event to the server; the server then sends copies of the event to all current Subscribers. SENSE also provides one other critical operational feature not defined for SNMP traps: reliable delivery. Even though the SENSE protocol uses UDP (as does SNMP), the SENSE server resends event messages to a Subscriber until the Subscriber acknowledges receipt of the event (or until a defined timeout has occurred or a maximum retry count has been exceeded). Hope this brings you up to speed on how our Printer MIB-related management application uses the Printer MIB, and how it does nothing whatsoever with SNMP traps. ...jay PS: By the way, it would be quite trivial to provide the ability to serve up Printer MIB traps to an arbitrary number of management apps using the SENSE technology. This would allow a management app to be "mostly" SNMP-based, but use a "side channel" to a SENSE server to reliably collect traps from a target printer. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- End Included Message ----- From jkm at underscore.com Tue May 6 11:22:42 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Webified version of the Sense FAQ now available Message-ID: <199705061522.LAA25597@uscore.underscore.com> Erik Voldengen (Northlake Software) has done a great job of getting the SENSE portion started on the PWG web site. The SENSE home page is pretty empty right now, but hopefully more content will be added over the course of the next few weeks. In the meantime, check out Erik's new webified version of the SENSE FAQ: http://www.pwg.org/sense/sense_faq.html As the SENSE web grows, we'll post all enhancement announcements to this list. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- Date: Mon, 05 May 1997 17:27:57 EDT From: Erik Voldengen To: jkm@underscore.com CC: landau@hannah.enet.dec.com Subject: Sense FAQ I've put together an HTML version of the FAQ you've created. It's very large, and anchors to each of the questions/answers really help. I'll complete the SENSE web page tomorrow - right now it's empty - but for now, you can see the FAQ at the following URL: http://www.pwg.org/sense/sense_faq.html Regards, ___________________________________________________________ Erik Voldengen Northlake Software Erik_Voldengen@nls.com http://www.nls.com 503.228.3383 503.228.5662 fax (PWG Web Master) ----- End Included Message ----- From don at lexmark.com Wed Jun 11 20:43:15 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> August Printer Working Group Meetings Message-ID: <199706121548.AA27330@interlock2.lexmark.com> The August Printer Working Group meeting will be held at Microsoft in Redmond. The current schedule is as follows: August 4th, 5th 9AM - 6PM 1394 Printing Working Group August 6th, 7th 8:30 AM - 6PM IPP Work Group August 8th 8:30 AM - 6PM JMP, etc. as required Each of you is on your own for hotel reservations. Recommendations for hotels are as follows: Double Tree (was Red Lion) Bellvue 425-455-1300 Hyatt Bellvue 425-462-1234 Hilton Bellvue 425-455-3330 Ask for the Microsoft rate at these hotels. Maps, directions, buildings and rooms will be distributed in a later note. If you have any concerns about the above schedule (other than the times which are fixed by room availability at Microsoft) please let me know ASAP so people can make their travel plans. Thanks, Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From hastings at cp10.es.xerox.com Thu Jun 12 12:08:37 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Re: PWG> Proposed change to the June meeting schedule [JMP ALL In-Reply-To: Proposed change to the June meeting schedule [JMP ALL> Message-ID: <9706121611.AA05133@zazen.cp10.es.xerox.com> Jay, I talked with Ron Bergman and we agreed that JMP could use all of Friday, up to the usual closing time of 3:00pm EDT. Ron is travelling, so he wanted me to convey this message ASAP, since JMP participants may need to change their plane reservations. We see from Lloyd's response that PMP doesn't need any time Friday. We'd also like to keep Thursday evening as scheduled as well. The high level JMP agenda is: 1. Answer any issues that arise between now and the meeting. 2. Review the current draft (V0.82 = Internet-Draft 01) and resolve any issues. 3. Review mappings from each job submission protocol to the Job Monitoring MIB for that separate document that we'll produce as an informational RFC. The review of the mapping will also be helping us with the review of the MIB itself. I'm sure we'll get lots of "Oh, it that what that attribute means, we need to clarify ...". In effect, producing and reviewing the mappings from job submission protocols to the Job MIB will be like a "paper backoff". And I sure would like to clear up ambiguities BEFORE we publish the proposed standard, rather than AFTER. So we can sure use all the time. Thanks for your generosity in making it available, Tom and Ron At 13:04 06/09/97 PDT, JK Martin wrote: >Given the fact that both the Printer MIB (PMP) and Job Monitoring MIB >(JMP) projects are in the eleventh hour and are about to "finish", it >is probably in the best interests of the PWG to let those groups have >priority scheduling at the upcoming June meetings. > >Therefore (once again), I am willing to give up the Friday meeting >slot time for SENSE so that these groups have a chance to actually >complete their work at these meetings. > >Given the large amount of finalization needed for the Job MIB, it >could be that the JMP group needs BOTH the Thursday nite meeting >slot IN ADDITION TO a Friday slot. > >As I recall, the PMP group is in much better shape, but it could be >that at least 2 hours are needed for this group's final effort. > >Ron Bergman (JMP chair) and Lloyd Young (PMP chair): would you two >please comment on this rescheduling opportunity, stating what your >requirements are? Please respond as soon as possible, as a change >in scheduling (either duration or start-time) may affect some >participants' travel plans. > >If we can squeeze an evening discussion about SENSE into the mix, >then great. But the JMP and PMP groups really need focus right >now, so let's give it to them. (pun intended... ;-) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > At 14:57 06/09/97 PDT, lpyoung@lexmark.com wrote: > >Jay, >Thanks for thinking of us but the Printer MIB does not need any time >on the agenda for the June meeting. Everything that is left to be >resolved can be resolved via the mailing list. >Lloyd Young > > > > From jkm at underscore.com Mon Jun 16 13:36:19 1997 From: jkm at underscore.com (JK Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Please RSVP to the June Meetings if you have not already done so Message-ID: <199706161736.NAA04481@uscore.underscore.com> [Sorry for the cross-posting, but this message must get out to *everyone* as soon as possible...] The hotel is asking that we have a firm attendance count by Wednesday, June 18 (that is, the day after tomorrow) for the series of PWG meetings to be held Monday thru Friday, June 23-27 (ie, NEXT WEEK). If you have not already sent me a message with the dates of the meetings you plan to attend--OR IF YOU HAVE CHANGED YOUR PLANS since sending me a message--then please send me (jkm@underscore.com) a message BEFORE NOON EDT on Wednesday, June 18. Following are the lists of people who claim to be attending the various PWG meetings scheduled for next week. If you have already sent an RSVP (aka "ping") message, then please be sure your name is listed under the appropriate meeting(s): P1394 (Monday-Tuesday, June 23-24) Alan Berkema Brian Batchelder Danny Mitchell Don Wright Frank Zhao Fumio Nagasaka Greg LeClair Hamid Shenavai Jeff Rackowitz Larry Stein Richard Andrade Shigeru Ueda IPP (Wednesday-Thursday, June 25-26) Angelo Caruso Bob Pentecost Carl-Uno Manros Charles Gordon Chuck Adams Don Wright Frank Zhao Greg LeClair (Wed only) Jasper Wong Jay Martin Jeff Copeland Jeff Rackowitz Lloyd Young (Thurs only) Richard Landau Richard Schneider Robert Herriot Scott Isaacson Shigeru Ueda Stuart Rowley Tom Hastings JMP (Thursday nite, Friday, June 26-27) Angelo Caruso Bob Pentecost Chuck Adams Don Wright Jeff Rackowitz Lloyd Young Richard Landau Stuart Rowley Tom Hastings Folks, we really need to have ACCURATE counts of attendees, so if you're planning to attend one or more of next week's meetings, then by all means please send me a message NOW if you haven't already done so. Similarly, if your plans have changed such that you will not be attending one or more meetings (or if I have you down for the wrong meetings), please let me know ASAP. Thanks for your cooperation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From don at lexmark.com Fri Jul 18 18:07:11 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> August PWG meetings Message-ID: <199707182207.AA22181@interlock2.lexmark.com> Just a reminder... The August meetings of the PWG working groups will be held at Microsoft in Redmond, WA. from August 4th through 8th. Here are the details on the meeting times and locations: Mon/Tue 1394 Printing 9:00AM to 6:00PM Building 27N, Olympic Room Wed/Thur IPP 8:30AM to 6:00PM Building 31, Pebble Beach Fri JMP/SENSE 8:30AM to 6:00PM Building 31, Pebble Beach There is a PDF of a map of the Microsoft site on the Chair's page (http://www.pwg.org/chair/mssite.psf). The map is a little hard to read because it fits the whole campus on a single page but buildings 27N and 31 are marked. See you in Redmond!! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From don at lexmark.com Mon Oct 20 16:12:15 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Boulder PWG Schedule / LA Meeting Details Message-ID: <199710202012.AA00130@interlock2.lexmark.com> Unfortunately, I will not be in attendance at the October PWG meetings in Boulder. (First one I have ever missed -- there goes my record.) Below is the schedule for the meetings. Please read this very close as there are a couple of new things and some new starting times. October 27, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 28, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 29, 1997 8:00 - 8:30 Printer MIB Update - Lloyd Young 8:30 - 5:30 IPP - Carl-Uno Manros October 30, 1997 8:30 - 12:00 IPP - Carl-Uno Manros 1:00 - 6:00 Sense - JK Martin October 31, 1997 8:30 - 12:00 Finisher MIB - Harry Lewis 1:00 - 5:30 Job MIB - Ron Bergman If appropriate, more detailed agendas for each working group will be posted to the appropriate mailing list by the designated chairman. ------------- The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. -------------- Enjoy! Don Wright PWG Chair ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From harryl at us.ibm.com Wed Oct 22 21:14:20 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> October PING list Message-ID: <199710202012.AA00130@interlock2.lexmark.com> Here's what I've got for a PING list. Please send any corrections ASAP.= My estimates were based on the larger attendance we had in the past. Sp= reading fixed costs (like the room, AV etc) across a smaller group, the meeting= cost has ended up at $42 per day. The hotel is not collecting fees, I am hav= ing to do this, myself. Please be prepared, with a company or personal check m= ade out to Harry Lewis for $42 for each day that you attend. I will provide a r= eceipt. P1394 (Monday/Tuesday) ----- Brian Batchelder - HP Alan Berkema - HP Dan Bye - SGS-Thomson (Monday) Dave Doman - Motorola Lee Farrell - Canon Osamu Hirata - Canon Greg LeClair - Epson Kerry Lee Harry Lewis - IBM Fumio Nagasaka - Epson Akihiro Shimura - Canon Greg Shue - HP Jerry Thrasher - Lexmark Atsushi Uchino - Seiko-Epson IPP (Wednesday/Thursday) --- Lee Farrell - Canon Steve Gebert - IBM Tom Hastings - Xerox Scott Isaacson - Novell David Kellerman - Northlake Software Carl Kugler - IBM Kerry Lee Harry Lewis - IBM Carl-Uno Manros - Xerox Jay Martin - Underscore Bob Pentecost - HP Jerry Podojil - Genicom (Thursday) Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson (Thursday) Yuji Sasaki - Japan Computer Industry Atsushi Uchino - Seiko-Epson Dale Wick - TrueSpectra Lloyd Young - Lexmark Peter Zehler - Xerox JMP/FIN (Friday) ------- Carlos Cantu - IBM Dennis Carney - IBM Lee Farrell - Canon Tom Hastings - Xerox David Kellerman - Northlake Software Harry Lewis - IBM Jay Martin - Underscore Kathy Melton - IBM Lisa Morgan - IBM Bob Pentecost - HP Jerry Podojil - Genicom Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson Lloyd Young - Lexmark Harry Lewis = From cmanros at cp10.es.xerox.com Fri Oct 31 18:12:02 1997 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:04:25 2009 Subject: SENSE> PING for Los Angeles Meeting December 1-5 Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield> Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jkm at underscore.com Sun Nov 2 11:08:36 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield> Suffice to say, the Boulder meeting didn't go as well as I expected. A private conversation with Dave Kellerman (Northlake Software) provided critical insight into the nature of the problem. Underscore has spent the last two years developing what we refer to as the "Sense Framework" for use in enterprise environments. This framework came about as the result of research into the various mechanisms and components required to handle event notifications among disparate applications, including the integration of existing printer management products. The trouble appears to revolve around the fact that everytime I try to describe Sense, I always describe the architecture from the top down. That is, I describe the components and mechanisms that have been designed to date, without first adequately describing why we designed the architecture the way that it is. What is needed now, IMHO, is a series of discussions that focus on the architecture from the bottom up, and not from the top down. In addtition, more focus must be made on how Sense can be used within embedded environments without the need for an intermediate server, as commonly described in the current documentation. Therefore, I will be posting messages to the Sense mailing list in the very near future that describes the requirements and features for event messages as it pertains to network printing, without bringing the existing three-tier architecture into the discussion. This should result in a bottom-up approach to the problem domain that should serve to foster an understanding the Sense architecture as currently defined. I would kindly ask others in the PWG community to offer their insights as to how we can advance the Sense effort, or describe similar failings to date in getting this effort moving. Thanks for hitting me in the head with a 2-by-4, Dave. ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jkm at underscore.com Sun Nov 2 10:54:01 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Minutes of the Boulder meeting (30 Oct 97) Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield> The Sense project conducted a meeting during the PWG meetings held in Boulder, Colorado, during the week of October 27. The project secretary was unable to attend, so these minutes come from my personal notes of the discussions. Since I am the project chairman and also served as the Sense discussion moderator, it is quite possible that some details may be missing in this notes. ...jay ---------------------------------------------------------------------- The meeting was orginally scheduled to be held the afternoon of Thursday, Oct 30; however, due to an interest in the subject of event notification by the IPP project, the morning of Oct 30 was used as a sort of "joint meeting" of both IPP and Sense. The IPP project expressed interest in the Sense event notification design for potential use in the IPP environment. Significant interest in Sense was shown by some of the IPP members, most notably Randy Turner, who suggested that Sense should be written up and submitted as an IETF experimental protocol. (Randy explained that, unlike standards-track and informational drafts, experimental protocols merely present work that has already been implemented and is how being publicly advertised for consideration by interested parties. Randy also mentioned that if a standards- track effort is later started, then the effort should proceed more rapidly, since existing implementations were already in practice. (Randy: did I get this right?) The essential elements of Sense were presented, and various walk- throughs of system operation were described, along with discussions of some of the key motivating requirements for Sense. A comprehensive description of the Sense architecture was not presented; in hind- sight, the lack of such a presentation seemed to hinder rapid understanding of Sense by some of the attendees. Everyone was encouraged to visit the PWG website (http://www.pwg.org/sense) and examine the public Sense documentation, in particular the document describing the set of initial Sense requirements and constraints (ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt). It was pointed out that Sense--like IPP--does not currently provide a security mechanism; rather, Sense also expects to leverage a future standard security mechanism once it appears on the IETF horizon. No substantive conclusions or recommendations resulted from the IPP portion of the Sense discussions, although the IPP folks requested the Sense project consider the needs of IPP and attempt a clear integration between the two, if possible. Jay Martin explained that the current design and implementation is specifically oriented to enterprise environments in which the challenge is to provide a framework for management of a (potentially large) collection of shared network printers; for a single printer in the "Internet" environment--specifically one behind a firewall--the Sense design may very well be overkill, although not entirely useless. The focus of the afternoon Sense meeting was to discuss whether the Sense project should be shutdown due to lack of interest. It was pointed out that Sense has taken a backseat (or perhaps a spot in the trunk) with respect to PWG priorities. However, now that almost all PWG projects were in a state of wrap-up (PMP, JMP, IPP v1.0), perhaps now would be the perfect time to ramp up on Sense activities, assuming there was continuing interest within the PWG. The consensus of the group was that the effort should not be shutdown, that there is still considerable interest in this activity by many attendees. Jay Martin concluded the meeting by saying more discussion of Sense is needed on the mailing list, and that he will attempt to foster new discussions on the Sense mailing list (sense@pwg.org) in the month of November. Assuming group discussion occurs, a Sense meeting will be scheduled for the upcoming Los Angeles meeting in December. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jkm at underscore.com Sun Nov 2 11:24:42 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Comments needed on the Sense Requirements document Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield> This is a multi-part message in MIME format. --------------F7C5FA3A8D52554EBCA30F3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Before useful discussions can commence, we really need to get basic consensus on the set of initial requirements and constraints. Once these are defined, we can move on to more detailed discussions on how the various mechanisms (protocols and components) can be defined. The original requirements document was posted way back in late 1995, yet we never moved to guage basic consensus from the group on that document: ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt Please read the requirements document as soon as you can, then post your comments to the Sense mailing list (sense@pwg.org). You should find this document to be a quick-read, as it does not attempt to drill down in any area. To expedite review I have attached a copy of the document to this message. Please submit your comments by Wednesday, November 5, and I'll post a summary/consensus statement on Thursday, November 6. If no comments are received during that period, we shall assume approval of the document as it is currently written; however, it would be best to receive positive comments from the group, rather than letting it become an approved draft by default. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------F7C5FA3A8D52554EBCA30F3E Content-Type: text/plain; charset=us-ascii; name="Requirements.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Requirements.txt" Simple Event Notification Service Environment (SENSE) Proposed Initial Requirements Version 1.0 28 November 1995 This document describes the requirements for a Simple Event Notification Service Environment (SENSE) and related protocol(s). This document is intended to serve as a basis for ongoing research and discussion by interested parties in developing more formal specifications and implementations. Overview -------- The need for SENSE stems from the widespread need for simple notification of events from various kinds of network entities to network clients. Work in this area was originated by JK Martin (Underscore), Rick Landau (Digital) and Mike Timperman (Lexmark) in response to an identified need for transmission of events from network printer devices to network management applications designed to monitor such devices. As work progressed it became readily apparent that the need for such notification services are pervasive in today's widespread client/server environments. The operative word in this initiative is "simple"; the intent is to derive a very simple facility that serves as a "wrapper protocol" that can support the delivery of event messages from a wide variety of sources. It is all too easy to go "hog wild" and specify intricate mechanisms for such a facility. It is the intent of the original development group to keep the SENSE facility very, very simple so as to support both simple client implementations and simple server implementations. It is a specific goal to make the SENSE facility easily implementable in small embedded systems, such as low-cost network printers and printer server devices. While it is not the intent to support only network printer devices, the final results of this initiative should support network printer devices to the maximum extent possible. Glossary -------- Following is a brief set of terms used elsewhere in this document: Event Any single instance of time-oriented information that may arise during the operation of an entity. There are no semantics associated with an Event; an Event can be anything from a "warning" to an "alert" to a simple informational statement. Event Source An entity that emits Events during its operation. Event Message A message containing an Event. The contents and format of the message are not defined by the SENSE facility; that is, the message content is opaque with respect to the protocol used by the SENSE facility. Event Server A network entity that provides event notification services. Event Client A network entity that consumes event notification services. Registration The transaction initiated by an Event Client to an Event Server in which the Client requests services from the Server. A Server expects Registration requests at any time during its operation. Subscription The relationship between an Event Client and an Event Server. A Client registers a Subscription with the Server for an agreed upon period of time, afterwhich the Subscription is automatically terminated by the Server. A "Subscription" can be viewed as a time-limited session between a Client and a Server. SENSE Requirements ------------------ A primary motivation for developing the SENSE specification is to improve the delivery of critical messages as compared to the SNMP TRAP model. In particular, the SENSE specification should improve on these difficiencies in the SNMP TRAP mechanism: - No standard method for adding/removing TRAP destination addresses, either statically or dynamically - All TRAP messages are directed to a fixed UDP port number, thereby forcing the implementation of a demultiplexing mechanism on hosts where multiple recipients operate - Only a single copy of the TRAP message is delivered to any given destination address; if the message gets lost, then no recipient is able to determine that a TRAP message was sent SENSE must satisfy the following functional and operational requirements (not listed in any particular order): 1. Relatively reliable receipt of Event Messages A key requirement is for a Client to expect reasonably reliable receipt of Event Messages. The term "reasonably reliable" is used to denote the fact that a Server should make multiple attempts to deliver the message to the Client. It should be noted that absolute reliability is not considered practical, and thus, not considered as a requirement. 2. Datagrams are used at the transport layer Since stream-oriented protocols are typically considered too "heavy" for lightweight services, datagrams should be used for all SENSE protocol implementations. 3. A well-known transport address is defined for common use To facilitate interoperability, the Server should operate using a standard, "well known" transport address. 4. A Server can operate using any transport address The Server should be able to operate with any defined address within the target transport environment. This will, of course, require that Clients know of and use the non-standard transport address. This requirement is called out so as to allow a Server to operate in an environment in which the standard transport address is already in use. This requirement should be considered optional for an implementation. 5. Minimal protocol data formatting requirements To maintain simplicity, the protocol data units (PDUs) should use displayable text strings for all data components rather than the equivalent binary forms. Using displayable text circumvents the incompatibilities between various network platforms and allows for simple implementation of Client applications. Since the number of PDUs exchanged between a Client and a Server is expected to be rather small, the resulting parsing of the data components by the Client and Server should not be considered a performance problem. 6. Multiple sources of events can be managed by a single Server A Server should be able to "front-end" any number of Event Sources. No minimum or maximum number of supported Event Sources should be required. 7. A Server can be queried to determine the set of event sources managed by the Server A Client should be able to request the list of Event Sources supported by the Server. The list should be formatted in displayable text. 8. A Server can be queried to determine its operational parameters A Client should be able to request a list of operational parameters and their values from the Server. The list should be formatted in displayable text. 9. A simple loopback capability to determine Server existence A Client should be able to "ping" the Server to determine whether the Server is operating at the target transport address. This requirement could be reasonably satisfied through the implementation of Requirement #8 above 10. A client dynamically registers for receipt of events from multiple event sources A Client should be able to dynamically request the creation of a Subscription from a Server, in which any number of Event Sources may be specified as being part of the Subscription. The Subscription request also includes a requested period of time for which the Subscription remains active; once this time period is exceeded, the Server automatically terminates the Subscription without further action by the Client. 11. A client specifies the network endpoint to which all Event Messages are directed When the Client requests the creation of a Subscription, part of the request includes the destination transport address (network address and transport port number) to which all Event Messages are delivered. 12. A client can cancel a subscription at any time A Client is free to prematurely cancel a Subscription (before the Subscription period runs out). 13. Event Messages are asynchronously transmitted by the Server to all registered clients when an event occurs The Server should send Event Messages to the network/transport address specified by the Client at Subscription request time as events occur. The Server will continue to periodically retransmit an Event Message until either the Server-defined retransmit time/count runs out, or until the Client acknowledges receipt of the event. 14. Clients acknowledge receipt of events A Client must acknowledge receipt of an Event Message from a Server. 15. The precise content and format of an Event Message is opaque relative to the underlying SENSE protocol The format and contents of an Event Message are (by definition) not defined within the SENSE specification; instead, the Client is expected to be intimately familiar with the format of such messages based on the associated Event Source. 16. A Server must be able to control resource consumption A key aspect of the SENSE facility is to be highly "Server-oriented" with respect to implementation and performance. In particular, the Server should be allowed to arbitrarily implement the values for such parameters as: Maximum number of Subscriptions Maximum Subscription period Maximum number of retries for delivery of event messages It is expected that the values of these parameters (and probably many others) will be part of the response to a request for a Server's operational parameters as described in Requirement #8 above. While not called out as a requirement in the above list, it is expected that the SENSE facility should be implemented for use with at least the following transports: - UDP/IP - IPX - AppleTalk DDP Other datagram-oriented transports are not necessarily precluded from implementation. Functional Model ---------------- A crude structural diagram that can be used to describe the desired functional model is shown below: Client -----| . | |--- Event Source . | | . . | | . Client -----+----- Server ---+--- Event Source . | | . . | | . . | |--- Event Source . | Client -----| This diagram describes the three primary interworking entities: Client Server Event Source The protocol used between the Client and the Server is expected to be defined for the SENSE facility. On the other hand, the protocol(s) between the Server and the Event Sources are not expected to be defined in the SENSE specification. Protocol Exchange Example ------------------------- Following is a rough protocol diagram describing the basic, error-free exchange between a Client and a Server whereby: o The Client registers a Subscription with the Server o The Server later sends Event Messages to the Client o The Client cancels the Subscription Client Server ------ ------ >---------- registration request ----------> <---------- registration reply ----------< . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . >---------- termination request ----------> <---------- termination reply ----------< # # # # # --------------F7C5FA3A8D52554EBCA30F3E-- From don at lexmark.com Mon Nov 3 16:02:50 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> December Meeting in LA Message-ID: <199711032102.AA28468@interlock2.lexmark.com> Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, here's my first pass at a meeting schedule for the December meeting. Dec 1, 2 - 1394 Printing Dec 3 - IPP Dec 4 - SENSE Dec 5 - FIN I will issue a final agenda on or about November 24th. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jkm at underscore.com Tue Nov 4 12:12:05 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Re: PWG> December Meeting in LA In-Reply-To: December Meeting in LA> Message-ID: <199711032102.AA28468@interlock2.lexmark.com> A Sense project meeting will be held in LA next month ONLY if real interest is shown on the Sense mailing list before the end of November. As of this writing, there is a call for consensus on the Sense requirements document (ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt), with a target deadline THIS WEEK (Wednesday, Nov 5) for comments. If little or no comments are posted to the public Sense project mailing list (sense@pwg.org) by the end of this week, then I will be inclined to declare that Sense project should be shutdown, and hence, no meeting will be held in LA in December. Common on, Sense fans, let's get some discussion rolling on the list if you'd like to see this technology develop into something we can all use. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, > here's > my first pass at a meeting schedule for the December meeting. > > Dec 1, 2 - 1394 Printing > Dec 3 - IPP > Dec 4 - SENSE > Dec 5 - FIN > > I will issue a final agenda on or about November 24th. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From hastings at cp10.es.xerox.com Tue Nov 4 12:59:53 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: <345CA584.AA4A3D77@underscore.com> Message-ID: <3.0.1.32.19971104095953.00ca92f0@garfield> Jay, To followup on the suggestion for a bottom up approach for embedded implementation, I'd like to suggest that it be for an embedded IPP printer. (Jay, consider this a second 2x4). There should be a white paper that describes the scenario for bringing up a SENSE server and the IPP printer with an embedded publisher. The white paper must describe each property that the publisher puts in the publication and in the edition and that a subscriber can query. Then we can get clients that would interwork with the SENSE server and the embedded IPP printers. This white paper should be developed quickly, so that SENSE could be considered as one of the (or the only new?) notification method for IPP. To me SENSE is like SNMP. You need a MIB spec before you can get any interoperation between one vendor's client and another vendor's server. The white paper that I'm proposing is like a MIB spec. Without such specifics for IPP, SENSE is just a general mechanism that can do anything. But without these agreements there can be no interworking between different vendors implementations. Also forget the requirements. SENSE is obviously very general. No one is questioning that. Lets "cut to the chase" as you are fond of saying, and get a spec for IPP's use of SENSE. Maybe you even need to coin a term for the spec that says how a particular set of developers use SENSE for a particular application, something like a "SENSE profile". I think we need an IPP profile spec first. Then we can see if there also needs to be a general printing profile, or whether the IPP profile really works for most printing. So the IPP profile spec needs: 1. List the publication properties by name and semantics. Tying them to IPP attribute semantics will make this much faster to write and understand. 2. List the edition propertied by name and semantics. Same as the publication properties. 3. Indicate the scenario of populating the SENSE server. Who does what. People will go read the SENSE documentation to get what they don't understand from the first draft "SENSE IPP Profile". Tom At 08:08 11/02/1997 PST, Jay Martin wrote: >Suffice to say, the Boulder meeting didn't go as well as I expected. >A private conversation with Dave Kellerman (Northlake Software) >provided critical insight into the nature of the problem. > >Underscore has spent the last two years developing what we refer to >as the "Sense Framework" for use in enterprise environments. This >framework came about as the result of research into the various >mechanisms and components required to handle event notifications >among disparate applications, including the integration of existing >printer management products. > >The trouble appears to revolve around the fact that everytime I try >to describe Sense, I always describe the architecture from the top >down. That is, I describe the components and mechanisms that have >been designed to date, without first adequately describing why we >designed the architecture the way that it is. > >What is needed now, IMHO, is a series of discussions that focus on >the architecture from the bottom up, and not from the top down. In >addtition, more focus must be made on how Sense can be used within >embedded environments without the need for an intermediate server, >as commonly described in the current documentation. > >Therefore, I will be posting messages to the Sense mailing list in >the very near future that describes the requirements and features for >event messages as it pertains to network printing, without bringing >the existing three-tier architecture into the discussion. This should >result in a bottom-up approach to the problem domain that should >serve to foster an understanding the Sense architecture as currently >defined. > >I would kindly ask others in the PWG community to offer their insights >as to how we can advance the Sense effort, or describe similar failings >to date in getting this effort moving. > >Thanks for hitting me in the head with a 2-by-4, Dave. ;-) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > > From jkm at underscore.com Tue Nov 4 14:00:49 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: Where to go from here?> Message-ID: <3.0.1.32.19971104095953.00ca92f0@garfield> Tom, I'm not sure we're on the same wavelength here. Maybe you can help me understand your position a bit more clearly. > To followup on the suggestion for a bottom up approach for embedded > implementation, I'd like to suggest that it be for an embedded IPP > printer. (Jay, consider this a second 2x4). Talking about requirements for an embedded IPP printer is fine, however it should be noted that Sense pre-dated IPP by over a year, and I really don't want to ignore the original requirements. (And thanks anyway, but one 2x4 is enough for me right now.) More importantly, though, is the need to get a firm consensus on the underlying requirements of event notification in the printer environment. That is, before we talk "spec" with regard to IPP, we really should be talking about the general feature requirements, including proposed scenarios described who needs what kind of events, and what kinds of components are expected to handle those events. > There should be a white paper that describes the scenario for bringing > up a SENSE server and the IPP printer with an embedded publisher. > > [...snip...] > > The white paper that I'm proposing is like a MIB spec. If you want to see such a white paper *very* quickly, then perhaps you can write one yourself? > Also forget the requirements. SENSE is obviously very general. > No one is questioning that. Lets "cut to the chase" as you are fond > of saying, and get a spec for IPP's use of SENSE. Maybe you even need to > coin a term for the spec that says how a particular set of developers > use SENSE for a particular application, something like a "SENSE profile". Forget the requirements? Beg your pardon? Sure, I like cutting to the chase, but that doesn't mean you jump clear over the primary issues that need to be resolved. > I think we need an IPP profile spec first. Then we can see if there also > needs to be a general printing profile, or whether the IPP profile really > works for most printing. Sure, that is certainly one approach to spec'ing out things. But as I said earlier, we first need to talk about what an "event" is, and who (and what) produces/consumes an event. > So the IPP profile spec needs: > > 1. List the publication properties by name and semantics. Tying them > to IPP attribute semantics will make this much faster to write and > understand. > > 2. List the edition propertied by name and semantics. Same as the > publication properties. > > 3. Indicate the scenario of populating the SENSE server. Who does what. I don't think we should be necessarily talking about a "Sense server" at this point. Instead, let's just focus on the producers and consumers of events, then see where we go from there. I think it was Carl-Uno who said (during the Boulder meeting) that he'd like to see how Sense would work without having an intermediate server. Upon further consideration, I now tend to agree. And that's what I believe the Sense project should be focusing on at this time. > People will go read the SENSE documentation to get what they don't > understand from the first draft "SENSE IPP Profile". As a generic observation, that's a good point, Tom. Do others in the Sense group agree with Tom's approach, or would you prefer to take my previously published approach of "starting from the beginning" and getting the basics down first? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at us.ibm.com Tue Nov 4 18:05:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: Where to go from here?> Message-ID: <3.0.1.32.19971104095953.00ca92f0@garfield> Jay asked... >Do others in the Sense group agree with Tom's approach, or would you >prefer to take my previously published approach of "starting from the >beginning" and getting the basics down first? I have to say I agree with Tom to a large extent. IPP and the Job MIB rely on each other. The main thing missing from the Job MIB are events.= While some of us have implemented private registration and filters for clients desiring Job MIB feedback, the JMP, as a team, stopped short of= standardizing job events due to the perception of insurmountable SNMP limitations and/or the fact that SNMPv3 is addressing these issues. Job MIB / IPP event profile... Consumers - Anyone who has submitted a print job and wants to know it= 's position/progress - Job tracking/accounting applications that want to know wh= en a job has completed so they can "harvest" final values - Printer and/or print "farm" operators who need to track j= obs or who have, effectively, become "end-users" Publishers - IPP/JobMIB/SENSE printers - IPP/JobMIB/SENSE print servers Events - Job (id) Pending, - Job (id) Printing, - Job (id) Page n of m Printed, - Job (id) Copy x of y Printed, - Job (id) Interrupted (reason), - Job (id) Finishing Complete, - Job (id) Complete, Event message - This needs some thought, but along with each event some= additional information could be carried, like "octets processed, total octets" or "position in queue" - as overall progress indicators thus utilizing the fact that each job will generate several events to overco= me the possibility of an individual datagram being lost. Of course, my simplified event profile in no way covers all of DPA and probably doesn't follow IPP or the JobMIB strictly - it's just a pragma= tic example. Harry Lewis - IBM Printing Systems ---- Forwarded --- owner-sense@pwg.org on 11/04/97 12:12:26 PM Please respond to owner-sense@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet cc: sense@pwg.org @ internet Subject: Re: SENSE> Where to go from here? Tom, I'm not sure we're on the same wavelength here. Maybe you can help me understand your position a bit more clearly. > To followup on the suggestion for a bottom up approach for embedded > implementation, I'd like to suggest that it be for an embedded IPP > printer. (Jay, consider this a second 2x4). Talking about requirements for an embedded IPP printer is fine, however it should be noted that Sense pre-dated IPP by over a year, and I really don't want to ignore the original requirements. (And thanks anyway, but one 2x4 is enough for me right now.) More importantly, though, is the need to get a firm consensus on the underlying requirements of event notification in the printer environment. That is, before we talk "spec" with regard to IPP, we really should be talking about the general feature requirements, including proposed scenarios described who needs what kind of events, and what kinds of components are expected to handle those events. > There should be a white paper that describes the scenario for bringin= g > up a SENSE server and the IPP printer with an embedded publisher. > > [...snip...] > > The white paper that I'm proposing is like a MIB spec. If you want to see such a white paper *very* quickly, then perhaps you can write one yourself? > Also forget the requirements. SENSE is obviously very general. > No one is questioning that. Lets "cut to the chase" as you are fond > of saying, and get a spec for IPP's use of SENSE. Maybe you even nee= d to > coin a term for the spec that says how a particular set of developers= > use SENSE for a particular application, something like a "SENSE profi= le". Forget the requirements? Beg your pardon? Sure, I like cutting to the chase, but that doesn't mean you jump clear over the primary issues that need to be resolved. > I think we need an IPP profile spec first. Then we can see if there = also > needs to be a general printing profile, or whether the IPP profile re= ally > works for most printing. Sure, that is certainly one approach to spec'ing out things. But as I said earlier, we first need to talk about what an "event" is, and who (and what) produces/consumes an event. > So the IPP profile spec needs: > > 1. List the publication properties by name and semantics. Tying them= > to IPP attribute semantics will make this much faster to write and > understand. > > 2. List the edition propertied by name and semantics. Same as the > publication properties. > > 3. Indicate the scenario of populating the SENSE server. Who does wh= at. I don't think we should be necessarily talking about a "Sense server" at this point. Instead, let's just focus on the producers and consumers of events, then see where we go from there. I think it was Carl-Uno who said (during the Boulder meeting) that he'd like to see how Sense would work without having an intermediate server. Upon further consideration, I now tend to agree. And that's what I believe the Sense project should be focusing on at this time. > People will go read the SENSE documentation to get what they don't > understand from the first draft "SENSE IPP Profile". As a generic observation, that's a good point, Tom. Do others in the Sense group agree with Tom's approach, or would you prefer to take my previously published approach of "starting from the beginning" and getting the basics down first? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- = From jkm at underscore.com Tue Nov 4 18:24:20 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: Where to go from here?> Message-ID: <3.0.1.32.19971104095953.00ca92f0@garfield> Harry, I guess I'm a bit disappointed by your response in which you appear to give credence to Tom's rather rash, "skip the requirements" approach to progressing Sense. Apparently neither of you got the gist of my earlier message in which I stated that we had to get back to basics so that people can understand how the current Sense architecture resulted in the way that it did. First things first, though. We REALLY NEED to get a consensus on the basic requirements for Sense, and then talk about protocol implications with respect to specific components we expect to have involved in the exchange (ie, production/consumption) of events. You've done a great job of making the initial sketch of the key requirements specific to IPP/JMP (ie, producers, consumers and initial set of high-level events). Now what is needed is a discussion surrounding protocol considerations and potential constraints. This topic is addressed in the Sense requirements document, and I'd really like to get group consensus on that document's contents before we proceed. Fair enough? Or do you (or Tom) think we'd be wasting the group's time talking about core requirements, etc? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Jay asked... > > >Do others in the Sense group agree with Tom's approach, or would you > >prefer to take my previously published approach of "starting from the > >beginning" and getting the basics down first? > > I have to say I agree with Tom to a large extent. IPP and the Job MIB > rely on each other. The main thing missing from the Job MIB are events. > While some of us have implemented private registration and filters for > clients desiring Job MIB feedback, the JMP, as a team, stopped short of > standardizing job events due to the perception of insurmountable SNMP > limitations and/or the fact that SNMPv3 is addressing these issues. > > Job MIB / IPP event profile... > > Consumers - Anyone who has submitted a print job and wants to know it's > position/progress > - Job tracking/accounting applications that want to know when > a job has completed so they can "harvest" final values > - Printer and/or print "farm" operators who need to track jobs > or who have, effectively, become "end-users" > > Publishers - IPP/JobMIB/SENSE printers > - IPP/JobMIB/SENSE print servers > > Events - Job (id) Pending, > - Job (id) Printing, > - Job (id) Page n of m Printed, > - Job (id) Copy x of y Printed, > - Job (id) Interrupted (reason), > - Job (id) Finishing Complete, > - Job (id) Complete, > > Event message - This needs some thought, but along with each event some > additional information could be carried, like "octets processed, total > octets" or "position in queue" - as overall progress indicators thus > utilizing the fact that each job will generate several events to overcome > the possibility of an individual datagram being lost. > > Of course, my simplified event profile in no way covers all of DPA and > probably doesn't follow IPP or the JobMIB strictly - it's just a pragmatic > example. > > Harry Lewis - IBM Printing Systems > > ---- Forwarded --- > > owner-sense@pwg.org on 11/04/97 12:12:26 PM > Please respond to owner-sense@pwg.org @ internet > To: hastings@cp10.es.xerox.com @ internet > cc: sense@pwg.org @ internet > Subject: Re: SENSE> Where to go from here? > > Tom, > > I'm not sure we're on the same wavelength here. Maybe you can help > me understand your position a bit more clearly. > > > To followup on the suggestion for a bottom up approach for embedded > > implementation, I'd like to suggest that it be for an embedded IPP > > printer. (Jay, consider this a second 2x4). > > Talking about requirements for an embedded IPP printer is fine, > however it should be noted that Sense pre-dated IPP by over a year, > and I really don't want to ignore the original requirements. > (And thanks anyway, but one 2x4 is enough for me right now.) > > More importantly, though, is the need to get a firm consensus on > the underlying requirements of event notification in the printer > environment. That is, before we talk "spec" with regard to IPP, > we really should be talking about the general feature requirements, > including proposed scenarios described who needs what kind of events, > and what kinds of components are expected to handle those events. > > > There should be a white paper that describes the scenario for bringing > > up a SENSE server and the IPP printer with an embedded publisher. > > > > [...snip...] > > > > The white paper that I'm proposing is like a MIB spec. > > If you want to see such a white paper *very* quickly, then perhaps > you can write one yourself? > > > Also forget the requirements. SENSE is obviously very general. > > No one is questioning that. Lets "cut to the chase" as you are fond > > of saying, and get a spec for IPP's use of SENSE. Maybe you even need to > > coin a term for the spec that says how a particular set of developers > > use SENSE for a particular application, something like a "SENSE profile". > > Forget the requirements? Beg your pardon? > > Sure, I like cutting to the chase, but that doesn't mean you > jump clear over the primary issues that need to be resolved. > > > I think we need an IPP profile spec first. Then we can see if there also > > needs to be a general printing profile, or whether the IPP profile really > > works for most printing. > > Sure, that is certainly one approach to spec'ing out things. But > as I said earlier, we first need to talk about what an "event" is, > and who (and what) produces/consumes an event. > > > So the IPP profile spec needs: > > > > 1. List the publication properties by name and semantics. Tying them > > to IPP attribute semantics will make this much faster to write and > > understand. > > > > 2. List the edition propertied by name and semantics. Same as the > > publication properties. > > > > 3. Indicate the scenario of populating the SENSE server. Who does what. > > I don't think we should be necessarily talking about a "Sense server" > at this point. Instead, let's just focus on the producers and > consumers of events, then see where we go from there. > > I think it was Carl-Uno who said (during the Boulder meeting) that > he'd like to see how Sense would work without having an intermediate > server. Upon further consideration, I now tend to agree. And that's > what I believe the Sense project should be focusing on at this time. > > > People will go read the SENSE documentation to get what they don't > > understand from the first draft "SENSE IPP Profile". > > As a generic observation, that's a good point, Tom. > > Do others in the Sense group agree with Tom's approach, or would you > prefer to take my previously published approach of "starting from the > beginning" and getting the basics down first? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From don at lexmark.com Wed Nov 5 08:49:19 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? Message-ID: <199711051349.AA05132@interlock2.lexmark.com> jkm said: >I guess I'm a bit disappointed by your response in which you appear >to give credence to Tom's rather rash, "skip the requirements" >approach to progressing Sense. > >Apparently neither of you got the gist of my earlier message in >which I stated that we had to get back to basics so that people >can understand how the current Sense architecture resulted in the >way that it did. What really is the question here? Should we narrow the focus of the SENSE requirements to be focused specifically on an IPP or similar environment or should they be broad and cover the range from a local network to the entire Internet? We, as the PWG, have run into this problem before. If we narrow our scope we stand a chance of getting some done. Of course the downside is that what we end up with probably won't scale easily. On the other hand, if we try to do something broad and all encompassing, chances are nothing will happen. What do we really want to accomplish? Is a narrow, focused set of requirements that address the IPP environment a good start and can we discipline ourselves to not paint ourselves into a scalability corner? Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jkm at underscore.com Wed Nov 5 13:31:38 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: Where to go from here?> Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Good commens, Don. I agree with you entirely on the subject of focus and how it can and should foster rapid success. What concerns me, I guess, is that Tom would have us rush in and use Sense--as it is currently defined and implemented--to immediately address the needs of IPP and JMP. This approach implies a complete and unanimous group approval on the Sense work to date. As the primary Sense developer, I should be both flattered and excited at the thought of such an immediate adoption of Sense as Underscore has conceived it. However, I wasn't born yesterday... Carl-Uno made the observation that Sense's current design was probably overkill for IPP...at least for *some* scenarios of IPP, anyway. And I tend to agree, to a certain extent. What I am hoping we can do in the immediate future is: 1. Get group consensus on the base set of requirements and reasonable constraints. This document should serve as the best guide to know when we have run "into the mud" on any given Sense topic in the future. 2. Commence discussions on the basic operational nature of events as seen (and handled) by consumers and producers of events. This discussion should naturally converge towards a basic understanding of such critical issues as protocol design, the concept of a "session" (remember, we're talking about a subscription/publication model here), and other related issues. Does everyone agree with this initial starting point? If so, then the next step (step #3) would be to draft up the first concrete design using IPP and/or JMP as the target event environment. By the way, it is now Wednesday, Nov 5, the deadline I had previously set for comments on the base requirements document. Unfortunately, as of this writing, no one has posted any comments (privately or publicly) on the document contents. The document may be found on the PWG server at: ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt I would appreciate it if folks would take 5-10 minutes to read the document (it is a *very* simple document), then post whether you agree with its contents, or post some changes/concerns/complaints/etc. If no one takes the time to comment on the proposed draft--an action which is considered core and ESSENTIAL in standards development--then I would tend to believe that we are wasting our time with Sense at this point, as our discussions would not be focused towards the kinds of goals that we have all come to recognize in all other PWG efforts. Flames are welcome at this point. Any discusson is better than no discussion. ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > jkm said: > > >I guess I'm a bit disappointed by your response in which you appear > >to give credence to Tom's rather rash, "skip the requirements" > >approach to progressing Sense. > > > >Apparently neither of you got the gist of my earlier message in > >which I stated that we had to get back to basics so that people > >can understand how the current Sense architecture resulted in the > >way that it did. > > What really is the question here? Should we narrow the focus > of the SENSE requirements to be focused specifically on an IPP > or similar environment or should they be broad and cover the > range from a local network to the entire Internet? > > We, as the PWG, have run into this problem before. If we > narrow our scope we stand a chance of getting some done. Of > course the downside is that what we end up with probably won't > scale easily. On the other hand, if we try to do something > broad and all encompassing, chances are nothing will happen. > > What do we really want to accomplish? Is a narrow, focused > set of requirements that address the IPP environment a good > start and can we discipline ourselves to not paint ourselves > into a scalability corner? > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From JPODOJIL at genicom.com Wed Nov 5 14:56:00 1997 From: JPODOJIL at genicom.com (Podojil, Jerry D. x119) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Jay, I would simply like to say that I agree with your last statements. I have reviewed your requirements document, and agree with the contents. I'm not sure why you are having so much trouble getting consensus on the requirements document - maybe the others involved here could elaborate. If an IPP based implementation is so inviting, that seems to imply consensus. -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, November 05, 1997 1:32 PM To: don Cc: sense Subject: Re: SENSE> Where to go from here? Good commens, Don. I agree with you entirely on the subject of focus and how it can and should foster rapid success. What concerns me, I guess, is that Tom would have us rush in and use Sense--as it is currently defined and implemented--to immediately address the needs of IPP and JMP. This approach implies a complete and unanimous group approval on the Sense work to date. As the primary Sense developer, I should be both flattered and excited at the thought of such an immediate adoption of Sense as Underscore has conceived it. However, I wasn't born yesterday... Carl-Uno made the observation that Sense's current design was probably overkill for IPP...at least for *some* scenarios of IPP, anyway. And I tend to agree, to a certain extent. What I am hoping we can do in the immediate future is: 1. Get group consensus on the base set of requirements and reasonable constraints. This document should serve as the best guide to know when we have run "into the mud" on any given Sense topic in the future. 2. Commence discussions on the basic operational nature of events as seen (and handled) by consumers and producers of events. This discussion should naturally converge towards a basic understanding of such critical issues as protocol design, the concept of a "session" (remember, we're talking about a subscription/publication model here), and other related issues. Does everyone agree with this initial starting point? If so, then the next step (step #3) would be to draft up the first concrete design using IPP and/or JMP as the target event environment. By the way, it is now Wednesday, Nov 5, the deadline I had previously set for comments on the base requirements document. Unfortunately, as of this writing, no one has posted any comments (privately or publicly) on the document contents. The document may be found on the PWG server at: ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt I would appreciate it if folks would take 5-10 minutes to read the document (it is a *very* simple document), then post whether you agree with its contents, or post some changes/concerns/complaints/etc. If no one takes the time to comment on the proposed draft--an action which is considered core and ESSENTIAL in standards development--then I would tend to believe that we are wasting our time with Sense at this point, as our discussions would not be focused towards the kinds of goals that we have all come to recognize in all other PWG efforts. Flames are welcome at this point. Any discusson is better than no discussion. ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > jkm said: > > >I guess I'm a bit disappointed by your response in which you appear > >to give credence to Tom's rather rash, "skip the requirements" > >approach to progressing Sense. > > > >Apparently neither of you got the gist of my earlier message in > >which I stated that we had to get back to basics so that people > >can understand how the current Sense architecture resulted in the > >way that it did. > > What really is the question here? Should we narrow the focus > of the SENSE requirements to be focused specifically on an IPP > or similar environment or should they be broad and cover the > range from a local network to the entire Internet? > > We, as the PWG, have run into this problem before. If we > narrow our scope we stand a chance of getting some done. Of > course the downside is that what we end up with probably won't > scale easily. On the other hand, if we try to do something > broad and all encompassing, chances are nothing will happen. > > What do we really want to accomplish? Is a narrow, focused > set of requirements that address the IPP environment a good > start and can we discipline ourselves to not paint ourselves > into a scalability corner? > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From harryl at us.ibm.com Wed Nov 5 18:20:00 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review Message-ID: <199711051349.AA05132@interlock2.lexmark.com> I have reviewed the SENSE requirements doc (v1.0 11/28/95) as requested= and have the following comments: 1. (Overview) In general, while current NMS and Printer MIB solutions = seem to be performing adequately, I agree with the underlying premise of SEN= SE, that there is room for widespread application of event driven network d= evice management and view this as an evolutionary step. 2. (Overview) Simple is stressed as an overriding characteristic of th= e requirements. I wonder if the current model, with it's publication and = edition paradigm is really as simple as originally intended. This would be unfa= ir as a criticism (and is not intended as such) since I do not have an alternat= ive model to offer. It's just an observation that the current state of the architecture may not fit the icon of simplicity put forth in the requir= ements. Simple is a very hard thing to define and it may be better to avoid the= term. Given that events really capture the essence of the situation perhaps t= he name should be changed to ES&NSE (Event Subscription & Notification Services= Environment). 3. (SENSE Requirements) The primary motive... lack of good Trap regist= ration and distribution in SNMP may well be handled in SNMPv3. This motivation= should be re-investigated. 4. (#14) Client ACK of event. I'm not sure this should be required in = all cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate= (#16) - server resource management. The server can really bloat while waiting f= or ACKs from clients who disappear etc. It is feasible to consider an "unreliab= le" mode of operation. 5. (not addressed) The requirements do not appear to directly address = the need for filtering. I know the requirements do not address data content and = it could be argued this is where this topic belongs, but I think filters are sig= nificant to any event based scheme and should at least be mentioned. I also ackn= owledge that filtering is exactly one of the reasons the current SENSE architec= ture may appear somewhat less than simple (my comment 2, above). Harry Lewis - IBM Printing Systems = From rbergma at dpc.com Wed Nov 5 21:30:18 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Where to go from here? In-Reply-To: <3460BB8A.9A5B9CC7@underscore.com> Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Jay, It looks like there is more interest in SENSE than was evident at the meeting last week. Also, some very good comments and suggestions were submitted. I certainly support any efforts to further this technology. I believe that I have a fairly good understanding of the concepts, functions, and capabilities of SENSE, especially with respect to its application to SNMP. I had expected that the discussion last week would be directed more towards the application of SENSE towards IPP. It was unfortunate that discussion regarding the notification requirements of IPP was not completed. This would be a good starting point for progressing SENSE. Once the IPP requirements are fully defined, it should be very easy to see how SENSE can or cannot provide a solution. Ron Bergman Dataproducts Corp. From jkm at underscore.com Thu Nov 6 13:50:04 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review In-Reply-To: SENSE Req review> Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Harry, Thanks for your comments. I wish others would take the time and do the same, or at least post a message to the list saying they are in full agreement with the document's contents. > 2. (Overview) Simple is stressed as an overriding characteristic of the > requirements. I wonder if the current model, with it's publication and edition > paradigm is really as simple as originally intended. This would be unfair as a > criticism (and is not intended as such) since I do not have an alternative > model to offer. It's just an observation that the current state of the > architecture may not fit the icon of simplicity put forth in the requirements. > Simple is a very hard thing to define and it may be better to avoid the term. > Given that events really capture the essence of the situation perhaps the name > should be changed to ES&NSE (Event Subscription & Notification Services > Environment). I can certainly understand how you might think the Publication/Edition model is not very simple. I think the reason for this is that we have not yet fully discussed the requirements as mapped to a proposed design/implementation. Perhaps once we start looking at potential designs (including the existing design as conceived by Underscore), then folks will be able to better judge whether the Publication/Edition model is useful, or whether something else should be pursued. For the time being, though, let's leave the project name as it is (ie, Sense). > 3. (SENSE Requirements) The primary motive... lack of good Trap registration > and distribution in SNMP may well be handled in SNMPv3. This motivation should > be re-investigated. Yes, you and I have privately spoken about this situation. Sense, having pre- dated SNMPv3 by quite some time, may now need to be reexamined to see if SNMPv3 eclipses the need for Sense, or at least certain parts of it. I need to do another head-to-head competitive analysis of SNMPv3 against Sense, similar to what I had previously done for DMI v2.0. Hopefully I'll be able to get to that in the next week or so. (By the way, can anyone give me some quick net pointers to the SNMPv3 docs?) > 4. (#14) Client ACK of event. I'm not sure this should be required in all > cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate (#16) - > server resource management. The server can really bloat while waiting for ACKs > from clients who disappear etc. It is feasible to consider an "unreliable" mode > of operation. Excellent observation, Harry. We, too, have found that an "unreliable mode" is certainly viable in certain environments. This shouldn't be too hard to add to Sense. Do others have any comments on this addition? Right off the top of my head, I'd say that the subscription request would be defined to have one or more message properties indicating the level of reliability for events delivered for that subscription. The client API in the current implementation actually supports the kinds of reliability controls you mention. However, these controls are used across the client session and can not be altered on a per-subscription basis. Perhaps such session-wide controls are enough for you, though. > 5. (not addressed) The requirements do not appear to directly address the need > for filtering. I know the requirements do not address data content and it could > be argued this is where this topic belongs, but I think filters are significant > to any event based scheme and should at least be mentioned. I also acknowledge > that filtering is exactly one of the reasons the current SENSE architecture may > appear somewhat less than simple (my comment 2, above). Ah yes, filters. As I described in Boulder last week, filters, or more precisely, filter specifications, are one of the primary reasons we conceived of the notion of an "Edition". Filter specifications can get very, VERY ugly, and before you know it, you often end up designing an entire "language" to deal with that. This is something we at Underscore desparately wanted to avoid. I'll address that issue in more detail in a later message. However, for now, suffice to say that a requirement exists for a client to be able to specify receipt of only a subset of all events that may be available from a given source. Exactly how that "subset" is defined and handled is a topic for design and implementation, IMHO. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at us.ibm.com Thu Nov 6 14:49:35 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SNMPv3 docs Message-ID: <199711051349.AA05132@interlock2.lexmark.com> <(By the way, can anyone give me some quick net pointers to the SNMPv3 = docs?) http://www.ietf.org/html.charters/snmpv3-charter.html Harry Lewis - IBM Printing Systems = From David_Kellerman at nls.com Fri Nov 7 18:56:40 1997 From: David_Kellerman at nls.com (David_Kellerman@nls.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Comments needed on the Sense Requirements document Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Jay and all, My list of requirements for an event notification service is a bit shorter than the published SENSE requirements document. Part of this is because I'm still trying to envision the abstract service, and the SENSE requirements drill down much further. Perhaps more importantly, it is also because I'm looking for a service that is scalable from very simple implementations on up, and the SENSE requirements focus on the high end. My starting point is the idea of a notification service that, at its simplest, allows reliable, efficient event notification from an agent to a client. In this form, the service should be very lightweight to implement. On top of this, this basic service should be designed so it can be used as a building block to construct large scale services. And I think we should be able to do this in such a way that the scaling is transparent to both agent and client. To be more specific, I'd like to see a simple agent/client service that can also be rewired as an agent/proxy/client service without change to the agent and client. Now bear with me, because I'm not an expert in event notification services (I just play one on mailing lists), but here's my edit on requirements: A. Schema based The idea being that there is an overall grouping of the information for each class of event producer, much like a directory entry schema. B. Reliable receipt of event messages I believe this implies client registration for notification (and renewal and cancellation), client acknowledgement of receipt, and retransmission by the agent. C. Efficient delivery of event messages I believe this implies client registration, asynchronous delivery of messages by the agent. D. Allows lightweight implementation (Okay, I'm going to drill down a little here.) I believe this means the agent gets to decide the contents of messages (i.e. the basic agent is not required to do client-specified filtering) E. Scalability I believe the way to do this is by introducing proxy servers, so the basic protocol needs to be able to deal with the issues involved in ensuring the liveness of copied data. (Drilling down again; revisiting message filtering.) I wonder if a notion of message schema variants might provide an alternative to client-defined message filtering. The idea being that an agent (proxy, in particular) might define and deliver "subset" variants in addition to the full message; by selecting a variant, a client could reduce the number of irrelevant notifications it received. F. Client discovery of services The client needs to be able to query an agent to determine available event notification services, message schemas, and so forth. The client also needs to be able to locate agents, and locating proxy agents should be a natural part of the service. G. Leverages existing technology (I'm on thin ice here.) To me, this all looks very much like a read-only dynamic directory service, and I wonder if we can't model it as a variant on LDAP. (Rationale similar to that for basing IPP on HTTP.) There is (was?) an internet draft, LDAP: Extensions for Dynamic Directory Services (draft-ietf-asid-ldapv3ext-02), authored by Yaacovi, Settle, and Genovese of Microsoft, and Wahl of Critical Angle, that might be relevant, although I have no idea of its current status or support. Also, the roles it specifies for clients and servers don't seem to map directly to what is needed here. I. Security, passage through firewalls No bright ideas here, but these issues need answers. An ugly but practial approach might be some combination of polling and encapsulation of information over HTTP for remote notification. Overall, I'd say these requirements look a lot like the existing SENSE requirements. Perhaps the biggest difference is that I would like to align with services that have evolved since the design of SENSE -- for both engineering and "mind share" reasons. Key issues that I think need to be revisited include: A. Delivery mechanism The datagram-based delivery is lightweight (a big advantage), but it has size limits and security and firewall problems. Is there a better choice? B. Message format SENSE tries to be content neutral; I'd nail this down more. And of course schemas need to be defined for specific classes of event producers. :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From: MX%"jkm@underscore.com" 2-NOV-1997 08:35:51.77 To: MX%"sense@pwg.org" Subj: SENSE> Comments needed on the Sense Requirements document Before useful discussions can commence, we really need to get basic consensus on the set of initial requirements and constraints. Once these are defined, we can move on to more detailed discussions on how the various mechanisms (protocols and components) can be defined. The original requirements document was posted way back in late 1995, yet we never moved to guage basic consensus from the group on that document: ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt Please read the requirements document as soon as you can, then post your comments to the Sense mailing list (sense@pwg.org). You should find this document to be a quick-read, as it does not attempt to drill down in any area. To expedite review I have attached a copy of the document to this message. Please submit your comments by Wednesday, November 5, and I'll post a summary/consensus statement on Thursday, November 6. If no comments are received during that period, we shall assume approval of the document as it is currently written; however, it would be best to receive positive comments from the group, rather than letting it become an approved draft by default. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Simple Event Notification Service Environment (SENSE) Proposed Initial Requirements Version 1.0 28 November 1995 This document describes the requirements for a Simple Event Notification Service Environment (SENSE) and related protocol(s). This document is intended to serve as a basis for ongoing research and discussion by interested parties in developing more formal specifications and implementations. Overview -------- The need for SENSE stems from the widespread need for simple notification of events from various kinds of network entities to network clients. Work in this area was originated by JK Martin (Underscore), Rick Landau (Digital) and Mike Timperman (Lexmark) in response to an identified need for transmission of events from network printer devices to network management applications designed to monitor such devices. As work progressed it became readily apparent that the need for such notification services are pervasive in today's widespread client/server environments. The operative word in this initiative is "simple"; the intent is to derive a very simple facility that serves as a "wrapper protocol" that can support the delivery of event messages from a wide variety of sources. It is all too easy to go "hog wild" and specify intricate mechanisms for such a facility. It is the intent of the original development group to keep the SENSE facility very, very simple so as to support both simple client implementations and simple server implementations. It is a specific goal to make the SENSE facility easily implementable in small embedded systems, such as low-cost network printers and printer server devices. While it is not the intent to support only network printer devices, the final results of this initiative should support network printer devices to the maximum extent possible. Glossary -------- Following is a brief set of terms used elsewhere in this document: Event Any single instance of time-oriented information that may arise during the operation of an entity. There are no semantics associated with an Event; an Event can be anything from a "warning" to an "alert" to a simple informational statement. Event Source An entity that emits Events during its operation. Event Message A message containing an Event. The contents and format of the message are not defined by the SENSE facility; that is, the message content is opaque with respect to the protocol used by the SENSE facility. Event Server A network entity that provides event notification services. Event Client A network entity that consumes event notification services. Registration The transaction initiated by an Event Client to an Event Server in which the Client requests services from the Server. A Server expects Registration requests at any time during its operation. Subscription The relationship between an Event Client and an Event Server. A Client registers a Subscription with the Server for an agreed upon period of time, afterwhich the Subscription is automatically terminated by the Server. A "Subscription" can be viewed as a time-limited session between a Client and a Server. SENSE Requirements ------------------ A primary motivation for developing the SENSE specification is to improve the delivery of critical messages as compared to the SNMP TRAP model. In particular, the SENSE specification should improve on these difficiencies in the SNMP TRAP mechanism: - No standard method for adding/removing TRAP destination addresses, either statically or dynamically - All TRAP messages are directed to a fixed UDP port number, thereby forcing the implementation of a demultiplexing mechanism on hosts where multiple recipients operate - Only a single copy of the TRAP message is delivered to any given destination address; if the message gets lost, then no recipient is able to determine that a TRAP message was sent SENSE must satisfy the following functional and operational requirements (not listed in any particular order): 1. Relatively reliable receipt of Event Messages A key requirement is for a Client to expect reasonably reliable receipt of Event Messages. The term "reasonably reliable" is used to denote the fact that a Server should make multiple attempts to deliver the message to the Client. It should be noted that absolute reliability is not considered practical, and thus, not considered as a requirement. 2. Datagrams are used at the transport layer Since stream-oriented protocols are typically considered too "heavy" for lightweight services, datagrams should be used for all SENSE protocol implementations. 3. A well-known transport address is defined for common use To facilitate interoperability, the Server should operate using a standard, "well known" transport address. 4. A Server can operate using any transport address The Server should be able to operate with any defined address within the target transport environment. This will, of course, require that Clients know of and use the non-standard transport address. This requirement is called out so as to allow a Server to operate in an environment in which the standard transport address is already in use. This requirement should be considered optional for an implementation. 5. Minimal protocol data formatting requirements To maintain simplicity, the protocol data units (PDUs) should use displayable text strings for all data components rather than the equivalent binary forms. Using displayable text circumvents the incompatibilities between various network platforms and allows for simple implementation of Client applications. Since the number of PDUs exchanged between a Client and a Server is expected to be rather small, the resulting parsing of the data components by the Client and Server should not be considered a performance problem. 6. Multiple sources of events can be managed by a single Server A Server should be able to "front-end" any number of Event Sources. No minimum or maximum number of supported Event Sources should be required. 7. A Server can be queried to determine the set of event sources managed by the Server A Client should be able to request the list of Event Sources supported by the Server. The list should be formatted in displayable text. 8. A Server can be queried to determine its operational parameters A Client should be able to request a list of operational parameters and their values from the Server. The list should be formatted in displayable text. 9. A simple loopback capability to determine Server existence A Client should be able to "ping" the Server to determine whether the Server is operating at the target transport address. This requirement could be reasonably satisfied through the implementation of Requirement #8 above 10. A client dynamically registers for receipt of events from multiple event sources A Client should be able to dynamically request the creation of a Subscription from a Server, in which any number of Event Sources may be specified as being part of the Subscription. The Subscription request also includes a requested period of time for which the Subscription remains active; once this time period is exceeded, the Server automatically terminates the Subscription without further action by the Client. 11. A client specifies the network endpoint to which all Event Messages are directed When the Client requests the creation of a Subscription, part of the request includes the destination transport address (network address and transport port number) to which all Event Messages are delivered. 12. A client can cancel a subscription at any time A Client is free to prematurely cancel a Subscription (before the Subscription period runs out). 13. Event Messages are asynchronously transmitted by the Server to all registered clients when an event occurs The Server should send Event Messages to the network/transport address specified by the Client at Subscription request time as events occur. The Server will continue to periodically retransmit an Event Message until either the Server-defined retransmit time/count runs out, or until the Client acknowledges receipt of the event. 14. Clients acknowledge receipt of events A Client must acknowledge receipt of an Event Message from a Server. 15. The precise content and format of an Event Message is opaque relative to the underlying SENSE protocol The format and contents of an Event Message are (by definition) not defined within the SENSE specification; instead, the Client is expected to be intimately familiar with the format of such messages based on the associated Event Source. 16. A Server must be able to control resource consumption A key aspect of the SENSE facility is to be highly "Server-oriented" with respect to implementation and performance. In particular, the Server should be allowed to arbitrarily implement the values for such parameters as: Maximum number of Subscriptions Maximum Subscription period Maximum number of retries for delivery of event messages It is expected that the values of these parameters (and probably many others) will be part of the response to a request for a Server's operational parameters as described in Requirement #8 above. While not called out as a requirement in the above list, it is expected that the SENSE facility should be implemented for use with at least the following transports: - UDP/IP - IPX - AppleTalk DDP Other datagram-oriented transports are not necessarily precluded from implementation. Functional Model ---------------- A crude structural diagram that can be used to describe the desired functional model is shown below: Client -----| . | |--- Event Source . | | . . | | . Client -----+----- Server ---+--- Event Source . | | . . | | . . | |--- Event Source . | Client -----| This diagram describes the three primary interworking entities: Client Server Event Source The protocol used between the Client and the Server is expected to be defined for the SENSE facility. On the other hand, the protocol(s) between the Server and the Event Sources are not expected to be defined in the SENSE specification. Protocol Exchange Example ------------------------- Following is a rough protocol diagram describing the basic, error-free exchange between a Client and a Server whereby: o The Client registers a Subscription with the Server o The Server later sends Event Messages to the Client o The Client cancels the Subscription Client Server ------ ------ >---------- registration request ----------> <---------- registration reply ----------< . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . >---------- termination request ----------> <---------- termination reply ----------< # # # # # From jkm at underscore.com Fri Nov 7 23:45:39 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Comments needed on the Sense Requirements document In-Reply-To: Comments needed on the Sense Requirements document> Message-ID: <199711051349.AA05132@interlock2.lexmark.com> Dave, Thanks for your comments. I'd like to respond in detail. I'm sorry, but this is quite long, but it does serve to explain much of how we arrived at the current Sense reference design and implementation. ---------------------------------------------------------------------- > My list of requirements for an event notification service is a bit > shorter than the published SENSE requirements document. Part of > this is because I'm still trying to envision the abstract service, > and the SENSE requirements drill down much further. Perhaps more > importantly, it is also because I'm looking for a service that is > scalable from very simple implementations on up, and the SENSE > requirements focus on the high end. > > My starting point is the idea of a notification service that, at its > simplest, allows reliable, efficient event notification from an > agent to a client. In this form, the service should be very > lightweight to implement. On top of this, this basic service should > be designed so it can be used as a building block to construct large > scale services. And I think we should be able to do this in such a > way that the scaling is transparent to both agent and client. > > To be more specific, I'd like to see a simple agent/client service > that can also be rewired as an agent/proxy/client service without > change to the agent and client. Agreed. Couldn't state it better myself. To reach this, we must be aware--from the very start--of which aspects of scalability we need to address. I'd like to talk about Sense and scalability for a few moments. The first scalability issue we addressed was the maximum number of available TCP connections in small embedded agent environments; hence, the requirement for datagrams (UDP) over streams (TCP). The second scaling factor we recognized was number of maximum number of client "sessions" (or registrations) a single agent could be expected to handle. Again, embedded agents may only be able to support a relatively small number, quite possibly fewer than the number of clients expected to request services of the agent within an enterprise environment. However, we didn't want the client to have to deal with issues of agent limitations in this regard; hence, the early adoption of a 3-tiered model with a central Server, in which the Server could be easily run on scalable hardware (ie, a general host system, such as NT, Unix, NetWare, etc). That way, agents (called "Publishers" in Sense) can immediately be built with the up-front expectation of being small in terms of capacity for clients (called "Subscribers" in Sense). Of course, there is no reason why an embedded system can't function as both Server and Publisher (or multiple Publishers). The real value in the use and concept of the Server is to allow the CUSTOMER the ability to centralize potentially large numbers of printer definitions in a single service, allowing easier discovery by clients looking for those objects (printers). An implementation goal of Sense is to allow the implementer to easily choose the approach (Publisher only, or Server/Publisher) such that implementing the Server component was not an excessively large amount of effort over the simple Publisher-only side. Of course, the resource requirements would be quite a bit higher in the combined Server/Publisher case, but the additional code required would be modest. For scalability of implementation, we mandated the use of ANSI C and Berkeley (BSD) sockets as the *SOLE* underlying technology; the entire reference implementation has been coded with these constraints, with the hope that the code base could be easily adopted by embedded system developers, as well as host-based developers. This philosophy serves to support another key goal of Sense, namely, rapid and pervasive deployment--which may be viewed as "scalability of deployment". While we don't believe Sense has a high critical mass factor (ie, pervasive deployment is not necessary to gain substantial value from Sense), everyone stands to gain big time if it is integrated with most components of the enterprise network printing environment. It was always our hope that printer vendors would take the approach of only implementing the Publisher(s) within the printer's embedded environment, based on the notion that a public domain Sense Server would be available for public distribution (either bundled with the printer software, or available free on the Web). That way vendors could minimize their development time/cost to get into the Sense arena. ---------------------------------------------------------------------- > Now bear with me, because I'm not an expert in event notification > services (I just play one on mailing lists), but here's my edit on > requirements: > > A. Schema based > The idea being that there is an overall grouping of the > information for each class of event producer, much like a > directory entry schema. Yes, event sources (collections of events for which a client has interest) must have some kind of distinguished name space in which clients can query. The design does not address the "class of event producer" as you mention; rather it is defined in terms of "class of event" described in terms of: - Format (syntax) - Content (semantics) - Periodicity (frequency) An instance of an event class is called an "Edition" within Sense. Where the "Publication" would be used to model the target entity (for example, a printer), an "Edition" is used to model the source of a single defined event stream associated with a given Publication. Another key assumption made early on was that a "producer" could very easily produce multiple instances of various event classes. For example, the same producer (Publisher) might produce (publish) an event class (Edition) having to do with device faults (possibly geared around the Printer MIB), while at the same time publish an Edition emitting accounting or other resource usage records. This is why we derived the two-level "Publication/Edition" model. We figured a client had two primary discovery jobs: 1. Locate target objects (eg, printers) 2. Locate compatible event streams associated with the object (ie, event streams for which the client was able to process) I'd like to discuss the nature and motivation for the two-level Publication/Edition model in more detail in a future message, as this design approach still seems to confuse some folks. ---------------------------------------------------------------------- > B. Reliable receipt of event messages > I believe this implies client registration for notification (and > renewal and cancellation), client acknowledgement of receipt, > and retransmission by the agent. > > C. Efficient delivery of event messages > I believe this implies client registration, asynchronous > delivery of messages by the agent. Agreed. Again, these features might be a bit much to support large numbers of clients within an embedded application. That is why we felt it necessary to provide a scalable Server component to support large numbers of clients--and therefore ease the burden of both the vendor and the customer. ---------------------------------------------------------------------- > D. Allows lightweight implementation > (Okay, I'm going to drill down a little here.) I believe this > means the agent gets to decide the contents of messages (i.e. > the basic agent is not required to do client-specified > filtering) Exactly. Again, couldn't agree with you more. As I mentioned in Boulder, we explored the rather traditional avenue of "event filter specifications" and quickly came away with the same opinion. Allow the agent (the producer, or Publisher) to dictate the set of events delivered to interested clients (ie, Subscribers); then, let the client perform filtering as needed. While this approach does not fully optimize network bandwidth, we feel the overall Sense specification would be quite a bit simpler without introducing an event filter specifications. Such specifications often result in the development of full-blown languages in their own right, and this was seen as a potentially large barrier to entry for developers. Letting the agent (Publisher) side dicate the granularity and number of event streams (Editions) was considered as an adequate compromise between resource efficiency and simplicity. I realize, though, that some may argue the opposite (and quite vigorously, too ;-). So far, though, in our many client implementations, there doesn't seem to be a lot of "content fat" in taking this approach. That is, a client rarely disregards events from subscribed Editions. ---------------------------------------------------------------------- > E. Scalability > I believe the way to do this is by introducing proxy servers, > so the basic protocol needs to be able to deal with the issues > involved in ensuring the liveness of copied data. This is precisely why the "Server" is so clearly defined as being separate from the "Publisher" in the Sense spec, to be able to handle "proxy-like" capabilities on behalf of potentially large numbers of Publishers. As I described in Boulder, Sense is defined to provide a degree of "disconnected service", whereby a client can obtain information about the target object without necessitating involvement with the object's "agent" (particularly important for embedded agents). (This same concept is embodied in the DMI specification, too.) Publications (and Editions, for that matter) possess a number of standard properties that allow a client to easily determine whether a Publisher is currently "live", as well as the last time the Publication or Edition was updated by its corresponding Publisher. ---------------------------------------------------------------------- > (Drilling down again; revisiting message filtering.) I wonder > if a notion of message schema variants might provide an > alternative to client-defined message filtering. The idea being > that an agent (proxy, in particular) might define and deliver > "subset" variants in addition to the full message; by selecting > a variant, a client could reduce the number of irrelevant > notifications it received. The "message schema variants" are represented as Editions of different classes, where the classes are defined in a hierarchical name space. For example, a Publisher may provide an Edition that emits "device alerts", where the device alerts all have the same format (syntax); this Edition might have the class named: DeviceAlerts The Publisher may also provide a number of Editions that represent content subsets of device alerts; for example, to differentiate "service alerts" from, say, "consumables alerts". In this case, the Edition classes might be named: DeviceAlerts.Consumables DeviceAlerts.FieldService Our goal was to be able to provide for this kind of granularity for various event types and environments. ---------------------------------------------------------------------- > F. Client discovery of services > The client needs to be able to query an agent to determine > available event notification services, message schemas, and so > forth. Yes, some sort of simple directory service is needed to query the supported services. This is a primary role of the Server; the Publisher, on the other hand, has no need to support such a directory service, thereby simplifying the design and implementation of the Publisher. ---------------------------------------------------------------------- > The client also needs to be able to locate agents, and locating > proxy agents should be a natural part of the service. A motivating reason for the Server was to provide a large repository of information, making it easier for the client (Subscriber) to locate interesting objects (Publications and Editions), and to be able to support a large number of Publishers. However, as I mentioned in Boulder, we expressly ignored requirements for locating Sense Servers. It was our hope that the scalability of the Server would allow a customer to maintain a very small number of Servers--quite possibly only a single Server--thereby making the Server discovery process trivial. (For example, the addresses of known Servers would be stored in well-known files or system registry entries, based on the underlying server host's architecture, etc.) ---------------------------------------------------------------------- > G. Leverages existing technology > (I'm on thin ice here.) To me, this all looks very much like a > read-only dynamic directory service, and I wonder if we can't > model it as a variant on LDAP. (Rationale similar to that for > basing IPP on HTTP.) > > There is (was?) an internet draft, LDAP: Extensions for Dynamic > Directory Services (draft-ietf-asid-ldapv3ext-02), authored by > Yaacovi, Settle, and Genovese of Microsoft, and Wahl of Critical > Angle, that might be relevant, although I have no idea of its > current status or support. Also, the roles it specifies for > clients and servers don't seem to map directly to what is needed > here. Ah yes, why not LDAP? And why not Windows/NT registry? And let's not forget Novell's NDS. And so on, and so on... We have always been in favor of leveraging existing technology...with one small requirement, though: The leveraged technology must be pervasively available, ideally being part and parcel (ie, integrated AND bundled) with the underlying operating system such that *everyone* has the same basic (useful) set of services. when Unixdom, Redmond and Provo come together and offer the world consistent, interoperable directory services. And that day will be at least ten years BEFORE those same players provide consistent, interoperable object services...such as seen in the everlasting CORBA vs. DCOM battle. And while not as formidable, we really question how quickly such standard implementations of Agent-X and SNMPv3 will be readily available such that printer and software vendors can safely rely on their existence within the typical customer environment. We don't get good vibes on this being likely in the near future, either. We certainly wish this wasn't the case, believe me. But I digress... This topic is worth of a separate thread on the Sense mailing list: "How long to wait for unified services?" ---------------------------------------------------------------------- > I. Security, passage through firewalls > No bright ideas here, but these issues need answers. An ugly > but practial approach might be some combination of polling and > encapsulation of information over HTTP for remote notification. Oh, now you had to go and use that "F" word: firewall Sense has been designed from day #1 as an intranet (ie, enterprise) facility. While I'm not saying it can't be used across firewalls-- after all, all one has to do is poke another well-defined hole in the firewall, if necessary--we just didn't address it. Given the trials and tribulations in IPP, perhaps now everyone can see why we chose to avoid this particular topic. We can talk about it, but it's not going to be easy to solve in a generic way. And we are *loath* to hold up the rest of Sense just because it doesn't stand up to "firewall standards" (whatever those are). ---------------------------------------------------------------------- > Overall, I'd say these requirements look a lot like the existing > SENSE requirements. Perhaps the biggest difference is that I would > like to align with services that have evolved since the design of > SENSE -- for both engineering and "mind share" reasons. I beg everyone to seriously consider my previous comments regarding the need for pervasive deployment of required underlying technology. If we can demonstrate a real, workable turnkey implementation that satisfies all the specified requirements, then we should run with it, even if it doesn't require all the many pieces of "standard" service technology that are expected to be aligned and available by the year 2014. Later, when all the "real" and "long-term" component solutions become commonly available, we can alter Sense to take advantage of them. However, if we feel we must wait for such technology to come into existence, then we might as well put Sense on the shelf for several years to come. Our reference implementation has shown that we don't have to wait. It's here now, and it appears to work. And, it can be shown to be easily portable across all the major server environments...with no special software components required (since all servers now have IP stacks, thank heavens). ---------------------------------------------------------------------- > Key issues that I think need to be revisited include: > > A. Delivery mechanism > The datagram-based delivery is lightweight (a big advantage), > but it has size limits and security and firewall problems. Is > there a better choice? Are you still of the mind that "size matters"? ;-) Seriously, we put a big stake in the ground by saying we would accept the limitation that any single Sense message (in particular, an event message) was limited to size of a single UDP packet (8KB). In all the many events generated within our reference Publishers (including an RFC 1759 Publisher), the UDP size limit has rarely been found to be a problem, even with a Server providing access to as many as 800 printers. > B. Message format > SENSE tries to be content neutral; I'd nail this down more. And > of course schemas need to be defined for specific classes of > event producers. Absolutely. We have some proposals on the table (for which we have since implemented), but the number of definitions is boundless, limited only by the time we need to agree on their definitions. (Yes, much like a MIB, but hopefully less daunting.) Hope all of this spawns some serious questions and discussions. ...jay PS: Security? Did someone mention security?? Yet another topic... ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From hastings at cp10.es.xerox.com Fri Nov 14 15:11:36 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review In-Reply-To: <3462115C.657968C9@underscore.com> Message-ID: <3.0.1.32.19971114121136.0107fb10@garfield> At 10:50 11/06/1997 PST, Jay Martin wrote: >> 4. (#14) Client ACK of event. I'm not sure this should be required in all >> cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate (#16) - >> server resource management. The server can really bloat while waiting for ACKs >> from clients who disappear etc. It is feasible to consider an "unreliable" mode >> of operation. > >Excellent observation, Harry. We, too, have found that an "unreliable mode" >is certainly viable in certain environments. This shouldn't be too hard to >add to Sense. Do others have any comments on this addition? > >Right off the top of my head, I'd say that the subscription request would be >defined to have one or more message properties indicating the level of reliability >for events delivered for that subscription. > >The client API in the current implementation actually supports the kinds of >reliability controls you mention. However, these controls are used across the >client session and can not be altered on a per-subscription basis. Perhaps such >session-wide controls are enough for you, though. I agree that the subscriber should be able to indicate whether he/she want reliable or unreliable. (It shouldn't be a propertly that only the publisher sets.) I thought that there was a property in the edition that specified the number of re-tries before giving up. Since there must be a separate counter for each subscriber to keep track of how many retries have been made, couldn't the subscriber also specify the number of retries when subscribing? A value of 1 would mean unrealiable. >> 5. (not addressed) The requirements do not appear to directly address the need >> for filtering. I know the requirements do not address data content and it could >> be argued this is where this topic belongs, but I think filters are significant >> to any event based scheme and should at least be mentioned. I also acknowledge >> that filtering is exactly one of the reasons the current SENSE architecture may >> appear somewhat less than simple (my comment 2, above). > >Ah yes, filters. As I described in Boulder last week, filters, or more precisely, >filter specifications, are one of the primary reasons we conceived of the notion >of an "Edition". Filter specifications can get very, VERY ugly, and before you >know it, you often end up designing an entire "language" to deal with that. > >This is something we at Underscore desparately wanted to avoid. I'll address >that issue in more detail in a later message. However, for now, suffice to >say that a requirement exists for a client to be able to specify receipt of only >a subset of all events that may be available from a given source. Exactly how >that "subset" is defined and handled is a topic for design and implementation, >IMHO. Yes, allow the subscriber to specify a simple subset of the 6 defined events (actually only 4, because 'all' and 'none' are really separate events). In IPP, we defined the following set of events and allowed the client to specify any combination of them. That doesn't sound too difficult. Part of a publication should be a single property which is the names of the set of possible events. The subscriber specifies a property which is a subset of that publication property. Here is the following text from the 10/14/97 Model draft (that was subsequently deleted because of a lack of a transport for the events). 4.2.2 notify-events (1setOf type2 keyword) This attribute specifies the events for which the end user desires some sort of notification. The "notify-addresses" attribute is used to describe the destination addresses for these events. Standard values are: 'none': the Printer SHALL not notify. 'all': the Printer SHALL notify when any of the events occur. 'job-completion': the Printer SHALL notify when the job containing this value completes (i.e., enters the 'completed', 'canceled', or 'aborted' state) with or without errors. 'job-problems': the Printer SHALL notify when this job has a problem (i.e., when the job leaves the 'processing' state and enters the 'processing-stopped' state). 'job-started-processing': the Printer SHALL notify when the Printer starts processing the Job (i.e., when the job leaves the 'pending' state and enters the 'processing' state). 'printer-problems': the Printer SHALL notify when this job is affected by a Printer problem. This happens when the printer enters the 'stopped' state while this job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' state. In a create request, if the client supplies 'none' along with any other combination of values, it is the same as if only that other set of values had been supplied (that is 'none' has no affect). If the client supplies 'all' along with any other combination of values, it is the same as if only 'all' had been supplied (that is 'all' subsumes all other values). > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From jkm at underscore.com Sat Nov 15 17:01:56 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review In-Reply-To: SENSE Req review> Message-ID: <3.0.1.32.19971114121136.0107fb10@garfield> Tom Hastings wrote: > I agree that the subscriber should be able to indicate whether he/she > want reliable or unreliable. (It shouldn't be a propertly that only > the publisher sets.) I agree 100%. No issue here. > I thought that there was a property in the edition that specified the > number of re-tries before giving up. Since there must be a separate > counter for each subscriber to keep track of how many retries have been > made, couldn't the subscriber also specify the number of retries when > subscribing? No, there is no "retry" property in an Edition. Retries are handled at the client level; that is, during client registration and potentially at per-Edition subscription time. In other words, I believe Sense is already designed to handle what you'd like to see, and if there are any holes remaining, we can certainly fill them using the kind of approach you and Harry have suggested. No issue here. > A value of 1 would mean unrealiable. Actually, I'd suggest a value of 0 to indicate "no retries" (ie, a retry count of zero). Seems to be more elegant and useful, no? To make this message a bit more readable, I have included the rest of your message (with Harry's and my embedded comments) at the end of this message. Following are my comments to that text. First, I think we're pretty much in agreement with the basic Edition- oriented philosophy that precludes the need for extensive filter specification, etc. (I realize Harry may not agree with this.) As you mention, the prior established specifications for IPP job- related events reception by a client are: none all job-completion job-problems job-started-processing printer-problems Of course, in the case of Sense, the "none" case is not relevant; the Subscriber client simply does not subscribe to any of the associated Editions. Separate Editions can be designed for the remaining types, though. To keep life simple, it would be best for us to focus on the "all" case, since I honestly believe this specification will be used by most clients. (Agreed?) What we need to do then is: 1) Name the Edition. Something like "IPP.Job.AllEvents" would follow what we have done in the Printer MIB area, but this choice is obviously quite arbitrary. What can be important, though, is the left-to-right dotted-string convention for naming things in a rough hierarchical manner. 2) Define the Event message format. A standard Edition property (Edition.Protocol) is used for this purpose. Again, there is tremendous leeway in defining the message format. At Underscore we spent quite a bit of time trying to come up with a generic event format mechanism that can work for many, many different kinds of event scenarios. We call this the "Simple Text Event Protocol, Type 1" (STEP.1), and documentation exists on the PWG Sense area describing this format and how it's used. We can take a crack at defining IPP Job messages using STEP.1, or devise and entirely different method. Makes no difference to us. One of the beauties of Sense is that it is defined to allow the existence of parallel Editions, where the same content and semantics is provided, but the format differs (for whatever programmatic reasons that might exist). 3) Defined the exact contents of the message (independent of the wire protocol, or "format" as I have referred previously). Here we have a pretty simple task, since we should merely leverage the data and format as (previously) defined in the IPP Model document. What I'd like to instill at this point is that defining an "Edition" (or multiple Editions) for IPP Job events is pretty trivial...assuming that you buy into the Sense architecture as currently defined. We must first get the architecture right before spending time on more concrete applications of Sense. Hopefully folks can see how easy it would be to define all kinds of Sense Editions for IPP-related events, but first we need to all agree on the actual architecture. Agreeing on the Sense architecture is what I hope to accomplish at the upcoming LA meeting next month. Assuming, of course, that more input/comments/etc are received on the Sense DL before the end of next week. ...jay PS: To help folks visualize things a bit bettter, here is the full contents of an Edition providing all device events for a printer based on the Printer MIB: Edition.ClientId = 6 Edition.Content = AllDeviceEvents Edition.Protocol = STEP.1 Edition.Publication = printer/digital/lps/17|dorky|underscore.com Id.Class = app/underscore/pa/publisher/sfplps/editions/step.1/AllDeviceEvents Id.Client = 6 Id.Contact = Id.Description = All printer device events Id.Domain = underscore.com Id.Host.Name = uscore Id.Id = 10 Id.Manufacturer = Underscore, Inc. Id.Name = dorky Id.Product = PrintAlert Id.SenseVersion = 1.0 Id.Signature = Id.Updated = 878572337 Id.URL = http://www.underscore.com/products/pa/publishers/sfplps.html Id.Version = $Id: .edition 1.1 1997/01/17 09:52:02 jkm Exp $ ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Additional comments from Tom/Harry on message filters and IPP job events: > >> 5. (not addressed) The requirements do not appear to directly address > the need > >> for filtering. I know the requirements do not address data content and > it could > >> be argued this is where this topic belongs, but I think filters are > significant > >> to any event based scheme and should at least be mentioned. I also > acknowledge > >> that filtering is exactly one of the reasons the current SENSE > architecture may > >> appear somewhat less than simple (my comment 2, above). > > > >Ah yes, filters. As I described in Boulder last week, filters, or more > precisely, > >filter specifications, are one of the primary reasons we conceived of the > notion > >of an "Edition". Filter specifications can get very, VERY ugly, and > before you > >know it, you often end up designing an entire "language" to deal with that. > > > >This is something we at Underscore desparately wanted to avoid. I'll address > >that issue in more detail in a later message. However, for now, suffice to > >say that a requirement exists for a client to be able to specify receipt > of only > >a subset of all events that may be available from a given source. Exactly > how > >that "subset" is defined and handled is a topic for design and > implementation, > >IMHO. > > Yes, allow the subscriber to specify a simple subset of the 6 defined > events (actually only 4, because 'all' and 'none' are really separate > events). > > In IPP, we defined the following set of events and allowed the client > to specify any combination of them. That doesn't sound too difficult. > > Part of a publication should be a single property which is the names of > the set of possible events. The subscriber specifies a property which is a > subset of that publication property. > > Here is the following text from the 10/14/97 Model draft (that was > subsequently deleted because of a lack of a transport for the events). > > 4.2.2 notify-events (1setOf type2 keyword) > > This attribute specifies the events for which the end user desires some > sort of notification. The "notify-addresses" attribute is used to describe > the destination addresses for these events. > > Standard values are: > > 'none': the Printer SHALL not notify. > > 'all': the Printer SHALL notify when any of the events occur. > > 'job-completion': the Printer SHALL notify when the job containing this > value completes (i.e., enters the 'completed', 'canceled', or 'aborted' > state) with or without errors. > > 'job-problems': the Printer SHALL notify when this job has a problem > (i.e., when the job leaves the 'processing' state and enters the > 'processing-stopped' state). > > 'job-started-processing': the Printer SHALL notify when the Printer starts > processing the Job (i.e., when the job leaves the 'pending' state and > enters the 'processing' state). > > 'printer-problems': the Printer SHALL notify when this job is affected by a > Printer problem. This happens when the printer enters the 'stopped' state > while this job is in the 'pending', 'pending-held', 'processing', or > 'processing-stopped' state. > > In a create request, if the client supplies 'none' along with any other > combination of values, it is the same as if only that other set of values > had been supplied (that is 'none' has no affect). If the client supplies > 'all' along with any other combination of values, it is the same as if only > 'all' had been supplied (that is 'all' subsumes all other values). From hastings at cp10.es.xerox.com Tue Nov 18 14:08:28 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review In-Reply-To: <346E1BD4.86C1D8E7@underscore.com> Message-ID: <3.0.1.32.19971118110828.00f5d630@garfield> At 14:01 11/15/1997 PST, Jay Martin wrote: >Tom Hastings wrote: > snip... >In other words, I believe Sense is already designed to handle what >you'd like to see, and if there are any holes remaining, we can >certainly fill them using the kind of approach you and Harry have >suggested. No issue here. > > >> A value of 1 would mean unrealiable. > >Actually, I'd suggest a value of 0 to indicate "no retries" (ie, a >retry count of zero). Seems to be more elegant and useful, no? I agree. Its a retry count, so 0 means no retries. snip... >As you mention, the prior established specifications for IPP job- >related events reception by a client are: > > none > all > job-completion > job-problems > job-started-processing > printer-problems > >Of course, in the case of Sense, the "none" case is not relevant; >the Subscriber client simply does not subscribe to any of the >associated Editions. > >Separate Editions can be designed for the remaining types, though. >To keep life simple, it would be best for us to focus on the "all" >case, since I honestly believe this specification will be used by >most clients. (Agreed?) > >What we need to do then is: > > 1) Name the Edition. Something like "IPP.Job.AllEvents" would > follow what we have done in the Printer MIB area, but this > choice is obviously quite arbitrary. What can be important, > though, is the left-to-right dotted-string convention for > naming things in a rough hierarchical manner. While "all" might be the most used, it depends on the operator coverage of the printer and whether the user likes lots of notifications or not. For printers that have operator coverage, only getting "job-completion" would be most used. I also found the "job-started-processing" event annoying, though some like it a lot. It depends on whether the print system responds in the create job response with whether the job was started or is pending. If the print system does (and VMS did), and for printers that are often idle (10% duty cycle), just knowing that the printer was idle when the job was submitted is better than being notified asynchronously (usually almost immediately) that the job has just started. In other words, I belive that which of the above combinations of events is very much a user preference issue. Does SENSE have any problems with allowing users to choose any combination? Does allowing users to choose mean that there has to be combinations of editions for each combination, each with a different name? Is this a problem to have to have so many combinations? If yes, then I'd like to see if we can fix SENSE architecture so that the SENSE server does a minimal amount of filtering as stored with the subscription. The publication lists what are the (short) list of event groups and the subscription says which event groups are wanted. The SENSE server ignores sending notifications to subscribers that do not have the indicated event group in their subscription. Would this be feasible? Tom snip... From lstein at fapo.com Thu Nov 20 15:26:58 1997 From: lstein at fapo.com (Larry Stein) Date: Wed May 6 14:04:25 2009 Subject: SENSE> January Meeting Notice Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From jkm at underscore.com Fri Nov 21 11:47:39 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:25 2009 Subject: SENSE> SENSE Req review In-Reply-To: SENSE Req review> Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> This is a multi-part message in MIME format. --------------CD7E0C95A648CCB8D73548E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom, > In other words, I belive that which of the above combinations of events > is very much a user preference issue. Does SENSE have any problems > with allowing users to choose any combination? Does allowing users to > choose mean that there has to be combinations of editions for each > combination, each with a different name? Is this a problem to have > to have so many combinations? > > If yes, then I'd like to see if we can fix SENSE architecture > so that the SENSE server does a minimal amount of filtering as stored > with the subscription. The publication lists what are the (short) list > of event groups and the subscription says which event groups are wanted. > The SENSE server ignores sending notifications to subscribers that > do not have the indicated event group in their subscription. As I have stated many times, I am very much against the specification and implementation of event filter specifications in Sense, due to the fact that such filter specifications typically turn into a full- blown language...with all the attendant nightmares that go with it. We tried to strike a balance between simplicity and flexibility in providing sets of events via the concept of "Editions". The producer (ie, Publisher) defines event sets and publishes Editions to represent those event sets. The client then subscribes to the event sets of interest; when an event arrives for a given subscribed Edition, the client decides whether the event is "of interest" (ie, filters the event) and handles it accordingly. I am very much against the notion of having the protocol/system design provide Nth-degree filtering. While such filtering can definitely improve network performance, it comes at a considerable system design and implementation cost. We explicitly took the path of "reasonable compromise" in that event sets are segregated (using Editions), but the client performs local filtering as desired by the user. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------CD7E0C95A648CCB8D73548E9 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by uscore.underscore.com (8.8.4/8.7.2) with SMTP id RAA10158 for ; Tue, 18 Nov 1997 17:11:20 -0500 (EST) Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <56847(1)>; Tue, 18 Nov 1997 11:22:48 PST Received: from garfield.cp10.es.xerox.com by norman.cp10.es.xerox.com (4.1/SMI-4.1) id AA23312; Tue, 18 Nov 97 11:03:18 PST Received: from dellxpi-11 (dellxpi-11 [13.240.120.138]) by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id LAA03949; Tue, 18 Nov 1997 11:00:05 -0800 (PST) Message-Id: <3.0.1.32.19971118110828.00f5d630@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 18 Nov 1997 11:08:28 PST To: Jay Martin From: Tom Hastings Subject: Re: SENSE> SENSE Req review Cc: Harry Lewis , sense@pwg.org In-Reply-To: <346E1BD4.86C1D8E7@underscore.com> References: <5030300013707863000002L032*@MHS> <3.0.1.32.19971114121136.0107fb10@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 14:01 11/15/1997 PST, Jay Martin wrote: >Tom Hastings wrote: > snip... >In other words, I believe Sense is already designed to handle what >you'd like to see, and if there are any holes remaining, we can >certainly fill them using the kind of approach you and Harry have >suggested. No issue here. > > >> A value of 1 would mean unrealiable. > >Actually, I'd suggest a value of 0 to indicate "no retries" (ie, a >retry count of zero). Seems to be more elegant and useful, no? I agree. Its a retry count, so 0 means no retries. snip... >As you mention, the prior established specifications for IPP job- >related events reception by a client are: > > none > all > job-completion > job-problems > job-started-processing > printer-problems > >Of course, in the case of Sense, the "none" case is not relevant; >the Subscriber client simply does not subscribe to any of the >associated Editions. > >Separate Editions can be designed for the remaining types, though. >To keep life simple, it would be best for us to focus on the "all" >case, since I honestly believe this specification will be used by >most clients. (Agreed?) > >What we need to do then is: > > 1) Name the Edition. Something like "IPP.Job.AllEvents" would > follow what we have done in the Printer MIB area, but this > choice is obviously quite arbitrary. What can be important, > though, is the left-to-right dotted-string convention for > naming things in a rough hierarchical manner. While "all" might be the most used, it depends on the operator coverage of the printer and whether the user likes lots of notifications or not. For printers that have operator coverage, only getting "job-completion" would be most used. I also found the "job-started-processing" event annoying, though some like it a lot. It depends on whether the print system responds in the create job response with whether the job was started or is pending. If the print system does (and VMS did), and for printers that are often idle (10% duty cycle), just knowing that the printer was idle when the job was submitted is better than being notified asynchronously (usually almost immediately) that the job has just started. In other words, I belive that which of the above combinations of events is very much a user preference issue. Does SENSE have any problems with allowing users to choose any combination? Does allowing users to choose mean that there has to be combinations of editions for each combination, each with a different name? Is this a problem to have to have so many combinations? If yes, then I'd like to see if we can fix SENSE architecture so that the SENSE server does a minimal amount of filtering as stored with the subscription. The publication lists what are the (short) list of event groups and the subscription says which event groups are wanted. The SENSE server ignores sending notifications to subscribers that do not have the indicated event group in their subscription. Would this be feasible? Tom snip... --------------CD7E0C95A648CCB8D73548E9-- From jkm at underscore.com Mon Nov 24 11:32:11 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: LA Meeting In-Reply-To: Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> Don, Well, it's now looking like I won't be able to attend the LA meetings afterall, so there will be no Sense meeting in December. I'll let Ron, Harry and Carl-Uno "fight" over the extra time slot that's now available on Thursday... ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From rbergma at dpc.com Mon Nov 24 12:02:42 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:04:26 2009 Subject: SENSE> SENSE Req review In-Reply-To: <3475DD8D.F11F58AA@underscore.com> Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> I certainly agree with Jay regarding the use of filters with SENSE. It should be possible to define a limited set of "Editions" that contain a minimal amount of information that is not normally required. For example, when a user submits a print job he would like... 1. to be informed of any problems within the printer from the time the job is submitted, until the job has completed. If the problem occurs before the job starts, the user most likely would like to be informed so he could take action to correct the problem. If he doesn't care, he most likely does not want any job monitoring information or can simply filter this information locally. 2. when his job has started. 3. progress of his job while printing. 4. when his job has completed. By filtering locally, the user application does not have to worry about finding the correct "edition" and the SENSE "publisher" only has to create one "edition" for the job. I cannot see where this configuration is more complex or less ideal than performing the filtering on the SENSE server. Other than some additional network traffic, which should be minor, I cannot think of any other disadvantages. Adding filters to the SENSE server for the few cases where the user does not want the "complete package" does not appear to justify the added complexity for the "publisher". My guess is that in most cases where a user does not want to know everything, he will ask for everthing and just ignore what he doesn't care about. Ron Bergman Dataproducts Corp. On Fri, 21 Nov 1997, Jay Martin wrote: > First, does anyone else on the Sense DL have any comments on this > topic? > > I don't want this thread to degenerate down to just Tom Hastings > and myself. Longstanding PWG participants know that Tom and I are > always at the opposite ends of the spectrum in defining things > (whatever the topic is), and I feel this discussion is going nowhere > fast without others' opinions. > > Tom, regarding some of your statements: > > > What we keep trying to tell you is not to be afraid of simple filters. > > I agree with you that filters can get out of hand. But for IPP > > for end-users monitoring their jobs and/or the printers to which they > > have sent jobs, the filter mechanism is just four bits. > > If Sense is only for IPP--and it damn well better NOT be--then sure, > anyone can whip up some simple solution and get it out the door > tomorrow. > > But Sense started off as a means to handle a *wide* variety of > events, with particular attention to the needs of network printers. > But not ONLY printers, since other system-related events would > also be desired (such as Job events, Queue events, etc.) > > > > I repeat the simple IPP requirements (which seem to keep getting deleted): > > > > Allow the subscriber to specify a simple subset of the 6 defined IPP > > event groups (actually only 4, because 'all' and 'none' are really NOT > > separate events). > > Ok, let's take a look at the set of "event classes" as currently > defined in IPP: > > > Standard values are: > > > > 'none': the Printer SHALL not notify. > > > > 'all': the Printer SHALL notify when any of the events occur. > > > > 'job-completion': the Printer SHALL notify when the job containing this > > value completes (i.e., enters the 'completed', 'canceled', or 'aborted' > > state) with or without errors. > > > > 'job-problems': the Printer SHALL notify when this job has a problem > > (i.e., when the job leaves the 'processing' state and enters the > > 'processing-stopped' state). > > > > 'job-started-processing': the Printer SHALL notify when the Printer starts > > processing the Job (i.e., when the job leaves the 'pending' state and > > enters the 'processing' state). > > > > 'printer-problems': the Printer SHALL notify when this job is affected by a > > Printer problem. This happens when the printer enters the 'stopped' state > > while this job is in the 'pending', 'pending-held', 'processing', or > > 'processing-stopped' state. > > Tom, here's where you and I *always* tend to disagree. You stated > previously (in a prior posting) that a user demands *infinite* > flexibility in selecting which event classes to monitor. > > I ask you: in REALITY, how many combinations are really viable here? > > Here are some highly suspicious selections, ones that I don't > think are desired by anyone: > > a) Only "job-started-processing" events. (Yeah, sure.) > > b) Only "printer-problems" events. Why you would be using IPP > to monitor printer problems is beyond me. Sure, it can be done, > but DON'T FORGET THAT THIS FACILITY IS ASSOCIATED WITH AN > EXISTING JOB, and not some general-purpose printer-specific > problem reporting mechanism. > > I'll stop right there. You see, when you talk about IPP events, > they are defined in terms of EXISTING jobs, and not some generic > "IPP printer" environment. By definition (and I think you forget > this), IPP only gives you events after you've registered for them > as part of a job submission. Am I wrong here? > > I'm going to bet that there are only two combinations of event > classes that user's will consistently use: > > a) Give me all events, I'm a control freak > > b) Give me all events EXCEPT job-started-processing, since > I'm not interested in intermediate events, only final > events > > Sure, some could argue for a couple more combinations. But that's > just it--only a couple more. Not 14 more to provide all possible > combinations. > > Proposing that a N-way set of combinations is required is > ridiculous, IMHO, and makes me think you haven't really given > much thought about real world scenarios. > > I'd really like to see some comments from others--either PRO or > CON--before continuing this discussion. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From jkm at underscore.com Mon Nov 24 12:17:51 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com> I've given a lot more thought to the notion of client-side specification of event filtering for a given Edition, based on the recent thread between Tom Hastings and myself. I guess I can support the notion of lightweight event filtering (done by the Server, based on the client spec at the time of subscription to an Edition), as long as we keep it *simple*. Here's what I propose: a) A new standard Edition property called "Event.Classes" is defined, where the value consists of one or more named event classes supported by the Publisher. The Publisher alone controls the names of those event classes. b) A client MAY specify Server-side event filtering by adding a new message property called "Event.Classes" in the subscription request, where the value of the property is a set of named event classes; if this property is not present or has a null value, it implies the client desires to subscribe to all event classes that may be supported by the Publisher of the target Edition. (In effect, this is how the current Sense implementation works, although it should be mentioned that backward compatibility is not essential from my perspective). c) Upon issuing an event message to the Server, a Publisher MAY include the "Event.Class" message property signifying the event classes associated with the event. If this message property is not specified in the event message, then it is assumed the event is related to all event classes supported by the Publisher for that Edition (again, this how Sense currently works). d) Upon receiving an event message from a Publisher for an Edition, the Server will forward copies of the event message to all Subscribers if their subscriptions included the specifically named event class that matches that provided by the Publisher in the event message. If no Event.Class message property exists in the event message, or if the value of that property is null, then the Server will forward a copy of the event message to all Subscribers having specified the equivalent of "all" at the time of subscription. e) A Subscriber may alter its desired set of event classes for an existing subscription by sending another Subscribe request, in which the contents of the subscription contain a new value for the Event.Classes message property. The Server, upon realizing that the client is already a Subscriber to the target Edition, will update the current subscription such that the new Event.Classes property value overwrites the previous value. If the Event.Classes property is not present or null in the new Subscribe request, the Server assumes the client desires to subscribe to all event classes defined in the Edition. Now, using IPP as a target concrete example, I would propose that an Edition used to provide IPP job events could be defined to have one or more of the following named event classes as the value of the Edition's Event.Classes property: job-completion job-problems job-started-processing printer-problems A null (or missing) Event.Classes property implies all known IPP events are supported as defined for the Edition (whatever that may be). For example, let's say an IPP Printer Publisher has defined an Edition that provides some--but not all--of the currently defined set of IPP job events: Event.Classes=job-completion,job-problems,job-started-processing If a client desired to subscribe to that Edition, but only wanted those events pertaining to the completion of jobs, then the client would send a Subscribe request that included the following message property: Event.Classes=job-completion If the Publisher then issues an event where the message includes the following message property, then the Subscriber would receive a copy of the event: Event.Classes=job-completion If the Publisher issues an event with the following message property, then the Subscriber would NOT get a copy of the event, since the Subscriber did not specify the equivalent of "all" when subscribing to the Edition: Event.Classes= (That is, the value of the "Event.Classes" message property in the event message is null, or perhaps missing.) What do folks think about this proposal? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From cmanros at cp10.es.xerox.com Sun Nov 2 05:38:13 1997 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: LA Meeting In-Reply-To: <3479AC0B.8DC74458@underscore.com> Message-ID: <3.0.1.32.19971102023813.00cf05e0@garfield> Wow, Talking about an ungrateful job to try to host this meeting. I do not see any chance to now take advantage of the extra day for IPP, it is too late. I already have another commitment for Thursday. Carl-Uno At 08:32 AM 11/24/97 PST, Jay Martin wrote: >Don, > >Well, it's now looking like I won't be able to attend the LA meetings >afterall, so there will be no Sense meeting in December. > >I'll let Ron, Harry and Carl-Uno "fight" over the extra time slot >that's now available on Thursday... ;-) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jkm at underscore.com Mon Nov 24 14:16:26 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: LA Meeting In-Reply-To: Re: LA Meeting> Message-ID: <3.0.1.32.19971102023813.00cf05e0@garfield> Carl-Uno, > Talking about an ungrateful job to try to host this meeting. > I do not see any chance to now take advantage of the extra day > for IPP, it is too late. I already have another commitment for Thursday. Don't worry. I'm sure either Ron or Harry will be more than happy to take the time for JMP and/or FIN. It's always been that way in the past. But you're right--hosting the PWG meetings is a thankless job. Welcome to the club! ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From rbergma at dpc.com Mon Nov 24 15:02:36 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: LA Meeting In-Reply-To: <3479D28A.7082DAA5@underscore.com> Message-ID: <3.0.1.32.19971102023813.00cf05e0@garfield> Jay, Sorry to hear that you cannot attend the meeting. I was looking forward to a productive discussion on SENSE and a follow-on to the JMP calls last week concerning jmJobSubmissionId. I hope David Kellerman will be able to attend! You are correct, though, if IPP does not use the time, it can certainly be put to good use for JMP and FIN. We should be able to complete the open issues on JMP and get a good start on the Finisher MIB. May I suggest Thursday for FIN and Friday for JMP? Ron Bergman Dataproducts Corp. On Mon, 24 Nov 1997, Jay Martin wrote: > Carl-Uno, > > > Talking about an ungrateful job to try to host this meeting. > > I do not see any chance to now take advantage of the extra day > > for IPP, it is too late. I already have another commitment for Thursday. > > Don't worry. I'm sure either Ron or Harry will be more than happy > to take the time for JMP and/or FIN. It's always been that way in > the past. > > But you're right--hosting the PWG meetings is a thankless job. > Welcome to the club! > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From don at lexmark.com Mon Nov 24 15:59:11 1997 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:26 2009 Subject: SENSE> LA Schedule Message-ID: <199711242107.AA29754@interlock2.lexmark.com> Given that Jay will not be able to attend the LA meeting, the following is the schedule for the week. Changes are only to Thursday and Friday. Mon/Tues 1394 Printing Wednesday IPP Thursday Finisher MIB Friday Job MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Mon Dec 1 10:40:35 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering In-Reply-To: <3479B6BF.6D1AEE5A@underscore.com> Message-ID: <3.0.1.32.19971201074035.01113bb0@garfield> Perfect! Great for IPP and any other application. Tom At 09:17 11/24/1997 PST, Jay Martin wrote: >I've given a lot more thought to the notion of client-side >specification of event filtering for a given Edition, based >on the recent thread between Tom Hastings and myself. > >I guess I can support the notion of lightweight event filtering >(done by the Server, based on the client spec at the time of >subscription to an Edition), as long as we keep it *simple*. > >Here's what I propose: > > a) A new standard Edition property called "Event.Classes" > is defined, where the value consists of one or more named > event classes supported by the Publisher. The Publisher > alone controls the names of those event classes. > > b) A client MAY specify Server-side event filtering by adding > a new message property called "Event.Classes" in the subscription > request, where the value of the property is a set of named event > classes; if this property is not present or has a null value, > it implies the client desires to subscribe to all event classes > that may be supported by the Publisher of the target Edition. > (In effect, this is how the current Sense implementation works, > although it should be mentioned that backward compatibility is > not essential from my perspective). > > c) Upon issuing an event message to the Server, a Publisher MAY > include the "Event.Class" message property signifying the event > classes associated with the event. If this message property is > not specified in the event message, then it is assumed the event > is related to all event classes supported by the Publisher for > that Edition (again, this how Sense currently works). > > d) Upon receiving an event message from a Publisher for an Edition, > the Server will forward copies of the event message to all > Subscribers if their subscriptions included the specifically > named event class that matches that provided by the Publisher > in the event message. If no Event.Class message property exists > in the event message, or if the value of that property is null, > then the Server will forward a copy of the event message to all > Subscribers having specified the equivalent of "all" at the time > of subscription. > > e) A Subscriber may alter its desired set of event classes for an > existing subscription by sending another Subscribe request, > in which the contents of the subscription contain a new value > for the Event.Classes message property. The Server, upon > realizing that the client is already a Subscriber to the target > Edition, will update the current subscription such that the new > Event.Classes property value overwrites the previous value. If > the Event.Classes property is not present or null in the new > Subscribe request, the Server assumes the client desires to > subscribe to all event classes defined in the Edition. > >Now, using IPP as a target concrete example, I would propose that >an Edition used to provide IPP job events could be defined to have >one or more of the following named event classes as the value of >the Edition's Event.Classes property: > > job-completion > job-problems > job-started-processing > printer-problems > >A null (or missing) Event.Classes property implies all known IPP >events are supported as defined for the Edition (whatever that may >be). > >For example, let's say an IPP Printer Publisher has defined an >Edition that provides some--but not all--of the currently defined >set of IPP job events: > > Event.Classes=job-completion,job-problems,job-started-processing > >If a client desired to subscribe to that Edition, but only wanted >those events pertaining to the completion of jobs, then the client >would send a Subscribe request that included the following message >property: > > Event.Classes=job-completion > >If the Publisher then issues an event where the message includes >the following message property, then the Subscriber would receive >a copy of the event: > > Event.Classes=job-completion > >If the Publisher issues an event with the following message property, >then the Subscriber would NOT get a copy of the event, since the >Subscriber did not specify the equivalent of "all" when subscribing >to the Edition: > > Event.Classes= > >(That is, the value of the "Event.Classes" message property in the >event message is null, or perhaps missing.) > > >What do folks think about this proposal? > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From rbergma at dpc.com Mon Dec 8 11:33:24 1997 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fwd) In-Reply-To: New proposal for Server-based event filtering (fwd)> Message-ID: <3.0.1.32.19971201074035.01113bb0@garfield> ---------- Forwarded message ---------- Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST) From: Ron Bergman To: Jay Martin Subject: Re: SENSE> New proposal for Server-based event filtering Jay, (Sorry so late for this reply. Im in Washington state and they changed the remote phone number and I could not get the new one until today.) Your proposal seems like a good addition to sense, but I am not convinced that it is really needed for IPP. I still do not believe that the combinations proposed by Tom will really be needed. But I also believe that there may be other situations (other than IPP) where the filtering may be useful. Ron From hastings at cp10.es.xerox.com Wed Dec 10 12:19:09 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fwd) In-Reply-To: Message-ID: <3.0.1.32.19971210091909.00cf0ea0@garfield> Ron and I have a disagreement here. I believe that having every client host get a notification message if it has a job pending for a printer whenever that printer gets a problem, cause a network problem when the queue gets long. Sure such client can filter out the notifications and not both the user who doesn't want them. But the simple filtering you propose eliminates the need for the client to filter out the notification. As an example, my default printer currently has 51 jobs in the queue, because something is wrong with the printer. Sending out 51 notifications to all users who are in the queue whenever the printer has (more) problems will add to the network traffic. Also clients don't need to filter out job start processing notifiation when the user's job starts processing for those users that don't want to be bothered with that notification. So this mechanism makes it simpler for clients. They don't need to filter at all. However, we all agree that this simple filtering is a good add to SENSE, so we can leave it at that. Tom At 08:33 12/08/1997 PST, Ron Bergman wrote: > > >---------- Forwarded message ---------- >Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST) >From: Ron Bergman >To: Jay Martin >Subject: Re: SENSE> New proposal for Server-based event filtering > >Jay, > >(Sorry so late for this reply. Im in Washington state and they changed >the remote phone number and I could not get the new one until today.) > >Your proposal seems like a good addition to sense, but I am not convinced >that it is really needed for IPP. I still do not believe that the >combinations proposed by Tom will really be needed. > >But I also believe that there may be other situations (other than IPP) >where the filtering may be useful. > > Ron > > > > > From jkm at underscore.com Wed Dec 10 15:50:00 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fwd) In-Reply-To: New proposal for Server-based event filtering (fwd)> Message-ID: <3.0.1.32.19971210091909.00cf0ea0@garfield> Tom, > However, we all agree that this simple filtering is a good add to > SENSE, so we can leave it at that. And I agree with you. No problem there. I'd like to go into a bit of detail about this part of your posting: > As an example, my default printer currently has 51 jobs in the queue, > because something is wrong with the printer. Sending out 51 notifications > to all users who are in the queue whenever the printer has (more) problems > will add to the network traffic. First off, 51 notifications will only be sent if 51 clients have subscribed to events for the printer; if a client does not subscribe to the relevant Edition of the printer, then it will not receive any events (by definition). Perhaps where we might be getting lost here is in the implementation of a "print job" in the Sense model. If a printer published an Edition for each outstanding job--and every client subscribed to ALL job Editions, then yes, the client would get 51 (similar) events upon the occurance of a job-affecting printer event, one for each job Edition the client subscribed to. It's important to note that we have not really defined how a job--in particular, an IPP job--would be modeled and implemented in the Sense domain. We have often touched on the notion of a model where "one Edition = one job", so let's explore that for a moment. Imagine a client application designed as a "personal job monitor" that continually monitors a defined list of printers, looking for Editions that represent jobs associated with the app's user. Let's call such an Edition a "Job Edition" here. Whenever a Job Edition is found that appears to be related to the user, the app subscribes to the Edition. The Edition may be implemented to support multiple event classes (via the new "Event.Classes" property in the Edition); if so, then the app might also specify one or more filters when subscribing to the Edition. Otherwise, the app will receive all events upon subscribing to the Edition. Then, when the printer encounters a problem of some sort, either within itself (ie, a device fault) or within the job (ie, job fault), then the client would get exactly one event message, assuming the event has not been filtered. This will be true whether there is 1 job in the queue, or 51 jobs, or whatever number of jobs. If, on the other hand, a client subscribes to *all* Job Editions, then the client would get 51 events (one for each Edition) when a printer problem event occurs. Tom, does this jive with your thinking? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Tom Hastings wrote: > > Ron and I have a disagreement here. > > I believe that having every client host get a notification message > if it has a job pending for a printer whenever that printer gets a > problem, cause a network problem when the queue gets long. Sure > such client can filter out the notifications and not both the user > who doesn't want them. But the simple filtering you propose > eliminates the need for the client to filter out the notification. > > As an example, my default printer currently has 51 jobs in the queue, > because something is wrong with the printer. Sending out 51 notifications > to all users who are in the queue whenever the printer has (more) problems > will add to the network traffic. > > Also clients don't need to filter out job start processing notifiation > when the user's job starts processing for those users that don't want > to be bothered with that notification. > > So this mechanism makes it simpler for clients. They don't need to filter > at all. > > However, we all agree that this simple filtering is a good add to > SENSE, so we can leave it at that. > > Tom > > At 08:33 12/08/1997 PST, Ron Bergman wrote: > > > > > >---------- Forwarded message ---------- > >Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST) > >From: Ron Bergman > >To: Jay Martin > >Subject: Re: SENSE> New proposal for Server-based event filtering > > > >Jay, > > > >(Sorry so late for this reply. Im in Washington state and they changed > >the remote phone number and I could not get the new one until today.) > > > >Your proposal seems like a good addition to sense, but I am not convinced > >that it is really needed for IPP. I still do not believe that the > >combinations proposed by Tom will really be needed. > > > >But I also believe that there may be other situations (other than IPP) > >where the filtering may be useful. > > > > Ron > > > > > > > > > > From harryl at us.ibm.com Wed Dec 10 17:15:23 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Event driven or Polling? Message-ID: <3.0.1.32.19971210091909.00cf0ea0@garfield> Jay, I've started trying to follow the SENSE discussion about job event= s and came across this... >Imagine a client application designed as a "personal job monitor" >that continually monitors a defined list of printers, looking >for Editions that represent jobs associated with the app's user. >Let's call such an Edition a "Job Edition" here. OK, but this in not what I want to imagine. This sounds like polling! Y= ou went on to say... >Whenever a Job Edition is found that appears to be related to >the user, the app subscribes to the Edition. Great, event based from that point! I may be reacting to something that was only meant to be illustrative t= o the discussion. Do you really expect Sense based job Monitoring to require application= s to poll for editions? Harry Lewis - IBM Printing Systems = From hastings at cp10.es.xerox.com Wed Dec 10 18:47:47 1997 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fwd) In-Reply-To: <348F0078.85315C93@underscore.com> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> At 12:50 12/10/1997 PST, Jay Martin wrote: >Tom, > >> However, we all agree that this simple filtering is a good add to >> SENSE, so we can leave it at that. > >And I agree with you. No problem there. > >I'd like to go into a bit of detail about this part of your posting: > >> As an example, my default printer currently has 51 jobs in the queue, >> because something is wrong with the printer. Sending out 51 notifications >> to all users who are in the queue whenever the printer has (more) problems >> will add to the network traffic. > >First off, 51 notifications will only be sent if 51 clients have >subscribed to events for the printer; if a client does not subscribe >to the relevant Edition of the printer, then it will not receive any >events (by definition). So we need to understand when a printer publishes an addition. Scheme A: Does a printer publish a separate edition for each job received? If so, then the name of the edition has to be related to the job id, so that a client subscribes to the correct edition(s). By the way, I assume that a management app can't subscribe to an edition that hasn't been published, so the management app as to wait until the job is accepted by the IPP printer and the IPP printer has published the editionn for that job, correct? Scheme B: Or does a printer publish a single edition for the printer that generates job event notifications? If so, then the name of the edition would be related to the name of the printer, so that the client could subscribe to the correct edition. There are pros and cons to each, I'm sure. > >Perhaps where we might be getting lost here is in the implementation >of a "print job" in the Sense model. If a printer published an >Edition for each outstanding job--and every client subscribed to >ALL job Editions, then yes, the client would get 51 (similar) events >upon the occurance of a job-affecting printer event, one for each >job Edition the client subscribed to. This is scheme A. > >It's important to note that we have not really defined how a >job--in particular, an IPP job--would be modeled and implemented >in the Sense domain. We have often touched on the notion of a >model where "one Edition = one job", so let's explore that for >a moment. > >Imagine a client application designed as a "personal job monitor" >that continually monitors a defined list of printers, looking >for Editions that represent jobs associated with the app's user. >Let's call such an Edition a "Job Edition" here. > >Whenever a Job Edition is found that appears to be related to >the user, the app subscribes to the Edition. The Edition may >be implemented to support multiple event classes (via the new >"Event.Classes" property in the Edition); if so, then the app >might also specify one or more filters when subscribing to the >Edition. Otherwise, the app will receive all events upon >subscribing to the Edition. How would the app distinguish between Job Editions that were for jobs that its user had submitted from Job Editions that were for jobs that other users had submitted? Would there be some Job Edition attribute that indicates the user (name) that submitted the job? Then the management app would look at each new Job Edition and see if the user name matched the one that the app was monitoring for. Or would the name of the edition have the user name (or job id) in it? With scheme A, the monitoring app would have to also subscribe to events that create Job Editions, so as not to have to poll the SENSE server, correct? So each user client is getting a notification for any user's job submission, correct? Then the management app can see if it wants to subscribe to the Job Edition just published or not. Alternatively, the monitoring app could poll the SENSE server looking for Job Editions that are for that user, but the polling would only need to start when the user submitted a job, and polling of the SENSE server could stop as soon as the expected Job Edition was published, correct? With Scheme B, the management app only subscribes once to each printer Printer Edition that the user is interested in. Then the management app has to filter out notifications for jobs that belong to other users, except ones that indicate that the other users' jobs are having problems for the user that wants all printer problems. In order for such management app filtering to work, the notification packet would have to have the user name as one of the attributes, so that the management app could filter out non-interesting notifications, correct? > >Then, when the printer encounters a problem of some sort, >either within itself (ie, a device fault) or within the >job (ie, job fault), then the client would get exactly one >event message, assuming the event has not been filtered. >This will be true whether there is 1 job in the queue, or >51 jobs, or whatever number of jobs. > >If, on the other hand, a client subscribes to *all* Job Editions, >then the client would get 51 events (one for each Edition) when >a printer problem event occurs. And if all clients subscribe to all Job Editions, then there are 51*51 notifications generated, so I hope we can avoid that case. > >Tom, does this jive with your thinking? There are lots of ways to use SENSE for the job submission scenario. Which one makes the most sense to you. I'm still pretty new to thinking about it. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > >Tom Hastings wrote: >> >> Ron and I have a disagreement here. >> >> I believe that having every client host get a notification message >> if it has a job pending for a printer whenever that printer gets a >> problem, cause a network problem when the queue gets long. Sure >> such client can filter out the notifications and not both the user >> who doesn't want them. But the simple filtering you propose >> eliminates the need for the client to filter out the notification. >> >> As an example, my default printer currently has 51 jobs in the queue, >> because something is wrong with the printer. Sending out 51 notifications >> to all users who are in the queue whenever the printer has (more) problems >> will add to the network traffic. >> >> Also clients don't need to filter out job start processing notifiation >> when the user's job starts processing for those users that don't want >> to be bothered with that notification. >> >> So this mechanism makes it simpler for clients. They don't need to filter >> at all. >> >> However, we all agree that this simple filtering is a good add to >> SENSE, so we can leave it at that. >> >> Tom >> >> At 08:33 12/08/1997 PST, Ron Bergman wrote: >> > >> > >> >---------- Forwarded message ---------- >> >Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST) >> >From: Ron Bergman >> >To: Jay Martin >> >Subject: Re: SENSE> New proposal for Server-based event filtering >> > >> >Jay, >> > >> >(Sorry so late for this reply. Im in Washington state and they changed >> >the remote phone number and I could not get the new one until today.) >> > >> >Your proposal seems like a good addition to sense, but I am not convinced >> >that it is really needed for IPP. I still do not believe that the >> >combinations proposed by Tom will really be needed. >> > >> >But I also believe that there may be other situations (other than IPP) >> >where the filtering may be useful. >> > >> > Ron >> > >> > >> > >> > >> > > > From jds at underscore.com Thu Dec 11 11:39:58 1997 From: jds at underscore.com (Jeffrey D. Schnitzer) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fw In-Reply-To: New proposal for Server-based event filtering (fw> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> The following message from Harry was caught by our Majordomo list software due to "ubscribe-say" appearing within the first 5 lines of the message body. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From: Harry Lewis To: Subject: Re: SENSE> New proposal for Server-based event filtering Date: Thu, 11 Dec 1997 11:00:47 -0500 MIME-Version: 1.0 Tom (I think) wrote: >By the way, I assume that a management app can't subscribe to an >edition that hasn't been published, so the management app as to wait >until the job is accepted by the IPP printer and the IPP printer has >published the edition for that job, correct? I while this may be one case, I hope it's not the only case. For printer editions, the management app should be able to manage it's subscription in correlation with it's queue. Drop off when the queue drains, "re-up" when there are jobs to submit and monitor. If the management app is supplying a transaction ID, like jmJobSubmissionID or the equivalent in IPP, it should be able to subscribe to a job edition without waiting for the edition to be published. Otherwise, we get into an undesirable polling situation, I believe, where the management app must poll to find out what editions are available prior to subscribing. Harry Lewis - IBM Printing Systems -- From jkm at underscore.com Thu Dec 11 12:30:51 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Event driven or Polling? In-Reply-To: Event driven or Polling?> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> Harry, Ah yes, I can see where I might have gotten you confused about polling by a Sense subscriber client. The short answer here is that the client does *not* poll in any manner whatsoever. It's tough at this juncture to describe an absolutely concrete explanation here, since we have yet to define the way to model and implement a Job in the Sense domain; this topic is currently being discussed in a separate thread on this DL, so watch that discussion (and participate!) so we can nail down the details. In any case, to allay your fears about client polling, let me try to explain how I think things ought to work, given the previous example and your comments: > >Imagine a client application designed as a "personal job monitor" > >that continually monitors a defined list of printers, looking > >for Editions that represent jobs associated with the app's user. > >Let's call such an Edition a "Job Edition" here. > > OK, but this in not what I want to imagine. This sounds like polling! Here's a sort of step-by-step sequence of events I would expect to be handled by such an application using Sense, assuming that a print Job is implemented as an Edition to a printer Publication: - Initial operating assumptions: * The app has been "told by the user" which printers to monitor (command line options, GUI-managed list, etc...), using some sort of naming convention * Similarly, the app has been configured for a target Sense server - The app registers itself on the Server - The app requests the list of printer Publications that match the printer names configured by the user - For each such printer Publication, the app then: * Subscribes to the printer Publication so as to receive future events that declare the creation/modification/removal of Editions associated with the Publication * Fetches the current list of Editions, and for each Edition: + Fetches the Edition properties that: - allow the app to discern whether the Edition represents a print Job, or some other type of Edition - identify the print Job as being associated with the user (using whatever mapping method is defined) + If the Edition is a Job *and* is related to the user, then the app subscribes to that Edition, using whatever filter specs that may be appropriate (ref: the recent discussion on adding simple event filters in Subscribe messages, etc) - When a state change happens to the Job, the publisher for the associated Edition posts an event for the Edition, a copy of which is sent to all subscribing clients. - When the app receives the event, it uses the contents to do "the right thing" for the user (whatever that may be); the event contains (by its own definition) sufficient information for the subscribing app to properly handle the event. - Subsequently, the app may receive an event from a subscribed printer Publication that denotes a new Edition has been added; the event message contains certain descriptive information about the new Edition, such as its class, name, etc. - Similar to above, the app then goes out and "qualifies" the Edition (ie, determines whether the Edition is something it should be interested in), and subscribes to it, if so - Subsequently, a printer Publication event may be received that indicates an Edition has been removed, and the app takes similar steps to determine whether it needs to update the app's state to potentially remove the Job (ie, Edition) from its internal list it is monitoring. (Note that there is no need for the subscribing app to explicitly unsubscribe from an Edition that has been removed.) - When the app is instructed to shutdown, it unregisters itself with the Sense server, which as a by-product, automatically unsubscribes the client from all previous subscriptions (ie, the client does not have to explicitly unsubscribe from all its subscriptions). So, it should be apparent that *no* polling is ever done, assuming the model and implementation for print Jobs is as described above. (This Job model approach is labelled "Scheme A" by Tom in the related thread.) Does this make Sense to you? (Gotta love that pun... ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis wrote: > > Jay, I've started trying to follow the SENSE discussion about job events and > came across this... > > >Imagine a client application designed as a "personal job monitor" > >that continually monitors a defined list of printers, looking > >for Editions that represent jobs associated with the app's user. > >Let's call such an Edition a "Job Edition" here. > > OK, but this in not what I want to imagine. This sounds like polling! You went > on to say... > > >Whenever a Job Edition is found that appears to be related to > >the user, the app subscribes to the Edition. > > Great, event based from that point! > > I may be reacting to something that was only meant to be illustrative to the > discussion. > Do you really expect Sense based job Monitoring to require applications to > poll for editions? > > Harry Lewis - IBM Printing Systems From jkm at underscore.com Thu Dec 11 12:41:40 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fwd) In-Reply-To: New proposal for Server-based event filtering (fwd)> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> Tom, > So we need to understand when a printer publishes an addition. Do you mean "Edition" (not "addition")? I'll assume you mean "Edition" here. > Scheme A: > Does a printer publish a separate edition for each job received? Well, that's the approach you're taking, so let's say "Yes" and run with that model for a minute. > If so, then the name of the edition has to be related to the job id, > so that a client subscribes to the correct edition(s). Actually, the name of the Edition does not necessarily have to map directly to the job id, although it could, I suppose. I would have expected to have one or more Edition properties that are used to map the Edition to the actual Job. The design of Sense is such that a client can ask for a set of object IDs (handles) based on a sort of query-filter, where a set of properties (and possible value sets) can be specified to narrow the target set. So, the client could ask for the set of Editions (ie, fetch the handles for the Editions) having a specified set of properties with certain values. > By the way, I assume that a management app can't subscribe to an edition that > hasn't been published, so the management app as to wait until the job > is accepted by the IPP printer and the IPP printer has published the > editionn for that job, correct? Correct. No Vulcan mind meld here. ;-) The publisher acting on behalf of the IPP printer would have to create the Edition once it fully knows about the incoming IPP job. > Scheme B: > Or does a printer publish a single edition for the printer that generates > job event notifications? Sure, we could model Jobs in that manner. I've given that approach quite a bit of thought--and could detail a potential design here--but I think Scheme A is better. (And I doubt folks would get the time to read the design for Scheme B anyway... ;-) > If so, then the name of the edition would be related to the name of the > printer, so that the client could subscribe to the correct edition. > > There are pros and cons to each, I'm sure. Yeah, I guess we could take that route. I like Scheme A better, at least right now, anyway. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jkm at underscore.com Thu Dec 11 12:48:43 1997 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> New proposal for Server-based event filtering (fw In-Reply-To: New proposal for Server-based event filtering (fw> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> Harry, Hopefully my previous posting answered your questions and allayed your fears about polling that you describe in this message. If not, let's talk. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- > From: Harry Lewis > To: > Subject: Re: SENSE> New proposal for Server-based event filtering > Date: Thu, 11 Dec 1997 11:00:47 -0500 > MIME-Version: 1.0 > > Tom (I think) wrote: > > >By the way, I assume that a management app can't subscribe to an > >edition that hasn't been published, so the management app as to wait > >until the job is accepted by the IPP printer and the IPP printer has > >published the edition for that job, correct? > > I while this may be one case, I hope it's not the only case. For printer > editions, the management app should be able to manage it's subscription > in > correlation with it's queue. Drop off when the queue drains, "re-up" > when there > are jobs to submit and monitor. If the management app is supplying a > transaction ID, like jmJobSubmissionID or the equivalent in IPP, it > should be > able to subscribe to a job edition without waiting for the edition to be > published. Otherwise, we get into an undesirable polling situation, I > believe, > where the management app must poll to find out what editions are > available > prior to subscribing. > > Harry Lewis - IBM Printing Systems > -- From jds at underscore.com Thu Dec 11 13:32:19 1997 From: jds at underscore.com (Jeffrey D. Schnitzer) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Use of subscribe and Majordomo Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> For this SENSE list only, I've turned off the Majordomo feature that filters out administrivia requests (such as "subscribe" sent to the address rather than ). It's tough to talk SENSE without using "subscribe" or "unsubscribe" early in a message! And "pig latin" doesn't really cut it. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From harryl at us.ibm.com Thu Dec 11 17:54:45 1997 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Event driven or Polling? In-Reply-To: Event driven or Polling?> Message-ID: <3.0.1.32.19971210154747.00fdea50@garfield> OK, Im convinced there is no polling. More of a multistep registration process for (potentially) multiple publications and editions. I would b= e more pleased with a single step registration for a single edition whic= h directly correlates to MY JOB... unless, of course, I'm some sort of administrate application wanting job info from multiple devices and rel= ated to many users. I'm probably treading dangerously close to the "in-band" vs. "out-of'b= and" topic, again. I know print job destinations may be altered by intermedi= ate steps in the print process, like redirection or print pooling. If somet= hing is going to insert itself between me and my target, however, and "take = control" of the situation, I wish it wouldn't leave it up to me to guess what ch= anges it has imposed on the system! Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 12/11/97 11:03:55 AM Please respond to owner-sense@pwg.org @ internet To: Harry Lewis/Boulder/IBM@ibmus cc: sense@pwg.org @ internet Subject: Re: SENSE> Event driven or Polling? Harry, Ah yes, I can see where I might have gotten you confused about polling by a Sense subscriber client. The short answer here is that the client does *not* poll in any manner whatsoever. It's tough at this juncture to describe an absolutely concrete explanation here, since we have yet to define the way to model and implement a Job in the Sense domain; this topic is currently being discussed in a separate thread on this DL, so watch that discussion (and participate!) so we can nail down the details. In any case, to allay your fears about client polling, let me try to explain how I think things ought to work, given the previous example and your comments: > >Imagine a client application designed as a "personal job monitor" > >that continually monitors a defined list of printers, looking > >for Editions that represent jobs associated with the app's user. > >Let's call such an Edition a "Job Edition" here. > > OK, but this in not what I want to imagine. This sounds like polling!= Here's a sort of step-by-step sequence of events I would expect to be handled by such an application using Sense, assuming that a print Job is implemented as an Edition to a printer Publication: - Initial operating assumptions: * The app has been "told by the user" which printers to monitor (command line options, GUI-managed list, etc...), using some sort of naming convention * Similarly, the app has been configured for a target Sense server - The app registers itself on the Server - The app requests the list of printer Publications that match the printer names configured by the user - For each such printer Publication, the app then: * Subscribes to the printer Publication so as to receive future events that declare the creation/modification/removal of Editions associated with the Publication * Fetches the current list of Editions, and for each Edition: + Fetches the Edition properties that: - allow the app to discern whether the Edition represents a print Job, or some other type of Edition - identify the print Job as being associated with the user (using whatever mapping method is defined) + If the Edition is a Job *and* is related to the user, then the app subscribes to that Edition, using whatever filter specs that may be appropriate (ref: the recent discussion on adding simple event filters in Subscribe messages, etc) - When a state change happens to the Job, the publisher for the associated Edition posts an event for the Edition, a copy of which is sent to all subscribing clients. - When the app receives the event, it uses the contents to do "the right thing" for the user (whatever that may be); the event contains (by its own definition) sufficient information for the subscribing app to properly handle the event. - Subsequently, the app may receive an event from a subscribed printer Publication that denotes a new Edition has been added; the event message contains certain descriptive information about the new Edition, such as its class, name, etc. - Similar to above, the app then goes out and "qualifies" the Edition (ie, determines whether the Edition is something it should be interested in), and subscribes to it, if so - Subsequently, a printer Publication event may be received that indicates an Edition has been removed, and the app takes similar steps to determine whether it needs to update the app's state to potentially remove the Job (ie, Edition) from its internal list it is monitoring. (Note that there is no need for the subscribing app to explicitly unsubscribe from an Edition that has been removed.) - When the app is instructed to shutdown, it unregisters itself with the Sense server, which as a by-product, automatically unsubscribes the client from all previous subscriptions (ie, the client does not have to explicitly unsubscribe from all its subscriptions). So, it should be apparent that *no* polling is ever done, assuming the model and implementation for print Jobs is as described above. (This Job model approach is labelled "Scheme A" by Tom in the related thread.) Does this make Sense to you? (Gotta love that pun... ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Harry Lewis - IBM Printing Systems = From lstein at fapo.com Fri Dec 12 10:48:28 1997 From: lstein at fapo.com (Larry Stein) Date: Wed May 6 14:04:26 2009 Subject: SENSE> January Meeting Notice Message-ID: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com ***************************************************************