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'.)
Will 'client-error-charset-not-supported' take precedence over 'server-error-version-not-supported'? If so we're saying that the position of the 'attribute-charset' attribute withing an IPP message will be preserved in future versions of IPP. That seems reasonable but I wanted to make sure we all agree to this implication.
-Hugo