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

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

henrik.holst at i-data.com henrik.holst at i-data.com
Wed Jul 14 04:35:05 EDT 1999






"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