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].
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/