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.
>
>
>
>
>