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/