IPP Mail Archive: Re: IPP>NOT mailto feature from IETF meeti

IPP Mail Archive: Re: IPP>NOT mailto feature from IETF meeti

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

From: Carl Kugler/Boulder/IBM (kugler@us.ibm.com)
Date: Wed Aug 16 2000 - 19:09:36 EDT

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


    I have a hypothetical scenario that might justify machine-readable
    notifications within email messages. Consider the "QUALDOCS-Box". This is
    a machine that replaces your fax machine some day. To the end user, it is
    similar to the old fax machine, but this machine plugs into a network drop
    instead of a phone jack. And you punch in URIs instead of phone numbers.
    Whether you're faxing or printing, sometimes things go wrong. Some errors
    are retryable, and most fax machines will try to send a document three
    times or so before giving up.

    Today, our IPP clients do automatic retries (with expontial backoff) on the
    following errors:

         Ipp 0x0502 server-error-service-unavailable
         Ipp 0x0505 server-error-temporary-error
         Ipp 0x0507 server-error-busy
         Http 503 Service Unavailable
          Tcp (any)

    (These clients are not end user clients; they are output subsystems in
    Infoprint Server and Infoprint Manager.)

    However, these return codes are only useful for determining the success or
    failure of the job submission. To find out the final disposition of the
    job, we have to rely on notifications. Some notifiable events might
    warrant a retry. For example, job-state goes to 'aborted' for
    job-state-reasons 'submission-interrupted'. A QUALDOCS-Box might do an
    automatic retry in this case. If, for whatever reason, the QDB could only
    get email notifications from a particular IPP Printer, it would need a
    machine-readable notification in order to be able to take this action.

    In summary, an IPP client isn't always an end-user client. It might be
    built into a dedicated device, or be part of a print server. In these
    cases, a machine readable email notification might be useful.


    --- In ipp@egroups.com, Jay Martin <jkm@u...> wrote:
    > 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

    This archive was generated by hypermail 2b29 : Wed Aug 16 2000 - 19:18:21 EDT