IPP Mail Archive: Re: IPP> MOD> Issue 1.19

IPP Mail Archive: Re: IPP> MOD> Issue 1.19

Re: IPP> MOD> Issue 1.19

Hugo Parra (HPARRA@novell.com)
Tue, 13 Oct 1998 11:01:26 -0600

I've inserted some comments in Carl's text below.

>>> "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 =

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 =

>...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 =

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. 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 =
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.


See the original message at http://www.egroups.com/list/ipp/?start=3D4605=

Free e-mail group hosting at http://www.eGroups.com/