IPP Mail Archive: Re: IPP> machine readable etc. - why Harry

IPP Mail Archive: Re: IPP> machine readable etc. - why Harry

Re: IPP> machine readable etc. - why Harry is right

From: Ron Bergman (rbergma@hitachi-hkis.com)
Date: Thu Aug 17 2000 - 13:43:10 EDT

  • Next message: Jay Martin: "Re: IPP> machine readable etc. - why Harry is right"

    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@peerless.com [mailto:pmoore@peerless.com]
    > Sent: Thursday, August 17, 2000 12:47 PM
    > To: McDonald, Ira
    > Cc: 'jkm@underscore.com'; McDonald, Ira; 'Harry Lewis/Boulder/IBM';
    > ipp@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@sharplabs.com> on 08/17/2000 09:20:20 AM
    > To: "'jkm@underscore.com'" <jkm@underscore.com>, "McDonald, Ira"
    > <imcdonald@sharplabs.com>
    > cc: "'Harry Lewis/Boulder/IBM'" <harryl@us.ibm.com>, ipp@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@underscore.com]
    > Sent: Wednesday, August 16, 2000 1:31 PM
    > To: McDonald, Ira
    > Cc: 'Harry Lewis/Boulder/IBM'; ipp@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@us.ibm.com]
    > > Sent: Wednesday, August 16, 2000 8:01 AM
    > > To: jkm@underscore.com
    > > Cc: imcdonald@sharplabs.com; ipp@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

    This archive was generated by hypermail 2b29 : Thu Aug 17 2000 - 13:40:44 EDT