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-history' 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-history', 5-10-minute-history', and '10-plus-minute-history'.
Comments?
-Hugo
>>> "Hastings, Tom N" <hastings at 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 "process"
the job?
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.
Tom
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Friday, July 09, 1999 08:18
To: ipp at pwg.org
Subject: Re: IPP> IPP Implementation Questions
<199907091358.jaa1481- at pwg.org> wrote:
original article:http://www.egroups.com/group/ipp/?start=5973
>> Hello - my name is Jerry Podojil (Genicom Corp.) and I am starting
design
> 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
server
> wait for this "last-document" before "completing" the job?
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
attribute.
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.
-Carl