IPP> MOD - Issue 1.28 What MUST an IPP object do if Create -J ob never g ets a final send operation?

IPP> MOD - Issue 1.28 What MUST an IPP object do if Create -J ob never g ets a final send operation?

IPP> MOD - Issue 1.28 What MUST an IPP object do if Create -J ob never g ets a final send operation?

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Nov 4 05:57:36 EST 1998


Henrik,

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 at i-data.com [mailto:henrik.holst at 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 at cp10.es.xerox.com> on 02-11-98 23:41:47
>
>To:   ipp <ipp at 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




More information about the Ipp mailing list