Your concern is why I proposed a SHOULD, not a MUST in the following:
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.
NOTE: that if you don't support the "status-message" operation attribute in
responses, then you can simply bail out when you find the syntax error as
you prefer, since your response will not contain any 'name' or 'text'
attributes.
Maybe we need to add this above NOTE to the Implementers Guide?
Tom
>>(That's actually 'client-error-bad-request'.)
>>As an implementor, I'd really prefer to be allowed to bail as
>soon as a syntax error is detected. It can be dangerous to
>proceed. For example, the parser might be expecting the next
>field to be an attribute length, but if it's actually a string
>or something, due to a syntax error, the parser might end up
>trying to allocate a string buffer of a gazillion bytes,
>crashing the application. Of course, you can build in
>protection against this kind of thing, and scan for patterns
>to try to resynch to the data stream, etc. But that all adds
>complexity.
>-----Original Message-----
>From: Carl Kugler [mailto:kugler at us.ibm.com]
>Sent: Monday, November 09, 1998 09:26
>To: ipp at pwg.org>Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
>>>Tom wrote:
>>>...
>> >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',
>>(Actually that's 'server-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.
>>(That's actually 'client-error-bad-request'.)
>>As an implementor, I'd really prefer to be allowed to bail as
>soon as a syntax error is detected. It can be dangerous to
>proceed. For example, the parser might be expecting the next
>field to be an attribute length, but if it's actually a string
>or something, due to a syntax error, the parser might end up
>trying to allocate a string buffer of a gazillion bytes,
>crashing the application. Of course, you can build in
>protection against this kind of thing, and scan for patterns
>to try to resynch to the data stream, etc. But that all adds
>complexity.
>> -Carl
>>"The price of reliability is the pursuit of utmost
>simplicity." --C.A.R. Hoare
>>>>>>>>>-----
>See the original message at http://www.egroups.com/list/ipp/?start=4837>--
>Free e-mail group hosting at http://www.eGroups.com/>