IPP> MOD - ISSUE 35: What error code to return on Print-URI or Send-U RI if document not accessible?

IPP> MOD - ISSUE 35: What error code to return on Print-URI or Send-U RI if document not accessible?

IPP> MOD - ISSUE 35: What error code to return on Print-URI or Send-U RI if document not accessible?

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Apr 30 17:55:45 EDT 1999


At the Wednesday, 4/28, IPP telecon, with a good participation, we agreed to
the following resolution to Issue 35 for IPP/1.1.  It is being sent to the
mailing list for discussion and approval.  I have included the recommended
text changes as the end, as well as summarized the agreements.

Please send any comments to the mailing list.  Silence will be interpreted
as agreement.

Tom

35) OPEN - ISSUE:  What error code to return on Print-URI or Send-URI if
document not accessible?

Section 3.2.2, "Print-URI Operation", it looks like it's an implementation
decision whether to pull the data from the document-uri at job submission
time or at job processing time.  Say I decide to pull the data at job
submission time.  Say I get some kind of error doing so, like
no-route-to-host, or HTTP 404.  Shouldn't I return some kind of error
status?  Currently, it looks like I have to return successful-ok as long as
the document-uri uses a scheme I support, regardless of whether or not I can
actually get the document data. 

Suggested addition:  

Add both a new 'client-error-document-access-error' status code and a
'document-access-error' value for "job-state-reasons", just like we have
done for compression and document format errors for Issues 3, 6, and 28.

Suggested text for section 3.2.2 Print-URI Operation:

Replace the sentences:

See The Implementer's Guide [IPP-IIG] for suggested additional checks.  The
Printer NEED NOT follow the reference and validate the contents of the
reference.

with:

The IPP Printer MAY validate the accessibility of the document as part of
the operation or subsequently.  If the Printer determines an accessibility
problem before returning an operation response, it rejects the request and
returns the 'client-error-document-access-error' status code.  If the
Printer determines this accessibility problem after accepting the request
and returning an operation response with one of the successful status codes,
the Printer adds the 'document-access-error' value to the job's
"job-state-reasons" attribute.  See The Implementer's Guide [IPP-IIG] for
suggested additional checks.  

Suggested text for section 4.3.8 job-state-reasons:

'document-access-error': The Printer could not access one or more documents
passed by reference, i.e., by Print-URI or Send-URI while processing the
job.  This reason is intended to cover any file access problem, including
file does not exist, server timeout, and access denied because of an access
control problem.  Whether the Printer aborts the job and moves the job to
the 'aborted' job state or prints all documents that are accessible and
moves the job to the 'completed' job state and adds the
'completed-with-errors' value in the job's "job-state-reasons" attribute
depends on implementation and/or site policy.

Suggested text for section 14.1.4 Client Error Status Codes:

4.1.4.19 client-error-document-access-error (0x0412)

The IPP object is refusing to service the Print-URI or Send-URI request
because the Printer encountered an access error while attempting to validate
the accessibility or access the document data specified in the
"document-uri" operation attribute.  This error is returned independent of
the client-supplied "ipp-attribute-fidelity".  The Printer object MUST
return this status code, even if there are Job Template attributes that are
not supported as well, since this error is a bigger problem than with Job
Template attributes. 






More information about the Ipp mailing list