> RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
> >
> > Carl Kugler (kugler at us.ibm.com)
> > Wed, 11 Nov 1998 10:39:23 -0700
> > > RE: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
> > >
> > > Hastings, Tom N (hastings at 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.
Clarification: For this proposed alternative: If the response includes any 'text' or 'name' attributes, they MUST be encoded using the charset specified in the "attributes-charset" operation attribute of the request. (If the "attributes-charset" of the request is unsupported, missing, or is otherwise unknown, the response MUST NOT include any 'text' or 'name' attributes.)
>> 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.
Clarification: that should really say: "any 0x4XX or 0x5XX 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).
(Depending partly on the outcome of the NLO debate.)
>>> -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 at us.ibm.com]
> > > >Sent: Monday, November 09, 1998 16:38
> > > >To: ipp at 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>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4869