Tom wrote:
>>> Carl,
>> We did discuss at a telecon also adding a new OPTIONAL
> "document-access-error-code" operation attribute and a corresponding Job
> attribute (for use when this error may get detected after the Print-URI or
> Send-URI has responded).
>> The idea was to be able to pass back whatever error status code and/or
> message came back from a number of sources. Sometimes the error comes back
> from the transport, sometimes from the protocol, and sometimes from the
> repository.
>> Sometimes the IPP Printer knows what the error means and sometimes it
> doesn't.
>> Conflicting objectives include: whether the value was something that could
> be displayed to the user versus could be parsed by a program. Some times
> the error is a code, sometimes the error is a human understandable text
> string, sometimes it is a human readable text string that includes either a
> number or a symbolic code.
>> Whatever comes back probably has to indicate what the source of the error
> is, so that a smart client could tell the source of the error.
>> One idea proposed was that the code started off with a prefix that indicated
> the source of the error and the rest of the keyword value was whatever the
> source of the error returned.
>> I think it needs quite a bit of work and needs to work with at least the
> following sources of document access errors:
>> TCP/IP
> HTTP
> FTP
>> What others?
>> Do you have a specific proposal? If yes, please make it to the DL and see
> if there is agreement?
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 :
http-XXX
ftp-YYY
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
ECONNREFUSED
ECONNRESET
EHOSTUNREACH
ENETUNREACH
ENOBUFS
ETIMEDOUT
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".
-Carl
>> Thanks,
> Tom
>> -----Original Message-----
> From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
> Sent: Friday, May 21, 1999 15:09
> To: ipp at pwg.org> Subject: Re: IPP> MOD - What IPP/1.1 issues need to be discussed at the
> IPP WG meet
>>> <918c79ab552bd211a2bd00805f15ce850135458- at x-crt-es-ms1.cp10.es.xerox.com>
> wrote:
> 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
> helpful
> > 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.?
>> -Carl
>