IPP Mail Archive: Re: IPP> Review of Additional Operations - Set 1

IPP Mail Archive: Re: IPP> Review of Additional Operations - Set 1

Re: IPP> Review of Additional Operations - Set 1

Tom Hastings (hastings@cp10.es.xerox.com)
Tue, 18 Aug 1998 22:08:45 PDT

At 08:06 08/12/98 PDT, Ron Bergman wrote:
>Tom,
>
>Sorry for the delay of this review. (The document was published after I
>left for vacation.)
>
>1. The format of the text version will need some work before it can be
> sent to the IETF. It is unfortunate that they cannot accept WORD or
> PDF files, but there is not much we can do but generate "clean" text
> documents.

Are you talking about the table in section 3.1 which has a single letter
wrap onto the next line? The rest of the document seemed acceptable
to me.

>2. On page #1, the name of my employer is spelled incorrectly.

Sorry.

>
>3. On page #3, section 1, the first line following the section title just
> repeats what has already been stated in the title. This line could be
> removed with no loss of content. (minor nit!)

I checked with my technical writer, and she says that tables need to have
something in the text that refers to them. Tables can't just float in
a document unreferenced.

>
>4. In section 2.3 (Restart-Job), the job state is shown in the table as
> changing from "processing-stopped" to "processing" and the operation
> is rejected. The job state should remain as "processing-stopped".

Good catch!

>
>5. Also in section 2.3 (Restart-Job), I disagree with your discussion
> concerning accounting applications. You are making an assumption
> that an accounting application will be able to recognize that the job
> was restarted if a new set of accounting information is pushed from
> the printer. This is not true for any accounting packages that I am
> familiar with. When the accounting package receives the data set for
> the reprinted job it will most likely do one one of two things; 1) it
> will recognize that information has been received for the job and
> discard the new data, assuming that this was a duplicate packet or
> 2) just overwrite the original data. I do not believe that any
> accounting package would recognize that the job was reprinted and
> act as stated in your text. How would the application know the
> difference between a duplicate packet and the scenario that you
> proposed?

Simple! If the "time-at-event" value is the same it is a duplicate.
If the "time-at-event" value is different, it is a restart and the
accounting application should record both (completion) events. This
strategy works for both reliable schemes, such as TCP/IP and unreliable
such as UDP.

> I believe that we agreed in Monterey that the Restart-Job
> would not be compatible with accounting applications and that a simple
> note similar to the following would be added:
>
> "NOTE: Resetting the job progress attributes should allow a job
> monitoring application to function unchanged for a job that has been
> restarted. However, since the job-id for the "restarted-job" is
> identical to the original job, this operation will most likely be
> incompatible with accounting applications. It is recommended that
> the Reprocess-Job operation be used when accurated accounting data
> is desired."

You have a different recollection than I had of the meeting agreements.
I recall discussion pointing out that using notification ("push") for
accounting as being a much more robost engineering strategy than "pull"
accounting.

Also it is important to indicate the alternative of using notification
for accounting, so that the simpler Restart-Job operation can be
implemented with it, instead of the more complex Reprocess-Job operation.
It would be mis-leading to leave the recommendation that Reprocess-Job
operation is the only way to get accurate (or robust) accounting.

>
>With these changes incorporated, we should have a document that reflects
>the agreements per the Monterey meeting.
>
>
> Ron Bergman
> Dataproducts Corp.
>
>
>
>
>