IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

Hugo Parra HPARRA at novell.com
Tue Oct 13 13:01:26 EDT 1998


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/



More information about the Ipp mailing list