> 1.19 - When an unsupported char set is requested, what character set should a server use
when returning the unknown attribute?
> The server should use it’s default character set as currently stated in the spec.
There is actually a larger question here. There are other cases in which a request can be REJECTED before the "attributes-charset" is known and validated.
I interpret MOD as saying that the request validation steps can occur in any order, and that the Printer is free to REJECT a request as soon as it finds a reason to do so:
>MOD>16.3 Suggested Operation Processing Steps for All Operations> In order to determine whether or not to accept or reject the request, the IPP object SHOULD execute the following steps. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request.
However, validating "attributes-charset" requires processing the whole request:
>...it is an error for the "attributes-charset" or "attributes-natural-language" attribute to be omitted in any operation request, or for an Operation attribute to be supplied in a Job Template group or a Job Template attribute to be supplied in an Operation Attribute group in a create request. It is also an error to supply the "attributes-charset" attribute twice.
So, in general, a request MAY be REJECTED before the request "attributes-charset" has been read and/or validated. Examples:
1) Bad version number.
2) Unsupported Operation identifier
3) "attributes-charset" was omitted.
4) "attributes-charset" was supplied more than once.
My simple implementation solution was to use the Printer's default charset whenever REJECTing a request. But this approach fails some of the test scripts.
I'd prefer a simple rule saying something like "a Printer MAY use its default charset in a rejection response". Or at least for some subset of responses like "client-error-bad-request" and "client-error-charset-not-supported". Otherwise we have a mess of special cases:
- The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request, except that "attributes-charset" has to be processed before the request is rejected, so at least one complete pass is required.
- The IPP object NEED NOT find all attribute errors before returning an error, but it must process the entire request to validate that "attributes-charset" is a single non-empty 'charset' value less than or equal to 63 octets,
and in the Printer object's "charset-supported" attribute, before returning an error.
- The Printer object checks to see if the "operation-id" attribute supplied by the client is supported as indicated in the Printer object's "printer-operations-supported" attribute. If not, the Printer REJECTS the request and returns the 'server-error-operation-not-supported' status code in the response AFTER processing the rest of the operation attributes group to read and validate the "attributes-charset".
- For rejection responses, the error status codes returned may differ between implementations, but "attributes-charset" errors take precedence.
- etc.
-Carl
-----
See the original message at http://www.egroups.com/list/ipp/?start=4605
--
Free e-mail group hosting at http://www.eGroups.com/