While a TCP/IP connection might be reliable when it is open, that reliability
doesn't apply to SMTP or UDP. Is accounting only valid using some methods?
What happens when the TCP/IP connection is dropped unexpectedly? What happens
if the channel is reliable but the printer is too busy?
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.
**********************************************
* Don Wright don@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@interlock.lexmark.com on 07/13/99 07:19:15 PM
To: Don Wright@LEXMARK, hastings%cp10.es.xerox.com@interlock.lexmark.com
cc: ipp%pwg.org@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@lexmark.com [mailto:don@lexmark.com]
Sent: Tuesday, July 13, 1999 15:05
To: hastings@cp10.es.xerox.com
Cc: ipp@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@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@interlock.lexmark.com on 07/13/99 05:32:25 PM
To: ipp%pwg.org@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@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".