I think that's a reasonable resolution.
Another approach would be to allow "status-message" in 0x0400 responses
but warn that "client beware!", the attribute charset of this type of
response might not match that of the request. Clients could, of course,
ignore status messages in unknown charsets. I prefer this resolution
because it lets me stick helpful debug messages in responses, for
development purposes.
I think it's important to get this issue straightened out, because if
you look at the old MOD section 16 (BTW, where is it now? I don't see
it in the IIG) there are many cases that result in the
client-error-bad-request (0x0400) response.
-Carl
>
> Tom
>
> >-----Original Message-----
> >From: Carl Kugler [mailto:kugler@us.ibm.com]
> >Sent: Monday, November 09, 1998 16:38
> >To: ipp@pwg.org
> >Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
> >
> >
> >>
> >> Is a message that specifies an operation that the server
> >doesn't support a =
> >> malformed request?
> >>
> >> -Hugo
> >>
> >
> >No. But must I use the "attribute-charset" from the request
> >when forming this type of response:
> >
> > 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 the Implementer's Guide [IPP-IIG]
> >section 16.3). The IPP application SHOULD NOT repeat the
> >request without modifications.
> >
> >I've got to put SOMETHING in the response "attributes-charset"
> >operation attribute. And I could OPTIONALLY have a
> >"status-message" in the response.
> >
> >
> > -Carl
> >
> >-----
> >See the original message at http://www.egroups.com/list/ipp/?start=4857
> >--
> >
>
http://www.pwg.org/hypermail/ipp/1637.html