1634-0001
<!-- received="Tue Nov 10 11:53:45 1998 EST" -->
<!-- sent="Tue, 10 Nov 1998 11:52:59 -0500" -->
<!-- name="debecker@lexmark.com" -->
<!-- email="debecker@lexmark.com" -->
<!-- subject="Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset" -->
<!-- id="199811101655.AA00116@interlock2.lexmark.com" -->
<!-- inreplyto="RE: IPP> MOD> Issue 1.19 [REVISITED - charset" -->
<title>IPP Mail Archive: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset</title>
<h1>Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset</h1>
<i>debecker@lexmark.com</i><br>
<i>Tue, 10 Nov 1998 11:52:59 -0500</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#1634">[ date ]</a><a href="index.html#1634">[ thread ]</a><a href="subject.html#1634">[ subject ]</a><a href="author.html#1634">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="1635.html">Manros, Carl-Uno B: "IPP> FW: Last Call: Media Features for Display, Print, and Fax to Prop"</a>
<li> <b>Previous message:</b> <a href="1633.html">Erik Guttman: "IPP> Re: DIR - Revised text for SLP 'printer:' template - with updated comments"</a>
<!-- nextthread="start" -->
</ul>
<!-- body="start" -->
<i>>Is a message that specifies an operation that the server doesn't support a</i><br>
malformed request?<br>
<p>
Not necessarily - but it could be. Either way, at the point where we encounter<br>
the unsupported operation number, we've already determined that we can't handle<br>
the request. We should therefore immediately stop processing the request and<br>
respond with an 0x501 status code. At this point, worrying about charsets is<br>
not useful, and building logic into the printer to do so is a needless expense.<br>
We don't know why the operation number is invalid - it *could* be a well-formed<br>
request for something we don't support, or it could be garbage. We don't know,<br>
and we shouldn't concern ourselves with it. What we do know is that we received<br>
a request for an operation we don't support, and that's what we should tell the<br>
client - period. There's no need for the printer to supply a status message<br>
here; the status code is adequately informative, and the client is perfectly<br>
capable of informing the user of the error. Trying to parse a data stream that<br>
we already know we can't do anything useful with is a waste of time at best, and<br>
dangerous at worst.<br>
<p>
Phil DeBecker<br>
Lexmark International<br>
debecker@lexmark.com<br>
<!-- body="end" -->
<p>
<ul>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="1635.html">Manros, Carl-Uno B: "IPP> FW: Last Call: Media Features for Display, Print, and Fax to Prop"</a>
<li> <b>Previous message:</b> <a href="1633.html">Erik Guttman: "IPP> Re: DIR - Revised text for SLP 'printer:' template - with updated comments"</a>
<!-- nextthread="start" -->
</ul>