Tom wrote:
> Your concern is why I proposed a SHOULD, not a MUST in the following:
>
Okay. It's just that the SHOULD makes me feel obligated to attempt it (endeavor to extract an attributes-charset from a malformed request), even though I don't think that's the wisest course in this case. The "out", as you suggest, is to avoid sending text in the response. However, I still need to put something in the response "attributes-charset".
> 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
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4840
--
Free e-mail group hosting at http://www.eGroups.com/