IPP Mail Archive: IPP Mail Archive: RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset

IPP Mail Archive: RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset

Carl Kugler (kugler@us.ibm.com)
Wed, 11 Nov 1998 11:28:39 -0700

> RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
>
> Carl Kugler (kugler@us.ibm.com)
> Wed, 11 Nov 1998 10:39:23 -0700
> > RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
> >
> > Hastings, Tom N (hastings@cp10.es.xerox.com)
> > Wed, 11 Nov 1998 06:22:27 -0800
> >
> > How about saying that for the 'client-error-bad-request (bad syntax), that
> > the
> > IPP object doesn't return the "status-message" attribute, if supported,
> > since
> > this is a developer error. Then for bad syntax it doesn't matter what
> > charset
> > is returned in the bad syntax error response, since there aren't any 'text'
> > or 'name'
> > attributes in the error response. So may as well return the
> > "charset-configured"
> > on a bad syntax error response.
>
> 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
>

On the other hand, your proposal would allow removing the
"attributes-charset" operation attribute from responses, since it would
ALWAYS be the case that EITHER the "attributes-charset" of the response
matched that of the response, OR there is no text or name attribute in
the response. I propose these alternative resolutions:

1) Remove the "attributes-charset" response operation attribute,
since it is UNUSED.

2) Allow the "attributes-charset" of response to differ from that of
the request for:
client-error-bad-request (0x0400) and
client-error-charset-not-supported (0x040D)

2a) (Addressing Phil DeBecker's concern:) Allow the
"attributes-charset" of response to differ from that of the request for:
client-error-bad-request (0x0400),
client-error-charset-not-supported (0x040D),
server-error-operation-not-supported (0x0501),
server-error-version-not-supported (0x0503), and
server-error-internal-error (0x0500)

2b) (Simpler:) Allow the "attributes-charset" of response to differ
from that of the request for any 0x40X or 0x50X response.

1) is attractive because it would improve the efficiency of the
protocol. For small responses, such as errors, the savings would be a
large percentage of the message size (maybe 50% or more).

-Carl

"It is vain to do with more what can be done with less."
-- The principle of parsimony

> >
> > 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
>

http://www.pwg.org/hypermail/ipp/1641.html