>-----Original Message-----
>From: Carl Kugler [mailto:kugler at us.ibm.com]
>Sent: Friday, November 06, 1998 16:27
>To: ipp at pwg.org>Subject: Re: IPP> MOD> Issue 1.19
>>>Hugo wrote:
>> Carl wrote:
>>>> > Were these concerns discussed any further before Issue
>1.19 was moved =
>> to=20
>> > 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 don't think we articulated a definite answer to this
>question. The =
>> desired behavior might not be far from what's currently
>documented but one =
>> or two clarifying statement may be necessary. To address
>the questions =
>> raised by Carl, I propose that:
>>>> 1. The "attribute-charset" attribute be required to be the
>first operation =
>> attribute. [Same as currently documented]
>>>> 2. A request (or response) containing more than one
>"attribute-character" =
>> attribute should be rejected. [As currently documented]
>>>> 3. All responses use the same 'valid' "attribute-charset"
>received in the =
>> corresponding request (i.e., the first operation attribute,
>if supported) =
>> [Might need to be clarified in the current doc]
>>>> 4. The IPP object should always attempt to retrieve the
>"attribute-charset=
>> " attribute from the request (i.e., the first operation
>attribute) even if =
>> it has detected errors with the version, operation, or
>request numbers, =
>> and use it in the response informing the error condition.
>[Needs to be =
>> clarified in the current doc]
>>>> 5. Whenever an IPP object cannot obtain a 'valid'
>"attribute-charset" =
>> attribute from the request (because it gets a request
>without an "attribute=
>> -charset" attribute as the first operation attribute or
>because it's given =
>> an attribute set is doesn't support) the response should be
>given in the =
>> server's default charset. [Needs to be clarified in the current doc]
>>>> 6. Reporting a duplicate "attribute-charset" attribute
>error does not =
>> take any precedence over reporting any other error
>condition. The IPP =
>> object should not need to parse the entire request first to
>make sure the =
>> "attribute-charset" attribute appears once and only once in
>the request. =
>> [Needs to be clarified in the current doc]
>>>> Did I miss anything?
>>It might be worth adding a clarification to the effect that
>case 5. above DOES take precedence over any other type of
>client error, since without a valid "attribute-charset" the
>only valid response the IPP object can generate is
>"client-error-charset-not-supported".
>>For example, if an IPP object gets a request with an
>unsupported Operation code and an unsupported
>"attributes-charset", the response must be
>"client-error-charset-not-supported", not
>"client-error-attributes-or-values-not-supported" [I guess
>that's the appropriate error status code for a request for an
>unsupported Operation].
I agree that the 'client-error-charset-not-supported' SHOULD take precedence
over 'client-error-operation-not-supported', just so that the client will
know that the charset coming back is in a different charset than the client
requested, so that the client should not attempt to display any 'text'
attributes returned, such as the "status-message". We probably need some
statement to indicate that.
>>Also, MAY an IPP object use its default charset when
>generating a client-error-bad-request response?
I would think it would depend on how bad the syntax was. If the IPP object
was able to find the "attribute-natural-language" in the request and it is
supported, then the IPP object should return the response in the charset,
not it's charset-configured (which the client might not be able to
understand).
> 14.1.4.1 client-error-bad-request (0x0400)
>The request could not be understood by the IPP object due to
>malformed syntax (such as the value of a fixed length
>attribute whose length does not match the prescribed length
>for that attribute - see section 16.3). The IPP application
>SHOULD NOT repeat the request without modifications.
>>Or must it press on according to case 4 above, and try to
>extract a valid charset from the request even in the face of
>syntax errors?
My suggestion is that it should press on, if it can, in order to see what
charset is being passed and requested for the response.
How about adding the following statement to the
'client-error-charset-not-supported' status code:
This error SHOULD take precedence over any other error, so that the client
will know that the returned charset is not the one requested. Therefore,
the IPP object SHOULD endeavor to determine the "attribute-charset"
operation attribute in the request. Of course, if the syntax of the request
is so bad that the IPP object cannot find the "attributes-charset", then the
IPP object has no choice but to return the 'client-error-bad-syntax' status
code.
>>>>> -Hugo
>>>>>>>-Carl
>>>-----
>See the original message at http://www.egroups.com/list/ipp/?start=4822>--
>Free e-mail group hosting at http://www.eGroups.com/>