IPP> MOD> Issue 1.19 [REVISITED - charset

IPP> MOD> Issue 1.19 [REVISITED - charset

IPP> MOD> Issue 1.19 [REVISITED - charset

Carl Kugler kugler at us.ibm.com
Mon Nov 9 14:29:11 EST 1998


Tom wrote:
> Your concern is why I proposed a SHOULD, not a MUST in the following:
> 

Okay.  It's just that the SHOULD makes me feel obligated to attempt it (endeavor to extract an attributes-charset from a malformed request), even though I don't think that's the wisest course in this case.  The "out", as you suggest, is to avoid sending text in the response.  However, I still need to put something in the response "attributes-charset".

> This error SHOULD take precedence over any other error, so 
> that the client
> will know that the returned charset is not the one 
> requested.  Therefore,
>  the IPP object SHOULD endeavor to determine the "attribute-charset"
>  operation attribute in the request.  Of course, if the 
> syntax of the request
>  is so bad that the IPP object cannot find the 
> "attributes-charset", then the
>  IPP object has no choice but to return the 
> 'client-error-bad-syntax' status
>  code.
> 
> NOTE: that if you don't support the "status-message" operation attribute in
> responses, then you can simply bail out when you find the syntax error as
> you prefer, since your response will not contain any 'name' or 'text'
> attributes.
> 
> Maybe we need to add this above NOTE to the Implementers Guide?
> 
> Tom
> 


-----
See the original message at http://www.egroups.com/list/ipp/?start=4840
--
Free e-mail group hosting at http://www.eGroups.com/



More information about the Ipp mailing list