All the proposed extensions appear useful to me. I can't help thinking back to
Scott's proposal for IPP printer MIB support, however. Looks like we'll
piecemeal our way into the MIB. Nonetheless...
1. Spool - Yes/No is good. I'm not sure we can say if a printer spools it will
never start interpreting the job immediately, however. This seemed to be a
motivating factor for this extension.
2. OpPanel - sure... again, just a flag that we're adding MIB objects one by
one. But, at least, let's keep it aligned with the MIB definition.
3. History - Great idea. I think we should recognize that the persistence part
may have some fudge. If the printer says it can "log" 10 jobs, how does a
"client" application know the current rate of jobs? If the printer says I'll
hold jobs for 3 mins, is this precise, or an estimate. If precise, does the
printer sacrifice throughput to uphold it's log (if it comes to that)?
If we do get into formalizing "history"... I suggest a r/w attribute that says
whether the system should favor printing or logging should circumstances warrant
this choice.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
"Hugo Parra" <HPARRA at novell.com> on 07/19/99 05:56:18 PM
To: hastings at cp10.es.xerox.com, ipp at pwg.org, Carl Kugler/Boulder/IBM at IBMUS
cc:
Subject: RE: IPP> IPP Implementation Questions [spooling strategies]
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