IPP Mail Archive: Re: IPP> MOD> Issue 1.19
Re: IPP> MOD> Issue 1.19
Carl Kugler (
kugler@us.ibm.com)
13 Oct 1998 18:44:27 -0000
I've inserted some comments in Carl's text below.
> -Hugo
>
> >>> "Carl Kugler" <kugler@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=C6s 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 =3D=3D 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.=20
>
> However, validating "attributes-charset" requires processing the whole =
> request:
>
> >...it is an error for the "attributes-charset" or "attributes-natural-lang=
> uage" 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-ch=
> arset" 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-sup=
> ported". 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-cha=
> rset" 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.
But the operation identifier, for example, precedes the 'attributes-charset'. So, for a Printer that processes the data stream as it arrives, in the case of an unsupported operation, the Printer would have to remember that problem and continue to process the request trying to find a valid 'attributes-charset' to use for the response.
And what if it can't validate the request 'attributes-charset'?
Section 16.3.5, Validate the values of the REQUIRED Operation attributes, says:
>attributes-charset (charset)
>IF NOT any single non-empty 'charset' value less than or equal to 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
What "attributes-charset" should be used for the 'client-error-request-value-too-long' response?
>If an IPP object receives a request with required attributes missing or repeated from a group, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code.
Suppose "attributes-charset" is repeated in the operation attributes group. What "attributes-charset" must be used in the 'client-error-bad-request' response? The first one? Either one?
> 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?
It all depends on how strongly you want to validate 'attributes-charset' before returning the response. Lately, 'attributes-charset' seems to have a kind of elevated status as a special attribute in a special position with special rules applied to it. Recent interpretations seem to imply that 'attributes-charset' errors take precedence over other errors, since you can't form a valid response except for 'client-error-charset-not-supported' unless you can get a valid, supported 'attributes-charset' from the request.
>
> - 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,=20
> 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=3D4605=
> =20
> --
> Free e-mail group hosting at http://www.eGroups.com/
>
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4627
--
Free e-mail group hosting at http://www.eGroups.com/