Comments included below.
From: Sandeep Kamath [mailto:email@example.com]
Sent: Saturday, November 13, 1999 5:23 AM
Subject: IPP> issue with job-state-reasons
I have an issue .
1) Assume a client has performed a Print-URI operation with a reference
to a large document .The request is processed checking for the
uri-scheme and the accessibility of the document, and the client is sent
(PZ> checking accessibility is optional)
a response with a valid job-id. While the IPP server is downloading the
document mid way ,the client does a get-job-attributes. We would return
the job-state as pending-held , but what the job-state-reasons say.
There is a job-state-reason 'job-incoming' , but is limited to
PZ> I would not use 'job-incoming' its use is narrowly defined and not
PZ> appropriate. I assume your implementation requires that the entire
PZ> job stream be transferred to your printer prior to processing.
PZ> If you could begin before transfer is complete then the 'job-state'
PZ> would be 'processing' and the 'job-state-reasons' would be
PZ> 'job-interpreting', 'job-transforming' and/or 'job-printing'.
PZ> Assuming your implementation can not process until the entire
PZ> document data has been retrieved I agree with your 'job-state'.
PZ> The 'job-state-reason' might be 'resources-are-not-ready'. This
PZ> assumes that the PDL itself is included in the definition of "resource".
PZ> The other alternative requires an extension to the 'job-state-reason'
PZ> values. A new value would be 'document-transfer' and its semantics
PZ> is that the printer is retrieving document data necessary for the job.
PZ> The new value would only apply to jobs that contain a document obtained
PZ> via a URI reference.
Software Engineer - Design & Development
Networking & Communication
TATA ELXSI LTD.