IPP Mail Archive: RE: IPP> IPP Implementation Questions [spooling strategies]

IPP Mail Archive: RE: IPP> IPP Implementation Questions [spooling strategies]

RE: IPP> IPP Implementation Questions [spooling strategies]

Hugo Parra (HPARRA@novell.com)
Mon, 19 Jul 1999 17:56:18 -0600

I like the idea of having a Printer Description attribute that tells an =
IPP client whether the printer can spool. IPP Clients can be smart about =
how they send jobs (e.g., stream-line vs concurrent submissions) to a =
printer if they know this information. I'm in favor of making it readable =
and writeable.

There are two other Printer Description attributes that I'd like the group =
to consider:

a) 'console-display-buffers' (1setOf text): the equivalent of the MIB =
console buffer attr. Users and operators have found it useful to remotely =
view the contents of the printer's display screens.

b) 'history-supported' (boolean/keyword?): Information to tell an IPP =
client (maybe part of a print server front-ending an IPP printer) whether =
it can rely on the printer supporting status information on 'completed', =
'canceled', and 'aborted' jobs. The 'keyword' approach would maybe =
include the following options: 'no-history', 'time-bound-history', =
'job-count-bound-history'. 'time-bound-history' and 'job-count-bound-histo=
ry' may need to provide more information such as how long jobs are kept in =
the history or up to how many jobs can be tracked. For this a separate =
attribute may need to be defined or we could define more keywords for this =
attribute that give indication of what this boundaries are, such as: =
'1-5-job-history', '5-10-job-history', '10-plus-job-history', '1-5-minute-h=
istory', 5-10-minute-history', and '10-plus-minute-history'.


>>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 07/14/99 01:14AM >>>
I agree with Carl's comments. As to your question:

Should the server wait for this "last-document" before starting to =
the job?

It depends on implementation. Some servers spool the entire job, =
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 =
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 =
the server choose. =20

Tom =20

-----Original Message-----
From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]=20
Sent: Friday, July 09, 1999 08:18
To: ipp@pwg.org=20
Subject: Re: IPP> IPP Implementation Questions

<199907091358.jaa1481-@pwg.org> wrote:=20
original article:http://www.egroups.com/group/ipp/?start=3D5973=20
> 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.
> Question:
> In the case where the server receives a Create Job followed by
multiple Send
> Document requests - is the server guaranteed to receive a Send
Document with
> 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? =20

See in draft-ietf-ipp-model-v11-02, section 4.4.31,
"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 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.=20