IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

Carl Kugler kugler at us.ibm.com
Fri Nov 6 19:27:26 EST 1998


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/



More information about the Ipp mailing list