You favor choice 1 of the 3 listed possible actions by a server, depending
on implementation and server policy (possibly set by the system
administrator) in the suggested Answer to Issue 1.28.
I don't think that we have to remove any of the possible choices though from
the standard, ok?
Thanks,
Tom
>-----Original Message-----
>From: henrik.holst@i-data.com [mailto:henrik.holst@i-data.com]
>Sent: Wednesday, November 04, 1998 01:59
>To: Hastings, Tom N
>Subject: Re: IPP> MOD - Issue 1.28 What MUST an IPP object do if Create
>-Job never g ets a final send operation?
>
>
>
>I think, if Create-Job never gets an Add-Document or
>Send-Document with 'last-document' set to 'true', it should
>move the job to the abort state and free up all allocated
>resources when the "multiple-operation-time-out" expire.
>Cause, if the IPP server doesn't do that, then a 'bad implemented'
>client would with several requests be able to allocate all resources
>in the IPP server.
>
>Henrik Holst
>___________________
>
>
>
>
>
>
>"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 02-11-98 23:41:47
>
>To: ipp <ipp@pwg.org>
>cc: (bcc: Henrik Holst/INT)
>
>Subject: IPP> MOD - Issue 1.28 What MUST an IPP object do if
>Create-Job
> never g ets a final send operation?
>
>
>
>
>This mail message proposes the updated text fix to Section 3.3.1
>Send-Document and Section 4.4.28 "multiple-operation-time-out"
>to resolve
>this issue. Please comment this week or the beginning of next
>week at the
>latest.
>
>Question:
>
>1.28 What MUST an IPP object do if Create-Job never gets an
>Add-Document
>or
>Send-Document with 'last-document' set to 'true'?
>Should the IPP object close the job after some period of time and:
>1. move the job to the 'aborted' state with the 'aborted-by-system'
>job-state-reasons value set
>2. move the job to the 'pending-held' state (with some new
>job-state-reason
>indicating an incomplete job, or
>3. move the job to the 'pending' state and print the job?
>
>What if the job never had any Add-Document or Send-Document
>operations, so
>that the job has no documents?
>
> IPP Bake Off
>
>Discussion:
>
>The IPP object should close the job after some period of time and:
>1. For spooling applications - move the job to the 'aborted'
>state with the
>'aborted-by-system' job-state-reasons value set.
>2. For non-spooling applications - move the job to the
>'pending-held' state
>with a job-state-reason of "incomplete-job" and an administratively set
>time-out (probably somewhere between 30 seconds and 4 min.).
>3. As a fallback - move the job to the 'pending' state and
>print the job?
>(A
>form of natural aging)
>
>These notions should be described in the IIG. This basically addresses
>system latencies that may occur during the process of
>performing a create
>job based job submission. In general, the Create-Job form of
>submission is
>intended to flow as a rapid sequence of operations without large
>discontinuities in time between related operations. We should note the
>caution that we are defining a tuning attribute, here, and thereby may
>effect overall system performance. The notion here is that it
>is not our
>intent for the sever to keep partially constructed job
>submissions on hold
>for long periods of time. We couldn't actual agree on a figure but we
>expect
>it to be somewhere between 30 sec to 4 minutes. The real
>number should be
>determined empirically and information updated in the IIG.
>
>The editor found the following discussion in Section 3.3.1
>Send-Document
>Operation, including a reference to the "multiple-operation-timeout"
>Printer
>attribute which is defined in Section 4.4.28 of the June Model spec:
>
> Since the Create-Job and the send operations (Send-Document
>or Send-URI operations) that follow can occur over arbitrarily
>long periods
>of time, each Printer object must decide how long to "wait"
>for the next
>send operation. The Printer object OPTIONALLY supports the
>"multiple-operation-timeout" attribute. This attribute indicates the
>maximum number of seconds the Printer object will wait for the
>next send
>operation. If the Printer object times-out waiting for the next send
>operation, the Printer object MAY decide on any of the
>following semantic
>actions:
> 1. Assume that the Job is an invalid job, start the process
>of changing the job state to 'aborted', and clean up all resources
>associated with the Job. In this case, if another send operation is
>finally
>received, the Printer responds with an "client-error-not-possible" or
>"client-error-not-found" depending on whether or not the Job object is
>still
>around when it finally arrives.
> 2. Assume that the last send operation received was in fact
>the last document (as if the "last-document" flag had been set
>to 'true'),
>close the Job object, and proceed to process it (i.e., move
>the Job's state
>to 'pending').
> 3. Assume that the last send operation received was in fact
>the last document, close the Job, but move it to the 'pending-held' to
>allow
>an operator to determine whether or not to continue processing
>the Job by
>moving it back to the 'pending' state.
> Each implementation is free to decide the "best" action to
>take depending on local policy, the value of "ipp-attribute-fidelity",
>and/or any other piece of information available to it. If the
>choice is to
>abort the Job object, it is possible that the Job object may
>already have
>been processed to the point that some media sheet pages have
>been printed.
>
>From the October 14 telecon minutes:
>
>We discussed that we had forgotten that the June Model and Semantics
>document contains a "multiple-operations-time-out" Printer
>Description (see
>section 4.4.28) that allows the IPP Printer to indicate the
>length of time
>before it closes down multi-document jobs that haven't had another
>operation
>performed on them.
>
>We agreed to the following:
>
>1. Clarify that "multiple-operations-time-out" is a "minimum", not a
>promise
>to close the job after exactly that much time.
>
>2. We reconfirmed that it is a requirement of the IPP Printer
>to clean up
>such jobs, not the client.
>
>3. The "multiple-operations-time-out" attribute is an OPTIONAL
>attribute,
>but that an IPP Printer MUST support the "multiple-
>operations-time-out"
>Printer Description attribute if it supports the Create-Job and
>Send-Document operations, i.e., if it supports multi-document jobs.
>
>4. The system administrator can set the "multiple-operations-time-out"
>attribute to any value. He/she is not restricted to a one to
>four minute
>value. Instead, the one to four minute value will be the RECOMMENDED
>default value for this attribute.
>
>ACTION ITEM (Tom): Update the proposed text for Issue 1.28
>for another two
>week review.
>
>
>Proposed Answer:
>
>Replace the last two paragraphs and three actions in MOD 3.3.1 (see
>Discussion above for the current text) with:
> Since the Create-Job and the send operations (Send-Document
>or Send-URI operations) that follow could occur over an
>arbitrarily long
>period of time for a particular job, a client MUST send another send
>operation within an IPP Printer defined minimum time interval after the
>receipt of the previous request for the job. If a Printer
>object supports
>multiple document jobs, the Printer object MUST support the
>"multiple-operation-time-out" attribute (see section 4.4.28). This
>attribute indicates the minimum number of seconds the Printer
>object will
>wait for the next send operation before taking some recovery action.
> An IPP object MUST recover from an errant client that does
>not supply a send operation with a "last-document" set to
>'true', sometime
>after the minimum time interval specified by the Printer object's
>"multiple-operation-time-out" attribute. Such recovery MAY
>include any of
>the following recovery actions:
> 1. Assume that the Job is an invalid job,
>start the process of changing the job state to 'aborted', add the
>'aborted-by-system' value to the job's "job-state-reasons"
>attribute, if
>supported, and clean up all resources associated with the Job. In this
>case, if another send operation is finally received, the
>Printer responds
>with an "client-error-not-possible" or
>"client-error-not-found" depending
>on
>whether or not the Job object is still around when the send operation
>finally arrives.
> 2. Assume that the last send operation
>received was in fact the last document (as if the
>"last-document" flag had
>been set to 'true'), close the Job object, and proceed to
>process it (i.e.,
>move the Job's state to 'pending').
> 3. Assume that the last send operation
>received was in fact the last document, close the Job, but
>move it to the
>'pending-held' and add the 'submission-interrupted' value to the job's
>"job-state-reasons" attribute, if supported. This action
>allows the user
>or
>an operator to determine whether to continue processing the
>Job by moving
>it
>back to the 'pending' state or to cancel the job.
> Each implementation is free to decide the "best" action to
>take depending on local policy, the value of "ipp-attribute-fidelity",
>whether any documents have been added, whether the
>implementation spools
>jobs or not, and/or any other piece of information available
>to it. If the
>choice is to abort the Job object, it is possible that the Job
>object may
>already have been processed to the point that some media sheet
>pages have
>been printed.
>
>Change the description for Section 4.4.28 "multiple-operation-time-out"
>from:
>4.4.28 multiple-operation-time-out (integer(1:MAX))
>This Printer attributes identifies how long (in seconds) the
>Printer object
>waits for additional Send-Document or Send-URI operations to follow a
>still-open multi-document Job object before taking one of the actions
>indicated in section 3.3.1.
>to:
>4.4.28 multiple-operation-time-out (integer(1:MAX))
>This Printer attributes identifies the minimum time (in
>seconds) that the
>Printer object waits for additional Send-Document or Send-URI
>operations to
>follow a still-open multi-document Job object before taking one of the
>actions indicated in section 3.3.1.
>It is RECOMMENDED that vendors supply a value for this
>attribute that is
>between 60 and 240 seconds. A system administrator MAY set
>this attribute
>to any value, including values outsides this range.
>
>Tom Hastings
>(310) 333-6413
>
>
>
>Tom Hastings
>(310) 333-6413
>
>
>
>
>
Tom Hastings
(310) 333-6413