Carl wrote:
> Hugo wrote:
> > Carl wrote:
> >
> > > Were these concerns discussed any further before Issue 1.19 was moved =
> > to=20
> > > the Approved Clarifications List and into the new Mod doc? If so, could
> > > someone point me to the discussion (I've been out of town for a while).
> > >
> > > -Carl
> >
> > I don't think we articulated a definite answer to this question. The =
> > desired behavior might not be far from what's currently documented but one =
> > or two clarifying statement may be necessary. To address the questions =
> > raised by Carl, I propose that:
> >
> > 1. The "attribute-charset" attribute be required to be the first operation =
> > attribute. [Same as currently documented]
> >
> > 2. A request (or response) containing more than one "attribute-character" =
> > attribute should be rejected. [As currently documented]
> >
> > 3. All responses use the same 'valid' "attribute-charset" received in the =
> > corresponding request (i.e., the first operation attribute, if supported) =
> > [Might need to be clarified in the current doc]
> >
> > 4. The IPP object should always attempt to retrieve the "attribute-charset=
> > " attribute from the request (i.e., the first operation attribute) even if =
> > it has detected errors with the version, operation, or request numbers, =
> > and use it in the response informing the error condition. [Needs to be =
> > clarified in the current doc]
> >
> > 5. Whenever an IPP object cannot obtain a 'valid' "attribute-charset" =
> > attribute from the request (because it gets a request without an "attribute=
> > -charset" attribute as the first operation attribute or because it's given =
> > an attribute set is doesn't support) the response should be given in the =
> > server's default charset. [Needs to be clarified in the current doc]
> >
> > 6. Reporting a duplicate "attribute-charset" attribute error does not =
> > take any precedence over reporting any other error condition. The IPP =
> > object should not need to parse the entire request first to make sure the =
> > "attribute-charset" attribute appears once and only once in the request. =
> > [Needs to be clarified in the current doc]
> >
> > Did I miss anything?
>> 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].
>
Oops! I knew that didn't look right. That sentence should say "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 "server-error-operation-not-supported (0x0501)".
> Also, MAY an IPP object use its default charset when generating a client-error-bad-request 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 section 16.3). The IPP application SHOULD NOT repeat the request without modifications.
>> Or must it press on according to case 4 above, and try to extract a valid charset from the request even in the face of syntax errors?
>> >
> > -Hugo
> >
> >
> >
> -Carl
>>> -----
> See the original message at http://www.egroups.com/list/ipp/?start=4822> --
> Free e-mail group hosting at http://www.eGroups.com/>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4826
--
Free e-mail group hosting at http://www.eGroups.com/