As you point out, it is tricky, since there are earlier errors, like
version-number-not-supported, or operation-not-supported that are natural to
check before you get to the Operation Attributes group and the
"attributes-charset" attribute. On the other hand, if your implementation
is returning the OPTIONAL "status-message" in responses, it isn't going to
help the client to always return it in the "charset-configured", if the
client doesn't support that charset.
Also we have hinted that a good implementation might make several checks,
rather than bailing out after the first error.
And finally we have agreed that Section 16.3 and 16.4 were written too
strongly to say that the IPP object MUST do all of these error checks. Some
have argued that a server can be forgiving. On the other hand, our original
thought (as written in 16.3 and 16.4) was that the server should be very
picky, since this is a new protocol, with carefully written conformance
requirements (unlike many IETF standards that rush to get working code and
then attempt to clarify the standard around what actually got implemented).
Our original thought had been that if the servers are picky, the clients
will be conforming and will have a much better chance of interoperating with
any server.
So here is the text for the Model, which does not allow an implementation to
always returns text and name in the configured-charset when any error
occurs:
The IPP object returns any 'text' or 'name' attributes using the Printer's
"charset-configured" charset and the 'client-error-charset-not-supported'
error status code.
Clarify MOD section 3.1.4.1 third paragraph by adding:
and any 'text' or 'name' attributes using the Printer's "charset-configured"
charset.
to the end of:
If the Printer object does not support the client supplied charset value,
the Printer object MUST reject the request and return the
'client-error-charset-not-supported' status code.
Clarify MOD section 14.1.4.14 'client-error-charset-not-supported' by
replacing:
the Printer MUST reject the operation and return this status (see Section
3.1.4.1).
with:
the Printer MUST reject the operation and return this status and any 'text'
or 'name' attributes using the Printer's "charset-configured" charset (see
Section 3.1.4.1).
Add to the IIG: Since such an error is a client error, rather than a user
error, the client should check the status code first so that it can avoid
displaying any other returned 'text' and 'name' attributes that are in an
unexpected charset. Also add to the IIG from the above discussion [your
e-mail].
Tom
>-----Original Message-----
>From: Carl Kugler [mailto:kugler@us.ibm.com]
>Sent: Friday, November 06, 1998 13:09
>To: ipp@pwg.org
>Subject: Re: IPP> MOD> Issue 1.19
>
>
>Were these concerns discussed any further before Issue 1.19
>was moved to the Approved Clarifications List and into the new
>Mod doc? If so, could someone point me to the discussion
>(I've been out of town for a while).
>
> -Carl
>
>> 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/
>>
>>
>
>
>
>-----
>See the original message at http://www.egroups.com/list/ipp/?start=4628
>--
>Free e-mail group hosting at http://www.eGroups.com/
>