Should the server wait for this "last-document" before starting to "process"
It depends on implementation. Some servers spool the entire job, including
all document data, before starting to process, so such an implementation
would wait for the "last-document" before starting to process the job. If
the time-out occurs without the "last-document", then the server takes one
of the indicated actions in section 3.3.1, as pointed out by Carl.
Other servers will start to process document data as soon as they have some.
These are the so-called "non-spooling" printers.
Currently, there isn't a way for a client to determine whether the Printer
will spool all the data or will start to process (and print) as soon as it
has some data.
ISSUE: Should we add such a Printer Description attribute?
ISSUE: If we did, would the Printer Description attribute be read-only
indicating the implementation, or would it be read-write, so that the
administrator could change the implementation?
ISSUE: Should the submitting client be able to control? ISO DPA has a
"job-scheduling" attribute that the client could supply that had three
values: 'after-complete', 'before-complete', and 'either'. The latter let
the server choose.
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Friday, July 09, 1999 08:18
Subject: Re: IPP> IPP Implementation Questions
> Hello - my name is Jerry Podojil (Genicom Corp.) and I am starting
> work on an IPP server implementation (for a printer).
> I don't know if this is the appropriate place to send implementation
> questions - if not please let me know.
> In the case where the server receives a Create Job followed by
> Document requests - is the server guaranteed to receive a Send
> the "last-document" flag set? Should the server wait for this
> "last-document" before starting to "process" the job? Should the
> wait for this "last-document" before "completing" the job?
See in draft-ietf-ipp-model-v11-02, section 4.4.31,
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 any recovery actions, such as the ones indicated in section
3.3.1. If the Printer object supports the Create-Job and Send-Document
operations (see section 3.2.4 and 3.3.1), it MUST support this
It is RECOMMENDED that vendors supply a value for this attribute that
is between 60 and 240 seconds. An implementation MAY allow a system
administrator to set this attribute (by means outside this IPP/1.1
document). If so, the system administrator MAY be able to set values
outside this range.