IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

IPP> MOD> Issue 1.19

Carl Kugler kugler at us.ibm.com
Mon Nov 9 12:10:58 EST 1998


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/



More information about the Ipp mailing list