From don at lexmark.com Mon Sep 14 15:26:47 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:25 2009 Subject: SENSE> Mailing Lists Message-ID: <199809141927.AA13984@interlock2.lexmark.com> The mailing lists are back up and running. Just to test everything out, I have sent this mail to ALL the mailing lists. If you get this mail on one list and not on another you think you should be on then I suggest you resubscribe by sending e-mail to: majordomo@pwg.org with the body of the note containing subscribe when is the name of the list you wish to subscribe to. You can include multiple subscriptions in the same note. Thanks for your patience during this transfer. ********************************************** * 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 jkm at underscore.com Mon Jan 5 12:47:39 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> More Time for IPP in January In-Reply-To: More Time for IPP in January> Message-ID: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> Ron Bergman wrote: > I agree with Harry, let's not overlap the agenda items. > > I do not anticipate any time required for the Job MIB so that Thursday can > be shared by IPP and SENSE. I assume that Friday is still reserved for > the Finisher MIB. Sorry, but there will be no SENSE session at the upcoming January PWG meetings in Hawaii. :-( ...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 hastings at cp10.es.xerox.com Tue Jan 6 15:57:10 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> More Time for IPP in January [agenda: IPP In-Reply-To: <34B11CBB.446A347D@underscore.com> Message-ID: <3.0.1.32.19980106125710.01021cb0@garfield> Jay, I assume that you are unable to attend the meeting? Thats too bad, because I though we were making some good progress on understanding SENSE. One of the hot items for IPP is how to do notifications which we deleted at the last minute from the Model document, so that we could publish the RFC without notification for the time being and work a real solution in a short time period after publishing V1.0. The desire is to agree on something quick enough that IPP implementations can converge on it, rather than implementors coming up with their own (different) solutions. We need to avoid the problem in IPP that we see in SNMP where each implementor does his/her own private trap registration mechanism. I hope that we can discuss IPP notification in the IPP meeting, anyway, and use as much of SENSE as makes sense. So others of us need to read the SENSE specs for the IPP discussion. Tom At 09:47 01/05/1998 PST, Jay Martin wrote: >Ron Bergman wrote: > >> I agree with Harry, let's not overlap the agenda items. >> >> I do not anticipate any time required for the Job MIB so that Thursday can >> be shared by IPP and SENSE. I assume that Friday is still reserved for >> the Finisher MIB. > >Sorry, but there will be no SENSE session at the upcoming January >PWG meetings in Hawaii. :-( > > ...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 Jan 14 17:14:49 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:26 2009 Subject: SENSE> PWG Meeting Agenda - Final Message-ID: <199801150126.AA09514@interlock2.lexmark.com> Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher 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 jkm at underscore.com Mon Feb 2 12:48:16 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? Message-ID: <199801150126.AA09514@interlock2.lexmark.com> Greetings, Given the lack of participation in this project, it is probably appropriate to formally shutdown the project and the mailing list. Any objections? Please submit your comments before the end of this week (Friday, Feb 6). If there are no significant objections, the project will be considered formally closed at that time. ...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 Mon Feb 2 13:25:38 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: Time to shutdown the SENSE project?> Message-ID: <199801150126.AA09514@interlock2.lexmark.com> Jay, I wouldn't say there is lack of interest. Notification was discuss= ed at the last 2 or 3 PWG meetings and it looks like an IPP "Notification sub= -effort" may actually be organized sometime in the future. SENSE (among other op= tions) was discussed in this context last week (and we wish you could have bee= n there). While there are many options that could become part of a notification s= cheme for print and printers, ranging from SNMPv3 to JAVA notification etc...= I believe SENSE is definitely worthwhile considering. Harry Lewis owner-sense@pwg.org on 02/02/98 10:53:55 AM Please respond to owner-sense@pwg.org @ internet To: sense@pwg.org @ internet cc: Subject: SENSE> Time to shutdown the SENSE project? Greetings, Given the lack of participation in this project, it is probably appropriate to formally shutdown the project and the mailing list. Any objections? Please submit your comments before the end of this week (Friday, Feb 6). If there are no significant objections, the project will be considered formally closed at that time. ...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 Feb 2 13:39:58 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: Time to shutdown the SENSE project?> Message-ID: <199801150126.AA09514@interlock2.lexmark.com> Harry Lewis wrote: > While there are many options that could become part of a notification scheme > for print and printers, ranging from SNMPv3 to JAVA notification etc... I > believe SENSE is definitely worthwhile considering. I appreciate your continued interest, Harry. But I really believe that so much time has gone by that people will now be more interested in pursuing other mechanisms. Recall that Sense was started in November of 1995. Technology has moved along quite a bit since then. I have grown pretty tired of constantly analyzing "Sense vs. XYZ" as new approaches have come onto the scene. I really think it's time to just shut this effort down. ...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 Feb 2 15:47:53 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: Time to shutdown the SENSE project?> Message-ID: <199802031753.AA24062@interlock2.lexmark.com> Jay Martin said: > >Harry Lewis wrote: > >> While there are many options that could become part of a notification scheme >> for print and printers, ranging from SNMPv3 to JAVA notification etc... I >> believe SENSE is definitely worthwhile considering. > >I appreciate your continued interest, Harry. But I really believe >that so much time has gone by that people will now be more interested >in pursuing other mechanisms. > >Recall that Sense was started in November of 1995. Technology has >moved along quite a bit since then. I have grown pretty tired of >constantly analyzing "Sense vs. XYZ" as new approaches have come >onto the scene. > >I really think it's time to just shut this effort down. > > ...jay I tend to agree with Jay... While the technology of SENSE is very much worth considering, I believe that rather than a stand-alone effort, SENSE or some parts of it might be folded into another project. There was a long, long discussion of notification at the IPP meeting last week and there was interest in investigating how some of the SENSE concepts and work could be included. I think this will be a hot topic for the Austin IPP meeting. Don ********************************************** * 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 jkm at underscore.com Wed Feb 4 18:13:39 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: Maui PWG Overview Minutes> Message-ID: <199802031753.AA24062@interlock2.lexmark.com> Harry, Part of your fine summary included this section on Sense: SENSE Notification Protocol No status. Jay Martin (SENSE Chair) not present. It is unfortunate that we were unable to schedule a SENSE discussion in Maui because IPP is interested in considering SENSE as notification scheme. IPP may also want to look at SNMPv3 (recently published RFCs). It was noted that there are many notification protocols available today that may need to be investigated. Would someone be so kind as to list the "many notification protocols available today that may need to be investigated"? I would be more than happy to start investigated those alternatives if someone would post them to the IPP list (or the Sense list, or whatever). Thanks in advance. ...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 Wed Feb 4 21:44:28 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: <34D606E0.A9D41CC6@underscore.com> Message-ID: <199802031753.AA24062@interlock2.lexmark.com> Jay, I would hope that before SENSE is shutdown that it is determined if this technology is applicable to IPP. As you see by the email and minutes of the Maui meeting, the issue of notifications is becoming a very hot topic. The SENSE work and the knowledge you obtained should certainly be of significant benefit to IPP. Ron Bergman Dataproducts Corp. On Mon, 2 Feb 1998, Jay Martin wrote: > Greetings, > > Given the lack of participation in this project, it is probably > appropriate to formally shutdown the project and the mailing list. > > Any objections? Please submit your comments before the end of this > week (Friday, Feb 6). If there are no significant objections, the > project will be considered formally closed at that time. > > ...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 DAVID_KUNTZ at HP-Roseville-om2.om.hp.com Wed Feb 4 21:57:17 1998 From: DAVID_KUNTZ at HP-Roseville-om2.om.hp.com (DAVID_KUNTZ@HP-Roseville-om2.om.hp.com) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: <34D8F623.AD3C1C41@underscore.com> Message-ID: Javasoft, OMG, and Microsoft's internal protocol were among the emerging notification schemes mentioned at the meeting. Dave Kuntz - HP ______________________________ Reply Separator _________________________________ Subject: SENSE> Re: PWG> Maui PWG Overview Minutes Author: Non-HP-jkm (jkm@underscore.com) at HP-Roseville,mimegw3 Date: 2/4/98 3:13 PM Harry, Part of your fine summary included this section on Sense: SENSE Notification Protocol No status. Jay Martin (SENSE Chair) not present. It is unfortunate that we were unable to schedule a SENSE discussion in Maui because IPP is interested in considering SENSE as notification scheme. IPP may also want to look at SNMPv3 (recently published RFCs). It was noted that there are many notification protocols available today that may need to be investigated. Would someone be so kind as to list the "many notification protocols available today that may need to be investigated"? I would be more than happy to start investigated those alternatives if someone would post them to the IPP list (or the Sense list, or whatever). Thanks in advance. ...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 Wed Feb 4 22:28:06 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: Re: PWG> Maui PWG Overview Minutes> Message-ID: Dave, Thanks for the starting points. Do you have a bit more info or pointers for these? Javasoft Are you referring to some defined subset or related service of RMI, or the emerging CORBA-related stuff, or something else? Any specific documents/URLs/etc you might cite? OMG You must be referring to the CORBA Event Services? Do you know whether the Event Service can run "standalone" without requiring many other components of the CORBA environment? (A "too fat" implementation will kill most interest here, IMHO) Microsoft internal protocol Is this a documented, "open" protocol? (Had to ask.) Or is this a protocol that a few select players have access to, but is otherwise unavailable/undocumented for general use? Anything you (or anyone else) can provide would be appreciated. Hopefully everyone is interested in publicly discussing the alternatives while we simultaneous flesh out the key requirements. ...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 -- ---------------------------------------------------------------------- DAVID_KUNTZ@HP-Roseville-om2.om.hp.com wrote: > > Javasoft, OMG, and Microsoft's internal protocol were among the > emerging notification schemes mentioned at the meeting. > > Dave Kuntz - HP > > ______________________________ Reply Separator _________________________________ > Subject: SENSE> Re: PWG> Maui PWG Overview Minutes > Author: Non-HP-jkm (jkm@underscore.com) at HP-Roseville,mimegw3 > Date: 2/4/98 3:13 PM > > Harry, > > Part of your fine summary included this section on Sense: > > SENSE Notification Protocol > > No status. Jay Martin (SENSE Chair) not present. It is unfortunate > that we were unable to schedule a SENSE discussion in Maui because > IPP is interested in considering SENSE as notification scheme. IPP > may also want to look at SNMPv3 (recently published RFCs). It was > noted that there are many notification protocols available today > that may need to be investigated. > > Would someone be so kind as to list the "many notification protocols > available today that may need to be investigated"? I would be more > than happy to start investigated those alternatives if someone would > post them to the IPP list (or the Sense list, or whatever). > > Thanks in advance. > > ...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 Wed Feb 4 22:52:00 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: Time to shutdown the SENSE project?> Message-ID: Ron Bergman wrote: > I would hope that before SENSE is shutdown that it is determined if this > technology is applicable to IPP. As you see by the email and minutes of > the Maui meeting, the issue of notifications is becoming a very hot topic. > The SENSE work and the knowledge you obtained should certainly be of > significant benefit to IPP. Ron, what would you suggest I do at this point to help describe how SENSE can be used for IPP? I have repeatedly requested folks to read the SENSE documentation, yet very few people have come back saying that agree/disagree on even the basic Proposed Requirements document. I guess I'm kind of at a loss at how to proceed. (You know, you can lead a horse to water, but you can't...) It appears to me that the folks on the IPP list are taking somewhat of a "fundamental research" technique in approaching async event notifications for IPP. Rather than examining an existing system (defined for that kind of operation) and seeing how it can be used to solve their particular problem, they appear to instead want to focus on the basics (eg, transports, etc) and work up from there, teaching themselves how to build a system from scratch in the process. I think that would be a shame, but if that's what it's going to take for people to understand the how's and why's of where we ended up with SENSE, then so be it. I just hope it doesn't take too long, that's all... 8-) If there's anything you (or anyone else) can do to help guide me in explaining how SENSE can be used to solve IPP's event notification problem, I am all ears. ...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 walker at dazel.com Thu Feb 5 10:21:39 1998 From: walker at dazel.com (James Walker) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: Re: PWG> Maui PWG Overview Minutes> Message-ID: <34D9D903.835988D1@dazel.com> Jay Martin wrote: > > ... > > Would someone be so kind as to list the "many notification protocols > available today that may need to be investigated"? I would be more > than happy to start investigated those alternatives if someone would > post them to the IPP list (or the Sense list, or whatever). Jay, My recollection on this was the following... ... Bob Herriot mentioned that JavaSoft was working an a "Java Notification API"; it is presumably a publish/subscribe model. He had no idea what kind of protocol was going to be underneath the API. ... Josh Cohen metioned that there were a couple (several? many?) ongoing (or just starting?) efforts in the IETF. I believe that he said that one of them was going on (or coming out of) the HTTP effort. You might try contacting him directly. One that I have seen that may or may not be applicable is RVP (ftp://ds.internic.net/internet-drafts/draft-calsyn-rvp-00.txt) ... I thought that X/Open (or I guess it is the Open Group) was doing some sort of notification effort (which I thought was called EMS?). Nobody seemed to know anything about it. ... I do not recall anyone mentioning or discussing Corba Event Services, but I may have just had some sand in my ears. hope that helps... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From harryl at us.ibm.com Thu Feb 5 17:01:19 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: Re: PWG> Maui PWG Overview Minutes> Message-ID: <34D9D903.835988D1@dazel.com> Another one... my notes show that Jim Walker identified something calle= d Persistent Searches as a possible alternative. Harry Lewis - IBM Printing Systems = From walker at dazel.com Fri Feb 6 12:24:55 1998 From: walker at dazel.com (James Walker) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: Re: PWG> Maui PWG Overview Minutes> Message-ID: <34DB4767.95CF8115@dazel.com> Harry Lewis wrote: > > Another one... my notes show that Jim Walker identified something called > Persistent Searches as a possible alternative. You are right, I did mention persistent search. This is a concept from the LDAP work, whereby a client can post a query that does not terminate after the original results are returned; instead new (or modified) entries that satisfy the search query will be returned on an active channel (see draft-smith-ldap-psearch-00.txt). This was mentioned not as an existing notification mechanism, but as an alternative design to the normal asynchronuous notification schemes (where the "notification server" contacts the "notification client" to send the event). In the persistent search case, there is an active channel between the server and the client (along the lines of the HTTP connection discussion that has been going on in the IPP DL). As we discussed in Maui, and as Jay has already mentioned, this alternative is not scalable, as resources are consumed for each active connection. But it is some nice food for thought. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From jkm at underscore.com Fri Feb 6 12:42:47 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Time to shutdown the SENSE project? In-Reply-To: Time to shutdown the SENSE project?> Message-ID: <34DB4767.95CF8115@dazel.com> Well, it looks like SENSE will (again) get a stay of execution, given the recent interest by the IPP folks. Since almost no one likes cross-postings, I'd like to suggest that all SENSE threads revolving around IPP should be conducted solely on the IPP mailing list (ipp@pwg.org). The exact schedule has not yet been devised for the upcoming IPP meeting in Austin, TX (March 4-5), but I am hoping that some serious time will be allowed for discussing how SENSE can (or can't) be used for IPP. ...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 -- ---------------------------------------------------------------------- Jay Martin wrote: > > Greetings, > > Given the lack of participation in this project, it is probably > appropriate to formally shutdown the project and the mailing list. > > Any objections? Please submit your comments before the end of this > week (Friday, Feb 6). If there are no significant objections, the > project will be considered formally closed at that time. > > ...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 Fri Feb 6 16:41:44 1998 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:04:26 2009 Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? In-Reply-To: <34DB4B97.6BB93C32@underscore.com> Message-ID: <3.0.1.32.19980206134144.00b70bd0@garfield> At 09:42 AM 2/6/98 PST, Jay Martin wrote: >Well, it looks like SENSE will (again) get a stay of execution, >given the recent interest by the IPP folks. > >Since almost no one likes cross-postings, I'd like to suggest >that all SENSE threads revolving around IPP should be conducted >solely on the IPP mailing list (ipp@pwg.org). > >The exact schedule has not yet been devised for the upcoming >IPP meeting in Austin, TX (March 4-5), but I am hoping that >some serious time will be allowed for discussing how SENSE >can (or can't) be used for IPP. > > ...jay > Jay, I am trying to get some feedback from our IETF Area Directors on how to proceed with the IPP notification subject. In the meantime, we can certainly discuss SENSE and other potential approaches for how to tackle the notification subject within the framework of the PWG. However, I think that starting to document more details about our requirements should come first, as has already been suggested by several people. Unless we are in for any surprises from the IESG, which might be higher priority, we should definately spend a good part of our PWG IPP in Austin to discuss this. Hope you can make it to Austin. 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 hastings at cp10.es.xerox.com Fri Feb 6 21:37:23 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: PWG> Maui PWG Overview Minutes In-Reply-To: <34D8F623.AD3C1C41@underscore.com> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> One more is that Carl-Uno says that the SMTP protocols use a notifiation method between mail servers. We could consider using one of them. Tom At 15:13 02/04/1998 PST, Jay Martin wrote: >Harry, > >Part of your fine summary included this section on Sense: > > SENSE Notification Protocol > > No status. Jay Martin (SENSE Chair) not present. It is unfortunate > that we were unable to schedule a SENSE discussion in Maui because > IPP is interested in considering SENSE as notification scheme. IPP > may also want to look at SNMPv3 (recently published RFCs). It was > noted that there are many notification protocols available today > that may need to be investigated. > >Would someone be so kind as to list the "many notification protocols >available today that may need to be investigated"? I would be more >than happy to start investigated those alternatives if someone would >post them to the IPP list (or the Sense list, or whatever). > >Thanks in advance. > > ...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 Mar 9 13:13:56 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Notification content In-Reply-To: Notification content> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> Harry, I agree with your observations entirely. And these concerns are *exactly* why SENSE was designed to _not_ support any kind of filtering, so as to ease the burden on the SENSE server (which is the "agent" in your text below). ...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: > > In Austin, I think we discussed the IPP notification requirement that any > attribute may be requested during registration for a given event. I think the > requirement stems from the notion that notification content should just "mimic" > the response to a query. But this is probably unrealistic. A query/response is > synchronous - during which, the "agent's" job is to gather the requested > information and package the response. With notifications, you pre-register for > asynchronous events. It would be a much greater burden on the agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants which > notifications, but also what information they requested with each type of event! > > Harry Lewis - IBM Printing Systems From harryl at us.ibm.com Mon Mar 9 13:55:02 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Notification content In-Reply-To: Notification content> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> Jay, with a generic event broker, like SENSE, I can understand how filt= ering could get out of hand. For the specific case of Job events, however, I = am actually advocating an EVENT TYPE filter. In my note, I was trying to p= oint out that allowing arbitrary CONTENT per event type is probably out of scope= From jkm at underscore.com Mon Mar 16 16:46:33 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> Ira, Thanks so much for your review and comments regarding the applicability (or not) of the new SNMPv3 async notification facilities. I particularly liked your summary paragraph: > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. This comes as no surprise to those of us developing SENSE over the last two years or so. SNMP was primarily designed for management network elements, and has never demonstrated the power required in larger, non-management applications, such as generic client-side features of network printing. That is precisely why we went off and did SENSE, to create a more scalable, more generic system for async notifications. Simply hacking onto existing (or future) SNMP facilities never seemed to make the grade. And now your analysis seems to verify that original assumption. Perhaps someday the PWG will come to understand the need for SENSE...or something just like it, 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 -- ---------------------------------------------------------------------- Ira Mcdonald x10962 wrote: > > Copies To: ipp@pwg.org > jmp_pwg.org > > Hi folks, Sunday (15 March 1998) > > Extracted below (with line numbers) is summary information from the five > SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). > > As Randy Turner has argued, it IS possible to use a small subset (Target > and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are > a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) > SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' > declaration at line 2773 of RFC 2273). > > But, the functionality provided is INFERIOR in important ways to that > provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted > on Wednesday (4 March 1998) or to my informal understanding of the IBM > method presented by Harry Lewis during last week's PWG monthly meeting > in Austin, TX. > > 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope > (traps of 'interest') specified as object identifier subtrees. > The SNMPv3 Target/Notification MIBs support scope only by short (32 > character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due > to their length) are NOT amenable to standardization. > > 2) The JAM MIB supports automatic trap deregistration specified as > 'DateAndTime'. > The SNMPv3 Target/Notification MIBs do NOT support automatic trap > deregistration at all! > > 3) The JAM MIB supports simple integer indices for all 'read-create' > object groups (written by a remote client). > The SNMPv3 Target/Notification MIBs support indices ONLY as (32 > character) UTF-8 'SnmpAdminString' values, seriously restricting the > number of SNMP objects which can be transferred in a single packet. > Since SNMP runs over UDP (in the Internet suite) and there is no > 'chunking' for SNMP requests, this limitation is significant! > > 4) The JAM MIB supports a 'read-only' lookup table (maintained by the > SNMP agent on the device) which provides direct lookup from SNMP > transport domain and transport address to a client (target) trap > registration entry (to avoid duplicate registrations). > But, the SNMPv3 Target/Notification MIBs support only brute force > (ie, read the entire Target table) for this important functionality! > > 5) The JAM MIB scales well to a very large number of (end-user) trap > client (target) registrations. > But, the SNMPv3 Target/Notification MIBs do not scale well. They > are intended ONLY for use by network management stations! > > 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses > could be used for (questionably) 'reliable' event notification. > But, 'Inform' is intended by the SNMPv3 developers to be used ONLY > for reporting up a hierarchy of network management stations! > Also, 'Inform' is not defined in SNMPv1, so the huge installed base > of SNMP agents which (almost exclusively) speak SNMPv1 cannot use > 'Inform'. > > 7) Lastly, as SNMP agent toolkits become available from software tool > vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the > printer industry vendors will inevitably conflict with the very > different intent of the SNMPv3 developers. Recall why the Job Mon > MIB is a PWG standard and NOT an IETF standard! > > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. > > Cheers, > - Ira McDonald (High North, outside consultant at Xerox) > > ------------------------------------------------------------------------ > **** SNMPv3 Documents **** > > rfc2271.txt: Architecture for Describing SNMP Management Frameworks > - 38-44: > This document describes an architecture for describing SNMP > Management Frameworks. The architecture is designed to be modular to > allow the evolution of the SNMP protocol standards over time. The > major portions of the architecture are an SNMP engine containing a > Message Processing Subsystem, a Security Subsystem and an Access > Control Subsystem, and possibly multiple SNMP applications which > provide specific functional processing of management data. > - 1913: > SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN > - 2420: > snmpFrameworkMIBCompliance MODULE-COMPLIANCE > > rfc2272.txt: Message Processing and Dispatching for SNMP > - 41-46: > This document describes the Message Processing and Dispatching for > SNMP messages within the SNMP architecture [RFC2271]. It defines the > procedures for dispatching potentially multiple versions of SNMP > messages to the proper SNMP Message Processing Models, and for > dispatching PDUs to SNMP applications. This document also describes > one Message Processing Model - the SNMPv3 Message Processing Model. > - 810: > SNMP-MPD-MIB DEFINITIONS ::= BEGIN > - 936: > snmpMPDCompliance MODULE-COMPLIANCE > - 976: > SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > > rfc2273.txt: SNMPv3 Applications > - 37-44: > This memo describes five types of SNMP applications which make use of > an SNMP engine as described in [RFC2271]. The types of application > described are Command Generators, Command Responders, Notification > Originators, Notification Receivers, and Proxy Forwarders. > > This memo also defines MIB modules for specifying targets of > management operations, for notification filtering, and for proxy > forwarding. > - 1561: > SNMP-TARGET-MIB DEFINITIONS ::= BEGIN > - 2209: > snmpTargetCommandResponderCompliance MODULE-COMPLIANCE > - 2305: > SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN > - 2773: > snmpNotifyBasicCompliance MODULE-COMPLIANCE > - 2881: > snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE > - 2894: > snmpNotifyFullCompliance MODULE-COMPLIANCE > - 2960: > SNMP-PROXY-MIB DEFINITIONS ::= BEGIN > - 3242: > snmpProxyCompliance MODULE-COMPLIANCE > > rfc2274.txt: User-based Security Model (USM) for SNMPv3 > - 37-41: > This document describes the User-based Security Model (USM) for SNMP > version 3 for use in the SNMP architecture [RFC2271]. It defines the > Elements of Procedure for providing SNMP message level security. > This document also includes a MIB for remotely monitoring/managing > the configuration parameters for this Security Model. > - 861: > USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > - 1701: > SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN > - 2439: > usmMIBCompliance MODULE-COMPLIANCE > > rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 > - 38-42: > This document describes the View-based Access Control Model for use > in the SNMP architecture [RFC2271]. It defines the Elements of > Procedure for controlling access to management information. This > document also includes a MIB for remotely managing the configuration > parameters for the View-based Access Control Model. > - 541: > SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN > - 1356: > vacmMIBCompliance MODULE-COMPLIANCE > ------------------------------------------------------------------------ From jkm at underscore.com Mon Mar 23 10:22:51 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> This is a *great* thread. Hopefully everyone is reading the exchanges between Randy and Ira so as to quickly come up to speed on the applicability (or not) of SNMPv3 to the network printer universe. One comment Ira wrote to Randy is particularly notable: > >I don't think SNMPv3 is heavyweight. It's designed be implemented in > >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM > >switches. And I think whatever solution we come up with will have to > >have the capability to support a distributed event notification system, > >similar to the way SENSE and other distributed notification mechanisms > >remove the burden from individual embedded printers from having to keep > >up with the entire world of notifications. > > IEM> But, your examples are all of infrastructure (intermediate-systems), > not printers, scanners, and other end-systems. Managing a hub or router > has essentially nothing in common with managing end-systems, except that > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be > widely deployed for at least the next three years - look at the deployment > track record of SNMPv2! In essence, all things are *not* necessarily equal under SNMP in terms of scale and functionality. I have been trying to get people in the PWG to understand this essential fact for years now. SNMP was designed for "network elements" (what Ira calls "infrastructure elements", another good name). That was the sole problem domain for which SNMP was designed. Can SNMP be used for other applications? Of course. Must we necessarily constrain our product designs around the limitations of SNMP? (That is, if SNMP can't do it, then either can/should we.) That's silly. Just because you can, doesn't mean you should... > No vendor can tell their customers that they can't manage their printers > until they deploy (largely non-existant) new enterprise open management > systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that > have support for SNMPv3 (some of those that I just mentioned don't have > support for SNMPv2, yet). Xerox research has found that many customers > HATE to be told that "this product just requires a few little server > applications." Elegant distributed event notification schemes like > SENSE are very unpopular with Xerox product planners and marketers > (and customers). Perhaps your customers haven't been bitten by unstable > NetWare NLMs or NT server applications? Amen, brother. We at Underscore constantly wrestle with the plain fact that customers ABHORE the need to install/maintain/operate additional components required to make your product work. That cold, hard fact became painfully obvious with our work on designing a product-oriented implementation of SENSE. For example, we needed a very, very lightweight directory service. No problem. How about LDAP? What about SLP? Hey, even NDS may be possible. And yet the continual problem we faced was: Which lightweight directory is ubiquitously available across all major server platforms today? The answer, of course, is: None. So we had to (quickly) design/implement the very, very lightweight directory service directly inside SENSE. It was no big deal, and we do not have any external dependencies that customers abhore. > [Jay, I personally think SENSE is good stuff - but technical excellence > isn't the only or even major factor in the deployment of technology.] Again, amen. I would never consider the current SENSE design as "technically excellent". That was NEVER the goal. The goals? Simple. Very lightweight. Eminently portable. Easy to use. Easy to understand. Easy to extend. Low resource requirements. ...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 Mar 23 10:26:43 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3.0.1.32.19980206183723.00b22c50@garfield> Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients. I agree 110%. That fundamental belief is one of the most critical assumptions for which SENSE was designed. Namely, require the managed entity (ie, a printer) to provide minimal scalability for key services (ie, just a few simultaneous client accesses), then route that information into a generalized client/server system with a very high degree of scalability. ...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 Mon Mar 23 13:38:27 1998 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:04:26 2009 Subject: SENSE> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> All, We have had a rather intensive debate between Randy, who first proposed that we might want to use SNMPv3 traps or informs for IPP notifications, and Ira, who thinks that the whole idea is wrong. With the exception of Jay's comments earlier today, it has been very quiet from the rest of the group on this subject. Are there any other views on the subject? Do you support one or the other combattants' views? If all we will be hearing is arguments between mainly two people with diametrically opposite views, we are not going to archieve anything. We are supposed to discuss this next week in the IETF in LA and it would be nice to have a little better understanding of where the group stands in this debate by then. Should we abandon SNMPv3 as a candidate for IPP notifications and concentrate our efforts on a new or different solution? Please give more feedback to the DL. 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 harryl at us.ibm.com Mon Mar 23 13:54:01 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica In-Reply-To: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica> Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> I response to Ira' comment... > IEM> But, your examples are all of infrastructure (intermediate-syste= ms), > not printers, scanners, and other end-systems. Managing a hub or rou= ter > has essentially nothing in common with managing end-systems, except t= hat > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to= be > widely deployed for at least the next three years - look at the deplo= yment We (PWG) crossed the "using SNMP to manage printers" question long ago.= Some people have never been comfortable with it but no one can deny we did. = To some degree, one can argue that every network element is part of it's infrastructure. That's pretty much how I believe we got where we are. I= 'm not saying it's right or wrong. I've just been trying to make good use of i= t rather than judge it or wish for something different. Also, I don't believe we can predict SNMPv3 rollout based on V2 lag. SN= MPv2 had a goory history - so bad that many chose not to implement. I view SNMPv= 3 as the answer to the v2 problem, not a repeat of it. Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Mon Mar 23 14:15:11 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica In-Reply-To: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica> Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> I also agree... (its not realistic for a simple embedded device to mai= ntain notification info for hundreds of clients). But, this does not mean tha= t the embedded Device should never be able to handle notification to multiple= clients. There may be more than one "notification server", or some smal= ler scale networks using peer-to-peer printing without a notification serve= r. Yes, the embedded device will ultimately limit the number of notificati= on hosts it can service, but (as I presented in Austin) I feel 16 - 32 is not unreasonable for many "network printers". Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 03/23/98 08:33:19 AM Please respond to owner-sense@pwg.org To: rturner@sharplabs.com cc: sense@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notification Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a sim= ple > embedded device to maintain notification info for hundreds of clients= From paulmo at microsoft.com Mon Mar 23 14:42:56 1998 From: paulmo at microsoft.com (Paul Moore) Date: Wed May 6 14:04:26 2009 Subject: SENSE> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> Some time since I aired my views on this. I think we should make IPP notifications a mechanism whereby a client can request that a notification be sent to it via any mechanism. That is to say - the notification itself is sent any way you like and is not part of IPP. IPP merely provides the means for the client to request that this be done. We might want to define some standard optional mechanisms (email being the obvious one). All notifications are optional. The IPP Model also needs to define what events are notification candidates and what they mean. The IPP request indicates which events it wants notification on, what mechanism to use, any parameters associated with that mechanism (email address) and maybe message content. The mechanisms available should be something that is queryable (get printer attributes). There is a separate thing that deals with device level alerts and events - along with robust data transmission, etc. etc. My thoughts on that topic have already been aired! > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 10:38 AM > To: ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > All, > > We have had a rather intensive debate between Randy, who first > proposed that we might want to use SNMPv3 traps or informs for > IPP notifications, and Ira, who thinks that the whole idea is > wrong. > > With the exception of Jay's comments earlier today, it has been > very quiet from the rest of the group on this subject. Are there > any other views on the subject? Do you support one or the other > combattants' views? > > If all we will be hearing is arguments between mainly two people > with diametrically opposite views, we are not going to archieve > anything. > > We are supposed to discuss this next week in the IETF in LA and > it would be nice to have a little better understanding of where > the group stands in this debate by then. Should we abandon SNMPv3 > as a candidate for IPP notifications and concentrate our efforts > on a new or different solution? > > Please give more feedback to the DL. > > 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 cmanros at cp10.es.xerox.com Mon Mar 23 16:10:02 1998 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:04:26 2009 Subject: SENSE> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.mi> Message-ID: <3.0.1.32.19980323131002.00ceac30@garfield> Paul, As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email. There has been some interesting discussion lately in the IFAX group about their intended use of MDNs for notifications over email. Those seem to indicate that implementation and actual use of MDNs in email is likely to be a very slow process... Carl-Uno At 11:42 AM 3/23/98 PST, Paul Moore wrote: >Some time since I aired my views on this. > >I think we should make IPP notifications a mechanism whereby a client can >request that a notification be sent to it via any mechanism. > >That is to say - the notification itself is sent any way you like and is not >part of IPP. IPP merely provides the means for the client to request that >this be done. > >We might want to define some standard optional mechanisms (email being the >obvious one). All notifications are optional. > >The IPP Model also needs to define what events are notification candidates >and what they mean. > >The IPP request indicates which events it wants notification on, what >mechanism to use, any parameters associated with that mechanism (email >address) and maybe message content. > >The mechanisms available should be something that is queryable (get printer >attributes). > >There is a separate thing that deals with device level alerts and events - >along with robust data transmission, etc. etc. My thoughts on that topic >have already been aired! > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, March 23, 1998 10:38 AM >> To: ipp@pwg.org >> Cc: jmp@pwg.org; sense@pwg.org >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? >> >> All, >> >> We have had a rather intensive debate between Randy, who first >> proposed that we might want to use SNMPv3 traps or informs for >> IPP notifications, and Ira, who thinks that the whole idea is >> wrong. >> >> With the exception of Jay's comments earlier today, it has been >> very quiet from the rest of the group on this subject. Are there >> any other views on the subject? Do you support one or the other >> combattants' views? >> >> If all we will be hearing is arguments between mainly two people >> with diametrically opposite views, we are not going to archieve >> anything. >> >> We are supposed to discuss this next week in the IETF in LA and >> it would be nice to have a little better understanding of where >> the group stands in this debate by then. Should we abandon SNMPv3 >> as a candidate for IPP notifications and concentrate our efforts >> on a new or different solution? >> >> Please give more feedback to the DL. >> >> 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 > > 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 paulmo at microsoft.com Mon Mar 23 16:29:20 1998 From: paulmo at microsoft.com (Paul Moore) Date: Wed May 6 14:04:26 2009 Subject: SENSE> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323131002.00ceac30@garfield> If this is the case "As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email." Then why is there a discussion? I can use anything I like for notifications. I cannot see why SNMP appears in this discussion. If a system wants to use SNMP to get events from a device then this is already possible - it has nothing to do with IPP. What IPP needs is end user focussed stuff (pagers, email, etc.). Faster than email would be the network native messenger service (SMB Net Send for example). > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 1:10 PM > To: Paul Moore; ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > Paul, > > As far as I am aware, we seem to have agreements on most of the points in > your message. The area in which there is still debate is for a delivery > mechanism, that can send out notifications more quickly than with email. > > There has been some interesting discussion lately in the IFAX group about > their intended use of MDNs for notifications over email. Those seem to > indicate that implementation and actual use of MDNs in email is likely to > be a very slow process... > > Carl-Uno > > > At 11:42 AM 3/23/98 PST, Paul Moore wrote: > >Some time since I aired my views on this. > > > >I think we should make IPP notifications a mechanism whereby a client can > >request that a notification be sent to it via any mechanism. > > > >That is to say - the notification itself is sent any way you like and is > not > >part of IPP. IPP merely provides the means for the client to request that > >this be done. > > > >We might want to define some standard optional mechanisms (email being > the > >obvious one). All notifications are optional. > > > >The IPP Model also needs to define what events are notification > candidates > >and what they mean. > > > >The IPP request indicates which events it wants notification on, what > >mechanism to use, any parameters associated with that mechanism (email > >address) and maybe message content. > > > >The mechanisms available should be something that is queryable (get > printer > >attributes). > > > >There is a separate thing that deals with device level alerts and events > - > >along with robust data transmission, etc. etc. My thoughts on that topic > >have already been aired! > > > >> -----Original Message----- > >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> Sent: Monday, March 23, 1998 10:38 AM > >> To: ipp@pwg.org > >> Cc: jmp@pwg.org; sense@pwg.org > >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > >> > >> All, > >> > >> We have had a rather intensive debate between Randy, who first > >> proposed that we might want to use SNMPv3 traps or informs for > >> IPP notifications, and Ira, who thinks that the whole idea is > >> wrong. > >> > >> With the exception of Jay's comments earlier today, it has been > >> very quiet from the rest of the group on this subject. Are there > >> any other views on the subject? Do you support one or the other > >> combattants' views? > >> > >> If all we will be hearing is arguments between mainly two people > >> with diametrically opposite views, we are not going to archieve > >> anything. > >> > >> We are supposed to discuss this next week in the IETF in LA and > >> it would be nice to have a little better understanding of where > >> the group stands in this debate by then. Should we abandon SNMPv3 > >> as a candidate for IPP notifications and concentrate our efforts > >> on a new or different solution? > >> > >> Please give more feedback to the DL. > >> > >> 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 > > > > > 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 walker at dazel.com Tue Mar 24 10:12:23 1998 From: walker at dazel.com (James Walker) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3517CD57.28B24665@dazel.com> Jay Martin wrote: > > Turner, Randy wrote: > > > I will reiterate my belief that I don't think its realistic for a simple > > embedded device to maintain notification info for hundreds of clients. > > I agree 110%. That fundamental belief is one of the most critical > assumptions for which SENSE was designed. Namely, require the > managed entity (ie, a printer) to provide minimal scalability for > key services (ie, just a few simultaneous client accesses), then > route that information into a generalized client/server system > with a very high degree of scalability. Well, here we go again... Is it just me, or are we running into the embedded printer requirements versus the print server requirements. If we are talking about IPP, the host to device protocol, then I agree that the device need only support a limited number of notification clients. If we are talking about IPP, the print client to server protocol, then I believe that print server ought to be able to scale to 100's, even 1000's, of clients. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From jkm at underscore.com Thu Jun 18 16:35:36 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: FIN> On reading the FIN draft In-Reply-To: On reading the FIN draft> Message-ID: <3517CD57.28B24665@dazel.com> Harry, > With regard to trap registration... I agree. I think, if you've been following > the Notifications discussions in the PWG (which I'm sure YOU have ;-), you'll > find proposals to define PWG specific registration schemes "rejected" on the > basis that SNMPv3 supplies most of what we need. As for "things we did with the > Job MIB"... remember, it was the IETF who turned their backs on us... this is > strictly a PWG standard. With all due respect, the fact that the Job MIB is not under the domain of the IETF has nothing to do with the concept of developing standard techniques in an open arena. I personally struggled with this concept while developing the SENSE technology. I knew all along that a system of inexpensive, light-weight, scalable event notification was of emminent utility around the world, across almost every type of distributed application. Hence, I was (and remain) quite shy about having the PWG declare its own notification system without regard for the needs of others. This is but one reason I put the brakes on the SENSE project--to wait and see if other proposals would emerge in a reasonable time frame. (I am now monitoring the WebDAV's ENP effort quite closely.) Just because the IETF declined to embrace the Job MIB shouldn't mean we have license to institute any kind of related technology we find interesting or useful. Give unto Caesar what is Caesar's, and all that rot... ;-) Please do understand, though, that I wholeheartedly encourage members of the PWG to band together and form a new IETF WG to address any IETF-related technology opportunity as a separate group. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From harryl at us.ibm.com Thu Jun 18 16:48:37 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Re: FIN> On reading the FIN draft In-Reply-To: On reading the FIN draft> Message-ID: <3517CD57.28B24665@dazel.com> Jay - I'm not quite sure what we're talking about here. Generally, I ag= ree wholeheartedly with what you are saying. For Notifications, it is clear= that the PWG has shown a desire to investigate existing or emerging standard= s as the basis for a solution. Originally, Paul Moore had commented on the robus= t use of attributes in the FIN MIB... a scheme we adopted in development of the = JOB MIB to reduce the number of OIDs and avoid an approach which had proven les= s than useful with the Printer MIB (Mandatory/Optional). No-one core to the Jo= b MIB team and no-one having prototyped and/or implemented the Job MIB seems = to have any issues. Admittedly, someone reviewing this for the first time (as P= aul was in the FIN MIB) may wonder. I was only trying to help Paul at least und= erstand the CONTEXT... even if he decides to persist in his disagreement with t= he method. Harry Lewis - IBM Printing Systems jkm@underscore.com on 06/18/98 02:42:15 PM Please respond to jkm@underscore.com To: sense@pwg.org, fin@pwg.org, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: FIN> On reading the FIN draft Harry, > With regard to trap registration... I agree. I think, if you've been = following > the Notifications discussions in the PWG (which I'm sure YOU have ;-)= , you'll > find proposals to define PWG specific registration schemes "rejected"= on the > basis that SNMPv3 supplies most of what we need. As for "things we di= d with the > Job MIB"... remember, it was the IETF who turned their backs on us...= this is > strictly a PWG standard. With all due respect, the fact that the Job MIB is not under the domain of the IETF has nothing to do with the concept of developing standard techniques in an open arena. I personally struggled with this concept while developing the SENSE technology. I knew all along that a system of inexpensive, light-weight, scalable event notification was of emminent utility around the world, across almost every type of distributed application. Hence, I was (and remain) quite shy about having the PWG declare its own notification system without regard for the needs of others. This is but one reason I put the brakes on the SENSE project--to wait and see if other proposals would emerge in a reasonable time frame. (I am now monitoring the WebDAV's ENP effort quite closely.) Just because the IETF declined to embrace the Job MIB shouldn't mean we have license to institute any kind of related technology we find interesting or useful. Give unto Caesar what is Caesar's, and all that rot... ;-) Please do understand, though, that I wholeheartedly encourage members of the PWG to band together and form a new IETF WG to address any IETF-related technology opportunity as a separate group. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- = From jeff at underscore.com Tue Jun 23 10:50:52 1998 From: jeff at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Please ignore this test message. Message-ID: <3517CD57.28B24665@dazel.com> Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From don at lexmark.com Mon Sep 14 15:26:47 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:26 2009 Subject: SENSE> Mailing Lists Message-ID: <199809141927.AA13984@interlock2.lexmark.com> The mailing lists are back up and running. Just to test everything out, I have sent this mail to ALL the mailing lists. If you get this mail on one list and not on another you think you should be on then I suggest you resubscribe by sending e-mail to: majordomo@pwg.org with the body of the note containing subscribe when is the name of the list you wish to subscribe to. You can include multiple subscriptions in the same note. Thanks for your patience during this transfer. ********************************************** * 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) * **********************************************