I agree that 'queued-for-marker' should be usable in the 'processing'
state. In some implementations this may make sense and in others it may
not. We should allow implementations flexibility in these decisions and
not try to dictate based upon other implementations. It seems that we
sometimes go to far in our specifications and don't allow the developers
any freedom. The specifications should only provide this much detail
where interoperability becomes an issue.
Ron Bergman
Hitachi Koki Imaging Solutions
On Fri, 16 Apr 1999, Hastings, Tom N wrote:
> I agree that the 'queued-for-marker' job state reason should also be usable
> with the 'processing' job state. Some developers from our company also sent
> me the same comment by email privately during the meeting.
>> So ok if we include the 'processing' state as one of the job states with
> which an implementation MAY use the new 'queued-for-marker' job state
> reason?
>> Thanks,
> Tom
>> -----Original Message-----
> From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
> Sent: Wednesday, April 14, 1999 16:15
> To: ipp at pwg.org> Subject: IPP> Queued for marking
>>>>> In New Orleans, we introduced a new job state reason ("queued-for-marker")
> for jobs that are interpreted (or maybe don't need interpreting... like
> TIFF) but "pending", "pending-held". This was a long and excruciating
> discussion which warped abruptly. I want to say that I feel this new
> job-state-reaons should apply to the "processing" state as well.
>> Harry Lewis
> IBM Printing Systems
>harryl at us.ibm.com>>