Thanks, Ron. I find it interesting that we've got (at least) 3 major spheres of
application for notifications.
1. Send me an e-mail (pager, fog-horn...) when my job is done. Must traverse the
wide net, firewalls etc.
2. (other end of spectrum)... Send (possibly unreliable UDP) traps for each page
complete so I can write an informative end-user progress application. Can be
Intra confined as opposed to Internet.
3. QUALDOCS - Needs reliable end of job AND page progress AND must traverse the
Internet!
The best approach to QUALDOCs notifications I've seen so far is Carl Kugler's
suggestions about "in-band" HTTP responses. This has the advantages
a. Utilizes an existing connection
b. Reliable - TCP
c. Traverses (HTTP).
Of course, if this solution is good for QUALDOCs it may also be applicable to
the Intranet (2), as well.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
Ron Bergman <rbergma at dpc.com> on 08/04/99 06:23:16 PM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: ipp at pwg.org
Subject: Re: IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session -
July 14, 199 9 in Oslo
Harry,
I agree with you 100%. As I have stated before, there may be optimal
notification delivery methods different notifications. The decision in
favor of TCP for page descriptions was based upon the recommendation by
Jim Rafferty that for QUALDOCS, the page completion information must be
reliable. This is what is currently expected for fax. This issue will
certainly be discussed in depth as a part of the QUALDOCS project.
Ron Bergman
Hitachi Koki Imaging Solutions
On Wed, 4 Aug 1999 harryl at us.ibm.com wrote:
-- snip snip --
>> 3. I disagree with the (evidently) prevailing perspective regarding UDP.
> > For "per page" event notification, it is suggested that
> >TCP connections should be used.
> The bad thing about per page notification is there are so many of them.
> The nice thing about per page notification is there are so many of them.
> The multiplicity of per page notifications provides a natural redundancy such
> that
> a. If you drop a few you can always "catch up"... after all... it's just a
> progress
> indicator. How many times has your web browser given you misleading
> "progress" (14 sec remaining for the last 2 minutes) yet you'd rather
> have this than no progress at all
> b. There are multiple opportunities to deliver the notification "payload".
> Thus, information IN the payload that might be crucial to identifying
> the job, user, etc... is insured by redundancy rather than by
> session and packet guarantee.
> c. These are small payloads. If congestion gets so bad that redundancy
> is failing... we're probably not doing much printing, either.
>> 3. What is the rationale behind duplicate subscriptions? I've missed this one.
> > Duplicate subscriptions will be allowed. A Printer might suppress
> >duplicate notifications.
>