Read my words again:
"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."
We didn't change the functions, we just didn't call it accounting to
make sure the expectation level was correct.
**********************************************
* 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/14/99 03:56:00 AM
To: Don Wright at LEXMARK
cc: ipp%pwg.org at interlock.lexmark.com
Subject: RE: IPP> NOT - Requirements - still needs an accounting applicati on
scenario
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".