IPP Mail Archive: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset

Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset

Carl Kugler (kugler@us.ibm.com)
Wed, 11 Nov 1998 10:25:41 -0700

This is a multi-part message in MIME format.
--------------E68886B32D321F39F51E4129
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well said!

> Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
>
> debecker@lexmark.com
> Tue, 10 Nov 1998 11:52:59 -0500
>
> >Is a message that specifies an operation that the server doesn't support a
> malformed request?
>
> Not necessarily - but it could be. Either way, at the point where we encounter
> the unsupported operation number, we've already determined that we can't handle
> the request. We should therefore immediately stop processing the request and
> respond with an 0x501 status code. At this point, worrying about charsets is
> not useful, and building logic into the printer to do so is a needless expense.
> We don't know why the operation number is invalid - it *could* be a well-formed
> request for something we don't support, or it could be garbage. We don't know,
> and we shouldn't concern ourselves with it. What we do know is that we received
> a request for an operation we don't support, and that's what we should tell the
> client - period. There's no need for the printer to supply a status message
> here; the status code is adequately informative, and the client is perfectly
> capable of informing the user of the error. Trying to parse a data stream that
> we already know we can't do anything useful with is a waste of time at best, and
> dangerous at worst.
>
> Phil DeBecker
> Lexmark International
> debecker@lexmark.com
>

http://www.pwg.org/hypermail/ipp/1634.html
--------------E68886B32D321F39F51E4129
Content-Type: text/html; charset=us-ascii; name="1634.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="1634.html"
Content-Base: "http://www.pwg.org/hypermail/ipp/1634.
html"

<!-- 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&gt; MOD&gt; Issue 1.19 [REVISITED - charset" -->
<!-- id="199811101655.AA00116@interlock2.lexmark.com" -->
<!-- inreplyto="RE: IPP&gt; MOD&gt; Issue 1.19 [REVISITED - charset" -->
<title>IPP Mail Archive: Re: RE: IPP&gt; MOD&gt; Issue 1.19 [REVISITED - charset</title>
<h1>Re: RE: IPP&gt; MOD&gt; 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&gt; 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&gt; Re: DIR - Revised text for SLP 'printer:' template - with updated comments"</a>
<!-- nextthread="start" -->
</ul>
<!-- body="start" -->
<i>&gt;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&gt; 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&gt; Re: DIR - Revised text for SLP 'printer:' template - with updated comments"</a>
<!-- nextthread="start" -->
</ul>

--------------E68886B32D321F39F51E4129--