I propose a (Keyword) "document-access-error" attribute. For protocol errors,
such as HTTP or FTP errors, standard values would be the "reference-uri"
URIScheme followed by an error number, like :
For example, the 'http-404' keyword would indicate that the HTTP server
could not find the resource. (Note: most Internet protocols use decimal
error codes (unlike IPP), so the ASCII keyword representation is in decmial.)
For socket errors, including DNS errors, the XPG4 (or ANSI, POSIX, or XOPEN)
standard <errno.h> symbolic constant would be returned as an ASCII string.
For example, standard values would include
In addition, I propose a new (Text) "debug-info" attribute. This could
be used to provide additional debug info messages on a best-effort basis.
This would not be machine readable, and not necessarily translated into the
client's natural language, but might be helpful to, say, help desk
personnel. Use of this attribute would not be limited to
'document-access-error', it could be used to provide additional info
for any type of error. For example, IPP error 0x500
"server-error-internal-error" should never really happen. If it does
occur for some unforseen reason, it might be helpful to have a stack
traceback available in "debug-info".
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> Sent: Friday, May 21, 1999 15:09
> To: firstname.lastname@example.org
> Subject: Re: IPP> MOD - What IPP/1.1 issues need to be discussed at the
> IPP WG meet
> Original Article: http://www.egroups.com/list/ipp/?start=5833
> > In order to help prepare for next week's IPP WG meeting, it would be
> > to know which of the IPP/1.1 issues from the Bake Off need to be further
> > discussed. All of these issues have been resolved as shown below and
> > included in the Internet-Draft "Model and Semantics" and "Encoding and
> > Transport" that was published on May 12.
> I'm still somewhat dissatisfied with the solution to ISSUE 35.
> The new text says:
> '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.
> Unfortunately, this provides little diagnostic information to the client.
> How is the client to know whether the problem is that the file doesn't
> exist, or there's no route to host, or DNS hostname cannot be resolved,
> permisson denied, etc.?