Bill makes a good point! The requirements for QualDocs could be viewed
as somewhat different from IPP in general. But a "native IPP notification"
(as Harry has referred to his proposed method) would be a very nice
addition to IPP. Work on this within QualDocs is an excellent suggestion.
The recent scenario of email as a notification method for QualDocs does not
fit within the requirements of QualDocs. The goal of QualDocs is to define
a "real time" internet-fax and eliminate the problems in the current email
based internet-fax.
Ron Bergman
Hitachi Koki Imaging Solutions
"Wagner,William" wrote:
> If I recall correctly, Harry's approach was morphed into the not equivalent
> Get because it did not address the established "requirement" that IPP
> notification allow notification of recipients other that the client
> submitting the job and at the time that the client was submitting the job.
> The argument that third party notification and notification subscriptions
> were not necessary was not accepted for IPP in general, but may be quite
> valid for QualDocs. As such, this may be pursued in conjunction with the
> QualDocs definition.
>> As suggested, the indicated objections to mail-to can be addressed, but I
> think this is a separate matter.
>> William A. Wagner (Bill Wagner)
> Director of Technology
> Imaging Division
> NETsilicon, Inc.
> 781-398-4588
>> -----Original Message-----
> From: pmoore at peerless.com [mailto:pmoore at peerless.com]
> Sent: Thursday, August 17, 2000 12:47 PM
> To: McDonald, Ira
> Cc: 'jkm at underscore.com'; McDonald, Ira; 'Harry Lewis/Boulder/IBM';
>ipp at pwg.org> Subject: IPP> machine readable etc. - why Harry is right
>> The more I listen to this debate the more Harry's proposal makes sense.
>> INDP will have issues with firewalls; I dont beleive email is practical for
> a
> real solution (see footnote), this leaves Harry's 'honest its not polling'
> mechanism. The objection to Harry's mechanism (I apologize to the other
> authors
> but Harry is the one that sticks in my mind) that connections will close is
> not
> valid in most cases. instant messenger systems are based on long lived
> connections and proxies dont chop them off (mine certainly doesnt)
>> PS
>> Why isnt email practical.
>> 1. Who will set up the mailbox for the client? Every client will need to
> have
> its own mailbox as well as the normal one for the human user. This doesnt
> seem
> like a 'drop in ' solution transparent to the net admins. It merely moves
> the
> hassle from the proxy admin to the email admin. The client cant have its own
> SMTP server since we are presupposing aggressive firewalls.
>> 2. Email systems do not promise to deliver messages a) in order b) in a
> timely
> fashion. An email message that arrives 1 hour late is normal, what will a
> client
> do if it doesnt receive notification after 1 hour of success or failure?
>> 3. Many people now use hotmail / yahoo style email systems where they read
> messages on a central server and never down load them. It is simply not
> possible
> to set up an email mailbox for these users that their client can read
> programmatically
>> 4. Many home users have restricted email accounts from their ISPs. It costs
> money to get extra ones
>> I am sure each objection could be addressed, but the point is that machine
> readable email is not a slam dunk. Sure we can put machine readable content
> in
> email messages but I am not sure that this will produce the solution we are
> looking for.
>> "McDonald, Ira" <imcdonald at sharplabs.com> on 08/17/2000 09:20:20 AM
>> To: "'jkm at underscore.com'" <jkm at underscore.com>, "McDonald, Ira"
> <imcdonald at sharplabs.com>
> cc: "'Harry Lewis/Boulder/IBM'" <harryl at us.ibm.com>, ipp at pwg.org (bcc:
> Paul
> Moore/AUCO/US)
>> Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The
> IPP
> Notification I-Ds will now go the IESG)
>> Hi Jay,
>> PRIOR to Bob Herriot's latest proposal, ALL previous
> texts of the 'mailto:' delivery method for IPP
> Notifications have permitted the IPP Printer (or
> other notification generator) to insert machine-readable
> content at will - please read the documents.
>> There has never been any concensus to completely
> remove the ability to send machine-readable with
> 'mailto:' and it's never been documented in any
> version of the working spec.
>> Note that Adobe Acrobat Reader is NOT built by MS,
> Netscape or any other browser manufacturer. It's
> just a simple application reader utility. Among
> other useful goals, the current IPP Open Source
> Client activity could quite easily produce and
> freely distribute (like Acrobat Reader) this app.
>> NOTHING at all has to be done by a browser
> manufacturer to enable this - it's just a new
> MIME type that is connected to a well-known app in
> the end user's environment when the end user
> installs the reader app.
>> By the way, QualDocs is going to very badly need
> machine-readable IPP notifications over email or
> it's never going to work gracefully to extend the
> current IETF Internet Fax standards - they're all
> based on email notifications.
>> Cheers,
> - Ira
>> -----Original Message-----
> From: Jay Martin [mailto:jkm at underscore.com]
> Sent: Wednesday, August 16, 2000 1:31 PM
> To: McDonald, Ira
> Cc: 'Harry Lewis/Boulder/IBM'; 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)
>> 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