> >It might be worth adding a clarification to the effect that=20
> >case 5. above DOES take precedence over any other type of=20
> >client error, since without a valid "attribute-charset" the=20
> >only valid response the IPP object can generate is=20
> >"client-error-charset-not-supported".=20
> >
> >For example, if an IPP object gets a request with an=20
> >unsupported Operation code and an unsupported=20
> >"attributes-charset", the response must be=20
> >"client-error-charset-not-supported", not=20
> >"client-error-attributes-or-values-not-supported" [I guess=20
> >that's the appropriate error status code for a request for an=20
> >unsupported Operation].
>=20
> I agree that the 'client-error-charset-not-supported' SHOULD take =
precedence
> over 'client-error-operation-not-supported',=20
>=20
> Actually that's 'server-error-operation-not-supported'.)
Will 'client-error-charset-not-supported' take precedence over 'server-erro=
r-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