Right, Harry. I couldn't agree more.
As I mentioned in a previous reply to Bill Wagner, what I am
most concerned about is all the TIME it will take to get this
kind of standard through the PWG, with very little (if any)
real-world return on the effort.
This situation also points out a very longstanding problem in
the PWG, that even though the group collectively says "No" to
a given proposal, those same people just wait a little bit,
then put propose it again...and again...and again.
We really need to stop this, IMHO. (And I'm certainly not
alone in this belief.)
The PWG needs to *rapidly* develop simple, open standards
that address requirements that are within 2 sigma from the
norm, not the usual 14.5 sigma that we tend to see over and
over and over again (and usually from the same people).
It's no wonder Microsoft walked away from IPP and rolled their
own implementation without coordination or even passive
review/approval by the PWG participants (to ensure reasonable
coverage of features, point out potential conflicts, etc.).
Maybe the next generation of PWG folks will do better.
Let's hope so.
...jay
Harry Lewis/Boulder/IBM wrote:
>
> Jay asked for discussion.
>
> 1. This is a VERY old topic.
> 2. I thought we agreed LONG ago the e-mail notification was for human
> readable (only)
> 3. I thought we agreed LONG ago that real time notification to a client or
> "notification manager" application (i.e. machine readable) is desirable
> 4. I've argued (and proposed) a LONG time ago that, fundamentally, we need
> a simple, NATIVE machine readable method (i.e. works using the exact same
> infrastructure, no more, no less, as IPP).
> 5. Several additional machine readable methods have been proposed (INDP,
> SNMP, ...).
> 6. As diversity and choice are great in many context but not so great in
> "standards"... a litany of events, discussions, meetings, phone calls and
> e-mail have resulted in INDP as the recommended machine readable protocol.
>
> We currently just the Job MIB with SNMP notification (private - as the JMP
> team would not allow the definition of Job Traps... now they are defined
> for IPP... Odd!). Works fine. Yes, it's shown to be useful and desirable
> when facilitating rich end-user job progress and status information.
>
> Harry Lewis
> IBM Printing Systems
This archive was generated by hypermail 2b29 : Wed Aug 16 2000 - 11:30:50 EDT