IPP> NOT - Requirements - still needs an accounting applicati on scenario

IPP> NOT - Requirements - still needs an accounting applicati on scenario

Ron Bergman rbergma at dpc.com
Tue Jul 20 12:16:56 EDT 1999


Carl-Uno,

The issue of congestion control is only applicable to situations where
notifications were sent from one device at a high frequency.  Keith Moore
even stated that he did not believe that the congestion control feature in
TCP would ever be invoked due to relative infrequent notifications.  The
one exception was notifications for each page completed.  In this case a
reliable delivery is not necessay, since if I miss the fact the page 22
was completed, the notification that page 23 completed bring my display up
to date.  For this situation UDP without an ack is sufficient.

	Ron Bergman
	Hitachi Koki Imaging Solutions.


On Wed, 14 Jul 1999, Manros, Carl-Uno B wrote:

> Henrik,
> 
> The question about UDP vs. TCP/IP was discussed again in today's IETF IPP WG
> meeting.
> 
> Various people including Keith Moore, Scott Lawrence, and Rohit Kahre
> suggested that if we want to use UDP we would have to add features for
> congestion control and probably acknowledgements. They claimed that once we
> have done that, we have almost re-invented TCP/IP again. Their joint
> recommendation was to start off using TCP/IP after all and only consider UDP
> is an optional solution later if we run into problems with the TCP/IP
> version.
> 
> It does not seem that anybody has prototyped the two alternatives, so we are
> left with judgement calls at this stage.
> 
> Note, this does NOT mean that I suggest we should do the notification
> scenario.
> 
> Carl-Uno
> 
> > -----Original Message-----
> > From: henrik.holst at i-data.com [mailto:henrik.holst at i-data.com]
> > Sent: Wednesday, July 14, 1999 1:35 AM
> > To: Hastings, Tom N
> > Cc: ipp at pwg.org
> > Subject: RE: IPP> NOT - Requirements - still needs an accounting
> > applicati on scenario
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > "Hastings, Tom N" <hastings at cp10.es.xerox.com> on 14-07-99 01:19:15
> > 
> > To:   don at lexmark.com, "Hastings, Tom N" <hastings at cp10.es.xerox.com>
> > cc:   ipp at pwg.org (bcc: Henrik Holst/INT)
> > 
> > Subject:  RE: IPP> NOT - Requirements - still needs an 
> > accounting applicati on
> >       scenario
> > 
> > 
> > 
> > 
> > In Copenhagen we agreed that only the UDP delivery method should be
> > required, and that we should take out the TCP method. Because we would
> > like to keep the optional HTTP method, which is running on 
> > the top of TCP.
> > 
> > Henrik holst
> > 
> > 
> > 
> > 
> > Don,
> > 
> > This discussion is why we do Requirements.
> > 
> > Why don't you think that the notification that we have in the 
> > current specs
> > don't have enough reliability for accounting?  It would seem 
> > to me that the
> > TCP/IP notification delivery method which opens a channel and 
> > keeps it open
> > is pretty darn reliable.  Of course, the number of such 
> > channels would be an
> > implementation and/or a site policy decision, as would 
> > establishing the
> > authorization of which applications could use this method.
> > 
> > In fact, the group agreed at one point to make the TCP/IP 
> > delivery method a
> > REQUIRED method to implement (of course, that might change).
> > 
> > I agree that we wouldn't want the IPP notification spec to 
> > force printers to
> > stop printing if the accounting channel wasn't accepting 
> > notifications.  In
> > fact, we might just omit specing how the policy is 
> > established all together
> > about which applications are accounting and what happens when 
> > events can't
> > be delivered to them, leaving all this up to private 
> > implementation.  But
> > lets not rule out accounting as a Scenario and a requirement.
> > 
> > Tom
> > 
> > -----Original Message-----
> > From: don at lexmark.com [mailto:don at lexmark.com]
> > Sent: Tuesday, July 13, 1999 15:05
> > To: hastings at cp10.es.xerox.com
> > Cc: ipp at pwg.org
> > Subject: Re: IPP> NOT - Requirements - still needs an accounting
> > application scenar io
> > 
> > 
> > Tom:
> > 
> > We explicitly removed accounting because "accounting" implies 
> > a level of
> > reliability that the working group was not willing to sign up 
> > for.  We also
> > agreed that we do not want to include functionality such as 
> > forcing printing
> > to
> > stop of the accounting application is not accessable.
> > 
> > I therefore disagree with your proposed addition of Scenario #8.
> > 
> > **********************************************
> > * Don Wright                 don at lexmark.com *
> > * Director, Strategic & Technical Alliances  *
> > * Lexmark International                      *
> > * 740 New Circle Rd                          *
> > * Lexington, Ky 40550                        *
> > * 606-232-4808 (phone) 606-232-6740 (fax)    *
> > **********************************************
> > 
> > 
> > 
> > 
> > 
> > hastings%cp10.es.xerox.com at interlock.lexmark.com on 07/13/99 
> > 05:32:25 PM
> > 
> > To:   ipp%pwg.org at interlock.lexmark.com
> > cc:    (bcc: Don Wright/Lex/Lexmark)
> > Subject:  IPP> NOT - Requirements - still needs an accounting 
> > application
> > scenar
> >       io
> > 
> > 
> > 
> > 
> > The notes from the IPP WG meeting in Copenhagen changed the 
> > 7th Scenario
> > from "audit and accounting" to "usage statistics".  That is 
> > ok, provided
> > that we add a new Scenario that does include an accounting 
> > application using
> > the notification mechanism for push type of accounting, where the IPP
> > Printer pushes the accounting data to the accounting 
> > application.  Here a
> > high Quality of Service is desirable for those sites that want to do
> > reliable accounting.
> > 
> > Here is the original Scenario 7 (which was agreed to be 
> > changed to "usage
> > statistics application):
> > 
> > 7. I am an accounting or audit application. I subscribe 
> > independently from a
> > job submission so that my subscription outlasts any 
> > particular job.  My
> > subscription may persists across power cycles.  I subscribe with the
> > following attributes:
> > 
> > - Notification Recipient - me
> > - Notification Type - immediate
> > - Notification Events - job completion
> > - Notification Attributes - impression completed, sheets 
> > completed, time
> > submitted, time started, time completed, job owner, job size 
> > in octets, etc.
> > 
> > 
> > 
> > I suggest adding a Scenario 8:
> > 
> > 8. I am an accounting application. I subscribe independently 
> > from a job
> > submission so that my subscription outlasts any particular job.  My
> > subscription may persists across power cycles.  I subscribe with the
> > following attributes:
> > 
> > - Notification Recipient - me
> > - Notification Type - immediate
> > - Notification Events - job completion
> > - Notification Attributes - time submitted, time started, 
> > time completed,
> > job owner, job size in octets, job-k-octets-processed,
> > job-impressions-completed, job-media-sheets-completed, etc.
> > 
> > Comments?
> > 
> > Tom
> > 
> > 
> > 
> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> > Sent: Monday, July 12, 1999 17:45
> > To: ipp
> > Subject: IPP> NOT - Notes and Agreements on IPP Notifications from IPP
> > WG meeting, 7/7/99 in Copenhagen
> > 
> > 
> > snip...
> > 
> > 12.  Section 4, item 7, delete word "audit" and change "accounting" to
> >   "usage statistics".
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 




More information about the Ipp mailing list