Tom,
My understanding of the decision in Copenhagen was more of semantics
rather than function. There is no reason why a "statistics notification
group" would not be identical to what is required for an "accounting
notification group". The only difference is that the "statistics group"
would not imply the degree of reliability that some may desire for
accounting. If a vendor desires to offer a reliable accounting package
this easily could be built on top of the IPP Statistics Package. For
those applications that don't need the bullet proof (Jeff Slater) package,
the IPP Statistics package would be more than sufficient. We do, however,
need to include either TCP or UDP with acknowledgement as an available
transport. I do not agree with the decision in Copenhagen to only specify
UDP without acknowledgement.
The issue of a reliable transport was also discussed in the IETF meeting.
But the concern there was more for congestion control. There was the
opinion that TCP should be used just to be safe, even though the frequency
of IPP notifications was expected to never invoke the TCP congestion
control feature. (The discussion at this point concerned the sending of a
notification at the completion of every page.)
I am now convinced that the transport selected should be a function of the
notification type and we should not allow any notification on any
transport. For example, the page complete notification should be only a
UDP without acknowledgement. If page completions are lost its not a big
deal, the next notifcation will bring you up-to-date. For Job Completion,
Job Statistics, or Errors a reliable transport should be required in most
cases. For these I believe that TCP is an overkill. UDP with
acknowledgement is more than adequate. Congestion control should not be
an issue.
Ron Bergman
Hitachi Koki Imaging Solutions
On Wed, 14 Jul 1999, Hastings, Tom N wrote:
> See my replies preceded by TH>
>> Tom
>> -----Original Message-----
> From: don at lexmark.com [mailto:don at lexmark.com]
> Sent: Tuesday, July 13, 1999 18:06
> To: hastings at cp10.es.xerox.com> Cc: ipp at pwg.org> Subject: RE: IPP> NOT - Requirements - still needs an accounting application
> scenario
>>> Tom:
>> While a TCP/IP connection might be reliable when it is open, that
> reliability
> doesn't apply to SMTP or UDP.
> TH> I agree. So an accounting application would supply the TCP/IP method,
> rather than the SMTP or UDP methods, in the Subscribe-Printer operation.
>> Is accounting only valid using some methods?
> TH> Yes. At least reliable accounting would only be reliable with some
> methods, such as TCP/IP.
>> What happens when the TCP/IP connection is dropped unexpectedly?
> TH> This can happen, or the accounting program might not be running, or
> might crash, or might be stopped accidentally, etc.
> TH> When any of these things happen, the notification event reports are not
> acknowledged and the policy/implementation kicks in that is beyond the scope
> of the standard.
>> What happens if the channel is reliable but the printer is too busy?
> TH> Same as when the accounting is not acknowledged. The
> policy/implementation is beyond the scope of the standard.
>> Our solution was to not call it accounting but rather statistics so that
> there
> is not an expectation of accounting level of QoS. Those of us in the
> discussion
> believe that the word "accounting" sets an unrealistic level of expectations
> and
> we were not willing to go after that level of expectations.
> TH> The problem with not addressing accounting is that each implementer
> dreams up private accounting attributes. It would be nice to agree on some
> core set of accounting data in a public standard. Obviously, there will be
> additional private data and some of these attributes can get registered
> along the way as well.
>> TH> It would also be nice to agree on some core set of additional usage
> Printer Description attributes for Scenario 7 that is accumulated across
> jobs (and power cycles?), such as total-impressions, total-media-sheets,
> total-time-running.
>> TH> The alternative to not using notification for accounting, is for the
> accounting program to query the Job History using Get-Job-Attributes after
> the job completes. Notification could be used to kick off such an
> accounting program and the accounting program should periodically poll as
> well, in case a notification doesn't get through to it (or the printer is
> too busy). Do you feel that polling, combined with notification, is a
> preferable way to do accounting? It does depend on the Printer to implement
> the Job History concept and keep jobs around for some period of time so that
> the accounting program get copy out the data.
>> TH> Even with this second approach, we should add it as Scenario 8. The
> difference being that the event report doesn't have to have all of the
> accounting data in it, which would simplify the notification. Also the
> event delivery method doesn't have to be reliable, since the accounting
> program has to poll anyway. The accounting program only needs to subscribe
> for the 'job-completed' event.
>> TH> With either approach to accounting, we should still agree on and add
> (the same) core set of accounting job attributes to add to the job object.
>> Here is the alternative Scenario 8 for "polled accounting":
>> 8. I am an accounting application. I poll periodically the Job History for
> jobs that
> have completed (aborted or canceled) since I last polled. In order to
> capture data
> sooner after jobs complete, I subscribe to 'job-completed' events.
> I subscribe independently from a job submission so that my subscription
> outlasts any particular job. My subscription may persists across power
> cycles. I don't have to use a
> particularly reliable delivery method, since I poll periodically too.
> I subscribe with the following attributes:
>> - Notification Recipient - me
> - Notification Type - immediate
> - Notification Events - job completion
> - Notification Attributes - time submitted, time started, time completed.
>> Tom
>>> **********************************************
> * 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 07:19:15 PM
>> To: Don Wright at LEXMARK, hastings%cp10.es.xerox.com at interlock.lexmark.com> cc: ipp%pwg.org at interlock.lexmark.com> Subject: RE: IPP> NOT - Requirements - still needs an accounting applicati
> on
> scenario
>>>>> 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".
>>>>>>>>