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

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

From: Wagner,William (bwagner@digprod.com)
Date: Thu Aug 17 2000 - 13:07:05 EDT

  • Next message: Jay Martin: "Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The IPP Notification I-Ds will now go the IESG)"

    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.

    -----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';
    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
    real solution (see footnote), this leaves Harry's 'honest its not polling'
    mechanism. The objection to Harry's mechanism (I apologize to the other
    but Harry is the one that sticks in my mind) that connections will close is
    valid in most cases. instant messenger systems are based on long lived
    connections and proxies dont chop them off (mine certainly doesnt)


    Why isnt email practical.

    1. Who will set up the mailbox for the client? Every client will need to
    its own mailbox as well as the normal one for the human user. This doesnt
    like a 'drop in ' solution transparent to the net admins. It merely moves
    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
    fashion. An email message that arrives 1 hour late is normal, what will a
    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
    to set up an email mailbox for these users that their client can read

    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
    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"
    cc: "'Harry Lewis/Boulder/IBM'" <harryl@us.ibm.com>, ipp@pwg.org (bcc:

    Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The
          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.

    - 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)


    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).


    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:16:07 EDT