Ira,
I find it quite discouraging to see that you continually side-step
the issue of the likely lack of available client-side software to
make this thing truly useful on a mass scale.
Who's going to provide the client-side software? Microsoft? Netscape?
Do you honestly believe this kind of capability is going to shoot
adreneline through these major infrastructure component companies
such that they're going to quickly add integrated support to their
mail products?
Recall that a very early premise of using HTTP for IPP was the
significant expectation that Netscape would be there with the PWG,
side-by-side, such that Netscape's products would have integrated
support for IPP right in the browser. Well, that just didn't happen.
How is this situation any different? Do you expect a company like
Xerox or Sharp to bestow a free capability to the world to make the
feature usable? Perhaps you expect this capability to represent some
sort of "market builder" concept in which many companies will rush
several competing products to market?
The PWG always prided itself on being more business-oriented than
other pure standards organizations (eg, the IETF, with all due respect).
A standards effort is started because a concensus declares market
viability. Moreover, the effort is scoped so that resulting products
(free or otherwise) are developmentally possible within a reasonable
period of time. And, above all, there is a clear and present benefit
by delivering products that build on the standard.
I (and others) have repeatedly stated that this is NOT the case with
machine-readable notifications within email messages. Just because
you CAN do something doesn't mean you SHOULD. (Deja vu all over again.)
Please don't misunderstand me here. If someone wants to go off and
submit a paper to the IETF and publish UNDER HIS/HER/THEIR names as
an "Informational" protocol (or whatever the term that's used to
denote a private research project), I have absolutely no problem with
that (and, in fact, would encourage it).
What I (and others) do NOT want is yet another long, drawn-out standards
effort that gets fatter and Fatter and FATTER as time goes on, one that
sucks up precious cycles from the PWG membership.
And with that, I shall refrain from further responses on this subject
unless explicitly asked (or targeted).
...jay
PS: In spite of this discord, I hope you and Nancy are enjoying a fine
Grand Marais summer! I wish Nancy the best with her gardening efforts.
"McDonald, Ira" wrote:
>> Hi Harry and Jay,
>> I agree with MOST of Harry's points below - as I
> never attended any of the PWG monthly meetings
> (which, for a variety of procedural reasons are
> NOT qualified as official meetings of the IETF IPP WG)
> I wasn't around for this elusive decision to force
> machine-readable out of email notifications.
>> The utility of machine-readable has NO RELATIONSHIP
> to whether notification is real-time or store/forward.
> There is MUCH more usable content in machine-readable
> for any client application. Doing printer-side
> localization of more attributes in the human-readable
> encoding just worsens interoperability. We (IPP WG)
> don't standardize the translations of the thousands
> of attribute names and attribute keyword and enum
> tag values, do we?
>> For what it's worth, I've got several implementation
> teams interested in IPP notifications via SNMP using
> the Job Mon MIB and all of them want to do email.
> I haven't got any implementors interested in INDP,
> because it causes so many headaches with security
> policies on customer sites.
>> Cheers,
> - Ira McDonald
>> -----Original Message-----
> From: Harry Lewis/Boulder/IBM [mailto:harryl at us.ibm.com]
> Sent: Wednesday, August 16, 2000 8:01 AM
> To: jkm at underscore.com> Cc: imcdonald at sharplabs.com; ipp at pwg.org> Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> The IPP Notification I-Ds will now go the IESG)
>> 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