IPP Mail Archive: RE: IPP> MOD - IPP/1.1 Issue #31

RE: IPP> MOD - IPP/1.1 Issue #31

Hastings, Tom N (hastings@cp10.es.xerox.com)
Wed, 5 May 1999 01:19:58 -0700

In order to close on IPP/1.1 issues Anthony Porter agrees to work with us on
adding the extra attributes for high end systems that rip separately from
marking as extensions to IPP/1.1, rather than adding them to the IPP/1.1
document at this time.

He suggests a more flexible definition for the new 'queued-for-marked'
job-state-reason which we have agreed to include in IPP/1.1 as part of the
resolution of ISSUE 31:

Suggested text for section 4.3.8 job-state-reasons:
'job-queued-for-marker': Job is in any of the 'pending-held', 'pending', or
'processing' states, but more specifically, but more specifically, the
Printer has completed enough processing of the document, to start marking
and the job is waiting for the marker. Systems that require human
intervention to release jobs using the Release-Job operation, put the job
into the 'pending-held' job state. Systems that automatically select a job
to use the marker put the job into the 'pending' or keep the job in the
'processing' job state while waiting for the marker, depending on
implementation. All implementations put the job into (or back into) the
'processing' state when marking does begin.

Also as part of resolving ISSUE 31, we will also clarify that an IPP Printer
can have more than one job in the 'processing' state (for the high end
printers that rip one or more jobs while marking one).

Finally, as part of resolving ISSUE 31, clarify that a job can remain in the
'processing' state even when the Printer is 'stopped', if that job is being
ripped; only the job that is being marked MUST be moved to the
'processing-stopped' state.

Ok everybody?

Thanks,
Tom

-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Monday, May 03, 1999 01:00
To: 'Hastings, Tom N'
Cc: 'Herriot, Bob'; 'Manros, Carl-Uno'
Subject: RE: IPP> MOD - IPP/1.1 Issue #31

Tom,
Yes, I realize that it is too late to incorporate many high-end extensions
into 1.1

For 4.3.8, it is possible for the job to enter 'job-queued-for-marker' even
though it has not been completely ripped, so the job could be in both
job-interpreting and job-queued-for-marker. How about:
'job-queued-for-marker': Job is in any of the 'pending-held', 'pending', or
'processing' states, but more specifically, the Printer has completed enough
processing of the document, to start marking and the
job is waiting for the marker.

There were a couple of anomalies in 4.4.10 in the Feb 17 text. One statement
said that a job could not be in the processing state if the printed had
stopped marking, and another said that only one job could in processing at a
time. Neither of these are true if there is a separate RIP unit.

Anthony