I've inserted some comments in Carl's text below.
-Hugo
>>> "Carl Kugler" <kugler at us.ibm.com> 10/12 12:43 PM >>>
> 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:
[[[HParra]]] One exception to this may need to be explicitly noted, namely, the reject response resulting from a job creation request specifying unsupported attributes and ipp-attribute-fidelity == TRUE. It should be strongly recommended/mandated that the response include the list of all unsupported attributes that caused the operation to fail, so users don't have to try submitting a job multiple times to find out exactly what all attributes caused the job to fail.
>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.
[[[HParra]]] Is a complete pass really required? Section 3.1.4 of the MOD states, "The 'attributes-charset' attribute MUST be the first attribute in the (Operation Attributes) group and the 'attributes-natural-language' attribute MUST be the second attribute int he group." Once an IPP printer has validated this information it should be free to reject a request at any point it deems appropriate. If a duplicate 'attribute-charset' is specified later on, the printer rejects the request when it runs into it, if it makes it that far before rejecting the request for any other reason. What am I missing?
- 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/