Harry and Carl's idea is still in the initial stages because there are
questions about whether it works through proxies. Someone needs to prototype
it and no one has had time. We are not sure whether proxies will keep the
connection open for the duration of a response that lasts a long time with
periods of transmission and other period of no transmission.
-----Original Message-----
From: Jay Martin [mailto:jkm@underscore.com]
Sent: Wednesday, August 16, 2000 5:30 PM
To: Carl Kugler/Boulder/IBM
Cc: IPP Mailing List; Harry Lewis/Boulder/IBM
Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
TheIPPNotification I-Ds will now go the IESG)
Carl,
Oops...it appears you caught me snoozing at the wheel on
the in-band vs. native, etc. ;-)
But either way--and this is a BIG ISSUE FOR EVERYONE--if
the IPP spec doesn't support what the group believes is
a major opportunity for IPP (in this case, QUALDOCS-like
fax services), then shouldn't the spec be revisited?
Ok, let's say I was asleep during the battle for putting
in the right data to make QUALDOCS-fax work. Somehow the
consensus was against you and Harry such that the info you
need is not in the spec (right?).
What exactly was the basis for denying you this information?
(If you have a pointer to a past msg, feel free to point me
there.)
...jay
Carl Kugler/Boulder/IBM wrote:
>
> > If this device is indeed going to take off, then it would seem the
> > world would be better served by modifying IPP to return the kind of
> > information the device would need to make further decisions.
>
> Jay, are you up to your rhetorical questions tricks again? :-) You KNOW
> that's what I've always wanted. That's why Harry and I have been harping
> on and on forever about "native", "in-band" notifications; multipart
> responses, server-directed polling, etc., all of which finally morphed
into
> the ipp-notify-poll (or is it ipp-notify-get?) delivery method.
> [Unfortunately, I was diverted at the time I needed to be nursing our
> proposal along. A recent change in assignment means I MIGHT actually get
a
> chance to build the dang thing.]
>
> -Carl
>
> P.S. What is RBOC bypass?
>
> Jay Martin <jkm@underscore.com> on 08/16/2000 05:26:21 PM
>
> Please respond to jkm@underscore.com
>
> To: Carl Kugler/Boulder/IBM@IBMUS
> cc: IPP Mailing List <ipp@pwg.org>
> Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The
> IPPNotification I-Ds will now go the IESG)
>
> Carl,
>
> Interesting scenario, for sure. I have no idea of the market window
> or acceptance rate of such a device, but it sure does sound dandy.
>
> However, I find you making your case based on the *shortcomings* of
> the response information during the IPP transaction:
>
> > Today, our IPP clients do automatic retries (with expontial backoff) on
> the
> > following errors:
> >
> > [snip]
> >
> > 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.
>
> If this device is indeed going to take off, then it would seem the
> world would be better served by modifying IPP to return the kind of
> information the device would need to make further decisions.
>
> To imply that machine-readable email is required due to a shortcoming
> of IPP doesn't sound like the right technical decision if a device of
> this kind is expected to have major global acceptance in the near future,
> wouldn't you say?
>
> I sure do like the application, though. Very neat. Yet another RBOC
> bypass opportunity. ;-)
>
> ...jay
>
> Carl Kugler/Boulder/IBM wrote:
> >
> > Jay-
> >
> > 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.
> >
> > -Carl
> >
> > --- 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 - 23:45:56 EDT