There are two other Printer Description attributes that I'd like the group =
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" <firstname.lastname@example.org> 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 =
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
From: email@example.com [mailto:firstname.lastname@example.org]=20
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? =20
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.=20