IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session - July 14, 199 9 in Oslo

IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session - July 14, 199 9 in Oslo

Ron Bergman rbergma at dpc.com
Wed Aug 4 20:23:16 EDT 1999


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




More information about the Ipp mailing list